According to the 1.5.x TM module documentation, DNS failover is triggered by a 503 reply or a timeout.
When using SRV records, it appears a 503 triggers the failure_route instead.
Given:
host -t srv _sip._udp.voip.example.net _sip._udp.voip.example.net has SRV record 1 0 5060 fast-server.example.net. _sip._udp.voip.example.net has SRV record 2 0 5060 slow-server.example.net.
On an invite to voip.example.net, if fast-server does not respond within "fr_timer" seconds, t_relay fires off a serial branch (t_on_branch is triggered) and the invite goes to slow-server.
If fast-server responds with a 503, the t_on_failure route is triggered instead, and the invite is not sent on to slow-server.
If its not a bug in the module, does anyone have clues of how to coax the next DNS SRV record out of the t_on_failure route? Or what can be done to get t_relay to consume the 503?
Thanks!
Hello,
On 12/10/09 5:29 AM, Nathan Angelacos wrote:
According to the 1.5.x TM module documentation, DNS failover is triggered by a 503 reply or a timeout.
When using SRV records, it appears a 503 triggers the failure_route instead.
Given:
host -t srv _sip._udp.voip.example.net _sip._udp.voip.example.net has SRV record 1 0 5060 fast-server.example.net. _sip._udp.voip.example.net has SRV record 2 0 5060 slow-server.example.net.
On an invite to voip.example.net, if fast-server does not respond within "fr_timer" seconds, t_relay fires off a serial branch (t_on_branch is triggered) and the invite goes to slow-server.
If fast-server responds with a 503, the t_on_failure route is triggered instead, and the invite is not sent on to slow-server.
If its not a bug in the module, does anyone have clues of how to coax the next DNS SRV record out of the t_on_failure route? Or what can be done to get t_relay to consume the 503?
does the 503 reply include a retry-after header?
Cheers, Daniel
El Jueves, 10 de Diciembre de 2009, Daniel-Constantin Mierla escribió:
does the 503 reply include a retry-after header?
Does Kamailio behaviour depends on that header? If so IMHO it's not correct.
I've joined long discussions in sip-implementors about 503 with/without Retry-After header. Some people think that a 503 without this header must be considered as a 500. But after discussions this assumption is not correct and a 503 must be considered similary even if it doesn't contain this header.
BTW RFC 3263 (Locating SIP Servers) says nothing about 500 error, neither about Retry-After header in 503 replies. It considers a 503 with/without Retry-After in same way.
IMHO Kamailio/SR should consider Retry-After just as informative but never change the routing/failover behavior based on it.
Regards.
Iñaki Baz Castillo wrote:
El Jueves, 10 de Diciembre de 2009, Daniel-Constantin Mierla escribió:
does the 503 reply include a retry-after header?
Does Kamailio behaviour depends on that header? If so IMHO it's not correct.
I've joined long discussions in sip-implementors about 503 with/without Retry-After header. Some people think that a 503 without this header must be considered as a 500. But after discussions this assumption is not correct and a 503 must be considered similary even if it doesn't contain this header.
BTW RFC 3263 (Locating SIP Servers) says nothing about 500 error, neither about Retry-After header in 503 replies. It considers a 503 with/without Retry-After in same way.
IMHO Kamailio/SR should consider Retry-After just as informative but never change the routing/failover behavior based on it.
Regards.
Thanks for that background info.
Personally I don't care which way it goes, as long as its documented. So that google will find this next time:
FWIW... Kamailio 1.5.3 follows 3261 21.5.4, even if it is confusing[1].
But [2] mentions that OpenSER 1.1.x was "RFC 3263" compliant - which treats Retry-After as informational in section 4.3.
----- [1] https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-April/012532.h...
[2] http://www.kamailio.org/mos/view/OpenSER-v1.1.x-Release-Notes/
On 12/10/09 3:02 PM, Iñaki Baz Castillo wrote:
El Jueves, 10 de Diciembre de 2009, Daniel-Constantin Mierla escribió:
does the 503 reply include a retry-after header?
Does Kamailio behaviour depends on that header?
yes, this is what I can tell from sources. Personally, I haven't used it so far, therefore I haven't checked the specks.
The new tm, for K 3.0, does not have it.
Cheers, Daniel
If so IMHO it's not correct.
I've joined long discussions in sip-implementors about 503 with/without Retry-After header. Some people think that a 503 without this header must be considered as a 500. But after discussions this assumption is not correct and a 503 must be considered similary even if it doesn't contain this header.
BTW RFC 3263 (Locating SIP Servers) says nothing about 500 error, neither about Retry-After header in 503 replies. It considers a 503 with/without Retry-After in same way.
IMHO Kamailio/SR should consider Retry-After just as informative but never change the routing/failover behavior based on it.
Regards.
Daniel-Constantin Mierla wrote:
Hello,
On 12/10/09 5:29 AM, Nathan Angelacos wrote:
According to the 1.5.x TM module documentation, DNS failover is triggered by a 503 reply or a timeout.
When using SRV records, it appears a 503 triggers the failure_route instead.
Given:
host -t srv _sip._udp.voip.example.net _sip._udp.voip.example.net has SRV record 1 0 5060 fast-server.example.net. _sip._udp.voip.example.net has SRV record 2 0 5060 slow-server.example.net.
On an invite to voip.example.net, if fast-server does not respond within "fr_timer" seconds, t_relay fires off a serial branch (t_on_branch is triggered) and the invite goes to slow-server.
If fast-server responds with a 503, the t_on_failure route is triggered instead, and the invite is not sent on to slow-server.
If its not a bug in the module, does anyone have clues of how to coax the next DNS SRV record out of the t_on_failure route? Or what can be done to get t_relay to consume the 503?
does the 503 reply include a retry-after header?
It did not. Adding one generates the expected results. Thanks!
(Now to convince the customer to add the header - "It worked before with the other provider...")
On 12/10/09 5:49 PM, Nathan Angelacos wrote:
Daniel-Constantin Mierla wrote:
Hello,
On 12/10/09 5:29 AM, Nathan Angelacos wrote:
According to the 1.5.x TM module documentation, DNS failover is triggered by a 503 reply or a timeout.
When using SRV records, it appears a 503 triggers the failure_route instead.
Given:
host -t srv _sip._udp.voip.example.net _sip._udp.voip.example.net has SRV record 1 0 5060 fast-server.example.net. _sip._udp.voip.example.net has SRV record 2 0 5060 slow-server.example.net.
On an invite to voip.example.net, if fast-server does not respond within "fr_timer" seconds, t_relay fires off a serial branch (t_on_branch is triggered) and the invite goes to slow-server.
If fast-server responds with a 503, the t_on_failure route is triggered instead, and the invite is not sent on to slow-server.
If its not a bug in the module, does anyone have clues of how to coax the next DNS SRV record out of the t_on_failure route? Or what can be done to get t_relay to consume the 503?
does the 503 reply include a retry-after header?
It did not. Adding one generates the expected results. Thanks!
(Now to convince the customer to add the header - "It worked before with the other provider...")
then maybe is easier to patch kamailio 1.5. Look in modules/tm/t_reply.c
At line 708, replace:
/* is the Retry-After header present (if present, * it should be already parsed) */ hdr = t->uac[picked_branch].reply->headers; for( ; hdr ; hdr=hdr->next) if (hdr->type==HDR_RETRY_AFTER_T) return 1; return 0;
with:
return 1;
Cheers, Daniel
Daniel-Constantin Mierla wrote:
On 12/10/09 5:49 PM, Nathan Angelacos wrote:
Daniel-Constantin Mierla wrote:
Hello,
On 12/10/09 5:29 AM, Nathan Angelacos wrote:
According to the 1.5.x TM module documentation, DNS failover is triggered by a 503 reply or a timeout.
When using SRV records, it appears a 503 triggers the failure_route instead.
Given:
host -t srv _sip._udp.voip.example.net _sip._udp.voip.example.net has SRV record 1 0 5060 fast-server.example.net. _sip._udp.voip.example.net has SRV record 2 0 5060 slow-server.example.net.
On an invite to voip.example.net, if fast-server does not respond within "fr_timer" seconds, t_relay fires off a serial branch (t_on_branch is triggered) and the invite goes to slow-server.
If fast-server responds with a 503, the t_on_failure route is triggered instead, and the invite is not sent on to slow-server.
If its not a bug in the module, does anyone have clues of how to coax the next DNS SRV record out of the t_on_failure route? Or what can be done to get t_relay to consume the 503?
does the 503 reply include a retry-after header?
It did not. Adding one generates the expected results. Thanks!
(Now to convince the customer to add the header - "It worked before with the other provider...")
then maybe is easier to patch kamailio 1.5. Look in modules/tm/t_reply.c
At line 708, replace:
/* is the Retry-After header present (if present, * it should be already parsed) */ hdr = t->uac[picked_branch].reply->headers; for( ; hdr ; hdr=hdr->next) if (hdr->type==HDR_RETRY_AFTER_T) return 1; return 0;with:
return 1;
Thanks!
I'm still a newbie... I really appreciate your patience and help.
Thanks for checking the 3.0 code as well. Good to know that we could try to wait for it as well.
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Nathan Angelacos