The Interworking of ip telephony with Legacy Networks




Дата канвертавання25.04.2016
Памер55.04 Kb.
The Interworking of IP Telephony with Legacy Networks

Yang Qiu


Valmio 10/4

00380 Helsinki

Yang.Qiu@nokia.com



Abstract


This document describes the Interworking of IP Telephony networks with legacy networks. The legacy networks are PSTN, ISDN, GSM and IS-41. All of these Legacy networks use the SS7/C7's ISUP for their gateway. So, in this document we only discuss the Interworking of IP telephony signaling with ISUP.
  1. Introduction


SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It 's typically carried over IP. Telephone calls are considered as a type of multimedia sessions where just audio is exchanged.

H.323 is an ITU's Standard that specifies Packet-based multimedia communications. It's an umbrella standard that references many other ITU standards.

MGCP is the 'Media Gateway Control Protocol'. This Protocol defines the communications between Media Gateway and Call Agent, so that the Media Gateway is fully controlled by the call agent.

MEGACO is the latest generation call agent-gateway signaling protocol and standardized by ITU and IETF.

ISUP is a level 4 protocol used in SS7/C7 networks. It typically runs over MTP but it will also run over IP as well. ISUP is used for controlling telephone calls in PSTN, ISDN, GSM and IS-41.

The module performing the mapping IP telephony signaling (SIP, H.323 and MEGACO) and ISUP is usually referred to as Media Gateway Controller (MGC). It has logical interfaces towards both networks, the network carrying ISUP and the network carrying SIP, H.323 or MGCP/MEGACO.

There is typically a Media Gateway (MG) with E1/T1 interfaces (voice from PSTN) and with IP interfaces (VoIP).

The MGC and the MG can be merged together in one physical box or kept separate.

Note: Although many modes of signaling are used in normal telephony network, ISUP is the 'almighty' signaling for these networks to connect with each other. ISUP is used by PSTN, ISDN, IS-41's gateway, GSM's GMSC/MSC (not include the BSC) as their signaling.

ISDN, GSM and IS-41are represented by PSTN and ISUP is also used for connecting to other networks.

R2 is a very old signaling in the PSTN; in this document there is no intention to take it into consideration. (In UMTS All-IP Core Network, MRF is used for connection between R2 and MEGACO/H.248)

  1. Interworking between SIP and ISUP


The first step in initiation of a call-using SIP is to locate a SIP server for the callee.

Once a SIP server has been found, the client can invite the callee to join the communication session, which may be either point-to-point or may be more than 2 hosts as in a conference call scenario.


1.1SIP-ISUP Gateway


In a SIP-ISUP network, SIP should be used to provide ISUP translating across PSTN-IP networks inter-connections.

The SIP-ISUP gateway is used where an IP network (the signaling is SIP) interfaces with the PSTN network (the signaling is ISUP). Such a network may frequently be needed to hand a call over to another network in order to terminate it. Therefore, such networks do not normally exist in isolation. They have business relationships with each other, and they are connected together in order to terminate calls.

In nowadays IP networks, SIP should terminate calls directly to an end-user device that are hosted by SIP server or by the PSTN. As well, SIP/IP networks may just serve as a transit network with IP inter-connections to other networks that have ISUP interfaces. Such a transit network will accept VoIP calls from one network and pass them over to another network where they may be terminated. And, the originating network most often will not know whether the receiving (i.e. next-hop) network is a terminating network or a transit network.

1.2SIP-ISUP Network components


The following are the components of a SIP-ISUP network.

  1. PSTN: This is the Public Switched Telephone Network. It may either refer to the entire inter-connected collection of local, long-distance and international phone companies or some subsets thereof. It could be any kind of network, if they use 'MSISDN/MSIN' to locate their user.

  2. IP-endpoint: Any sort of device that originates SIP-calls to the network may be considered as an IP end-point for the purposes of this document. Thus, the following devices may classify as:

  • MGC: A Media Gateway Controller (MGC) is an entity used to control a gateway (that is typically used to provide conversion between the audio signals carried on telephone circuits and data packets carried over packet networks). The term MGC is thus used in this document to clarify entities that control the point of inter-connection between the PSTN and the IP-networks. An MGC communicates ISUP to the PSTN and SIP to the IP-networks and converts between the two.

  • SIP-phone: The term used to represent all end-user devices that originate SIP calls.

  • Firewalls or edge-elements through which calls may enter the network from that of a peer network.

  1. Proxy: A proxy is a SIP entity that helps route SIP signaling messages to their destinations. Consequently, a proxy might route SIP messages to other proxies (some of which may be co-located with firewalls), MGCs and SIP-phones.

