Category: Wireless VoIP

Intercepting VoIP Calls with Wireshark

Wireshark_call_trace
In case you have an Nokia N95 or similar SIP capable 3G / Wifi / VoIP phone and wondered why the little icon during a VoIP call shows an ‘open lock’, the answer is simple: The encoded voice data is not end-to-end encrypted. That means that anyone on the network between you and the other party who can intercept the data packets can listen to your conversation.

Sounds difficult to do in practice? Well, not really. I recently discovered that Wireshark, a free network monitoring tool, can decode G.711 PCM encoded speech data of SIP VoIP calls as shown in the picture on the left.

Just to be clear, this is not the fault of Nokia as I haven’t seen any other SIP client in practice yet that encrypts the voice data stream. In a public Wifi hotspot, intercepting the call and listening to the conversation is very simple, as the data packets are not encrypted between the device and the Wifi access point. In home networks, things get more difficult because most people nowadays have encryption between their devices and the Wifi access point enabled. But do you know what happens on the other side of your DSL connection…?

3GPP Moves On: LTE-Advanced

LTE is not yet even deployed and the 3GPP  Third Generation Partnership Project) is already  thinking about how to further evolve the technology. A main driver is probably the ITU (International Telecommunication Union), who will in due time release their requirements for so called IMT-Advanced 4G wireless systems.

It is quite certain that in terms of bandwidth, LTE and all other beyond 3G wireless systems such as the current WiMAX 802.16-2005 (802.16e) specification will fall short of the ITU requirements, which will probably be in the range of 100 MBit/s to 1 GBit/s. A very ambitious goal. Earlier this month, 3GPP hosted an IMT-Advanced workshop in Shenzen to which 170 representatives of network vendors and network operators from all over the world attended.

Not much has been reported about it yet in the news or on blogs, so one could think they are working in the shadows. But far from that, the 3GPP website reported on it here and all papers presented during the workshop and a report can be downloaded from here. Tons of information! Compared to other standards bodies that keep their proceedings to themselves, it is great to see 3GPP is so openly distributing their information. They set a good example!

The following bullets list some of the first ideas for LTE-Advanced presented during the meeting to comply with the likely requirements of IMT-Advanced. During the meeting it was decided to officially gather and approve them in 3GPP TR 36.913 over the coming months:

  • LTE advanced shall be backwards compatible to LTE (i.e. like HSPA is backwards compatible to UMTS)
  • Primary focus should be on low mobility users in order to reach ITU-Advanced data rates.
  • Use of channel bandwidths beyond 20 MHz currently standardized for LTE (e.g. 50 MHz, 100 MHz).
  • Increase the number of antennas for MIMO beyond what is currently specified in LTE
  • Combine MIMO with beamforming.
  • Further increase in Voice over IP capacity
  • Further improved cell edge data rates
  • Improved self configuration of the network

Very ambitious goals, given that vendors are still working on the challenges of LTE. But then, what would the world be without ambitious goals?

Thanks to Zahid Ghadialy and his post on his ‘3G and 4G Wireless Blog’ for the pointer!

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 🙂

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.

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 🙂

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.

Will Femtos Be More Successful than UMA?

Recently, Telecom Italia Mobile (TIM) and BT, two of the three tier one operators in Europe who’ve adopted Unlicensed Mobile Access (UMA) have decided to ditch the fixed/mobile convergence service. I wonder what that spells for the future uptake of 3G femtocells!?

While femtos are based on an entirely different technology, their value proposition seems to go in same direction: Replacement of the fixed line telephony service and better indoor coverage. Looks like users are not ready for it yet. So what’s your opinion, why should femtos be more successful than UMA?

Draft 802.11n Devices Must Implement 802.11e QoS

It’s good to see that both the IEEE 802.11n draft Standard and the Wifi-Alliance certification program require that future draft 802.11n Wifi devices also have to support the 802.11e QoS standard, sometimes also referred to as Wireless Multimedia (WMM).

WMM introduces Quality of Service for the Wifi Air Interface which means certain traffic flows can be prioritized over others. This is important for example when high bandwidth streaming and several phone calls are to be carried over the same wireless access point simultaneously.

By requiring QoS support from 802.11n devices I think this functionality has a real chance to become widespread in a relatively short amount of time which would probably not have happened otherwise.

Sources:

  • The 802.11n draft standard which confirms this in several paragraphs, like for example in a quite simple and not very easy to understand statement in chapter 5.2.8: "An HT STA is also a QoS STA"

For further information on WMM and how applications can use the functionality take a look at this previous blog entry.

VoIP’s problem with Wifi

A couple of months ago I’ve been reporting about my experiences with the UTStarCom F1000G Wifi VoIP phone. It went back into the box basically because the software was too unstable. Another reason I didn’t like the phone at the time was that the Wifi reception of the phone was not very strong and voice quality suffered when only two walls were between the access point and the phone. At the time I thought this issue might be related to this type of phone only. Now one of my friends reports that he has the same problem with Nokia E-series phone he tried out. While stability was not the issue, voice quality degrades pretty quickly when moving away from the access point. He also came to the conclusion that the range is no match to those of DECT cordless phones. Looks like good Wifi antennas have not yet found their way into small form factor phones. However, I am afraid that’s a necessity to make VoIP over Wifi work.

How Do You Hand Over A 4G Voice Call to 2G?

WiMAX, LTE, UMB, etc. etc., buzz words in the emerging 4G wireless space. Different interests, standardization groups and politics but they all have one thing in common: All are based on IP and all will rely on Voice over IP (VoIP) in one form or another (e.g. IMS or SIP) to carry voice calls. With sheer bandwidth, IP header compression and optimized handover strategies between cells I can imagine it happening. But what happens when you run out of network coverage and only a GSM network is available to continue the call in?

A number of alternatives exist. The first one might be evolved EDGE which could deliver GPRS data rates high enough to sustain a VoIP call begun in a 4G network on the packet switched side of the network. However, I wouldn’t bet on this one happening everywhere. It’s more likely that the VoIP call must be continued in the circuit switched side of the GSM network. But how can that be done?

Voice Call Continuity (VCC) could come to the rescue. A first version is already standardized in 3GPP TS 23.206 and it can do this and many other interesting things. I’ve done a short intro on VCC before, take a look here. Yes, it’s standardized but it’s not a home run:

One of the problems with VCC is that the mobile needs to be connected to both the 4G network and the GSM network at the same time to perform a handover. This consumes more energy then only being connected to one network at a time. Furthermore, such a dual connection might be difficult to establish if the two networks use the same frequency band. If the 4G network is deployed in the 2.5 or 3.5 GHz band then this is not going to be a problem. In case classic 2G frequency bands (850, 900, 1800, 1900 MHz) are partly re-farmed and the GSM network to be handed over to is nearby then VCC will become a challenge. 3GPP Release 8 might yet get a work item to study the possibility of single radio VCC (SR-VCC) to deal with these issues and I am looking forward to see how handover speeds in the order of a few hundred milliseconds can be achieved.

Summary

All-IP wireless networks will be a great thing to have but solving the handover to legacy wireless networks to prevent calls from dropping is going to be a difficult thing.