Yealink Forums
DNS-SRV Record lookup fails -- *Solved* - Printable Version

+- Yealink Forums (
+-- Forum: IP Phone Series (/forumdisplay.php?fid=4)
+--- Forum: T4x Series (/forumdisplay.php?fid=31)
+--- Thread: DNS-SRV Record lookup fails -- *Solved* (/showthread.php?tid=622)

DNS-SRV Record lookup fails -- *Solved* - Bryan Nelson - 07-12-2013 03:41 AM

I am currently testing the new T-46g model, and am having an issue with the SRV records that our system uses. T-2x models do not have a problem with the same address. It appears that it is only attempting an a-record lookup on the address, and not the full NAPTR\SRV lookup.

Registering via UDP with our a-record works fine, and I really do like this new model!

; <<>> DiG 9.9.2-P1 <<>> _sip._udp.********.*******.com SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51495
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

_sip._udp.********.*******.com. 300 IN SRV 100 10 5060 ********.*******.com.
_sip._udp.********.*******.com. 300 IN SRV 10 10 5060 ********.*******.com.

;; Query time: 64 msec
;; WHEN: Thu Jul 11 13:36:18 2013
;; MSG SIZE rcvd: 160
Jul 11 18:59:34 SIP [384]: SUA <5+notice>[000] host=[********.*******.com], transport=[3], port=[5060], family=[2]
Jul 11 18:59:34 SIP [384]: DNS <5+notice>[DNS] ********.*******.com is not found in dns cache
Jul 11 18:59:34 SIP [384]: DNS <5+notice>[DNS] set DNS timeout: [3000], tries: [2]
Jul 11 18:59:34 SIP [384]: DNS <5+notice>[DNS] About to query [********.*******.com] IN A/AAAA
Jul 11 18:59:34 SIP [384]: DNS <3+error >[DNS] query error: [DNS server returned answer with no data]
Jul 11 18:59:34 SIP [384]: SUA <5+notice>[000] DNS query : DNS query error

I have "solved" this issue after reading the admin guide a little closer. The behavior is a little different than previous models, which may cause some confusion.

"If a port is set to 0 and the transport type is set to DNS-NAPTR, NAPTR and SRV queries will be tried before falling back to A queries. If no port is found through the DNS query, 5060 will be used. If an explicit port (except 0) is specified and the transport type is set to DNS-NAPTR, the only lookup will be an A query"

*edit -- Redacted server addresses due to attempted access.

In previous models(even the similar T-38), SRV records would still be attempted when the port is set to the default of 5060. On the T-46, you must manually set the port to "0" if you wish to use SRV. Ideally, this behavior would be matched to the older phone models, for consistency. Otherwise, it may be a good idea to set the default port to "0" when setting the transport to NAPTR\SRV, as it doesn't make much sense for the default setting to automatically disable the transport you select. Wink

RE: DNS-SRV Record lookup fails -- *Solved* - Yealink Support - 07-15-2013 05:09 PM

Hi Bnelson,
Thanks for your feedback, i will submit this suggestion to our product department.

RE: DNS-SRV Record lookup fails -- *Solved* - dtgriscom - 10-19-2013 12:25 PM

I just hit this problem myself, trying to get my T46G to connect to Callcentric. All the configurations were correct, and verified by Callcentric (looking at screen shots). I'd left the port number for both the "Outbound Proxy Server" and "Server Host" to the 5060 that was there when it came to the factory, and it never successfully registered (with DNS errors shown in the log).

My first solution was to replace the domain names in the two fields with the corresponding IP addresses: this worked, but was a kludge. After reading this thread, though, I restored the domain names and changed the port numbers to 0: bingo, it worked.

You clearly have a problem here. Either the port number default needs to be "0" (or an empty string being equivalent to "0", although that currently isn't true), or you need to change the behavior. Otherwise, your phones won't work with Callcentric without a confusing workaround.

RE: DNS-SRV Record lookup fails -- *Solved* - dtgriscom - 10-19-2013 07:25 PM

BTW, I'm using firmware version, and hardware version Before I solved the problem I updated from the factory firmware, which was (I think) I'm fairly sure the original version had the problem, too.