[May 03, 2007]

Collapsing the SIP Trapezoid

By Medhavi Bhatia

One of the biggest success stories in the internet and telecom space over the last few years has been SIP

. With gazillions of IETF drafts and millions of lines of code written in a short span of time, it has been one of the most elaborate projects undertaken by its collaborators which come from industry, educational institutions and enthusiasts. Thanks to all this hard work, SIP can now be found in all realms of the universe.

Everyone makes mistakes and the inventors of SIP have had their share so far. One of these was not to properly account for NATs when designing the protocol. This was quite expected since NATs were pretty much ignored by everybody at the time. The wide popularity of browsers and the ease of client/server computing model allowed NATs to proliferate. The internet was starved for IP

addresses and no one really tracked how NATs solved the problem as long as they did. Then, as more collaborative P2P applications like music sharing and gaming started to catch on everyone was trying to solve the same problems again and again: all these applications involved designing new protocols to work with hosts behind NATs. SIP was no stranger. The protocol received numerous bug fixes, patches and extensions to allow hosts behind NATs to speak SIP with their peers and servers outside. These changes, often complicated, allowed SIP�s trapezoid model to work in an end to end fashion. The interesting thing observed by the P2P community was that while the SIP control connection hopped through at least one server, the bearer path of the trapezoid (usually media) was a direct P2P connection between the end hosts behind NATs. The mechanism to establish the bearer path was called ICE and it was designed in a sufficiently general way to allow virtually any protocol, even SIP to be signaled on the bearer path. This was fundamental. The rest is just details.

The connection established by the SIP/ICE combo is a precious since any packets sent on that connection arrive at the other end in a true P2P fashion. In fact any protocol capable of working directly between end hosts could be multiplexed with ICE on such a connection. Examples not only include P2P protocols like Chord, Kademlia, Pastry and gaming protocols but SIP as well. The only requirement is that all these protocols should be able to multiplex on this connection with the control protocol which is SIP/ICE.

The good news: these connections can be established on demand or kept alive for long periods of time. In turn they can be used to generate new P2P connections. The bad news: this is all quite complicated. Well, a lesson hard learned. A new working group, appropriately called BEHAVE, has since been started in the IETF to give guidance to NAT

vendors to design P2P friendly NATs. Several other IETF working groups including the newly started P2PSIP group are looking at designing the P2P protocols and SIP extensions required to make them work.

Medhavi Bhatia is the CTO and co-founder of 3CLogic (www.3clogic.com), a Rockville, MD based startup which provides real-time P2P enabled applications for enterprises and large networks.