[asterisk-bugs] [Asterisk 0012312]: [patch] DNS SRV lookups causing re-registration problems

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12312 
====================================================================== 
Reported By:                jrast
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12312
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for review
Target Version:             1.6.2
Asterisk Version:           1.4.18 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-03-26 17:38 CDT
Last Modified:              2009-01-09 15:45 CST
====================================================================== 
Summary:                    [patch] DNS SRV lookups causing re-registration
problems
Description: 
SIP peer uses DNS SRV records which list multiple entries for
_sip._udp.domain.  

Asterisk is selecting one and successfully registering with it.  When
attempting to re-register, Asterisk is not selecting the same host. 
Instead it is ALWAYS selecting another host, sending seven SIP REGISTER
requests to it, then failing over to the next (correct) host, at which
point the re-register succeeds.  However, this process exceeds the
registration expiry and the registration is timing out on every
re-registration cycle.

Peer in question is callcentric.com.
====================================================================== 

---------------------------------------------------------------------- 
 (0097377) putnopvut (administrator) - 2009-01-09 15:45
 http://bugs.digium.com/view.php?id=12312#c97377 
---------------------------------------------------------------------- 
After reviewing the patch and investigating more regarding SRV handling in
Asterisk, my suspicions were confirmed, which are:

1) We never actually will fail over to a lower priority or weighted SRV
record, ever.
2) We don't actually look them up in a round-robin fashion as assumed in
the bug description. We just use the order of the records returned to us by
whatever resolver is used.

So here's something that doesn't make sense to me. If there are SRV
records set up at callcentric for SIP, and they are equally prioritized and
weighted, why is it that a REGISTER sent to one works properly but a
REGISTER sent to the other does not? This seems like a misconfiguration on
the end of the provider and not something that Asterisk is doing wrong.

Furthermore, because of point 2) above, it's not Asterisk's fault that
whatever DNS resolver is in use is returning the records in a different
order than they previously were. As far as Asterisk is concerned, the only
attributes of the records that matter when sorting them is the weight and
priority, we do not go to the effort of making sure that records of the
same weight and priority are in the same order as our cached list because
that should not matter.

Now, I'm not trying to say there's not a bug here, because as oej pointed
out in his first note, we should continue using the first SRV record until
we have a failure. If Asterisk is really performing a new SRV lookup on
every re-registration, then that behavior is incorrect. The existing trunk
code appears to handle this correctly, but it looks as though 1.4 may have
issues. I will look at bbryant's 1.4 patch to see if it handles things
properly (I've just been looking at the trunk patch up to this point). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-09 15:45 putnopvut      Note Added: 0097377                          
======================================================================