Every now and then I enjoy a break from book writing and other high level work and fix a problem at its base. In a previous post I reported about my joys with the N95 SIP VoIP client and the little quirk I have with it in my home network in Paris: Outgoing calls take 30 seconds before they start. Since the phone works fine in my home network in Germany I figured that there must be something wrong on the network side. However, without some tracing tools there is no telling why.
So when I returned to Paris this time, I brought along an extra Wifi access point and an Ethernet hub so I could trace the traffic between the N95 and the Internet with Wireshark to see why the outgoing call is always delayed by 30 seconds and to figure out if I can somehow fix it.
The picture on the left shows what I saw at first. As per the standard, the Nokia SIP client sends a couple of DNS requests to get the IP address of the SIP server and the STUN server. As per the standards, the SIP client on the phone doesn’t use standard DNS requests but uses DNS SRV (service) requests which do not only resolve a domain to an IP address but a domain name + service (SIP + STUN) into an IP address. Looks like my brand new ADSL2+ D-Link modem/router can’t handle them because they simply remain unanswered. Eventually, the SIP client in the phone gives up and sends a standard DNS query to get the IP address of the SIP server. All well at this point, registration is successful and the SIP client goes into service state.
When making an outgoing call (packets marked in black in the picture), however, the SIP client suddenly remembers that the DNS SRV requests for SIP and STUN were not successful in the first place and sends them again. Once more, they are not answered. After 30 seconds (hello!) the SIP client gives up and places the call without pinging the STUN server first. Doesn’t seem to be a problem in practice as the router opens the UDP ports anyway.
O.k., so the solution is to turn off DNS relaying on the router. The D-Link router might be stupid as far as DNS is concerned but at least one can turn off it’s stupidity and instruct the client devices to send DNS queries directly to the external DNS server. And voila, everything starts working as it should. The second picture on the left shows how the SIP client behaves once the external DNS server properly answers the DNS SRV requests. The client registers in a flash and for an outgoing call quickly pings the STUN server an then places the call. Wonderful!
So who’s to blame?
I guess 90% of the blame should go to D-Link for a crappy DNS implementation. Guys, how can it be that the latest generation ADSL2+ router can’t do DNS right!? I am speechless. 10% of the blame goes to Nokia. Why are you trying to contact the STUN server with fruitless DNS SRV requests when it is quite obvious they have not been answered in the past? Being somewhat more flexible on the client side wouldn’t hurt 🙂
nice analysis 🙂
if i knew who to send this to internally i would