Fixed my N95 SIP Problem in Paris

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.

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

Pic2sip
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 🙂

University of Oxford – Future Technologies Conference 2008

Last year, people said the University of Oxford’s Future Technology conference was THE wireless event to attend in 2007 and I was sad to have missed it. Not so this year, as my ticket is booked and I am looking forward very much to an exciting conference day on the 18th of April.

In case you haven’t heard of the event yet, take a look at the official web site here. At last, I will meet Dean Bubley, Ajit Jaokar, Tomi Ahonen and Christian Lindholm in person, all speakers at the conference. Topics on the agenda range from Mobile Social Networking, iPhone Applications, user-generated content and advertising, mobile web 2.0 applications, mobile browser extensions, mobile search, etc., etc. I know Tomi and Dean sometimes have different opinions on a topic so I am especially looking forward to their debate 🙂

If you are reading this and planning to go to Oxford for the event as well, I am looking forward very much to meet you there!

In case you have to miss this opportunity, there are also a number of interesting telecom courses at the beginning of summer at the university which you might be interested in. In case you are in the WiMAX business, have a closer look at the 2 day WiMAX course that I will present together with John Edwards of Picochip and Chris Beardsmore of Intel.

MIMO Explained

Multiple Input Multiple Output, or MIMO for short, seems to make it into every wireless radio technology today from Wifi to WiMAX, HSPA+ and LTE. Yes, we know that it requires multiple antennas at the transmitter and the receiver and offers to multiply throughput by sending an individual data stream over each antenna in the same frequency band. But just how can the receivers at the other end separate the two data streams again as they have combined in the air to something completely incomprehensible!? National Instruments has a great introduction to MIMO on their web page which describes this in simple terms with just the right amount of maths that it is still understandable for someone out of college for a decade or more and who hasn’t touched maths since  🙂

Nokia 6300i: WLAN and VoIP move to Mid-Range Phones

I just saw Nokia’s announcement of the 6300i and had to take a closer look. While I am more of a fan of their Nseries devices, the announcement nevertheless caught my eye since the 6300i includes WLAN for browsing and VoIP.

While Nokia’s website doesn’t (yet) confirm that VoIP equals a SIP client (and not UMA), it looks very much like it since the WLAN doesn’t seem to be inside for UMA and can be used as a standard Internet connection.

Interesting how fast those two high end features have moved to the mid-range sector and another sign VoIP over Wifi might soon become the norm rather the exception. I hope carriers are starting to think of a couple of alternatives to removing the VoIP functionality in their firmware version soon. Here are some suggestions.

Also on board of the S40 based phone is Nokia Maps as a Java application, another high end feature moving down to a mid-range phone at the lower end with a recommended retail price of around 200 euros (according to Teltarif).

Does anyone have experience with the S40 music player? If it’s good I can very well imagine this phone addressing a large audience.

HSPA+ Background Information

It looks like UMTS will not give way to LTE in the future just like that. The High Speed Packet Access (HSPA) extensions which are now used in most UMTS networks today might get another upgrade in the future with HSPA+. Features such as 64QAM modulation, MIMO and Continuous Packet Connectivity (CTC) are on the horizon. Here are some documents I found recently which go a bit deeper into the topics:

Enjoy!

Why IPv6 Will Be Good For Mobile Battery Life

The other day I ran a post on the behavior of the SIP VoIP implementation of my Nokia N95 and that I was quite surprised to see it sending keep-alives to the network every 30 seconds. While this is normal and necessary to keep the NAT firewall open, it does have an impact on battery life, especially if a cellular network is used for the connection. The impact of such keep-alives is also considerable on the network once the number of devices using such always-on applications rise. Each cell usually serves 2000 devices at a time. Now imagine 2000 devices sending a keep-alive every 30 seconds via the same cell…

Bob Hinden of Nokia recently gave a presentation on the issue at the recent Google IPv6 conference and you can find the video of his presentation on YouTube. He made two interesting points for me here:

  • With IPv4 and NAT, it’s not only SIP VoIP that sends keep-alives but also push eMail clients, VPN and Instant Messengers. So he’s right, the problem gets even worse.
  • With IPv6 the NAT problem goes away as there are plenty of addresses and NAT is no longer required. Hence, IPv6 capable always-on applications can live without the keep-alives and ‘silence returns’ to the idle time.

Good points! Until we arrive at this state, however, it’s not even a good idea in most scenarios to use a public IPv4 address while you are mobile. Take a look at this blog post I wrote some time ago on how peer to peer applications of others drain my battery because of IPv4 address reassignments. I don’t know a lot about IPv6 yet but this should not happen with IPv6 anymore because I will not be assigned an IP address that was previously used by someone else!? Comments as always welcome.

P.S. Thanks to afr who made me aware of the video in Jaiku who heard it from Constantine 🙂

Telecom Italia’s Plans To Upgrades Wireless Backhaul

This report on Telecom: Italy fits to my recent blog post on T-Mobile upgrading their wireless backhaul to meet the rising demand for higher data rates. The report says that Telecom Italia will connect about 1700 ‘antennas’ of their wireless base stations to new fiber infrastructure which will also be used to bring faster fixed line Internet connections to homes and businesses. The wording is a bit strange since base stations are connected to a backhaul fiber and not individual ‘antennas’. I wonder how many antennas they count per base station!? There are usually 3 sectors per base station, each having its own antenna. That would make it around 600 base stations. But that’s just a guess on my side.

Carlo Longino Starts Blogging For Nortel

Carlo Longino, probably known by many from his musings at Mobhappy, has recently started blogging for Nortel on the Hyperconnectivity blog. His topics are WiMAX and 40G optical. I just stumbled over it by accident and quite like what I have seen. Seems like a good move from Nortel to find some bloggers from outside the company to push their ideas in addition to blogs such as those from Nortel’s CTO John Roese and Phil Edholm.

Interesting also to see and to compare the approaches of different companies. Nokia’s S60, for example, is also doing lots of different blogs to reach out. Their approach is not from the top level or from the outside but from the people actually working on the products.

If you have recommendations of good blogs from people of other wireless companies please leave a comment.

Tracing the N95’s VoIP Implementation

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

The 8-10 Year Interval in Mobile Repeats with LTE

I just realized that new cellular network technologies seem to be launched every 8-10 years. Analog cellular networks such as the C-Netz started operation back in 1984, GSM went on air in 1992 and UMTS became operational in 2002. Now it’s 2008 and LTE and mobile WiMAX are at the doorstep. While WiMAX is a bit ahead and will be used by newcomers, most incumbent operators will probably opt for LTE which in my opinion won’t go live before 2010, i.e. 8 years after UMTS was generally available. And from there it will take another year or two before we see LTE devices beyond PC cards and a network coverage beyond a few major cities.