Troubleshooting VoIP: What is Dead Air?

September 6th, 2006 by Martin Cadirola

One of the most common problems when placing/receiving VoIP calls is when a call is established but there is neither audio nor video. This condition is commonly known as “dead air”.

For those used to the old standard TDM telephony this is an uncommon situation, audio for calls is guaranteed as soon as the call is established; this is because media (audio/video) and signaling (information required to establish and terminate a call) travel typically through the same route so if there is no media, there will be no call either.

For VoIP, the route of the media is almost always completely independent from the route of the signaling. If for some reason the path for the media is broken, the call will exhibit a “dead air” condition. So what can cause the media path from being broken in first place? What should be checked in that case? Here are a few things to check for:

1. Connectivity: If the dead air is symmetrical (silence on both directions) make sure that there is connectivity with the remote media endpoint. You can check the SIP response using Ethereal to capture a network trace and determine what the remote address of the endpoint is. Then ping it.

2. Firewalls: Some VoIP providers have a specific range of RTP ports that can be used to send/receive media to/from. If the softphone is not configured correctly to use this range the media streams can be blocked. This could happen for any case of dead air; symmetric or not and even cases where audio is blocked but video is not.

3. Codec mismatchs: Another common problem that causes dead air is codec mismatch, for example if the softphone is configured to do G.723 5K3 but the endpoint is expecting G.723 6K3, all audio packets are dropped at the endpoint. Looking at a network trace captured using Ethereal should show this mismatch.

We will be writing more tips for troubleshooting VoIP, so please stay tuned!

2 Responses to “Troubleshooting VoIP: What is Dead Air?”

  1. Emmanuel BUU Says:

    IMHO, the Internet and the ISP, the router vendors should provide a better way to handle RTP connections at the network level. This NAT thing is very damaging for VoIP telephony.

    Another issue that is not mentioned here is the flow control. In traditional telephony, cicuits where synchronous. SO the bandwitth was build-in. In VoIP the flow control mechanism exists but I am not sure this is wildy implemented.

    Audio is the easy part. When in comes to video, we are not talking about “dead air” but “blank screen”. On top of all the issues that are related, there is the variety of video codecs which encoding and decoding parameters negiciations is much more complex by an order of magnitude.

  2. Cesar Says:

    Right, for traditional telephony each audio call has 64KBps reserved end-to-end. For VoIP on the public Internet, there is no real way to guarantee the bandwidth, even for the very low bit rate codecs like AMR or G.723 as the public Internet is best effort service by definition. That explains why the traditional telephony providers charge double than their VoIP counterparts for the same service.

    BTW, in the Kapanga case there is no “blank screen” but “frozen screen” :) … K reshows the last received frame!

Leave a Reply