given the following registrar domain name: sip.example-com. This resolves to 100.100.100.1. 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 100.100.100.2 and b.sip.example-com resolves to 100.100.100.1.
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.
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.)
Time
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
Queries
_sip._udp.sip.alice-voip.de: type SRV, class IN
Answers
_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 213.1.1.1
s2.sip.alice-voip.de: type A, class IN, addr 195.1.1.1
[Unsolicited: True]
Time
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
Queries
sip.alice-voip.de: type A, class IN
Answers
sip.alice-voip.de: type A, class IN, addr 195.1.1.1
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?
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.
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.
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.
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.