1.3The structure of SIP-PSTN Network


In Figure 1 two LECs (Local Exchange Center) are bridged by the IP network together. SIP is employed as the VoIP protocol used to set up and tear down VoIP sessions and calls. The VoIP network receives ISUP messages over SS7/C7from one PSTN interface and sends them out to another (PSTN termination). Let say, a call originates from LEC1 and be terminated by LEC2. The originator is defined as the generator of the SIP setup signaling and the terminator is defined as the consumer of the SIP setup signaling. MGC1 is thus the originator and MGC2 becomes the terminator. One or more proxies may be used to route the call from the originator to the terminator.



Figure 1: ISUP-SIP inter-connecting

Voice calls do not always have to originate and terminate in the PSTN (via MGCs). They may either originate and/or terminate in SIP phones. The alternatives for call origination and termination suggest the following possibilities for calls that transit through an IP network.


1.4SIP to ISUP mapping


Figure 2 is the State Machine of the mapping from SIP to ISUP.



Figure 2: SIP-PSTN State machine

      1. Call setup




Figure 3: SIP-PSTN Call Flow

  1. When a SIP user tries to begin a session with a PSTN user, the SIP node issues an INVITE request.

  2. Upon receipt of an INVITE request, the gateway will then map it to an IAM message and then be sent to the ISUP network

  3. The ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message

  4. The 'called party status' code in the ACM message is mapped to a SIP provisional response and returned to the SIP node:

  • 180 for 'subscriber free'

  • 183 for ' no indication'

This response may contain SDP to establish an early media stream (as show in Figure 2). If no SDP is presented, the audio will be established in both directions after the ISUP send ANM.

  1. The SIP node sends a PRACK message to confirm receipt of the provisional response.

  2. The PRACK is confirmed

  3. The ISUP node may issue a variety of CPG messages to indicate, for example, that the call is being forwarded.

  4. Upon receipt of a CPG message, the gateway will map the event code to a SIP provisional response and send it to the SIP node.

  5. The SIP node sends a PRACK message to confirm receipt of the provisional response.

  6. The PRACK is confirmed

  7. Once the PSTN user responses, an ANM will be sent to the gateway

  8. Upon receipt of the ANM, the gateway will send a 200 message to the SIP node.

  9. The SIP node, upon receiving an INVITE final response (200), will send an ACK to acknowledge.
      1. Auto-answer Call setup




Figure 4: SIP-PSTN Call Flow (auto-answer)

  1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.

  2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network

  3. Since the ISUP node is configured for automatic answering, it will send a CON message upon receipt of the IAM. (For the ANSI C7, the message will be an ANM)

  4. Upon receipt of the CON/ANM, the gateway will send a 200 message to the SIP node.

  5. The SIP node, upon receiving an INVITE final response(200), will send an ACK to acknowledge receipt
      1. ISUP Setup Failure




Figure 5: SIP-PSTN Setup Failure

  1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.

  2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network

  3. Since the ISUP node is unable to complete the call, it will issue a REL.

  4. The gateway releases the circuit and confirms that it is available for reuse by sending an RLC.

  5. The gate translates the cause code in the REL to a SIP error response and sends it to the SIP node

  • unallocated (ISUP:1) 410 Gone

  • no route to network(ISUP:2)404 Not found

  • no route to destination(ISUP:3)404 Not found

  • user busy(ISUP:17)486 Busy here

  • no user responding(ISUP:18)480 Temporarily unavailable

  • no answer from the user (ISUP:19)480 Temporarily unavailable

  • call rejected(ISUP:21)603 Decline

  • number changed (ISUP:22)301 moved Permanently

  • Destination out of order(ISUP:27)404 Not found

  • Address incomplete(ISUP:28)484 Address incomplete

  • Facility rejected(ISUP:29)501 Not implemented

  • Normal unspecified(ISUP:31)404 Not found

  1. The SIP node sends an ACK to acknowledge receipt of the INVITE final response
      1. Call cancelled by SIP node




