[Serusers] INVITE transaction timer vs. 'Proceeding' timer

[Klaus Darilion]

Nils Ohlmeier wrote:
...

> In my opinion an UA should never send a CANCEL without user interaction.

IMO sending cancel e.g. after 5 minutes is fine.
IMO also the called SIP client should stop ringing if it does not 
receive a CANCEL after some while. (If the CANCEL is lost somewhere, my 
Cisco phone will continue to ring several hours :-( )

regards
klaus

> 
>   Nils
> 
> On Wednesday 25 January 2006 12:11, Arek Bekiersz wrote:
> 
>>Hello,
>>
>>
>>This time I've got a question :)
>>I think it will be useful for everybody.
>>
>>
>>I have discussion with SIP device manufacturer about expiration time of
>>call attempt. When call is made from UA it sends INVITE with "Expires:
>>65". It is controlled by device's timer setting "ring_time_limit". This
>>timer can be set to anything between 10 and 600 seconds, we set it to 65
>>seconds. Fine.
>>
>>However at the same time it starts a special timer, say
>>"max_response_time_invite". It can be set to anything between 8 and 20
>>seconds. We set it to 20 sec. Fine so far.
>>
>>
>>CASE 1: Imagine we call from UA to PSTN number, using one of VoIP->PSTN
>>providers. We have more than one provider, so we setup SER with
>>"fr_timer" value of, let's say 25 seconds and "fr_inv_timer" of 60. We
>>prepare failure routes in case when those timers hits in PSTN call. When
>>"fr_timer" hits, we simply reroute to another gateway. Great.
>>
>>SER forwards INVITE from UA to remote PSTN gateway and at the same time
>>sends back "100 Trying" to UA. Fine.
>>
>>Imagine now that it is busy-hour and it takes PSTN provider 21 seconds
>>to send back "180 Ringing" (or "183 Session Progress") and after 8
>>seconds more remote callee picks up ("200 OK").
>>
>>Unfortunately device wil send CANCEL to SER, because it hasn't received
>>"180 Ringing" or "183 Session Progress" within the
>>"max_response_time_invite" setting of 20 seconds. It only received "100
>>Trying" at the beginning.
>>This ruined any failure route attempts from SER, as call failed.
>>
>>
>>
>>CASE 2: Imagine now a second call. This time PSTN provider send "183
>>Session Progress" after 14 seconds and remote callee picked up after
>>further 15 seconds. This time everything went good. UA did not hit
>>"max_response_time_invite" timer - it waited patiently for whole 29
>>seconds for remote callee to pick up.
>>
>>I think that when UA receives provisional response (like "100 Trying")
>>from SER it should stop timer "max_response_time_invite" and use
>>'ring_time_limit'. What device does now, it uses:
>>
>>* "max_response_time_invite" when "100 Trying" received
>>* "ring_time_limit" when "180 Ringing" or "183 Session Progress" received
>>
>>
>>I haven't really found explanation of this in RFC3261. When you look at
>>state machine on page 128, it is not explicitly said which timer
>>controls behaviour of UA when in "Proceeding" state ("Proceeding" is
>>entered oin receipt of ANY provisional response).
>>
>>QUESTION 1: what timer controls behaviour of UA when in "Proceeding"
>>state? Especially regarding timeout. Is this still the 'timer B' started
>>at the beginning of INVITE transaction? If it is 'timer B', why UA is
>>CANCELing transaction after 20 seconds, if it informed by "Expires: 65"
>>field in INVITE that it set 'timer B' to 65 seconds.
>>
>>
>>QUESTION 2: What should I propose to manufacturer for maximum value for
>>"max_response_time_invite"? Something like 120 seconds ?
> 
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
>