Dear all,
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 SIP 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"?
For me, logically, "ring_time_limit" should control the time how long the device should ring before issuing time out reply by itself, and "max_response_time_invite" how long to wait before call is established. It is how I interpret the meaning of the parameters names.
In this situation, the device will send the CANCEL after 20 sec (max_response_time_invite) all the time.
Cheers, Daniel
Arek Bekiersz wrote:
Dear all,
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 SIP 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"?
-
Arek Bekiersz -
Daniel-Constantin Mierla