Figure 6: SIP-PSTN Call Cancelled

  1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.

  2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network

  3. The ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message

  4. The 'called party status' code in the ACM message is mapped to a SIP provisional response and returned to the SIP node: (180 for 'subscriber free', and 183 for ' no indication') This response may contain SDP to establish an early media stream (as show in Figure 2). If no SDP is present, the audio will be established in both directions after the ISUP send ANM.

  5. The SIP node sends a PRACK message to confirm receipt of the provisional response.

  6. The PRACK is confirmed

  7. To cancel the call before it is answered, the SIP nodes sends a CANCEL request

  8. The CANCEL request is confirmed with a 200 response

  9. Upon receipt of the CANCEL request, the gateway sends a REL message to terminate the ISUP call.

  10. The gateway sends a '487 Call Cancelled' message to the SIP node to complete the INVITE transaction.

  11. Upon receipt of the REL message, the remote ISUP node will reply with a RLC message.

  12. Upon receipt of the 487, the SIP node will confirm reception with an ACK.

1.5ISUP to SIP mapping


Figure 7 is the State Machine of the mapping from ISUP to SIP.



Figure 7: PSTN-SIP State machine

      1. Call setup




Figure 8: PSTN-SIP Call Flow

  1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.

  2. Upon receipt of an IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.

  3. By the time an event signifying that the call has sufficient addressing information , the SIP node will generate a provisional response of 180 or greater. It this 180 contains a session description.

  4. Upon 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'.

  5. The gateway sends a PRACK message to confirm receipt of the provisional response.

  6. The PRACK is confirmed

  7. The SIP node may use further provisional messages to indicate call progress.

  8. After an ACM has been sent, all provisional responses will be translated into ISUP CPG message.

  9. The gateway sends a PRACK message to confirm the receipt of the provisional response.

  10. The PRACK is then confirmed

  11. When the SIP node answers the call, it will send a 200 OK message.

  12. Upon receipt of the 200 OK message, the gateway will send an ANM message towards the ISUP node.

  13. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
      1. Auto-answer Call setup




Figure 9: PSTN-SIP Call Flow (auto-answer)

  1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.

  2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.

  3. Since the SIP node is set up to automatically answer the call, it will send a 200 OK message.

  4. Upon receipt of the 200 OK message, the gateway will send a CON message towards the ISUP node.

  5. An ACK will sent be the gateway to the SIP node to acknowledge the receipt of the INVITE final response.
      1. ISUP Setup Failure




Figure 10: PSTN-SIP Setup Failure

  1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.

  2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.

  3. The SIP node indicates an error condition by replying with a response with a code of 400 or greater.

  4. The gateway sends an ACK message to acknowledge receipt of the INVITE final response.

  5. An ISUP REL message is generated from the SIP code.
      1. Call cancelled by SIP node




Figure 11: PSTN-SIP Call Cancelled

  1. When a PSTN user tries to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.

  2. Upon receipt of the IAM message, the gateway will then generate an INVITE message, and sends it to an appropriate SIP node based on called number analysis.

  3. When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater.



  1. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message with an event code.

  2. The gateway sends a PRACK message to confirm receipt of the provisional response.

  3. The PRACK is confirmed

  4. If the calling party hanged up before the SIP node answers the call, a REL message will be generated.

  5. The gateway frees up the PSTN circuit and indicates that it is available for reuse by sending an RLC.



  1. Upon receipt of a REL message before an INVITE final response, the gateway will send a CANCEL towards the SIP node.

  2. Upon receipt of the CANCEL, the SIP node will send a 200 response.

  3. The remote SIP node will send a '487 Call Cancelled' to complete the INVITE transaction.

  4. The gateway will send an ACK to the SIP node to acknowledge the receipt of the INVITE final response.

1.6Normal Release of the connection

      1. Caller hangs up (SIP and ISUP initiated)




Figure 12: SIP Initiated

For a normal release of the call (reception of BYE), the MGC immediately sends a 200 response. It then releases the resources in the MG and sends an REL with a cause code of 16 (normal call clearing) to the PSTN. Release of resources is confirmed by the PSTN with a RLC. In SIP bridging situations, the REL contained in the BYE is sent to the PSTN.



Figure 13: ISUP Initiated
If the release of the connection was caused by the reception of a REL, the REL is included in the BYE sent by the MGC.

      1. Callee hangs up (Analog ISUP User)




Figure 14: Analog user hangs up

In analog PSTN, if the callee hanged up in the middle of a call, the local exchange sends a SUS instead of a REL and starts a timer (T6, SUS is network initiated). When the timer expires, the REL is sent.


  1. Interworking Between H.323 and ISUP

1.7 Overview of H.323 Standards


