9 Oct
2014
9 Oct
'14
10:29 p.m.
Dear Kamailio users,
I have an issue with some upstream carriers quickly replying with 100 Trying but then
basically times out.
I'm looking for a good solution to distinguish between the 100 reply and any other
replies, and alter the timeout values. My goal is to be able to re-route calls where the
180/183 is not received within a few seconds, and if the 180/183 is received I'd like
to give the call a much longer timeout.
I realize there is a "fr_inv_timer" that would do this, but I would not like to
set that to low since I fear it would affect many other call types, i.e. if a carrier
would send 183 once but for some reason does not resend on regular intervals.
I'm on Kamailio 4.1 and my current settings are:fr_timer : 2000fr_inv_timer :
120000restart_fr_on_each_reply : 1
The only solution I can think of is to update the fr_inv_timer in an on_reply-route if the
reply code is 180/183 but I'm not sure that would even work? Is that the way to go or
is there another way?
Thanks in advance!/Tobias
9 Oct
9 Oct
11:18 p.m.
Hi again,
Maybe I was to quick on my previous mail, after some more searching I found a very similar
question:http://lists.sip-router.org/pipermail/sr-users/2012-November/07549…
I guess this is still the way to go?
Thanks,/Tobias
From: the_fx(a)hotmail.com
To: sr-users(a)lists.sip-router.org
Date: Thu, 9 Oct 2014 21:29:30 +0200
Subject: [SR-Users] Best way to handle 100 but no 180/183?
Dear Kamailio users,
I have an issue with some upstream carriers quickly replying with 100 Trying but then
basically times out.
I'm looking for a good solution to distinguish between the 100 reply and any other
replies, and alter the timeout values. My goal is to be able to re-route calls where the
180/183 is not received within a few seconds, and if the 180/183 is received I'd like
to give the call a much longer timeout.
I realize there is a "fr_inv_timer" that would do this, but I would not like to
set that to low since I fear it would affect many other call types, i.e. if a carrier
would send 183 once but for some reason does not resend on regular intervals.
I'm on Kamailio 4.1 and my current settings are:fr_timer : 2000fr_inv_timer :
120000restart_fr_on_each_reply : 1
The only solution I can think of is to update the fr_inv_timer in an on_reply-route if the
reply code is 180/183 but I'm not sure that would even work? Is that the way to go or
is there another way?
Thanks in advance!/Tobias
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:21 p.m.
Hello,
you can play with t_set_fr() in an onreply_route[x] block for the invite
transaction:
- http://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_set_fr
Cheers,
Daniel
On 09/10/14 21:29, Tobias wrote:
Dear Kamailio users,
I have an issue with some upstream carriers quickly replying with 100
Trying but then basically times out.
I'm looking for a good solution to distinguish between the 100 reply
and any other replies, and alter the timeout values. My goal is to be
able to re-route calls where the 180/183 is not received within a few
seconds, and if the 180/183 is received I'd like to give the call a
much longer timeout.
I realize there is a "fr_inv_timer" that would do this, but I would
not like to set that to low since I fear it would affect many other
call types, i.e. if a carrier would send 183 once but for some reason
does not resend on regular intervals.
I'm on Kamailio 4.1 and my current settings are:
fr_timer : 2000
fr_inv_timer : 120000
restart_fr_on_each_reply : 1
The only solution I can think of is to update the fr_inv_timer in an
on_reply-route if the reply code is 180/183 but I'm not sure that
would even work? Is that the way to go or is there another way?
Thanks in advance!
/Tobias
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
11:36 p.m.
Hello Tobias,
fr_inv_timer won't do much for you, because it deals only with final
replies (>= 200) to the INVITE transaction. 1xx replies are all
provisional in nature.
Thus, the nature of the problem is such that if you've received a 100
Trying, you've already dampened fr_timer, but the only other TM timer at
your immediate disposal is fr_inv_timer, which is fired when a final
reply, positive or negative, is not received within the specified time.
That's the only built-in timing granularity that TM provides for the
life cycle of an initial INVITE transaction.
As you surmised and Daniel confirmed, your only solution is to "hack"
around this by using a really low fr_inv_timer value. If you want, for
example, your total PDD for any given vendor to not exceed 10s, then you
can set fr_inv_timer to 10s. If you have received a non-100 1xx response
(e.g. 18x) in the meantime, you can t_set_fr() the fr_inv_timeout to the
more logical 120s or whatever.
Note that fr_inv_timeout/t_set_fr() are per-branch. If you want to
impose such lifetimes for the whole transaction, irrespectively of
branch, you might also want to check out:
http://kamailio.org/docs/modules/4.1.x/modules/tm.html#max_inv_lifetime
http://kamailio.org/docs/modules/4.1.x/modules/tm.html#tm.f.t_set_max_lifet…
-- Alex
On 10/09/2014 03:29 PM, Tobias wrote:
Dear Kamailio users,
I have an issue with some upstream carriers quickly replying with 100
Trying but then basically times out.
I'm looking for a good solution to distinguish between the 100 reply and
any other replies, and alter the timeout values. My goal is to be able
to re-route calls where the 180/183 is not received within a few
seconds, and if the 180/183 is received I'd like to give the call a much
longer timeout.
I realize there is a "fr_inv_timer" that would do this, but I would not
like to set that to low since I fear it would affect many other call
types, i.e. if a carrier would send 183 once but for some reason does
not resend on regular intervals.
I'm on Kamailio 4.1 and my current settings are:
fr_timer : 2000
fr_inv_timer : 120000
restart_fr_on_each_reply : 1
The only solution I can think of is to update the fr_inv_timer in an
on_reply-route if the reply code is 180/183 but I'm not sure that would
even work? Is that the way to go or is there another way?
Thanks in advance!
/Tobias
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
11:45 p.m.
Hi Alex, Daniel,
Crystal clear, thanks for your help! Time to dive into the config.
/Tobias
Date: Thu, 9 Oct 2014 16:36:02 -0400
From: abalashov(a)evaristesys.com
To: sr-users(a)lists.sip-router.org
Subject: Re: [SR-Users] Best way to handle 100 but no 180/183?
Hello Tobias,
fr_inv_timer won't do much for you, because it deals only with final
replies (>= 200) to the INVITE transaction. 1xx replies are all
provisional in nature.
Thus, the nature of the problem is such that if you've received a 100
Trying, you've already dampened fr_timer, but the only other TM timer at
your immediate disposal is fr_inv_timer, which is fired when a final
reply, positive or negative, is not received within the specified time.
That's the only built-in timing granularity that TM provides for the
life cycle of an initial INVITE transaction.
As you surmised and Daniel confirmed, your only solution is to "hack"
around this by using a really low fr_inv_timer value. If you want, for
example, your total PDD for any given vendor to not exceed 10s, then you
can set fr_inv_timer to 10s. If you have received a non-100 1xx response
(e.g. 18x) in the meantime, you can t_set_fr() the fr_inv_timeout to the
more logical 120s or whatever.
Note that fr_inv_timeout/t_set_fr() are per-branch. If you want to
impose such lifetimes for the whole transaction, irrespectively of
branch, you might also want to check out:
http://kamailio.org/docs/modules/4.1.x/modules/tm.html#max_inv_lifetime
http://kamailio.org/docs/modules/4.1.x/modules/tm.html#tm.f.t_set_max_lifet…
-- Alex
On 10/09/2014 03:29 PM, Tobias wrote:
Dear Kamailio users,
I have an issue with some upstream carriers quickly replying with 100
Trying but then basically times out.
I'm looking for a good solution to distinguish between the 100 reply and
any other replies, and alter the timeout values. My goal is to be able
to re-route calls where the 180/183 is not received within a few
seconds, and if the 180/183 is received I'd like to give the call a much
longer timeout.
I realize there is a "fr_inv_timer" that would do this, but I would not
like to set that to low since I fear it would affect many other call
types, i.e. if a carrier would send 183 once but for some reason does
not resend on regular intervals.
I'm on Kamailio 4.1 and my current settings are:
fr_timer : 2000
fr_inv_timer : 120000
restart_fr_on_each_reply : 1
The only solution I can think of is to update the fr_inv_timer in an
on_reply-route if the reply code is 180/183 but I'm not sure that would
even work? Is that the way to go or is there another way?
Thanks in advance!
/Tobias
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3703
days inactive
3703
days old
4 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Tobias