WirelessMoves

Why Are We Still Using Narrow Band Codecs for SIP to SIP Calls?

I really like the SIP Voice over IP implementation of the Wifi enabled Nokia Nseries phones such as the N95 and the N82. After all, they save me a lot of money these days as SIP to SIP calls for example even between different operators are free. On first thought, voice quality seems to be excellent, I can't tell the difference between a VoIP call and a traditional circuit switched call over a cellular network. But put into a different perspetive, that's a bit short sighted. For direct SIP to SIP calls that do not cross a circuit switched interface, why do the two SIP clients still use the backwards compatible G.711 narrow band voice codec released in 1972 or the narrowband AMR (Adaptive Multi Rate) codecs? Today, much better codecs such as Wideband AMR (AMR-WB) are available that have a similar audio quality as Skype to Skype calls. So why are we still stuck with a narrow band encoding? It can't be computing power, especially in the case of high end Nseries phones. Maybe license or patent issues? Ideas, anyone?

SIP providers miss a great opportunity to go beyond the limitations of circuit switched networks and offer subscribers a superior experience for direct VoIP to VoIP calls. And I think it would be a good selling argument once suddenly for some connections you have a much better audio quality than to someone still stuck in the circuit switched world (or in a SIP network that is not interconnected and thus has to use a circuit bridge). I can very well imagine that at some point conversations would start with "oh, you are still on an old phone line" :-)

P.S.: Some details: The N95 SIP client supports AMR, G.711 a- and my-law, iLBC and G.729. All narrowband...

The Nokia 6300i and VoIP over Wifi

Back in April this year, Nokia announced the 6300i that comes with Wifi and VoIP (but no 3G support). At the time, it was not quite certain from the press release what kind of VoIP the phone would offer. Now that the mobile is available, the user guide gives further details on page 30. The word SIP is never used but based on the configuration information, it certainly looks like SIP like on the Nseries phones and not like UMA. For UMA, the 6300i seems to have a brother, the 6301. Together with Firmware Over the Air (FOTA) update capability, and Opera Mini coming pre-installed, it looks like Nokia has started an interesting test balloon in the sub 200 euro category (Amazon Germany has it for 179 euros, taxes and shipping included!). I'd really like to try the VoIP implementation. I wonder if it is as good as that of the N95? Or maybe even better?

CS Voice (And Other Services) over LTE

I've been speculating recently how voice calls could work in next generation 3GPP LTE networks. The politically and technically foreseen way is IMS, the IP Multimedia Subsystem, and a service platform running on top of IMS such as the IMS Centralized Services (ICS). ICS is quite promising as it includes a solution to bring GSM only handsets without any IMS extensions into an overall voice solution and can hand-over voice calls from LTE to GSM when leaving the coverage area. The major drawback of ICS is its complexity and its anyone's guess when we will see this in mobile devices for the general public.

In the meantime, there has been some support in 3GPP to investigate a different solution: How to extend the current circuit switched voice service of GSM to LTE. In 3GPP a number of companies started writing some proposals, which were gathered in 3GPP TR 23.879. In this paper, the main proposal is to connect the Media Gateway part of the Circuit Switched Mobile Switching Center (MSC) to the packet core and give the the MSC Server direct access to the Mobility Management (MME) Entity of the Access Gateway to the LTE Radio network.

Place and Cost

I am at the European Telecommunication Standards Institute (ETSI) in Southern France this week and every now and then I have to give a call to some experts back in Germany. Interesting how a 5 minute call to the same number is priced depending on which calling option I use:

• Using my French SIM card in my N95: € 3.50 (70 cents a minute)
• Using my German SIM card in my N95: € 2.90 (58 cents a minute)
• Using the N95 VoIP function via the Wifi network: € 0.09 (1.79 cents a minute)
• Using the VoIP client on my PC via Wifi: € 0.00 (call is VoIP end to End)

In the end I mostly use the N95 VoIP option over Wifi as for some calls some privacy is needed which is not not provided in the meeting room where the PC is located. I could move the PC but the € 0.09 is a good tradeoff for the convenience.

I titled this post "place and cost" because it shows how cost dramatically drops when different access methods are available and compete with each other. In places with less competition like the car, the countryside, etc.) mobile operators take over and option 3 and 4 are no longer possible. Unless of course, the operator offers a reasonable 3G data plan which make VoIP calls affordable again. One might argue it is more expensive to operate nationwide mobile networks with good coverage compared to DSL networks but I doubt the difference is € 0.09 to € 3.50.

