ageet Forums

I'm setting up a fail-over SIP system which is based on DNS round-robin for front-end SIP-proxys. While testing different clients I have discovered that AGEphone doesn't try another IP from the list while establishing a connection to proxy. I would consider this a bug.

I am not so sure if this is really anything that the client side has much control over. If you are certain that a bug in AGEphone Mobile 2 prevents it from using the other addresses in your system, please let me know some more details about your setup and also attach or forward (michael@ageet.com) your simple and extended log file.

Here is what I have in my DNS zone:

Code: Select all

sip             IN      A       10.100.0.137
                IN      A       10.100.0.162


The log file of the phone startup is full of the following records:

Code: Select all

#<< Send   10.100.0.137:5060   04/16/2009 13:15:06
REGISTER sip:sip.ccm.local SIP/2.0
Via: SIP/2.0/UDP 10.100.0.136:48600;branch=z9hG4bK7167804
Max-Forwards: 70
To: "Belman V." <sip:6000@sip.ccm.local>
From: "Belman V." <sip:6000@sip.ccm.local>;tag=38623BF6
Call-ID: CE3DB86F-009808587F371DE87942@10.100.0.136
CSeq: 1 REGISTER
Contact: <sip:6000@10.100.0.136:48600>
Expires: 3600
User-Agent: AGEET SIP Stack 2.50 ageet.com
Event: registration
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, MESSAGE, NOTIFY, REFER
Content-Length: 0


All other records are the same.

Since the server on 10.100.0.137 is down the phone does never register. If of some luck the name sip.ccm.local would resolve into 10.100.0.162 then registration is passed OK and everything works as expected.

Thank you for the description! Reading this and also taking a quick peek at Wikipedia's description of the subject at hand I am still not sure if this really is an AGEphone problem and not rather one inherent in the round robin DNS approach:

"Although easy to implement, round robin DNS has problematic drawbacks, such as those arising from record caching in the DNS hierarchy itself, as well as client-side address caching and reuse, the combination of which can be difficult to manage. Round robin DNS should not solely be relied upon for service availability. If a service at one of the addresses in the list fails, the DNS will continue to hand out that address and clients will still attempt to reach the inoperable service."

Please excuse me if that view is too simplistic, but it seems to fit your situation quite well and I wonder what we could actually do on the client side to make this work.

I'm a 20-year experienced system administrator with at least 13 years being spent with IP networks. So, hopefully I do understand pros and contras of DNS round-robin.

Seriously, my case has no other solution because it's gonna be two systems being placed in different geographical locations. Solutions which make use of a single IP for high availability are not of any use in this case, unfortunately. I don't know how does WM resolver works. But in hope that it's based upon standard Windows routines I would expect it to support multiple IPs per DNS entry. What would be expected from a client in this case is to remember all of those IPs and try them consequently one after another until a successful connect could be done. Or, if WM resolver does it in a proper way, a client would try to re-resolve an address every time a connect attempt is performed; this way the job of changing IPs would be done by the resolver itself.

As an example you could have a look at google.com. It resolves into three IP addresses (might be different for other locations). Every time one tries to ping this address he pings another IP.

Thank you for your description and I am very sorry for the late answer! As I am not a programmer myself and have no means to check into this any further I'll forward this thread to our programmers and let you know what they said about it. If this is anything that can / has to be resolved on the client side rest assured that we will do it if it is a reasonable effort.