Using DNS NAPTR

[FASTDEVICE]

I want to start a thread for questions related to the use of DNS NAPTR.

My understanding is that we are to use this method for Outbound Proxy, but I'm uncertain how it applies to the Server Host aka realm.  

[Rick Guyton]

We use NAPTR on the proxy and not on the realm. Fun fact, on yealinks, if you don't specify port 0, it basically ignores NAPTR even if the transport type is DNS-NATPR.

[FASTDEVICE]

I see this working differently from manufacturer to manufacture.  On Yealink there is only one option to enable Transport type, but on Polycom you can enable the Proxy separately from the Server Host. I'm assuming that on Yealink you must still set the Server Host's port to 7000 or your going to get DNS failures??? 

[Rick Guyton]

Yea, there's one option, but you have to specify port 0 as well or it'll just use regular A record lookup and UDP. the provisioner doesn't give me an option to set the port number for the realm. So I don't know what it sticks in there honestly. Either 5060 or 7000. I know it doesn't use 0 for sure though.

[FASTDEVICE]

I just check and the 2600hz provisioner places a port 0 in for the Server Host. How does the Server Host manage to figure out the proper port of 7000 when set to zero?

[Tuly]

on Yealink when you set to zero, the phone will lookup the SRV and go based on the SRV port, (the SRV port on the 2600hz DNS is port 7000)

Darren said in the last webinar that they will do 1 webinar for Phone failover, i think it's very useful for questions like, will the phone failover when the proxy not down completely down? only issues with call routing etc..

How long does it usually take for a phone to fail over to a different proxy, 

After failing over do we need to restart in order for BLF to work?

How can we test failover so  when we really need it, we should be confident that it's working

[FASTDEVICE]

Truly, there is no NAPTR record for the Server Host/ Realm. I understand it getting the SRV record for Proxy, but Server Host has none... that's where I'm confused.

[Guest]

I have lots of questions around this as well...and have done a bunch of testing with Yealink and Panasonics and *think* I have most of it figured out. I built my own config management tool so don't use the adv provisioner and can control the config. 

This doc from Yealink talks about how the phone works with NAPTR and DNS-SRV and mentions the need to put port 0 in there to work: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&...

Basically - setting the transport type to 3 (dns-naptr) just tells the phone to query NAPTR and then the SRV records to grab the port (7000). That's handy if for some reason 2600 had an issue with port 7000 and we need to quickly change it globally to 7050 or something. 

Telling the phone itself to use DNS-NAPTR and DNS-SRV is ON by default. There are a number of config variables that enable things like caching results of NAPTR lookups but I haven't messed with them (yet). I assume I can further optimize to help in the case of a DNS failure.

 i have been setting the transport type to 0 (UDP) or 1(TCP) in instances where the customer has a firewall with double NAT that causes registration problems. This has not broken failover since the phone still queries NAPTR to get the A records (us-east then us.central for example) and then uses SRV to get the IP address. 

SO...as FastDevice mentioned there is no NAPTR record for the realm and that was alarming to me until I watched the phones on a PCAP. You can see that it uses the outbound proxy's DNS results to register as well as to send calls so I think the realm is really just a last ditch effort in case the proxies don't respond. This may be irrelevant since the realm's IP is the same as US-CENTRAL anyway. 

Clear as mud?