The Session Initiation Protocol (SIP) is becoming the lingua franca of the telecommunications world. It began as a simple peer-to-peer protocol, but has since gone in all kinds of directions and now forms the underpinning for the emerging next generation of telecommunications networks. Many SIP standards have been developed by the Internet Engineering Task Force (IETF) and other standards groups such as the Third Generation Partnership Project (3GPP) and the European Telecommunications Standards Institute (ETSI) have also weighed in with SIP related specifications. As a result, many vendors have chosen to implement SIP, but often the different implementations do not interoperate.
If you are a carrier or systems integrator and need to make all of these SIP entities work together, what can you do? Welcome to the new world of SIP mediation. SIP is a standard, but there is often a need for SIP mediation to translate vendor A's version of SIP into a version understood by Vendor B. As a result, there is a fast growing business in the area of Border Elements in order to convert between the different flavors of SIP. Sometimes the border element is standalone; often it will be built into another network component such as a transcoding gateway. These issues are even more complex if one of the SIP entities supports SIP-I rather than SIP. As I discussed in a recent post, SIP-I is a variant of SIP that has been designed to embed information from SS7 networks and place the details in an attachment to the SIP session. By default, the two parties will negotiate, one will say they support SIP-I rather than plain old SIP and that will be the end of the conversation. Unless-you can find a way to convert SIP to 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 Mobile Switching Center (MSC) that supports SIP-I. The tricky part is: How do you create SIP-I from SIP? There are no direct standards on how to do this, but the standards that map between SS7's ISDN User Part (ISUP) call control and SIP work in both directions, so it is possible to convert SIP messages into ISUP messages and then convert ISUP messages into SIP-I messages. This may sound like there is a need to implement back-to-back gateways, but a smarter approach is to embed the ISUP conversion into the gateway or border element, and convert directly from SIP to SIP-I.
Is this tricky? You bet. I recently read a vendor press release that claimed there are no ISUP standards. In reality, this isn't true at all. Three major standards bodies each developed their own different flavors of ISUP. The most common flavor is the set of Q series standards developed by the International Telecommunications Union (ITU) for international use. However, ETSI and the American National Standards Institute (ANSI) have each developed their own strains of SS7's ISDN User Part (ISUP) call control. All three of the standards suites are widely deployed and-many countries built variants on top of the standards. So, when looking for a product that can talk SIP-I, carriers and OEMs need to be careful and make sure that the product is flexible enough to be configured to support the dialect of ISUP that is used within the carrier network.
Getting back to the topic which started this discussion, in the ideal case, the SIP implementations supported within equipment from two vendors will interoperate properly. In the event they don't communicate properly, SIP mediation may be able to provide a solution. There are many vendors who will claim they can perform SIP Mediation, but given the many differences between vendor implementations, there will likely be a need for the mediating device to store and utilize profiles for each of the SIP entities which need to communicate. These issues are compounded if one of the devices supports SIP-I, since now there will also be a need to make configuration adjustments based on which version of SS7 ISUP is being used in the network where the SIP-I communications device resides.
In summary, the popularity of SIP and the many SIP related standards have created new challenges for SIP interoperability. These challenges have been magnified as newer SIP flavors such as SIP-I have been added into the mix for support of mobile networks. SIP mediation will often be required in order to translate between the SIP implementations of different vendors or to cross network boundaries. The net result should be worth the trouble, enabling carriers to maintain current revenue generating services and build new services for Voice over IP and mobile subscribers.