[Home]

Summary:ASTERISK-05166: [request] [post 1.2] asterisk does not process priorities in DNS SRV records
Reporter:Alex Zhilyakov (azhilyakov)Labels:
Date Opened:2005-09-27 17:23:55Date Closed:2011-06-07 14:03:14
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hello,

Asterisk performs DNS SRV queries to find a SIP server to register to. When DNS server sends a responce back to Asterisk with multiple SRV RR records, those records may have different "priority" and "weight" attributes.

According to RFC 2782, "A client MUST attempt to contact the target host with the lowest-numbered priority it can reach".

Asterisk, however, does not choose a lower-priority host first; instead, it chooses hosts in a manner similar to round-robin.

This is a violation of DNS SRV standard.


-Alex
Comments:By: Michael Jerris (mikej) 2005-09-27 21:56:41

The DNS SRV support in asterisk is known and documented incomplete.  

By: Michael Jerris (mikej) 2005-09-27 22:10:54

oej-  Given the state of SRV record support, is this a feature request or a bug?

By: Alex Zhilyakov (azhilyakov) 2005-09-28 09:09:13

I had a quick look at DNS and SIP source code, and it seems to be not a big deal to prioritize SRV records.

However, it looks to me that all DNS-related functions are able to return only a *SINGLE* ip/port as a result of DNS lookup.

The real question now is, whether it is possible in currect asterisk code, to do the following:

1. DNS SRV query results in 2 (or more) records with different priorities
2. Asterisk tries to contact the host with lowest priority
3. If this host is not "reachable", it tries to contact a host with higher priority

Let's suppose we do a patch prioritizing SRV records; Then, since all DNS-related functions return a SINGLE ip/port, it may result in Asterisk trying to contact a single, lowest-priority, host, and not cycling to a  higher-priority host in case the first one is not "reachable". Can somebody familiar with source code comment on this?

Thank you.

-Alex

By: Olle Johansson (oej) 2005-09-28 15:11:06

This is a documented lack of feature. We need to fix it in the 1.3 dev tree, but it will not be easy to fix within the current chan_sip.

By: Olle Johansson (oej) 2005-11-22 09:13:53.000-0600

Closing this issue report, will re-open as soon as someone contributes code.