A couple of days ago I posted an entry on my experiences with the N95’s SIP VoIP implementation. While the overall result was very positive, I continue to see the strange 30 seconds dial out delay with my Wifi/DSL setup in Paris. To get to the bottom of this I have started a little tracing session to see at which point things go wrong.
To have a positive example for a comparison, I traced the SIP behavior of the N95 in my Wifi network in Germany where everything works fine. For the purpose I have put a hub in between the DSL modem and the Wifi access point to trace the messages going back and forth between the SIP server, the voice gateway and the N95. Here are some interesting results which I didn’t expect:
STUN Implementation
Once the SIP client on the phone is registered, it communicates once every 30 seconds with the STUN (Simple Traversal of UDP over NAT) server on the Internet. This is required due to the Network Address Translation feature of DSL and cable modems that allow using many devices in the local network despite only having a single IP address. While I knew that the SIP client has to ping the STUN server every now and then to keep the UDP ports open on the NAT firewall in the DSL router, I didn’t expect to see it every 30 seconds. Seems to be a normal behavior as a Windows XP SIP Client behaves the same.
Registration Interval And Impact Of Signaling on the Network
To keep the UDP session with the SIP Registar and Proxy alive, the
SIP client on the N95 registers with the service every 5 minutes. This
is probably also a precaution or necessity to keep the UDP port open
for incoming signaling messages in the NAT firewall. In Wifi/DSL/cable
networks, this frequent communication together with the 30 seconds STUN
updates is not a problem. It also doesn’t seem to have a big impact on
battery performance as I discovered already in my earlier blog entry.
For cellular networks however, such behavior is quite problematic. Just
imagine 2000 VoIP capable devices hanging on each cell and sending SIP
and STUN signaling messages over it every 30 seconds… Thats over 66
uplink resource requests per second just for SIP and STUN signaling.
Bye bye Idle state… Looks like the combination of NAT and SIP over cellular networks on a large scale is a no go!
STUN Before The Invite
When dialing out or before accepting an incoming call, the Nokia SIP implementation also pings the STUN server once before proceeding with the call. The Windows XP SIP client doesn’t do that so it seems to be a precaution on Nokia’s side.
One RTP Packet Opens the NAT
When dialing out, the Nokia SIP implementation sends an RTP packet to open the NAT firewall for incoming RTP speech packets. Further outgoing RTP packets are only sent when the other side picks up. So that first (and only packet) is definitely sent for this purpose.
Supported Speech Codecs
According to the Session Description in the Invite message the Nokia VoIP client supports the following speech codecs: G.711 PCM a-law and my-law, Adaptive Multirate (AMR), iLBC and G729. With the SipGate voice gate to the standard phone network, the G.711 PCM codec is selected so no speech transcoding is required at the gateway. Good for the gateway and good for speech quality but this requires 10 kbyte/s bandwidth in the uplink or downlink. Not very resource efficient 🙂
Summary
Some of the things I have described here can also be seen in the screenshot at the top of this blog entry. Click on the image to get the full sized version. Next week, I’ll be in Paris again and will check out things there. More news then.