Archive for the 'VoIP Technology' Category

SIP as a foundation for building modern interactive Value Added Services (Part II)

Tuesday, January 16th, 2007 by Emmanuel Buu

Continuing my thoughts about value added services in a SIP world, I’d like to complete my idea about this subject by defining an interactive service and briefly talking about what enabling technologies and protocols are available.

So how do you define an interactive service?

I believe an interactive service has 3 main components:

  • Enables users to interact with the service or other users in real-time by an online interaction.
  • Utilizes “presence”.
  • Allows the service logic (or backend application) to send unsolicited events to the user or subscriber.

IM services like Skype, MSN and Yahoo Messenger, etc., are perfect examples of this type of service. Note that interactive services are not a new concept and many BBS in the 80s or the 90s or even terminal based services on the French Minitel used these principles already. Except that at this time there was no video transport and very crude UI and protocols. And let’s not forget that an interactive value added service willl be the combination of both interactive and value added service.

What technologies and protocols enable us to produce interactive services then?

I can summarize them like this:

  1. A user interface technology.
  2. A set of protocols to download the user interface, authenticate the user and provide a two way interactive conversation composed of media (IM, audio, video), server events and user commands.
  3. Application servers that implement the business logic and protocol connectors to interact with clients.
  4. Billing servers.

For now let’s focus on items 1 and 2. For these items there’s an obvious choice: Adobe Flash. It is a widespread UI technology and it has interactive functions provided by Flash Media Server. However, control and media transport use a proprietary protocol called RTMP based on TCP and a proprietary video codec On2. This severly limits the interoperation with other infrastucture.

We also studied the MPEG4 framework that has provisions for client/server interactive services. However, there is no known implementation of this.

Another choice was Microsoft: they prepared an alternative with XAML and its offer Microsoft Live Communication Server but it will be deployed with Vista. It will take two years for Vista to be supported enough to build mass services and we believe that HTML, Ajax will be in place already and it will be extremely difficult for XAML to take over.

Given these constrains, we decided to stick with “the triplet”: HTTP, HTML and Ajax and combine them with these great protocols:

  • XMPP: It is a very tempting choice because it has all the primitives and the extensibility built-in.
  • SIP: which provides a very good interoperability with the existing telco infrastructure.

Finally, at Ivès we chose SIP because of the reasons stated above. Without being too specific, the fact is that the MESSAGE primitive can be used for IM services, the INFO primitive can be used by the user to send commands or receive events and thus a SIP presence server can be created.

SIP as a foundation for building modern interactive Value Added Services (Part I)

Friday, January 5th, 2007 by Emmanuel Buu

The main purpose of my company, Interactivité Vidéo et Systèmes (IVèS), is to build and operate interactive video value added services (IVS). We deliberately chose SIP as the basis of the interactive part of our services. I would like to give here a broader discussion about what value added services are and what technologies they need.

What are Value Added Services?

Value added services (VAS) are not necessarily marketing buzz words. They are predefined business models and processes implemented on an IT or telecommunication infrastructure. eBay is a value added service, is another one, also. Newspapers with online subscription fees are also good examples. Their offerings have enough value in itself that customers are ready to pay for it.

They are opposed to what I call basic services. Those are multi-purpose tools that do not serve a business in particular, like E-mail, IM, Wikis, Blogs, telephone. They can either be offered for free or charged and they are not bound to any business process in particular.

And there is this so called Internet model that consists in setting up free services that capture a lot of audience then generate revenue streams by selling advertisement space. It allowed a surprising number of businesses and non-profit organizations to grow and have the venture capitalists interested in it. These type of companies range from the Web 2.0 kind(like You Tube, Daily Motion or NetVibes) to community services like Wikipedia. They are not easy to categorize. Some of them can potentially turn into value added services (like YouTube broadcasting content for TV companies). Some introduce innovative concepts (like location based services, tagging, social networking). Some of these are financed by wealthy investors. When such services are useful or attractive to users, they add value to the Internet as a whole, ultimately justifying the fees paid for Internet access that finance the Network evolution and deployment.

We believe at IVèS that there is a confluence of factors that will make a new wave of interactive Value Added Services emerge: The high speed Internet connectivity access is spreading, the mobile data networks are maturing, the technology is already here and oil prices are making travel more expensive.

Signaling Links: SIP vs. SS7

Thursday, January 4th, 2007 by Emmanuel Buu

Traditional telephony links together SS7 switches using permanent, static connections. These are commonly referred as signaling links. The SS7 protocol (MTP2 and MTP3) has robust keep-alive and error correction mechanisms.

On the contrary, most of the SIP signaling links are done using UDP. So a lot of error correction and retransmission has to be done using the SIP protocol to account for the unreliability of the UDP protocol. SIP over TCP is possible but I would rather make it the standard. I would improve the RFC to impose permanent connection between user agents and registrar and whenever it is possible, make permanent TCP connection between SIP proxies. TCP keepalive should be mandatory for those connection. As a side effect, this would also help the NAT traversal for SIP.

For interdomain SIP communication, where the destination proxy is determined by a DNS SRV lookup, proxy to proxy connection needs to be made only when a SIP session between the two domains is initiated. I would make the connection linger and the reused in case of subsequent calls.

I dream of the day I can use SCTP for proxy to proxy connections (instead of TCP) but this is still a very “exotic” protocol.

Fax over IP: How does it really work?

Friday, September 22nd, 2006 by Martin Cadirola

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 .

Troubleshooting VoIP: What is Dead Air?

Wednesday, 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!