Summary:ASTERISK-21752: Asterisk peers with host=<dnsname> do not accept calls from all hosts in dnsname's multiple host SRV record set
Reporter:David Brillert (aragon)Labels:
Date Opened:2013-05-02 07:57:47Date Closed:
Versions:11.3.0 13.18.4 Frequency of
is related toASTERISK-18353 SIP registration doesn't use round-robin DNS.
is related toASTERISK-15688 dnsmgr failes to match peer when SIP srvlookup is on
Description:When host=<dnsname> and the name is a SRV record set with multiple hosts, Asterisk does not accept incoming calls for all hosts in that SRV revcord set.
Asterisk locks on the first host and ignores the rest in the list.
Comments:By: Olle Johansson (oej) 2013-05-02 08:25:36.903-0500

This is a problem I just thought could happen, but had no indication that it had happened to users. Interesting. I'm working on implementing improved support for SRV records in the pgtips branch. Parts of it may be a bug fix.

In my branch, I'm adding an ACL list (a list of IPs) that we will use for matching on incoming calls instead of only using the IP we decided to communicate with at one point.

By: Olle Johansson (oej) 2013-05-02 08:39:57.205-0500

ASTERISK-18353 talks about round robin DNS, but has the same kind of issues.

Also read http://www.dslreports.com/forum/r23342155-Another-asterisk-question

By: David Brillert (aragon) 2013-05-16 08:11:07.330-0500

I see that a clone was made at ASTERISK-21767
Does that mean that there is some priority associated with this bug report?

By: Walter Doekes (wdoekes) 2013-05-29 08:26:25.066-0500

It means that it has arrived in the internal Digium queue. But that means nothing ;)

@oej: I thought this was a known issue. I always had to set up multiple peers for each entry in in the A or SRV list. (When user/From-based matching wasn't an option.)

By: Olle Johansson (oej) 2013-05-29 08:35:06.496-0500

Yes, I've always set up multiple peers as well.

By: Matt Jordan (mjordan) 2013-07-20 18:01:26.203-0500

So, depending on how you squint at this, this could be a bug or it could be an improvement. Most likely, we'd treat it as an improvement to the existing DNS support.

There's no question that the current DNS support is lacking. However, inserting support for multiple hosts into DNS handling would probably be quite a large change - particularly if it was done correctly.

What does correctly mean?

Well, if your DNS handling supports multiple hosts, then every things that uses the DNS stack should get the benefit - that is, {{chan_sip}} and {{chan_iax}} and anyone else. Unfortunately, the channel drivers often don't expect requests to come from multiple IP addresses - so semantics changes in the DNS handling are bound to have a ripple effect up the stack.

As such, I'm concerned that this change would be difficult to do properly and not break existing deployments.

The best we could do would be to treat it as something to do for a future version of Asterisk.

By: David Brillert (aragon) 2013-07-21 14:59:33.158-0500

@Matt: Asterisk 12, or is it too late for that too?
@Olle: Have you done any preliminary work on any branch?

By: Matt Jordan (mjordan) 2013-07-21 18:17:45.451-0500

Asterisk 12 is feature frozen in 10 days (July 31st). Feature frozen => a well tested patch has to be up on Review Board by that point. While that isn't theoretically impossible, it is highly unlikely.

By: David Brillert (aragon) 2014-06-06 07:57:56.136-0500


Did you ever merge a fix into pgtips?
Do you have patch or branch for Asterisk11...