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/075497.html I guess this is still the way to go? Thanks,/Tobias

From: the_fx@hotmail.com To: sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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_lifeti...

-- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users