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