gigaset n300a / respect srv

gigaset n300a / respect srv

  • Written by
    Walter Doekes
  • Published on

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? (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? (38)
09:24:26.064445 IP nameserver.local.53 > gigaset.local.32978: 25738 2/3/2 SRV 10 0, SRV 20 0 (231)
09:24:26.066939 IP gigaset.local.32978 > nameserver.local.53: 22676+ SRV? (38)
09:24:26.067290 IP nameserver.local.53 > gigaset.local.32978: 22676 2/3/2 SRV 40 0, SRV 30 0 (231)
09:24:26.070633 IP gigaset.local.32978 > nameserver.local.53: 11475+ A? (28)
09:24:26.070934 IP nameserver.local.53 > gigaset.local.32978: 11475 2/3/0 A, A (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 > SIP, length: 495
09:24:26.077905 IP > gigaset.local.5060: SIP, length: 497
09:24:26.099485 IP gigaset.local.5060 > SIP, length: 685
09:24:26.102665 IP > 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:

Gigaset N300A SIPsettings

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.

Update 2013-03-21

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

That might explain why they did what they did. But it still isn’t intuitive. And it’s still wrong that they query both.

Back to overview Newer post: serialize json date / microsoft extension Older post: thunderbird / mailing list / reply