25 Jan
2006
25 Jan
'06
1:11 p.m.
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 ?
--
Thanks,
Arek Bekiersz
25 Jan
25 Jan
1:52 p.m.
Arek,
As for the timer for Case 1 (I think you lose me on Case 2 ;) ), we use a
scenario where we re-set the INV timer to a longer value using AVPs if we're
going to end up forwarding the call to a different machine. One reason is that
we can't be certain that the new machine will respond quickly and another is
that some people prefer to have their own home voicemail pick up instead of
our voicemail.
In the beginning of the ser.cfg, I have:
modparam("tm", "fr_inv_timer_avp", "inv_timeout")
Then, down in the ser.cfg where I do a forward, I use AVPops to set the timer:
# Now set the timeout to 45 seconds (write the integer
# 45 to the avp inv_timeout (see the earlier modparam)
avp_write("i:45","inv_timeout");
That's the simplest way of handling varying levels of timeouts...
N.
On Wed, 25 Jan 2006 12:11:49 +0100, 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 ?
--
Thanks,
Arek Bekiersz
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:36 p.m.
Hi,
regarding case 1: I never understood why some vendors do put timeouts to the
Proceeding state. It is simply up to the user how long he wants to try to
reach the other party. And if the UA did not received a 18x response yet the
user should hopefully hear nothing, so he will most likely give up very soon.
In my opinion an UA should never send a CANCEL without user interaction.
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 ?
26 Jan
26 Jan
9:07 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6876
days inactive
6877
days old
3 comments
4 participants
participants (4)
-
Arek Bekiersz -
Klaus Darilion -
Nils Ohlmeier -
sip