A study on interworking between SIP and PSTN networks
Chinmay Chakraborty, GSSST dept. IIT Kharagpur, India


Abstract – The present paper suggests a principle applicable to internetworking between two networks. This principle helps to resolve specific problem of internetworking between PSTN and IP networks. Session Initiation Protocol (SIP) is an application level signaling protocol used in Internet telephony architecture. The Objective of the paper is to provide networking function (IWF) which can be converged PSTN and IP networks. The IWF is to provide signaling and traffic interworking between the two networks. The signaling messages from PSTN i.e. ISUP (ISDN User Part) is converted into SIP text based messages and vice-versa.

Keywords IWF, SIP, ISUP, VoIP, PSTN

1. Introduction
The IP telephony (VOIP) is optimized for transport of voice over IP network. It uses Session Initiation Protocol (SIP) at application layer level for signaling developed by the Internet Engineering Task Force (IETF). Though its primary role is to initiate sessions, SIP is widely used for signaling. Signaling inside PSTN is based on SS7. ISUP/SIP gateway architecture is an important element in the signaling conversion between SS7 and SIP.

Figure 1: Protocol interworking in IWF
2. Overview of SIP
The SIP protocol was formerly designed for Internet Multimedia Services like VoIP. The Session Initiation Protocol (SIP) [1] is considered to be a powerful alternative to the H.323 standard as the signaling system for the dominant Voice over IP (VolP). Session Initiation Protocol (SIP), is also an application-layer signaling protocol for
creating, modifying and terminating sessions with one or more participants.
2.1 Network Architecture
This includes Internet telephone calls, multimedia distribution, and multimedia conferences. SIP defines two preliminary classes of network entities: clients and servers. Basic entities in SIP are called User Agents (UA). They can be operated in client mode (User Agent Client, UAC), in server mode (User Agent Server, UAS) or in both modes at the same time. For reliable and flexible operation SIP needs the following servers :
• Proxy Server-forwards SIP requests and responses
• Redirect Server- provides up to date routing information as well as returns “contact this address” responses
• Registrar Server-handles location of registered messages
• Location Server- it is a SIP/SIMPLE application framework. It has also database for proxies, redirect servers and registrars
• Presence Server- it’s to make the most of users presence information in any type of internet or telecom application
• Event Server- it is used for the network element, acting as Notifier, which receives SUBSCRIBE messages for different SIP Event types, such as Registration and MWI (Message Waiting Indication)
2.2 Signaling
Typically SIP transaction is the request/response model depicted in Table 1 based on RFC 2543 by IETF [2]. Request for Comments RFC 2543 defines a set of different message headers. SIP is a text-based protocol and uses the UTF8 char set.

SIP Message Description
INVITE Invites a user to a call
ACK Used to confirm that a transaction is completed successfully
OPTIONS Used to query options & capabilities of the remote peer
BYE Used to terminate a session between user agents
CANCEL Terminates a request for a user
REGISTER Used to register the UA with location server
INFO Used for mid-session signaling
Table 1: SIP request/response model
2.3 Functions
After a request message is received and interpreted, the recipient responds with a SIP response message. The response message contains a numeric status code (three digit numbers) and its associated textual phrase. Some of these codes and their description are given in table 2.
Class Description Example
1xx Informational: Request received, continuing to process the request 100 Trying, 180 Ringing

2xx Success: The action was successfully received, understood, and accepted 200 OK

3xx Redirection: Further action needs to be taken in order to complete the request 300 Multiple choices
301 Moved Permanently
302 Moved Temporarily
4xx Client Error: The request contains bad syntax or cannot be fulfilled at this server 400 Bad Request
401Unauthorized
404 Not Found
486 Busy here
5xx Server Error: The server failed to fulfill an apparently valid request 500 Internal Server Error
503 Service Unavailable

6xx Global Failure: the request cannot be fulfilled at any server 600 Busy Everywhere
604 Does Not Exist Anywhere
Table 2: Responses

3. Overview of SS7 Signaling
3.1 Basic architecture: Common Channel Signaling System No. 7 (SS7 or C7) [3] is a global standard for telecommunications defined by the ITU-T. SS7 is a protocol for performing call establishment, billing, routing, and exchange of information in PSTN networks. The SS7 protocol is designed to facilitate these functions and to maintain the network. Message Transfer Part (MTP) [4] is divided into three levels. The lowest level - MTP layer 1 is equivalent to the OSI Physical Layer. MTP layer 1 defines the physical, electrical, and functional characteristics of the digital signaling link. The MTP layer 2 provides error detection and sequence checking, and retransmits unacknowledged messages. Finally, the MTP layer 3 defines the Signaling Network functional level for narrowband signaling links. The ISDN User Part (ISUP) defines the protocol used to set-up, manage, and release trunk circuits that carry voice and data between terminating line exchanges. ISUP is used for both ISDN and non-ISDN calls. However, the calls that originate and terminate at the same switch do not use ISUP signaling.


Figure 2: The SS7 protocol stack

