SPA112 redundant proxies (SRV records)

Tieken Maas · ‎02-16-2013

Hello everyone,

is it possible to register SPA112 with CUCM 8.6 nodes using SRV records at all?

When I indicate IP address of the publisher, SPA112 gets successfully registered. However, when I configure SRV records on my DNS server for two callmanager nodes and set SPA112 to use SRV records, it doesn't work.

I checked the DNS server, it receives DNS queries from the SPA and sends correct reply, but the SPA seems to ignore this information and fails to register itself on the nodes. Intially, the device had 1.0.2 firmware and I had to upgrade it to 1.2.1 version which fixed these bugs:

CSCtz15420 Fixed an issue in which the ATA did not attempt registration if the proxy was identified by a domain name.

CSCua08194 Fixed an issue in which DNS SRV lookup failed.

However, upgrade didn't help...

Thanks for any ideas!

Tieken

marcin · ‎08-06-2017

I am using 1.4.1 (002) on SPA112 and I am experiencing same issue if one of my SRV records resolves to private IP.

Testing: domain.com is a real domain. 192.168.1.20 is a private IP

spa112 can register on 192.168.1.20

setup A dns record localpbx.domain.com to point to 192.168.1.20

spa112 unable to resolve localpbx.domain.com, and not attempting to register.

spa112 is sending continues requests to dns server,

And yes, it resolves on dns server, on public dns server and on local network.

Subsequently _sip._udp.localpbx.domain.com is not getting resolve.

Dan Lukes · ‎08-06-2017

You didn't disclosed the SRV record setup, so no way to answer question related to it.

Thus just generic answer follows - turn on syslog&debug (highest level possible) on Voice Application and capture them. Capture DNS requests and appropriate responses. It may help with further analysis.

marcin · ‎08-06-2017

Dan, thank you for your respond.

The SRV record is not relevant.

Omitting SRV setup point host.validdomain.ext to private IP i.e. 192.168.1.20 on public dns server, as an A record, (I have use my own bind server and godaddy with same results)

and then configure spa112 to register on host.validdomain.ext.

The spa112 fails to resolve host.validdomain.ext to private IP.

If the IP is public the spa112 resolves it and registers just fine.

The monitoring of the traffic shows that the spa112 send the dns requests, receives it, but sends next within 2-3 seconds. The logical conclusion is that the spa122 firmware reject private IP if it is a result of dns query.

I wrote about SRV only because when I attempted to set it up I have encounter the issue.

SRV can not be pointed to an IP address only to a host.

_sip._udp.voip.server.com 0 5 5060 sip.server.com.

Not acceptable:

_sip._udp.voip.server.com 1 5 5060 192.168.1.20

Dan Lukes · ‎08-06-2017

I am experiencing same issue if one of my SRV records resolves to private IP

... it sounds like question related to SRV record, isn't it ?

OK. If I remember correctly, there has been so many issues with the DNS name used for registration. With no debug log captured I'm unable to provide more than just generic advisory - don't do it. Use IP address instead.

With logs we may (or may not) be able to identify a workaround for your issue.

Note that CSC is dedicated for volunteer and customer's self-support. If you wish for Cisco official support, call SMB Support center. But don;t put so much hope on it, especially if you have no valid support contract.

marcin · ‎08-06-2017

I'm sorry I have edited my previous respond to include more details, but I still do not see this as an SRV issue.

Dan Lukes · ‎08-06-2017

You are posting your comments in thread dedicated to SRV record issues, thus it's either SRV issue, or you are off topic at all here ;-)

SRV can not be pointed to an IP address only to a host.

True.

If the IP is public the spa112 resolves it and registers just fine.

The monitoring of the traffic shows that the spa112 send the dns requests, receives it, but sends next within 2-3 seconds. The logical conclusion is that the spa122 firmware reject private IP if it is a result of dns query.

Well, you didn't provided source data, but you provided analysis of the issue issue.

I can just assume your's analysis is correct. In such case you identified firmware bug (if I remember, youare not first person mentioning something like it). Only workaround know to me is - not to use DNS names, use IP address instead (I'm not speaking about right side of a SRV record here - I'm speaking of configuration of SPA122).