Taisto,
Thanks, I understand the scenario in question now. Help someone.
I think perhaps new Proxy requests *DNS iteration*, even recursive
requests from retargetting match the same 'response context' which is
running the same stateful proxy C timer (?). This timer is reset not on 1xx
but 101-199 provisional responses (distinction).
- Wayne
Thread follows:
********************************************************
Hi Wayne,
Thanks for your reply, but I we're not really taking about the same
scenario.
First of all, the failure I am talking about, is defined in 3263,
when a proxy has attempted to forward a request to the next hop,
with the help of dns information.
If that "fails" according to the definition in 3263, we make a new
attempt, to the next possible destination given by the dns info, and
this new attempt is given a new branch-parameters, so I'd say its a
new txn.
Now the UAC is not a problem, since my proxy is txn-stateful, so its
already sent a 100 Trying and stopped both retransmissions of the INVITE,
aswell as any possibility for the UAC to have a timer B pop.
(since it only pops in calling-state, not after receiving 1xx, so we can
stay in proceeding in-definitely if understand things correctly)
((Additionally, according to my understanding, when/if the Timer B pops
in))
((the UAC, since we havent got a single 1xx we are not allowed to send))
((CANCEL))
This means the proxy is free to try to go though all the possible next-hop
destinations the dns is listing, retrying and re-creating new txns
everytime
the INVITE's timer B fires....until we get a 1xx or run out of next-hops
in the dns-result.
And resetting the timer c every new attempt would make sure it cannot
fire until I have got a 1xx and stopped retrying.
So the text in 16.8:
"If the client transaction has not received a provisional response",
seems impossible with normal timer-values, and thats why I am wondering
wether I've missunderstood the Timer C reset scenarios. The only time
the rfc says RESET timer C, is on reception of 1xx, but at the same time
we have "Timer C MUST be set for each client transaction when an INVITE
request is proxied", which is quite strong...
/TQ
[EMAIL PROTECTED] wrote:
>
>
>
> Taisto,
> No guru here but will try a response to your query.
>
> My understanding is the proxy will set timer C for each 'request'.
> Now for an INVITE over UDP if the UAC does not received a provisional
> response before T1 fires it will retransmit the request, so whether you
> view that as 'resetting' timer C for the original request OR setting
timer
> C for the new request the net effect is the same.
>
> I am in doubt about the above as a response because you have
> referenced 3263 - Locating SIP Servers and I am not sure what failure
> scenario in this RFC you are referring to ?. You mention the transaction
> timing out after 32sec, so if we stay with INVITE - timer B, then the UAC
> will send a CANCEL request which the proxy will process. In processing
the
> CANCEL for the INVITE the proxy will clear the state including any
pending
> timers - (the CANCEL request is handled independently).
>
> If say the UAC was so despondent about not getting an answer he
> pulled his phone from the wall the Proxy timer C (>3min) would fire and
it
> will clear the INVITE transaction including sending it's own CANCELs
> downstream if it had received provisional responses.
>
> So it should not be possible for timer C to continue to be
extended.
> I hope I am close to the mark.
>
> - Wayne
>
> Taisto asked:
> ***************************************************
>
> Greetings gurus,
>
> I've been going working on a proxy for while now, and am currently
> staring to look at timer C handling.
>
> The short version: Should I reset timer C when I create a new txn,
> on a failure scenario(according to 3263)?
>
> Longer version:
>
> I've become a bit puzzled on what I should do in a failure scenario,
> matching the one described in 3263, which causes me to create a new
> transaction and make a second (Nth) attempt.
>
> My question arose since timer C is supposed to started be "per
> transaction",
> and this would lead me to assume that I would reset the timer for every
> attempt, since each attempt has a new branch => new txn.
>
> But if I do that, then one of the scenarios in 16.8 (below) becomes,
> at least with default timer values, impossible.
> Since timer C is 3 minutes, and every time i get a failure I create a
> new txn, which resets the timer. And failure occurs if txn times out
> which normally happens after just 32 secs.
>
> Then timer C should never be able to fire, because we'd keep creating
> new txns, and resetting the timer all the time?
>
> And since the rule about interpreting this case as a 408 is so clear,
> i was wondering wether I am resetting timer C when I shouldnt..
>
> Regards
> Taisto Qvist
> Network Architect.
>
>
> --
> 16.8 Processing Timer C
>
> If timer C should fire, the proxy MUST either reset the timer with
> any value it chooses, or terminate the client transaction. If the
> client transaction has received a provisional response, the proxy
> MUST generate a CANCEL request matching that transaction. If the
> client transaction has not received a provisional response, the
proxy
> MUST behave as if the transaction received a 408 (Request Timeout)
> response.
> --
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
> **********************************************************************
> Any personal or sensitive information contained in this email and
> attachments must be handled in accordance with the Victorian Information
> Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
> (Commonwealth), as applicable.
>
> This email, including all attachments, is confidential. If you are not
the
> intended recipient, you must not disclose, distribute, copy or use the
> information contained in this email or attachments. Any confidentiality
or
> privilege is not waived or lost because this email has been sent to you
in
> error. If you have received it in error, please let us know by reply
> email, delete it from your system and destroy any copies.
> **********************************************************************
>
>
--
____________________________________
Taisto Qvist
IP-Solutions AB
Bellmansgatan 30
118 47 Stockholm
Fixed/PSTN: +46 (0)8 615 08 60
Mobile: +46 (0)708 88 02 63
Mailto: [EMAIL PROTECTED]
SIP: [EMAIL PROTECTED]
Web IPv4: http://www.ip-solutions.se/
Web IPv6: http://www.ip-solutions.se/
Fax: +46 (0)8 442 09 67
____________________________________
*PLEASE DO NOT SEND HTML-FORMATTED MAIL*
**********************************************************************
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.
This email, including all attachments, is confidential. If you are not the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments. Any confidentiality or
privilege is not waived or lost because this email has been sent to you in
error. If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**********************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