3.2 SS7 messages: An SS7 message is called a signal unit (SU). There are three kinds of signal units i.e. fill-in signal units (FISU), link status signal units (LSSU) and message signal units (MSU). CRC checksum is calculated for each FISU, signaling link quality is checked continuously by both signaling points at either end of the link. LSSU carry one or two octets of link status information between signaling points at either end of a link ( shown in figure 3). The link status is used to control link alignment and to indicate the status of a signaling point. Message Signal Units (MSUs) carry all call control, database query and response, network management, and network maintenance data in the signaling information field (SIF).

4. Understanding of ISUP Message format
ISUP information is carried in the Signaling Information Field (SIF) of an MSU. The SIF contains the routing label followed by a circuit identification code (CIC). The CIC indicates the trunk circuit reserved by the originating switch to carry the call. The CIC is followed by the message type field that defines the contents of the remainder of the message. These messages are transmitted in various stages of call establishment and teardown of connections.






Figure 3: SS7 Messages


4.1 Basic Call Setup Messages in ISUP
The message type code 01 indicates that it is an IAM. This message is sent in the forward direction by each switch needed to complete the circuit between the calling party and called party until the circuit is connected to the destination switch. An IAM contains the called party number in the mandatory variable part and may contain the calling party name and number in the optional part. It has four fixed parameters, one variable parameter and some optional parameters as per the Q.763 standard [5].
Similarly, the message type code 06 and 09 indicate Address Complete Message (ACM) and Answer Message (ANM). An ACM message is sent in the backward direction to indicate that the remote end of a trunk circuit is reserved. The originating switch responds to an ACM message by connecting the calling party's line to the trunk to complete the voice circuit from the calling party to the called party. The originating switch also sends a ringing tone to the calling party's line. When the called party answers, the destination switch terminates the ringing tone and sends an ANM message to the originating switch. The originating switch initiates billing after verifying that the calling part's line is connected to the reserved trunk. The ACM consists of one fixed parameter and optional parameters. The ANM does not contain any fixed or variable parameters but it contains certain optional parameters i.e. backward call indicators, optional backward call indicators, connected number, access transport, etc. The message type code 0C indicates Release Message (REL). A REL sent in either direction indicating that the circuit is being released due to the cause indicator specified. A REL is sent when the calling or called party hangs up the call. A REL is also sent in backward direction if the called party line is busy. It has a variable part called the cause indicators and some optional parts. The MTC of 10 indicates Release Complete (RLC) message. A RLC is sent in the opposite direction of the REL to acknowledge the release of the remote end of a trunk circuit and ends the billing cycle as appropriate. It does not have any fixed or variable part but has two optional parameters.

4.2 Mapping between ISUP to SIP

This part of the article focuses on the translation of ISUP messages into SIP messages [6] and the mapping of ISUP parameters into SIP headers. The purpose of translation is to allow SIP elements (such as proxy servers ) to understand ISUP messages and make routing decisions, for ISUP calls that traverse a SIP network. The mapping between ISUP and SIP is described using PSTN to SIP call flow diagram in figure 4.


Figure 4: Call flow between PSTN and IP Network

