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.
**********************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
