Hello,
I'm trying to create a scenarion which was very simple with Kamailio 1.x, but seems impossible with sr3.0. I need to do failover for INVITE's and also limit the call setup time per-branch, so I defined the problem in 2 parts that need to work separately, but also combined into 1 proxy.
1) Fast failover.
After t_relay, the destination should be tried for max 2 sec per host. No maximum for the whole set. Thus, if a destination has 4 SRV records, and each host fails after 2 secs, a 408 will be sent back after a total of 8 secs. If a (proivisional) response arrives within 2 sec, a 408 MUST NOT be sent.
The exact value of the timer should be configurable per t_relay call.
In kamailio this is accomplished by setting the fr_timer(_avp) to 2000ms. In sr3.0 I have yet to find a combination of timer settings that work.
2) Call setup duration.
If a destination host returns a response, I want to limit the attempt to 80 secs (default, should be configurable per t_relay call) of ringing/progress/whatever. After that a failure route will take care to route to a different destination, at this time this timer should be restarted. At no other time after the _first_ provisional reponse after the t_relay call should the timer be restarted.
In Kamailio this was accomplished by just setting fr_inv_timer(_avp) to the desired value before t_relay(). In sr3.0 this timer will be restarted after additional provisional responses and will not be resetted after a new t_relay call (from failure_route).
Any suggestions on how to get the desired behaviours are welcomed (at the moment scenario 1 is more important than 2).
Am 26.03.2010 16:42, schrieb Alex Hermann:
In sr3.0 this timer will be restarted after additional provisional responses
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#re...
???
regards klaus
On Friday 26 March 2010, Klaus Darilion wrote:
Am 26.03.2010 16:42, schrieb Alex Hermann:
In sr3.0 this timer will be restarted after additional provisional responses
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#r estart_fr_on_each_reply
And exactly under that uri is mentioned: "If not set, the fr_inv_timer will be restarted only for the first provisional replies and for increasing replies greater or equal 180"
So it is impossible to stop the timer from resetting at all. But this is just a minor issue, the others are more important.
On Mar 26, 2010 at 16:56, Alex Hermann alex@speakup.nl wrote:
On Friday 26 March 2010, Klaus Darilion wrote:
Am 26.03.2010 16:42, schrieb Alex Hermann:
In sr3.0 this timer will be restarted after additional provisional responses
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#r estart_fr_on_each_reply
And exactly under that uri is mentioned: "If not set, the fr_inv_timer will be restarted only for the first provisional replies and for increasing replies greater or equal 180"
So it is impossible to stop the timer from resetting at all. But this is just a minor issue, the others are more important.
The idea was to avoid restarts by retransmissions of the same reply (e.g. phones that retransmits 180), but still allow an extension of the branch lifetime if the phone sends another provisional reply, not seen before. E.g. 180, 180, 180 will re-start the timer only for the first 180. 180, 180, 181, 181, 182 will re-start the timer 3 timers: for the first 180, for the first 181 and for the first 182. Note that K 1.5 and older had exactly the same behaviour (and same default) in this case (the code is inherited from ancient ser versions.)
In all the cases (restart on or off) you can still limit the total invite lifetime (see max_inv_lifetime).
Anyway it would be trivial to add another setting for restarting fr_inv only once, if it's really needed.
Andrei
On Friday 26 March 2010, Alex Hermann wrote:
- Fast failover.
After t_relay, the destination should be tried for max 2 sec per host. No maximum for the whole set. Thus, if a destination has 4 SRV records, and each host fails after 2 secs, a 408 will be sent back after a total of 8 secs. If a (proivisional) response arrives within 2 sec, a 408 MUST NOT be sent.
What I have now is when I set fr_timer to 2 secs, I always get a 408 if the 1st host id down, even if I receive a response from the 2nd host in the SRV.
It seems at least part 1 is due to a misunderstanding on my part of the branch selection for the final reply. I have filed my request to change this (imho unlogical) behaviour under #54 in the tracker.
On Mar 26, 2010 at 16:42, Alex Hermann alex@speakup.nl wrote:
Hello,
I'm trying to create a scenarion which was very simple with Kamailio 1.x, but seems impossible with sr3.0. I need to do failover for INVITE's and also limit the call setup time per-branch, so I defined the problem in 2 parts that need to work separately, but also combined into 1 proxy.
- Fast failover.
After t_relay, the destination should be tried for max 2 sec per host. No maximum for the whole set. Thus, if a destination has 4 SRV records, and each host fails after 2 secs, a 408 will be sent back after a total of 8 secs. If a (proivisional) response arrives within 2 sec, a 408 MUST NOT be sent.
The exact value of the timer should be configurable per t_relay call.
In kamailio this is accomplished by setting the fr_timer(_avp) to 2000ms. In sr3.0 I have yet to find a combination of timer settings that work.
fr_timer_avp and fr_inv_timer_avp work in sr too, but note that they are obsoleted (they are kept only for backwards compatibility). The preferred way is using t_set_fr(....), t_reset_fr(...) a.s.o. They can be called even after t_relay() and they still work. They can also be called from branch routers, or reply routes. You should also have a look at max_inv_lifetime and max_noninv_lifetime if you want to limit the total dns failover time.
See: http://sip-router.org/wiki/ref_manual/timers (probably the most complete timers doc). http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#fr...
Andrei
-
Alex Hermann -
Andrei Pelinescu-Onciul -
Klaus Darilion