Kapanga Softphone, The premier SIP client supporting voice, video and fax over IP

Fax over IP is one of the great features of Kapanga Softphone. From time to time, our prospects asks us about what actual benefit our implementation of Fax over IP brings to the table. Our answer is simple: reliability.

There are two ways of sending faxes over IP; one is transporting the fax tones over RTP (Real-Time Transport Protocol) just like plugging your standard fax machine to the ATA device from your provider; the other is transporting the binary information the fax tones carry using IFP (Internet Fax Protocol). The latter method is standardized by the International Telecommunications Union (ITU) under the T.38 specification. We at Kapanga Softphone implemented T.38 support and built it into the softphone.

Why is then T.38 the recommended way to send faxes over IP? Here are a few key reasons:

1. Transporting fax tones (and tones in general) over RTP is unreliable when using voice low bit rate codecs. In other words, sending a fax using G.723 is virtually impossible due to the distortion introduced by the transcoding.

2. When a fax is traveling through RTP, even the slightest presence of echo prevents the end points from demodulating (=receiving) fax tones correctly.

3. T.38 is the preferred option for end points like softphones and media servers since generating and receiving fax tone signals in audio requires a lot of CPU power.

4. T.38 provides embedded redundancy and error correction methods, resulting in a more reliable way of transmitting fax over IP than RTP.

Thus fax sent using T.38 through an IP network will result in a very reliable solution for both sending and receiving fax .

The IP Multimedia Subsystem (IMS) is a standardized architecture that defines networks providing both mobile and fixed communications using packets (VoIP) and circuit switching (PSTN, the good old regular phone service). Using IMS, service providers can specify, design and deploy networks assuring compatibility with other IMS-based networks.

IMS also defines the fixed/mobile convergence (FMC) paradigm where users can, for example, transition transparently from wireless 802.11 (WiFi) or 802.16 (WiMAX) networks to PSTN networks using GSM or CDMA. The goal: to place a WiFi phone or video call at home through an IMS-enabled phone and then continue a conversation as one drives to work *but* without dropping the call; with an IMS-enabled phone, the phone should take care of switching between networks without letting the calling parties know about it.

Lucent’s website has a very interesting white paper about IMS and its evolution. We highly recommend it for those folks looking to understand the philosophy behind these various technologies. Have fun!

I will be visiting a few friends at VON/Boston at the Boston Convention Center next week. It’ll be interesting to see how much activity will take place this year compared to 2005. I’ll keep you posted with the newest stuff going on. If you are interested in meeting with me, send me an email to support -at- kapanga -dot- net. Cheers, Martin

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!

Most of us working in the VoIP industry understand the importance of Quality of Service (QoS) when making voice and video calls. And obviously the end-user is the one that will adopt more VoIP services as he or she perceives that there’s not much difference between a regular Telco and a VoIP provider.

There are many factors involved in QoS, many of which we will summarize in future posts in this blog. In the mean time, I recommend you check out Brix Networks’ TestYourVoIP site. It has a cool web-based Java applet that measures voice MOS Score in real-time by simulating a phone call to different destinations. You can also test IP Video using their sister site, TestYourIPVideo. The most interesting application is the “Internet Phone Quality Google Gadget”, basically a little piece of software that lets you make all these measurements right from the desktop using Google Desktop. All of these tools are available for free.

Regardless of the what’s going on these days the fact is that 5 years from now, QoS (and hopefully prices) will be a lot better than today. Have you come across other VoIP tools? Please let us know!