There is strong momentum in the telecom industry as carriers make the shifts to providing voice and other services over an emerging SIP network infrastructure. However, there is a large class of customers whose phones are circuit-based and a tremendous amount of existing circuit-switched infrastructure that will be in the carrier networks for years to come. One of the challenges for carriers is to transition in stages to a SIP-based core network and related applications, while leveraging existing infrastructure and providing a package of services for both traditional and IP phone users. One of the keys to accomplishing this is by providing support for interworking between the traditional circuit-switched signaling methods and SIP. In particular, the SS7 (Signaling System 7) signaling approach is widely deployed on telephone switches that were deployed during the past twenty years.
A variety of standards groups have taken on the challenge of providing interworking between the large SS7 install base and SIP. (define - news - alert) In this article, we will review the various efforts that have been made in standards bodies to address these needs and consider typical use cases on how SIP and SS7 can be used together to provide connectivity and voice services for both IP and circuit switched users.
SS7 and Voice-over-IP
The SS7 network emerged in the 1980’s as carriers began to design their networks in a way that would be more friendly toward the development of various enhanced services. SS7 followed earlier technologies like the Integrated Services Digital Network (ISDN), but was different in that SS7 utilized a separate overlay network for signaling, so that it would be possible for signals and media (for example, voice or fax) to follow separate pathways when traversing the public circuit-switched network. By separating the signaling from the media path, it was possible to improve network efficiency, evolve more complex services and offer extra protection for signaling within network equipment.
The greatest success story of SS7 to date has been in providing the signaling infrastructure that is used for virtually all cellular wireless calls worldwide. However, SS7 is also widely used in the landline circuit network, also known as the Public Switched Telephone Network (PSTN). The use of SS7 can vary greatly. For example, the SS7 ISDN User Part (ISUP) is a call control protocol and is primarily used for setting up and tearing down calls, albeit with much more information being contained about the calls than was commonly the case on earlier networks like ISDN. Another common use of SS7 is for database access applications. Here, the Transaction Capabilities Application Part (TCAP) plays a key role by enabling the lookup of database information that is commonly used for applications such as local number portability.
As SIP has become the mainstream protocol for VoIP, the need arose for SIP-based equipment to interwork with virtually all of the existing PSTN protocols. Among these, SS7 is arguably the most important, since it was the last of the major PSTN protocols to emerge and is widely used for all kinds of existing enhanced services in both landline and wireless applications. In line with this, there has been a great deal of standards work done by a variety of different bodies to enable effective interworking between SS7 and SIP (see Table 1). In the sections to follow, we will examine the most important of these standards developments and discuss the current state of deployments.
In the Land of RFCs
The Internet Engineering Task Force (IETF) is the place where SIP originated and where most of the related standards development takes place. The standards produced by the IETF are known as standards track Request for Comments (RFC) documents. The primary RFC document on SIP to SS7 interworking is RFC 3398. This standard was one of the early efforts of the SIPPING working group and its focus is on mapping ISUP messages to SIP messages, and ISUP parameters to SIP headers. This kind of mapping is often implemented via a media or signaling gateway for cases where phone calls are being transported between an SS7 network and a SIP network.
One of the challenges in ISUP to SIP mapping is the existence of several SS7 variants. The most common variants are those of the International Telecommunications Union (ITU) and the American National Standards Institute (ANSI). However, other variants are also possible. RFC 3398 makes some simplifying assumptions to deal with this; it provides its mapping based on the ITU version of ISUP and then offers guidelines on some differences which may occur in other versions.
An example of the mapping of a SIP session to an ISUP session using these conventions can be found in Figure 1.
A key part of this translation is to take the headers of the SIP Invite and then use mapping conventions in order to populate the parameters of the equivalent ISUP setup message, which is called the IAM, or Initial Address Message.
RFC 3398 provides a basic guide to interworking between SIP and ISUP, but it turns out that there are also other RFCs that can help in providing a more robust implementation. For example, there is an RFC 3326 that provides a SIP header that allows ISUP cause codes to be transmitted via SIP, thus offering some additional information to the gateway about what is actually taking place at different stages of an ISUP call, such as at the time of a call release. Support for these RFCs is provided in some existing gateway products, such as the Cantata IMG1010.
Union of the Parts
The International Telecommunications Union was the key originating standards body for SS7 and has produced its own standards document offering guidance on translation between ISUP and SIP. The document is known as the Q.1912.5 recommendation. It maps the two protocols and addresses additional details that enable additional ISUP functionality to be translated for use in the SIP network. For example, there has been a lot of work done in both SIP and ISUP to support asserted identities and address related privacy issues. If a subscriber has requested a service that calls for suppression of caller identification information, there are ways to reflect this in the ISUP messages. Further, there are equivalent mechanisms in SIP which are described in RFCs 3323 and 3325. The challenge is to be able to effectively translate between these two representations. The Q.1912.5 document provides implementers advice on how to do this, but stopped short of fully supporting the ISUP service known as COLP/COLR which addresses these matters.
There is also a method called overlap signaling that is used in some variants of ISUP. The mapping of this signaling was not addressed at all in RFC 3398, but guidance is provided within Q.1912.5 on how to take this information and take appropriate actions on the SIP side.
Q.1912.5 document also makes reference to an approach which is known as SIP-T by the IETF and SIP-I by the ITU. In this instance, SIP is used as a tunneling method to transport the full set of ISUP headers from one SIP-T enabled entity to another. SIP-T is a preferred approach for bridging ISUP networks via IP, since none of the ISUP header content is lost in translation to SIP headers. By contrast, the typical mapping of ISUP to SIP causes about 80% of the ISUP parameter information to be left behind.
All in all, this recommendation provides a useful complement to RFC 3398 that will allow a SIP — ISUP gateway to offer a richer, more complete translation between the two protocols. There is deployment of this recommendation, but its use has been less prevalent than that of RFC 3398.
IMS — Convergence of the Species
In recent years, there has been a lot of discussion about a new approach to using the SIP standards that is known as the IP Multimedia Subsystem or IMS. IMS attempts to take the SIP standards and put them in a framework that is suitable for developing a variety of enhanced services, not only for voice but for other types of media. One of the key concepts of IMS is that the services should be provided independent of the type of access that is used. So, for example, one could have a voice mail service in IMS that can be used whether a call originates from a cellular wireless, traditional landline or WiFi hot-spot.
IMS began as an effort to provide services for next generation wireless networks, but there was an understanding from the beginning that many calls would originate on the existing SS7 network. In IMS, there is a Media Gateway Control Function that is used to intermediate between the worlds of ISUP and SIP. A key focus of this function is to perform signaling conversion between ISUP and SIP. Some implementers also choose to combine both this function and the Media Gateway media conversion function within the same system. The basic concept is to take a call as it comes in from the SS7 network and then convert it to SIP on the edge of the IMS network. From this point forward, the signaling is based on SIP and the media has been packetized. This allows the call to interact with various SIP enabled Application Servers and other IMS entities such as the Media Resource Function (MRF) to actually execute a service such as voice mail or video mail (see Figure 2).
In order to accomplish the interworking between ISUP and SIP, the Third Generation Partnership Project (3GPP) has devised its own set of documents that guide the translation. Some of the key documents in the IMS that are related to this activity are 29.163 on interworking between the IMS and circuit networks, and 24.406 on voice call continuity between cellular and IMS networks. From a technical perspective, the 3GPP work builds on the ITU-T Q.1912.5 recommendation and is closely aligned to it. However, it has gone beyond the earlier document in some respects. For example, it has taken some steps to formalize mapping support for asserted identity and privacy services on the ISUP side that were not fully addressed in the earlier specification.
Since the related 3GPP standards work is still underway, deployment of these specifications is at an earlier stage than the previously discussed documents, but implementers of the SIP to ISUP interworking as defined in Q.1912.5 are already close to compliance with the 3GPP document.
Summary
In the circuit-switched world, SS7 signaling has been used to provide a wide variety of services for both wireless and landline users, including such popular features as local number portability. Since there will be a co-existence of the circuit-based and SIP networks for many years to come, it is important that devices such as media and signaling gateways can provide ways to support calls that need to cross the boundaries of these two networks. As reviewed in this article, the IETF, ITU and 3GPP standards organizations have all developed standards to aid implementers in converting SS7 ISUP into SIP and vice versa. As a result, vendors have been able to provide products that provide ISUP to SIP signaling conversion at the boundaries between networks. This allows carriers to leverage their current SS7 infrastructure and execute a measured transition in the deployment of SIPbased network elements and services.
Industry legend James Rafferty is the Senior Product Manager for IP Telephony at Cantata Technology (news - alert) (http://www.cantata.com). He is responsible for the company’s IP and carrier voice product lines. James is also active in the IP Telephony standards process through his work with the MEGACO working group of the Internet Engineering Task Force and related contributions to ITU-T Study Group 16.
|
SUBSCRIPTIONS
TMCnet LOGIN
WEBINARS