Breaking the Radio Silence with VoIP

In cellular networks, the primary rule for voice telephony is efficiency, efficiency, efficiency. Translated into practice, this means that the mobile device patiently waits till it receives a paging for an incoming call or until the user wants to establish an outgoing call. In the time between, there is complete radio silence, except for occasional short signaling exchanges once every few hours to confirm to the network that the device is still switched on. With always on mobile Internet devices, this is going to change significantly, as the following example shows:

In previous blog entries, I've described how well the SIP VoIP client works on the Nokia N95. It blends in very nicely with the rest of the phone's functionality and I can't tell the difference between a cellular call and a VoIP call over Wifi. On the radio layer, however, things could not be more different.

While the cellular telephony application remains silent while no call is ongoing, the VoIP part remains quite active on the IP layer. Per minute, there are at least 10 message exchanged between the mobile and the network for various reasons such as keeping communication ports open on NAT firewalls. While it doesn't seem to be an issue for battery capacity, as there is still ample capacity left in the evening despite being logged into the SIP server over Wifi all day,  it does have implications for cellular networks once VoIP is used there, too. While not all messages exchanged over Wifi will appear in cellular networks, at least 6 of those 10 are relevant for that scenario as well.

Today, each cell serves about 2000 users. For the network, this is not a problem since most mobiles are dormant. In a world where most mobile devices are IP enabled and use a standard SIP VoIP client, 2000 x 6 (or even more) message exchanges per minute means 12,000 message exchanges per minute over a single cell for more or less nothing.

To stay with the SIP VoIP example, here's an overview of what I traced with my Wifi Tracer during a typical 60 seconds time interval while the SIP client is running and the phone is connected to a Wifi network:

• At 7 seconds into the minute, the N95 wakes up because it receives a notification from the access point that an IP packet has arrived. It sends 'power save poll' management frame and receives an IP packet from the STUN server or the SIP server. In total, the mobile transmits 4 frames and receives 4 frames during this message exchange (including acknowledgments at the MAC layer).

• At 11 seconds into the minute, The N95 decides to return the polling gesture and sends 1 packet to the STUN server and 1 packet to the SIP server. The STUN server sends a confirmation. Afterwards, the mobile enters the Wifi sleep state and informs the network with a corresponding management frame. In total, the mobile transmits 4 frames and receives 3 frames.

• At 12 seconds into the minute, the mobile has to turn on it's transmitter again because there is some data waiting again. It sends a poll frame and receives an ARP broadcast as the access point queries all IP addresses in the subnet. The mobile answers the ARP request and goes back to sleep. In total, the mobile transmits 7 frames and receives 6 frames.

• At 16 seconds into the minute, the mobile feels a sudden urge to check that the MAC address of the router is still valid. This is as unnecessary as the ARP request from the router at 12 seconds, but it's happening at least once a minute. The mobile transmits 2 frames and receives 2 frames.

• At 22 seconds into the minute, a keep alive frame is received from the SIP or STUN server. I stop counting frames at this point.

• At 34 seconds into the minute, the router runs another ARP request for all IP addresses in the subnet.

• At 35 seconds, the SIP/STUN server sends a keep-alive frame.

• At 37 seconds, the mobile returns the favor.

• At 46 seconds, the mobile returns to sleep state and signals this to the Wifi Access Point.

• At 49 seconds, the SIP/STUN server sends a keep alive frame.

• Silence until 4 seconds into the next minute.

And now imagine you have a push eMail client and Instant messenger running, which will create even more traffic and 2000 other mobiles in the cell doing the same.

Standards bodies seem to have become aware of this issue, at least to some degree and have started to specify radio interface enhancements to counter the challenge. In case of UMTS and HSPA, the following come to mind:

• The Continuous Packet Connectivity (CPC) feature set
• Enhanced Cell-FACH
• To some degree: IMS, which probably doesn't need the polling as there is no NATing
• And finally: More use of IPv6, which reduces the need for NATing

I am not sure how LTE and WiMAX handle such very low speed but persistent message exchanges on the MAC layer. If anyone can give me pointers to that, I'd really appreciate.

Intercepting VoIP Calls with Wireshark

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.

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 :-)

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 :-)