gigaset n300a / respect srv

Does the Siemens Gigaset N300A handle SRV records?

Yes it does.. but..

Let’s look at a bit of Gigaset DNS traffic:

09:24:26.059850 IP gigaset.local.32978 > nameserver.local.53: 50512+ NAPTR? gigaset.voip.example.com. (28)
09:24:26.061552 IP nameserver.local.53 > gigaset.local.32978: 50512 0/1/0 (87)
09:24:26.063894 IP gigaset.local.32978 > nameserver.local.53: 25738+ SRV? _sip._udp.gigaset.voip.example.com. (38)
09:24:26.064445 IP nameserver.local.53 > gigaset.local.32978: 25738 2/3/2 SRV proxy1.voip.example.com.:5060 10 0, SRV proxy2.voip.example.com.:5060 20 0 (231)
09:24:26.066939 IP gigaset.local.32978 > nameserver.local.53: 22676+ SRV? _sip._tcp.gigaset.voip.example.com. (38)
09:24:26.067290 IP nameserver.local.53 > gigaset.local.32978: 22676 2/3/2 SRV proxy2.voip.example.com.:5060 40 0, SRV proxy1.voip.example.com.:5060 30 0 (231)
09:24:26.070633 IP gigaset.local.32978 > nameserver.local.53: 11475+ A? gigaset.voip.example.com. (28)
09:24:26.070934 IP nameserver.local.53 > gigaset.local.32978: 11475 2/3/0 A 1.2.3.5, A 1.2.3.4 (133)

It’s doing an NAPTR query. Ok. I don’t have those.
Next, it’s looking up the _sip._udp and _sip._tcp SRV records. Good.
Next, it’s looking up the A record. Why?

09:24:26.076373 IP gigaset.local.5060 > proxy2.voip.example.com.6060: SIP, length: 495
09:24:26.077905 IP proxy2.voip.example.com.6060 > gigaset.local.5060: SIP, length: 497
09:24:26.099485 IP gigaset.local.5060 > proxy2.voip.example.com.6060: SIP, length: 685
09:24:26.102665 IP proxy2.voip.example.com.6060 > gigaset.local.5060: SIP, length: 473

What? Did it does connect to proxy2? Yes.. the first one it got from the A record. That’s wrong. Why did it look up the SRV records if it wasn’t going to use them?

It gets worse. There’s an option to have it send NAT keepalives (4 NUL bytes), which works fine. But the keepalive host gets out of sync with the registration server; causing NAT keepalives to be completely useless!

It sends keepalives to proxy1 while registering to proxy2. Now inbound connections from the proxy server (proxy2) where we register will be rejected by the NAT-router. The keepalives have been punching the wrong hole the whole time.

This is a known problem, which is the reason why we’re using SRV records here in the first place. The record priority ensures that all traffic is sent to proxy1 unless it is down, in which case everything goes to proxy2.

However, it turns out that you can convince the Gigaset to use the SRV records. And it’s a simple as clearing out the ports. The two port input fields shown here should be blank:

Now things work like expected. (At least with firmware 42.051 (420510000000 / V42.00).)

Suggestion to Siemens: put a notice on there that you shan’t fill in the port if you want things to work properly.

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
name.