H.323 is an umbrella standard that can be referred to many other ITU standards as shown in Table 1. Call setup and control is handle by H.225.0 and H.245.

Table 1: H.323 standards

Network

Non- Guaranteed Bandwidth Packet-switched network ( e.g. IP )

Video

H.261, H.263

Audio

G.711, G.722, G.728, G.729

Call Signaling & media packetisation

H.225.0

Call control

H.245

Multipoint

H.323

Data

T.120

For the IP Telephony, we should pay more attention to the H.225.0 call setup and H.245 call control standards.

H.225:

  • Specifies call setup messages which are based on the Q.931

  • Specifies gatekeeper messages(Registration, Admissions and Status)

  • Describes the use of RTP

H.225 specifies a subset of Q.931 messages that can be used by H.323 implementations. H.225 follows Q.931's procedures for circuit mode connection setup. Although the 'bearer' is actually been signaled for, no actual 'B' channels of the ISDN type exist on the packet based network. Successful completion of the H.225-Q.931 will setup a reliable H.245 channel.

H.245:

  • Specifies conference control and capability exchange message

  • allows endpoints to specify RTP port numbers and codec types

Once the H.245 channel is setup, the H.245 message could be connected to control the multimedia session.

1.8The structure of Interworking between H.323 and PSTN


To establish a point-to-point H.323 conference, Two TCP connections are needed. The first of these that must be set up is commonly known as the Q.931 channel. The caller initiates setup of this TCP connection to a well-known port at the callee. Call setup messages are then exchanged as defined in H.225.0.

Once the H.245 channel has been setup, the Q.931 channel is no longer required. The H.245 channel is then used to allow both sides to exchange their audio/video capabilities and to determine which side will act as the master.

Another function carried out over the H.245 channel is to initiate the setup of RTP sessions for the data transfer and RTCP sessions for delivery monitoring and feedback reports. Finally when data transfer is complete the H.245 channel can be used to terminate the call.

The Figure 15 shows an example of how interconnection of two regular phones connected to the PSTN can be accomplished across an IP network.

The calling party dials the telephone number of the local gateway followed by the destination telephone number. The local gateway then maps the destination number to the Q.931 transport address of the remote gateway. The Q.931 Setup message will carry the destination telephone number to the remote gateway which can setup a local call across the PSTN to the destination telephone thereby completing the end to end path. Upon completion of call set up, each gateway is responsible for media conversion in both directions, e.g. G.729 in RTP packets  G.711 in timeslots.

Figure 15: PSTN-IP- PSTN

In the Example of PSTN-IP-PSTN:


  1. The gateway GW1 performs gateway function to map called number to Q.931 transport address of GW2

  2. Q.931 Setup carries call party number to GW2

  3. Q.931connect enables GW1 to learn H.245 transport address of GW2

  4. H.323 has 2 different ways to use the separate H.245 channel : (these are not in this document area)

  • Fast connect

  • Tunneled H.245 message setup

After the H.245 channel between two gateways are setup, they follow the same rule as the normal H.245 dialog between two terminals.

  1. MGCP and MEGACO

1.9Gateway Decomposition


Initial VoIP Gateways handles both call signaling and media conversion. The gateway decomposition model removes the call signaling intelligence from the gateway.

  • Gateways are then controlled by external call agents containing call signaling intelligence

  • Gateways communicate with call agent, uses a specific protocol(e.g. MGCP/MEGACO)

1.10Aims of Gateway Decomposition:


Scalability

Existing gateways only support a small number of lines (a few thousand), partly because the gateway must perform full call signaling as well as media conversion. By removing the intelligence from the gateway and making it a dumb device under the control of a remote call agent the gateway will be able to support a larger number of liners.



Seamless PSTN Integration

Many existing Internet telephony solutions require a 2-stage dialing where a gateway number must be dialed prior to dialing the actual destination number. This is quite cumbersome for the end-user. However if gateways are setup as dumb device then they will be inexpensive enough for residential users to buy and place in their homes thus avoiding the need for 2-stage dialing since the users phone will already be connected to a gateway.



SS7 connectivity

Existing H.323 gateways do not support SS7/C7 connectivity and are also unable to support the full set of PSTN services that is accomplished by using SS7/C7.



Availability

Existing Internet telephony solution have limited fail-over mechanisms and are also unable to meet the very low downtime that users have come to expect over the PSTN. Gateway decomposition supports fail-over so that if a call agent fails, another call agent can automatically take over.


