Authorizations when using DNS SRV bug?
Hello! I am using Callcentric for my tests and have observed what appears to me a possible bug in the way Freeswitch handles DNS SRV records. Callcentric uses DNS SRV records as a way to direct traffic to their SIP server. A 'srv' 'dig' of '_sip._udp.callcentric.com' returns: _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha6.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha7.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha1.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha3.callcentric.com. Based on this information, Freeswitch appears to correctly round robin all available IP addresses except in a particular situation: in the middle of authorizations. For example, in a registration, Freeswitch send a packet to alpha1.callcentric.com. Callcentric then challenges Freeswitch with a Proxy Authorization request. Freeswitch then sends the packet with the requested credentials but not necessarily to alpha1.callcentric.com! In many cases, instead of sticking to the 'challenging' server, Freeswitch round robins and sends the second packet to, one of the other servers. This continues for a little while and eventually, simply by luck, the second packet is sent to the 'challenging' Callcentric server. Shouldn't Freeswitch stick to the same server when challenged for credentials? Is this a bug? Is there a way to make Freeswitch behave differently? Thanks! Carlos Antunes Nowthor Corporation
On Aug 20, 2009, at 1:28 PM, Carlos S. Antunes wrote:
Hello!
I am using Callcentric for my tests and have observed what appears to me a possible bug in the way Freeswitch handles DNS SRV records.
Callcentric uses DNS SRV records as a way to direct traffic to their SIP server. A 'srv' 'dig' of '_sip._udp.callcentric.com' returns:
_sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha6.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha7.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha1.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha3.callcentric.com.
Based on this information, Freeswitch appears to correctly round robin all available IP addresses except in a particular situation: in the middle of authorizations.
very true, but i've been reading over the RFCs on this, and it seems that FreeSWITCH isn't doing anything incorrectly. in RFC3263 (section 4), when talking about client usage of SRV: The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. [1] being RFC3261 in RFC3261 (section 8.1.3.5), when talking about 4xx responses: In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous.
For example, in a registration, Freeswitch send a packet to alpha1.callcentric.com. Callcentric then challenges Freeswitch with a Proxy Authorization request. Freeswitch then sends the packet with the requested credentials but not necessarily to alpha1.callcentric.com! In many cases, instead of sticking to the 'challenging' server, Freeswitch round robins and sends the second packet to, one of the other servers. This continues for a little while and eventually, simply by luck, the second packet is sent to the 'challenging' Callcentric server.
Shouldn't Freeswitch stick to the same server when challenged for credentials?
can you show anything in the RFCs that says so?
Is this a bug?
see above
Is there a way to make Freeswitch behave differently? disable-srv on the profile
All that said, if it has to be a "bug", then it seems to me that it's more of a "bug" in callcentric's service. They'd probably be better of actually prioritizing their SRV records. If they want load balancing and want to do checking for stale nonces, then they should be sharing nonces across all of their proxies or using a proper load balancer. Raymond Chandler http://freeswitchsolutions.com http://cluecon.com http://cudatel.com
Raymond Chandler wrote:
very true, but i've been reading over the RFCs on this, and it seems that FreeSWITCH isn't doing anything incorrectly.
in RFC3263 (section 4), when talking about client usage of SRV: The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. [1] being RFC3261
in RFC3261 (section 8.1.3.5), when talking about 4xx responses: In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous.
I'd say that based on my own and brief perusal of the relevant RFC's, you are right that Freeswitch is operating without violating the specs. Therefore, there is no bug in Freeswitch.
Is there a way to make Freeswitch behave differently? disable-srv on the profile
In Callcentric's case, it doesn't help either. A request for 'A' recods for 'callcentric.com' returns a bunch. The only way appears to select and stick with only one.
All that said, if it has to be a "bug", then it seems to me that it's more of a "bug" in callcentric's service. They'd probably be better of actually prioritizing their SRV records. If they want load balancing and want to do checking for stale nonces, then they should be sharing nonces across all of their proxies or using a proper load balancer.
Agreed. That being said, having a way to force Freeswitch to stick to the same IP address in the middle of authorization/authentication wouldn't violate any specs but would certainly make things easier when dealing with not so well implemented round robin scenarios. Do you think a new option could be added to Freeswitch to achieve round robin avoidance in these cases? Thanks! Carlos Antunes Nowthor Corporation
Agreed. That being said, having a way to force Freeswitch to stick to the same IP address in the middle of authorization/authentication wouldn't violate any specs but would certainly make things easier when dealing with not so well implemented round robin scenarios. Do you think a new option could be added to Freeswitch to achieve round robin avoidance in these cases?
patches gladly accepted ;-) The code that handles the dns srv stuff is apparently buried in the nta code of sofia, so it's not as easy as it sounds to "just add an option". I personally don't have the skillz needed to take on such an endeavor, but would love to see that as an option. Callcentric isn't the only provider that has equally weighted SRVs and doing checks for stale nonces, so i'm sure we'll here more of this issue when we get more residential users using more various providers. Raymond Chandler http://freeswitchsolutions.com http://cluecon.com http://cudatel.com
Actually, disregard my previous mail... this patch probably wouldn't be gladly accepted... I seem to have forgotten about the part where the DNS SRV lookup "MUST be done once per transaction".... So if we don't do that, then we would be breaking spec. Just disabling SRV on the profile to which the gateway to the faulty carrier is attached should fix the problem. You shouldn't actually need to hard code any IPs into your hosts file. Raymond Chandler http://freeswitchsolutions.com http://cluecon.com http://cudatel.com
Raymond Chandler wrote:
Actually, disregard my previous mail... this patch probably wouldn't be gladly accepted... I seem to have forgotten about the part where the DNS SRV lookup "MUST be done once per transaction"....
Hmm, where does it say that, after the lookup, one cannot use the same IP address as before? :) Carlos Antunes Nowthor Corporation
On Aug 20, 2009, at 5:03 PM, Carlos S. Antunes wrote:
Hmm, where does it say that, after the lookup, one cannot use the same IP address as before? :)
Section 4 of RFC3263 as quoted in my first email.... "The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. " Raymond Chandler http://freeswitchsolutions.com http://cluecon.com http://cudatel.com
Raymond Chandler wrote:
On Aug 20, 2009, at 5:03 PM, Carlos S. Antunes wrote:
Hmm, where does it say that, after the lookup, one cannot use the same IP address as before? :)
Section 4 of RFC3263 as quoted in my first email....
"The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. "
Raymond, sure. But do the "procedures here" preclude one from choosing the same host given that both the priorities and weights are the same for all the hosts?
On Aug 20, 2009, at 5:25 PM, Carlos S. Antunes wrote:
Raymond Chandler wrote:
On Aug 20, 2009, at 5:03 PM, Carlos S. Antunes wrote:
Hmm, where does it say that, after the lookup, one cannot use the same IP address as before? :)
Section 4 of RFC3263 as quoted in my first email....
"The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. "
Raymond, sure. But do the "procedures here" preclude one from choosing the same host given that both the priorities and weights are the same for all the hosts?
well, not exactly, in fact... every so often, you will end up choosing the same 1 out of 4 hosts twice in a row at random, but the procedures basically say to choose one at random if they're evenly prioritized and evenly weighted.... so saying "i'm gonna keep this one for later user" kind of goes against "random" That said, I'm really just about done with this thread since I don't personally agree with the spec in this case anyway since stale nonce checking makes sense to avoid replay attacks, etc. Although, I haven't looked at the specs to see if checking for stale nonces breaks any specs... that might be an interesting search ;-) Raymond Chandler http://freeswitchsolutions.com http://cluecon.com http://cudatel.com
Raymond Chandler wrote:
On Aug 20, 2009, at 5:25 PM, Carlos S. Antunes wrote:
Raymond Chandler wrote:
On Aug 20, 2009, at 5:03 PM, Carlos S. Antunes wrote:
Hmm, where does it say that, after the lookup, one cannot use the same IP address as before? :)
Section 4 of RFC3263 as quoted in my first email....
"The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. "
Raymond, sure. But do the "procedures here" preclude one from choosing the same host given that both the priorities and weights are the same for all the hosts?
well, not exactly, in fact... every so often, you will end up choosing the same 1 out of 4 hosts twice in a row at random
Exactly! :)
but the procedures basically say to choose one at random
Right, but isn't the generator pseudo-random, instead? (If one takes "random" literally, pseudo-random would violate the spec!) What prevents one from using the "right" pseudo-random generator?
That said, I'm really just about done with this thread since I don't personally agree with the spec in this case anyway since stale nonce checking makes sense to avoid replay attacks, etc. Although, I haven't looked at the specs to see if checking for stale nonces breaks any specs... that might be an interesting search ;-)
I am going to try to find an appropriate IETF mailing list to ask some questions about this random SRV stuff and will repost here once I have some additional info. Thanks for trying to keep me honest, though! :) Carlos Antunes Nowthor Corporation
Read RFC 2782, About the significance of a 0 weight vs weighted. Ray proved that if you have your records weighted at 0 it behaves correctly. /b On Aug 20, 2009, at 5:18 PM, Carlos S. Antunes wrote:
I am going to try to find an appropriate IETF mailing list to ask some questions about this random SRV stuff and will repost here once I have some additional info.
Thanks for trying to keep me honest, though! :)
You can bypass the srv records if you like by passing a :port with the hostname where you use it in freeswitch. On Aug 20, 2009, at 1:28 PM, Carlos S. Antunes wrote:
Hello!
I am using Callcentric for my tests and have observed what appears to me a possible bug in the way Freeswitch handles DNS SRV records.
Callcentric uses DNS SRV records as a way to direct traffic to their SIP server. A 'srv' 'dig' of '_sip._udp.callcentric.com' returns:
_sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha6.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha7.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha1.callcentric.com. _sip._udp.callcentric.com. 10025 IN SRV 20 7 5080 alpha3.callcentric.com.
Based on this information, Freeswitch appears to correctly round robin all available IP addresses except in a particular situation: in the middle of authorizations.
For example, in a registration, Freeswitch send a packet to alpha1.callcentric.com. Callcentric then challenges Freeswitch with a Proxy Authorization request. Freeswitch then sends the packet with the requested credentials but not necessarily to alpha1.callcentric.com! In many cases, instead of sticking to the 'challenging' server, Freeswitch round robins and sends the second packet to, one of the other servers. This continues for a little while and eventually, simply by luck, the second packet is sent to the 'challenging' Callcentric server.
Shouldn't Freeswitch stick to the same server when challenged for credentials? Is this a bug? Is there a way to make Freeswitch behave differently?
Thanks!
Carlos Antunes Nowthor Corporation
Brian, You've been vindicated. Callcentric is now advertising zero weighted SRV records! :) I've re-enabled SRV lookups for the Callcentric profile and will monitor to see if I get any errors. Carlos Brian West wrote:
Or as I have argued today they should fix their SRV records to be zero weighted.
/b
On Aug 20, 2009, at 1:36 PM, Michael Jerris wrote:
You can bypass the srv records if you like by passing a :port with the hostname where you use it in freeswitch.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Bkw, I would recommend charging a fee from callcentric for the consultancy. This consultant thing can get you going someday! LOL Jmesquita funny joke On 8/28/09, Carlos S. Antunes <csa@nowthor.com> wrote:
Brian,
You've been vindicated. Callcentric is now advertising zero weighted SRV records! :)
I've re-enabled SRV lookups for the Callcentric profile and will monitor to see if I get any errors.
Carlos
Brian West wrote:
Or as I have argued today they should fix their SRV records to be zero weighted.
/b
On Aug 20, 2009, at 1:36 PM, Michael Jerris wrote:
You can bypass the srv records if you like by passing a :port with the hostname where you use it in freeswitch.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Sent from my mobile device
Thats still debatable.... The RFC's on these things read like chinese stereo instructions. /b On Aug 28, 2009, at 12:13 AM, Carlos S. Antunes wrote:
Brian,
You've been vindicated. Callcentric is now advertising zero weighted SRV records! :)
I've re-enabled SRV lookups for the Callcentric profile and will monitor to see if I get any errors.
Carlos
participants (5)
-
Brian West
-
Carlos S. Antunes
-
João Mesquita
-
Michael Jerris
-
Raymond Chandler