PJSIP SRV Lookup Failing if you specify a port

Ok - My carrier has two ports available for registration - 5060 and 7000 - If I specify the port, SRV lookup fails miserably and the trunk never even tries to register - If I remove the port and let it try (and register on 5060) it works fine - The SRV lookup happens just like it does with CHAN SIP and away you go - Why would it be this way?

Specifying the port on CHAN SIP does not mess with the SRV lookup.

I saw this from 2018:

[FREEPBX-16784] PJSIP SRV Lookup - Sangoma Issue Tracker

Surely this has been fixed by now? Why can I not specify a port and have SRV lookup work as intended?

The RFC for this[1] states:

If the TARGET was not a numeric IP address, but a port is present in
   the URI, the client performs an A or AAAA record lookup of the domain

The resolver follows that. This is because SRV records contain the port to use, so overriding it goes against the actual configured DNS of whatever is being resolved.

[1] https://tools.ietf.org/html/rfc3263#page-8


Does the A or AAAA lookup contain the port? I am looking at the Packet Captures I used to figure out what it was doing and I didn’t see a port in the response back on the DNS queries - Just the hostnames.

Answer my own question - yes it does:

_sip._udp.somewhere.net: type SRV, class IN, priority 30, weight 50, port 7000, target somewhere-else.net

A and AAAA records don’t. SRV records do. For example:

[email protected]:~> dig srv _sip._udp.flowroute.com

; <<>> DiG 9.16.1-Ubuntu <<>> srv _sip._udp.flowroute.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22132
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;_sip._udp.flowroute.com.	IN	SRV

_sip._udp.flowroute.com. 43200	IN	SRV	10 10 5060 sip-nv1.flowroute.com.

;; Query time: 52 msec
;; WHEN: Mon Apr 19 20:34:05 ADT 2021
;; MSG SIZE  rcvd: 93

That is an SRV record from Flowroute, and they specify a port of 5060. Once this record is retrieved the resolver then performs an A and AAAA lookup to get the IP address to contact.

Thanks - Yeah, I was not going deep enough into the SRV record returned - that’s cool!

Not broken!

Radically simplified trunk setup too - Only 4 blanks to fill out versus two pages for my SIP trunk definition. Cool.


If you have a static IP address and your provider supports IP authentication, you probably should not be using registration. Set Match (Permit) to allow calls from any of their addresses. If their system is reasonable, when they get no response to a call sent from one address, they will resend it from another.

For outgoing, your setup should be based on what failover options you have. If you don’t have a reliable fully functional failover, IMO you should set up two or more trunks that send to different addresses at the provider. This avoids issues where a missed qualify response causes a call to fail, even though a subsequent SRV lookup would yield a working server address.

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