Procedure
• When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the signaling gateway.
• On receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node.
• On receipt of a provisional response of 180 or greater, the gateway will generate an ACM message. If the response is not 180, the ACM will carry a called party status value of no indication.
• After an ACM is sent, all provisional responses will be translate into ISUP CPG messages
• When the SIP node answers the call, it will send a 200 OK message.
• On receipt of the 200 OK messages, the gateway will send an ANM message towards the ISUP node.
• The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
• On receipt of the REL, the gateway sends BYE to SIP node and sends RLC message to ISUP node to acknowledge REL.
4.3 Algorithm for ISUP to SIP conversion
The IWF should convert incoming ISUP message to SIP message. The procedure for the conversion is shown in figure 5 as a flowchart diagram. If any ISUP message comes, the gateway identifies the type of the message.
• When IAM message is received, the called party and the calling party numbers are decoded and converted into To and From headers of SIP INVITE message.
• If ACM message is received, a provisional response of 18x class should be sent to the SIP network. If the ACM contains a backward call indicator parameter with a value of `subscriber free ', the soft-switch should send a `180 Ringing' response.
• When ANM is received, the call has been answered and thus `200 OK 'response should be sent to the SIP network. This 200 OK should contain an answer to the media offered in the INVITE.
• If CPG is received, a provisional response of 18x will be sent to SIP side, depending on the event information present in the CPG message.
• When REL is received, the gateway maps the ISDN cause codes to SIP messages. ISUP contains a set of messages used for maintenance purposes. They are received during the any ongoing call.
The mappings of all the ISUP parameter values are defined in RFC 3398 [7].


There are three kinds of maintenance messages, continuity check messages, messages for blocking circuits, messages for resetting circuits. Continuity check and blocking circuit messages have no corresponding SIP actions. Upon reception of the reset message for a circuit currently being used by the gateway for a call, the call must be released immediately. The gateway should behave as if a REL had been received, a BYE or CANCEL message is send (depending on the status of the call) to SIP side and RLC must be send to PSTN side. Blocking messages indicate that the circuit is to be blocked for any subsequent calls, but these messages do not affect any ongoing call. The gateway sends a blocking acknowledgement message to the PSTN side. This requires no corresponding SIP actions. When a continuity check message is received, the gateway should not send any corresponding SIP messages. The scope of the continuity check applies only to the PSTN trunks, not to any IP media paths.




Figure 5: Flowchart for ISUP to SIP mapping
4.4 Call flow between SIP to ISUP
The work is focused on mapping between the two signaling protocols: the SIP and the ISUP [8]. The SIP to PSTN call flow is described in the figure 6.

Figure 6: SIP to PSTN call flow


Message flow
• When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
• Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
• The remote ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message.
• The called party status code in the ACM message is mapped to a SIP provisional response.
• The remote ISUP node may issue a Call Progress (CPG) messages to indicate a change in the progress of the call, for example, that the call is being forwarded.
• Upon receipt of a CPG message, the gateway will map the event code to a SIP provisional response.
• Once the PSTN user answers, an Answer (ANM) message will be sent to the gateway.
• Upon receipt of the ANM, the gateway will send a 200 message to the SIP node.
• The SIP node, upon receiving an INVITE final response (200), will send an ACK to acknowledge receipt.
• Upon receipt of the BYE, the gateway sends 200 to SIP node and sends REL message to ISUP node.
• PSTN node will send RLC message to the gateway to acknowledge REL.
4.5 Algorithm for SIP to ISUP conversion
The IWF should be able to convert SIP messages to ISUP messages also. If any SIP message comes, first the gateway identifies the type of SIP message whether it is request or response message. If the INVITE request method is received, then the headers in the INVITE message should be converted to the parameters of IAM message and store the parameters in the database, these parameters are useful in processing further messages. The gateway will send the IAM message to the PSTN node. If 18x provisional responses are received, the response code should be converted to called party status parameter and the gateway will send the ACM message. If ACM message is already sent, then CPG message will be send to PSTN side. If 3xx, a redirection response message is received, the gateway should try to reach the destination by sending one or more new call setup messages using URI's found in the response message. If response code of 400 or greater is received, then the INVITE previously sent by the gateway should release the resources and send a REL to the PSTN and ACK to SIP network.
The mapping of messages and response codes are defined in RFC 3398 [2].
Example
IAM to INVITE mapping
When an IAM arrives at the gateway, a SIP INVITE message must be created for transmission to the SIP network. Here the gateway populates the fields of the INVITE based on parameters found within the IAM. The procedure for this conversion is shown in figure 8 as a flow chart diagram. IAM message has four fixed and one variable parameter and also five mandatory and few optional parameters. The parameter indicates the desired bearer characteristics of the call; the Transmission Medium Requirement is required.


Figure 7: Flowchart for SIP to ISUP mapping

The mapping of ISUP to SIP involves two steps i.e. Translation of parameters and Encapsulation of ISUP Message in SIP message.

Translation of parameters:
The called party and calling party numbers in IAM message are mapped primarily to two URI's in the INVITE message. The called party number is mapped to the To header field and the calling party number is mapped to the From header field. For this mapping soft switch uses ENUM (Telephone Number Mapping) database, where all the contact details of all the registered users will be stored. The soft switch will query the ENUM database to resolve the called party number to a URI.
Encapsulation of ISUP Message in SIP message: Some of the parameters need not to be translated in order to achieve the goals of SIP to ISUP mapping. So, the soft switch might package the ISUP message into the same SIP message by using the Multipurpose Internet Mail Extensions (MIME) multi part format [9]. Thus, the transparency of ISUP message is ensured through an IP network.

Conclusion
In this paper, decoding of the ISUP message has been presented. Since the IP telephony industry has strongly embraced SIP, it’s necessary for conversion between ISUP and IP to have compatibility with the existing networks. Now-a- days, it’s still very much in the developing phase. The potential problems exist when the soft switch network provides a transit function between PSTN and SIP based VoIP networks. The soft-switch (SIP (--) ISUP) approach will be the best choice for smooth migration to the Next Generation Networks.


References

[1] IETF: Session Initiation Protocol, IETF RFC 3261.
[2] IETF: Session Initiation Protocol, RFC 2543.
[3] www.pt.com
[4] ITU-T Q.703 “Specifications of Signaling System No. 7 - Message Transfer Part “, Dec 99.
[5] ITU-T Q.763 “Signalling System No. 7 – ISDN user part formats and codes “, Dec 99.
[6] RFC 3666 A. Johnston et al., “Session Initiation Protocol (SIP) Public Switched Tele phone Network (PSTN) Call Flows ”, IETF RFC 3666, Dec 2003.
[7] G.Camarillo et al. Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping ", IETF RFC 3398, Nov 2002.
[8] RFC 3372 A. Vemuri et al., “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures”, IETF RFC 3372, Sept 02.
[9] ZIMMERER, E., et al.: 'MIME media types for ISUP and QSIG objects'. RFC 3204, IETF, December 2001.