9 Dec
2009
9 Dec
'09
11:29 p.m.
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!
10 Dec
10 Dec
6:46 a.m.
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
--
Daniel-Constantin Mierla
* http://www.asipto.com/
9:02 a.m.
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 <ibc(a)aliax.net>
12:08 p.m.
New subject: [Kamailio-Users] Question regarding TM module DNS failover with SRV records
Iñaki Baz Castillo wrote:
El Jueves, 10 de Diciembre de 2009, Daniel-Constantin
Mierla escribió:
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.…
[2] http://www.kamailio.org/mos/view/OpenSER-v1.1.x-Release-Notes/
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.
12:29 p.m.
New subject: [Kamailio-Users] Question regarding TM module DNS failover with SRV records
On 12/10/09 3:02 PM, Iñaki Baz Castillo wrote:
El Jueves, 10 de Diciembre de 2009, Daniel-Constantin
Mierla escribió:
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
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.
--
Daniel-Constantin Mierla
* http://www.asipto.com/
11:49 a.m.
Daniel-Constantin Mierla wrote:
Hello,
On 12/10/09 5:29 AM, Nathan Angelacos wrote:
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...")
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?
12:32 p.m.
On 12/10/09 5:49 PM, Nathan Angelacos wrote:
Daniel-Constantin Mierla wrote:
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
* http://www.asipto.com/
Hello,
On 12/10/09 5:29 AM, Nathan Angelacos wrote:
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...")
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?
12:49 p.m.
Daniel-Constantin Mierla wrote:
On 12/10/09 5:49 PM, Nathan Angelacos wrote:
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 wrote:
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;
Hello,
On 12/10/09 5:29 AM, Nathan Angelacos wrote:
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...")
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?
5496
days inactive
5496
days old
7 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Nathan Angelacos