Does the Siemens Gigaset N300A handle
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 18.104.22.168, A 22.214.171.124 (133)
It’s doing an
NAPTR query. Ok. I don’t have those.
Next, it’s looking up the
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
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
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
This is a known problem, which is the reason why we’re using
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
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.
RFC 3263 (Locating SIP Servers) 4.2 writes (in June 2002):
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.
That might explain why they did what they did. But it still isn’t intuitive. And it’s still wrong that they query both.