Handling of SRV records


given the following registrar domain name: sip.example-com. This resolves to The DNS service record of _sip._udp.sip.example-com shows two records: Server a.sip.example-com with priority 10 and server b.sip.example-com with priority 20. a.sip.example-com resolves to and b.sip.example-com resolves to

First question: Is this correct behavior by the ITSP? I would expect, that the registrar domain name would resolve to the same host as the service record with the highest priority (10). But it’s the other way around. This just happens once in a while but some problems arise from here.

Asterisk is behind NAT. There is no firewall rule to forward incoming traffic to Asterisk. Therefore I’m using the qualify mechanism to punch holes in the firewall.

But what happens is, in case of this odd DNS problem, Asterisk registers outbound to the ITSP using the of sip.example-com (which is the same as the priority 20 service record). The qualify mechanism on the other hand is using the priority 10 service record. So it’s punching holes in the firewall, but not to the server it’s registered to.

Second question: Is there an error in my configuration or is this expected behavior?

Thanks in advance!

  • I had to change the URIs (dot vs. dash) because of new user restriction (only 2 per post).

Which SIP channel driver are you referring to and version of Asterisk? That changes the answer. It also depends on the DNS result at the time whether it is expected or not. It may very well be expected at that time.

Thanks for your reply.

Sorry, I forgot: It’s PJSIP and Asterisk 16.2.1~dfsg-1+deb10u1 (Debian 10 package).

If you enable debug logging (debug to file or console in logger.conf) and do core set debug 5 it will provide information on the DNS resolution process and show what it did.

I’ve got a TCP dump and a regular log. Here is a brief output of the DNS answers I’m (and Asterisk are) confused about. (I changed some hostnames and IPs.)

2019-09-29 16:08:07,975675

Domain Name System (response)
    Transaction ID: 0x3867
    Flags: 0x8180 Standard query response, No error
    Questions: 1
    Answer RRs: 2
    Authority RRs: 0
    Additional RRs: 2
        _sip._udp.sip.alice-voip.de: type SRV, class IN
        _sip._udp.sip.alice-voip.de: type SRV, class IN, priority 10, weight 100, port 5060, target s1.sip.alice-voip.de
        _sip._udp.sip.alice-voip.de: type SRV, class IN, priority 20, weight 100, port 5060, target s2.sip.alice-voip.de
    Additional records
        s1.sip.alice-voip.de: type A, class IN, addr
        s2.sip.alice-voip.de: type A, class IN, addr
    [Unsolicited: True]

2019-09-29 16:08:11,303713

Domain Name System (response)
    Transaction ID: 0x6e7a
    Flags: 0x8180 Standard query response, No error
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 1
        sip.alice-voip.de: type A, class IN
        sip.alice-voip.de: type A, class IN, addr
    Additional records
        <Root>: type OPT
    [Unsolicited: True]

But I’ll try to get a full debug log. I just don’t know, if we’ll see such a DNS situation again within the next few days. Most of the times the ITSP delivers “matching numbers”. (IP of highest priority SRV record matches IP of registrar domain.)

But if I got you right, those non-matching DNS entries might be okay under certain circumstances. Right?

There is nothing that states the A record of “sip.alice-voip.de” has to match the first SRV record that is returned.

Thanks for this answer. Good to know.

But is the qualify mechanism actually meant to be used for UDP hole punching? It works perfectly as long it’s OPTIONS requests are sent to the address of the outbound registration.

Or can you think of a better solution?

It’s generally meant to either ensure the remote endpoint still exists, or to keep a REMOTE NAT hole open. While it can be used to keep your LOCAL NAT hole open as you’ve seen there is no guarantee on which IP address will be used in certain circumstances, and there’s no guarantee that the remote side will send inbound calls from that same IP address.

Thank you for clarifiying this. Maybe you could add this explanation to the docs.

Now, since it’s clear, that it’s neighter an ITSP nor an Asterisk problem, I wouldn’t wanna bother you reading long debug log files. Okay?

Just two last questions:

  1. What would you do to achieve local UDP hole punching? Use the Asterisk API? Is there a CLI command like: “pjsip send OPTION to 123.456.789.123”?
  2. It is possible, that the ITSP sends INVITEs from a different address than I registered to (your last half sentence)?
  1. There’s no command for that, generally to ensure things always work people forward the ports or limit on their firewall to the expected IP addresses of any ITSPs.
  2. Yes, it is possible. It depends upon their environment/policy/deployment.

One of the service providers I use does exactly that. They have a range of 255 addresses that they rotate and [apparently] the invite comes from the one I’m registered to usually but sometimes it does not. It seems like my old router passed them all but I bought a new router with a better firewall and it did not. So I had to forward the UA port but only for the range of ip addresses. As far as I can tell that corrected the issue.

Thanks for this comment! But what would the identify-section look like? I only know the registrar domain (sip.alice-voip.de). Via SRV records asterisk might be able to look up some more hosts. But if the ITSP initializes the call from any other host, how shall Asterisk know not to reject the incoming call?

Have they told you which IPs or which range they would use?

I believe that they have. I am going to try to make sure that the 2 ranges of IP’s they said they use are opened/forwarded in my router. It is a bit of a mystery.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.