The Session Initiation Protocol (SIP) has been a major success story for the deployment of Voice over IP networks and related enhanced services.   Until recently, there has not been much use of SIP in wireless networks, but this is starting to change.  There is a new generation of Mobile Switching Centers (MSCs) which are used to connect mobile users to a next generation wireless infrastructure based on the Internet Protocol (IP).   These MSCs use a variation of the SIP protocol known as SIP-I.   

Let's compare the traditional use of SIP within Voice over IP networks to the use of SIP-I.   Many Voice over IP networks are deployed using a SIP based core, but need to be able to connect to both SIP and traditional circuit-based subscribers.    A common way of connecting between the SIP network and the circuit-switched network is to use a media gateway.  Products such as the Dialogic® IMG 1010  Integrated Media Gateway are designed to efficiently convert between the ISDN User Part (ISUP) messages used in the SS7 network and SIP.   The most common standards used to guide such conversions are RFC 3398 from the Internet Engineering Task Force (IETF) and Q.1912.5 from the International Telecommunications Union.   This approach works well for carriers that offer voice and other value-added services based on the SIP network, but much of the information coming over from the SS7 network is lost during the conversion.   

Mobile network operators have depended a great deal on aspects of service managed by the SS7 network, so they have quite a bit at stake in finding a way to move to IP in order to gain IP's cost savings and geographic flexibility, without losing the value of their many SS7-based services.   For the MSC vendor and their wireless service provider customers, advantages of moving to IP include:  1) Ready availability of SIP-based components for lots of new revenue generating services, 2) Ability to rely on IP trunks and not require a dedicated set of circuit-switched lines to connect to the mobile core, and 3) Eliminate the need to directly support complex and expensive SS7 stacks onboard the MSC.  Hence, SIP-I.   SIP-I takes the SIP protocol based on RFC 3261 and a cavalcade of other RFCs, then adds to it the ability to transport all of the elements of an SS7 ISUP message within an attachment to the SIP message.

SIP-I had its origins in the IETF, where a specification known as SIP for Telephones (SIP-T) was specified in RFC 3372.  The ITU liked the idea of SIP plus ISUP so much that they came up with their own specification, Q.1912.5, which defines SIP-I and uses the same concept of including a MIME attachment along with the SIP message to carry the ISUP signaling content.   SIP-I has also been strongly endorsed by the Third Generation Partnership Project (3GPP) and is referenced in many of the 3GPP specifications.  

So, that must mean it's now easy to connect between the SIP network elements used in Voice over IP and the SIP-I elements used in portions of the wireless network, right?   Uh, not exactly.   SIP support is much more widespread than SIP-I and most SIP-enabled entities such as media gateways, media servers and application servers do not support SIP-I at all.   A key reason is that effective support of SIP-I requires an ISUP stack or engine that can process incoming ISUP messages and create the needed MIME attachments.  Typically a network appliance like a SIP-to-SS7 gateway comes into play if the carrier wants to convert SS7 ISUP signaling into SIP-I.  But suppose there is no direct ISUP connection at all and you still want to connect between the VoIP and mobile network?    You'll need to find a way to convert SIP into SIP-I.  

New border elements and transcoding gateways-such as Dialogic's IMG 1010-can convert SIP signaling into SIP-I and allow the two network entities to connect.  For example, an IP Centrex system using SIP could connect to mobile users within the same company by communicating with an MSC that supports SIP-I.  The tricky part is: How do you create SIP-I from SIP?    I'll talk about that in my next post.