1.11Gateway Decomposition Architecture


TGW: Trunk gateway.

In UMTS All-IP core Network, it is named as the T-SGW

Connects PSTN to IP network. Performs the media transformation and act according to instructions from call agent.

RGW: Residential gateway.

In UMTS All-IP core Network, it is named as the R-SGW

For a connection of residential telephone to an IP network, it's feasible and inexpensive, as created by the removal of call intelligence from gateway. The media transformation is performed and the instructions from call agent are followed accordinglty

In UMTS All-IP Core Network, the RGW is used to connect the MAP between UMTS All-IP Core Network and 2G Legacy network for roaming.



Call agent.

In UMTS All-IP Core Network, the Call agent is named as ' Call Processing Server' (CPS)



  • Call agent controls TGWs and RGWs using MGCP.

  • Handles SS7 signaling for trunks that interconnect PSTN with IP network

  • Interacts with SCPs over SS7 network in support of various services ( e.g. routing of 'free-of-charge' telephone numbers to actual destination)

  • May support SIP/H.323 signaling

In the architecture of Figure 16, if one call agent fails, another one will take over without losing any calls.

Call agents terminates SS7 connectivity allow seamless integration with PSTN.

Centralized intelligence leads to a rapid introduction of new services simply by upgrading the call agent software and making the service available to anyone that will pay for it.

The above architecture will work with existing non-intelligent customer premises equipment (CPE). Also permits intelligent CPEs to be used that perhaps offer some additional services that call agent does not support.

Fail-over mechanisms are also unable to meet the very low downtime that users have come to expect over the PSTN. Gateway decomposition supports fail-over so that if a call agent fails another call agent can automatically take over.



Figure 16: Gateway Decomposition Architecture

1.12Call Agent – Gateway communication


  1. Call agent asks the gateway to be informed of certain events(E.g. off-hook, on-hook, dialed digits etc)

  2. Gateways report events to call agent

  3. Call Agent informs gateway what to do next and what information to be returned.

1.13MGCP-PSTN call flow


In the Figure 17, ring is transmitted across the PSTN for both parties as this is the most common approach that is used in today's PSTN. This is possible because a RGW includes both a standard telephone connection and an IP network connection.


Figure 17: MGCP-PSTN call flow

I: indicates information

C: indicates a command

1.14MGCP-SIP call flow



Figure 18: MGCP-SIP call flow

I: indicates information

C: indicates a command

The diagram above show the call flow for a caller connected to a RGW and a callee support SIP residing on an IP network


1.15MEGACO Vs SIP/H.323


MEGACO assumes dumb end points, similar to PSTN and IN model.

SIP/H.323 assume intelligent end points, similar to Internet model.


1.16UMTS All-IP Core Network




Figure 199: UMTS All-IP Core Network

It is a Network of Voice over GPRS. SIP and MEGACO are used for their signaling.



HSS has 2 parts:

  • GPRSHLR

  • UMS. UMS will take control of the application level mobility management (serving the CSCF)

CPS has 2 parts:

  • CSCF. CSCF provides call control service to IP-telephony subscriber.

  • MGCF. MGCF control the gateway.

GW has 4 parts:

  • T-SGW, T-SGW converts ISUP to the signaling over IP.

  • R-SGW, R-SGW allows roaming from IP telephony domain to Legacy networks and Legacy subscriber roaming to IP telephony domain.

  • MGW and MRF. MGW+MRF will convert the voice data and convert the R2 signaling to the signaling over IP.

References


  1. 3GPP: 'architecture for an ALL IP network', 3G TR 23.922 version 1.0.0 30th June 2000

  2. 3GPP: 'Combined GSM and Mobile IP Mobility Handling in UMTS IP CN', TR 23.923, version 3.0.0 30th June 2000

  3. Aparna Vemuri, Jon Peterson: SIP for Telephones (SIP-T)-Context and Architectures, SIP WG, July 14 2000, http://www.softarmor.com/sipwg/teams/sipt/index.html

  4. Ericsson: Best Current Practice for ISUP to SIP mapping , IETF, September 2000, http://www.softarmor.com/sipwg/teams/sipt/index.html

  5. Phillips Omnicom: Voice over IP, Phillips Omnicom, July 2000.HERTS SG1 1EL – UK

  6. Srinivas sreemanthula etc: 'RT Hard Handoff Concept for All-IP System, version V1.0.2, and IPMN project.




--


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка