Changes are afoot in the Internet Engineering Task Force (IETF) efforts around voice over IP (VoIP). March 2006 will probably be noted as the beginning of two important new activities there. First, the IETF has created an entire new area, called Real-Time Applications and Infrastructure (RAI), which collects all the groups working on VoIP and VoIP related technologies under a single umbrella. The second event is the formation of a new working group within that area, Session Peering for Multimedia Interconnect (SPEERMINT). As the name implies, SPEERMINT is going to be looking at SIP peering between providers.

Many Benefits
SIP peering has been a topic of conversation for some time now. There are many motivations to deploy it. The obvious one is cost reduction. When SIP peering is not used, calls between providers get routed over the public switched telephone network (PSTN), which usually incurs a cost for both providers. This cost includes the direct fees paid to the PSTN provider for interconnection, but also includes the capital and operational costs of running gateways to provide the interconnect. Doing a direct connection using SIP eliminates the need for the PSTN connectivity, immediately saving companies operating costs. SIP peering can also greatly improve voice quality. Without SIP peering, calls between two SIP providers will require transcoding to G.711 going into the PSTN, and transcoding back coming out. This is not an issue if the transmission was using G.711 to begin with, but if it wasn’’t, transcoding greatly reduces the voice quality. Regardless of transcoding, the gateways are likely to introduce delay into the system, as they’ll need to provide an additional set of jitter buffers. Worse yet, PSTN-based interconnects make it impossible to use wideband speech codecs. These codecs provide better-than-PSTN voice quality, and they are the source of the much-praised voice quality of Skype. With SIP peering, these codecs can be used for inter-provider calls. Without SIP peering, they can’t. The difference between wideband and narrowband speech is huge it’s like the difference between HDTV and TV. Wideband speech has the potential to be a significant differentiator for VoIP, and it cannot be realized without SIP peering. SIP peering also allows for services beyond voice to work between providers. Indeed, the whole promise of SIP is to bring new services to telecommunications. Video, presence, and instant messaging, for example, are all possible with SIP, but none of them work when two SIP providers interconnect via the PSTN.

No Extensions Necessary
But what does SIP peering mean? Is there some new special protocol required for SIP peering? What problems does peering introduce that aren’t already covered by the existing specifications and products? Those are good questions. First and foremost, SIP peering does not require any new extensions to SIP. The ability to interconnect provider networks is built into the SIP protocol itself. There is a common misconception that SIP peering requires some kind of special profiling of SIP in order to provide interoperability. That is simply not true. SIP was designed to interoperate, even among implementations that support different extensions and capabilities. SIP networks are interconnecting today without additional extensions. SIP has built-in negotiation capabilities that allow fallback to a common baseline set of capabilities when there is mismatch between sides. As an example, SIP has an extension for preconditions (RFC 3312), which makes sure that a call proceeds only if a quality of service (QoS) reservation exists between the endpoints. What happens if only one side supports the extension? If implementations follow the specifications, they will correctly fall back to baseline operation without this feature. Now, some will argue that this is a problem. “We need this feature to always be used between our networks!” they’ll say. The interesting thing is, the extension is implemented at the endpoints, not in the network servers. Thus, a SIP “profile” that mandates usage of the extension could not be applied to the SIP servers doing the interconnection. Fortunately, the SPEERMINT working group has recognized that SIP peering is not about SIP profiling. Its charter explicitly rules profiling as out of scope, in fact. So, if SIP peering is not about a SIP profile, what is it about?

Improved Procedures
For the most part, SIP peering is about putting in place a set of best practices and operational procedures for the interconnection. Examples might include the following:

• For call routing — using carrier telephone number mapping (ENUM) to find the terminating provider.
  
  
• For accounting — keeping tabs on the calls between providers so they can reconcile bills, if needed.
  
  
• For security — using existing SIP security mechanisms, such as transparent LAN services (TLS) and SIP Identity.

Those practices don’t manifest themselves as new protocol extensions, but rather, as capabilities in the SIP proxies that sit at the edges of the two networks and peer with each other. That’s not to say that new extensions won’t be required to solve new problems. One such example is diagnostics, the ability to trace calls to figure out which network is causing the problem. It’s important to note that SIP extensions for troubleshooting are not specific to inter-provider operation; they would be equally applicable to intra-provider troubleshooting. Indeed, drafts have been brought to the IETF on several occasions proposing such extensions. SIP peering only amplifies the need. I, for one, am excited about this new area of work in the IETF. It’s the first IETF group that is operationally focused, and its establishment signifies a maturation in SIP technology. As technologies move through the adoption curve and into the mainstream, the problems change from the basics of just making it work to the challenges of making it work reliably in a worldwide deployment. That’s where we are now with SIP.