ARCHITECTURES TO SUPPORT PSTN – SIP VOIP INTERCONNECTION

Gömbös Attila, Horváth Géza10 April 2009

About SIP-to-PSTN connectivity

� Providing a voice over IP solution that will scale to PSTN call volumes, offer PSTN call quality and equivalent services, as well as supporting new and innovative services is a significant challenge

� There are however still 200 million PSTN users hanging around and you would like to talk at least to some of them� Problem: Your device speaks a different language than your

grandmother’s

� Solution: use a gateway, i.e., adapter which converts signaling and speech from Internet to PSTN and vice versa

2

Where is SIP and PSTN interworking needed? (Bridging)

3

PSTNSIP transit networkPSTN

� IP trunking solutions used by long haul voice providers.

� Typically these offerings use private IP networks to connect islands of the PSTN together, e.g. a low cost way of calling the USA from the Europe.

� Customers access these services using traditional PSTN phones but the voice is carried over an IP network.

Where is SIP and PSTN interworking needed? (Gateway)

4

� Private customers want to reach users with PSTN devices using VoIP sets and vice versa.

� Companies built a VoIP infrastructure for internal usage, and want to use this infrastructure to reach PSTN world.

Private VoIP network

PSTN

Key benefits of using VoIP5

Session Initiation Protocol - MEMO6

SIP memo - Architecture

� IETF’s application layer signalling protocol� Setting up, modification and breaking down of multimedia sessions

PSTN

Internet

GW

RouterProxy/ Redirect 1

Proxy/ Redirect 2

UA

Location

Server

Registrar 1

Registrar 2

Media session

UA

7

SIP memo - Messages

� Request� INVITE, ACK, BYE, CANCEL,

OPTIONS, REGISTER

� Response

� 1xx, 2xx, 3xx, 4xx, 5xx, 6xx

� E. g.� 100 Trying

� 180 Ringing

� 200 Ok

8

Public Switched Telepone Network -MEMO

9

PSTN memo - Architecture10

signalling

SPSP

SP

STPSTP

SP: Signalling PointSTP: Signalling Transfer Point

user plane

ISDN networkISDN network

ISDN

interf

aceISD

N

interf

ace

ISDN interface

ISDN interface

Common chann

el

SS7

DSS1

DSS1

End-to-end

conn

ection

PSTN memo - Signalling11

source: w3.tmit.bme.hu/thsz

Transaction services

Call control services

ISDN terminal ISDN terminalISDN exchangeISDN exchange

B – channel connection

Dialing

Ringing

Answer

Hanging up

Ringback tone

Singaling

Media

Gateway architecture

Translation vs. Encapsulation

SIP-T vs. SIP-I

Levels of interworking12

Levels of SIP-PSTN interworking

� Interworking has to levels:� Media

� Signaling

� The media interworking in a gateway involes terminating a PCM trunk on the PSTN side and bridging the media with an IP port that sends and receives RTP packets.

� Signaling translation is much more complex.

13

SIP servers SIP servers

SIP phones

SIP - enableddevices

Gateways

PBX

Media:RTPMedia:RTP Signaling:SIPSignaling:SIP

Media:TDM PCMMedia:TDM PCM Signaling:ISUP,Q.931,CAS,etcSignaling:ISUP,Q.931,CAS,etc

Telephones

IP networkIP network

PSTNPSTN

PSTN-SIP gateway architecture

� SG routes all ISUP messages forward the MG. Meanwhile, Message Transport Protocol (MTP) as the lower layer in SS7 is replaced by IP, and ISUP as the upper layer is encapsulated into TCP/IP headers. Another task is to translate the dialed number into an IP address before the call is traversed.

� The MG maps or transcodes the media in the PSTN domain (e.g., PCM encoded voice) and media in the IP domain (e.g., media transported over RTP/UDP/IP).

� MGC converts the format of signaling from native one in PSTN to that used in IP network, control the MG by introducing Megaco/MGCP and performs AAA.

14

PSTN side

PSTN side

Signalling gateway

Signalling gateway

Media gateway controller

Media gateway controller

Media gatewayMedia gateway

IP sideIP side

ISUP/IP

Megaco/MGCP

SIP

Voice strea

m

ISUP

Voice stream

Affix: protocol stacks – ISUP over IP15

MTP1

MTP3

MTP2

SCCP/ISUP

SCTP

MTP3

M2UA

SCCP/ISUP

IPMTP1

Interworking function

MTP2

SCTP

M2UA

IP

SS7 signalling point IP signalling point

Signalling gateway

IP network

SS7 Adaptation protocol

(xUA, xPA)

Common signalling transport (SCTP)

Standard Internet protocol (IP)

SIGTRAN architectural model

SIP for Telephones16

� SIP for Telephones (SIP-T) is a framework for SIP interworking with the PSTN� Defined in RFC3372

� It includes two approaches: � Translation� Encapsulation

� The SS7 ISUP messages arriving at a SIP-ISUP gateway are 'encapsulated' within SIP

� This makes sure the information necessary for services is not discarded in the SIP request

� However, routing decisions for SIP requests are made at proxy servers which cannot be expected to understand ISUP messages.

� To overcome this, some of the critical information is translated from an ISUP message into the corresponding SIP headers, allowing theSIP request to be routed.

Translate: Process of SIP-PSTN call17

SIP-PSTN call through gateway

PSTN-SIP call through gateway

Mapping of SIP-PSTN messages18

SIP message or

responseISUP message ISDN message

INVITE IAM or SAM Setup

INFO USR User

BYE REL Release

CANCEL REL Release

ACK - -

REGISTER - -

18x ACM or CPG Alerting

200 (to INVITE) ANM or CON Connect

4xx, 5xx, 6xx REL Release

200 (to BYE) RLC Release complete

SIP telephony and ISUP tunneling problems� There are many country-specific variants of ISUP.

� A call routed from the PSTN to SIP then back to the PSTN. Some of the lost parameters from the first PSTN leg could be useful in routing in the second PSTN leg.

� To solve this problem encapsulation of PSTN signaling is needed.SIP-T uses multipart MIME bodies to enable SIP messages to contain multiple payloads.

19

INVITE sip:+1-972-555-2222@proxy.carrier.com; user=phone SIP/2.0

Via: SIP/2.0/UDP gw1.carrier.com:5060

To: sip:+1-972-555-2222@proxy.carrier.com;user=phone

From: sip:+1-314-555-1111@gw1.carrier.wcom.com;user=phone

Call-ID: 12345602@gw1.carrier.com

CSeq: 1 INVITE

Contact: sip:+1-314-555-1111@gw1.carrier.wcom.com;user=phone

Content-Type: application/sdp

Content-Length: 156

v=0

o=GATEWAY1 2890844527 2890844527 IN IP4 gatewayone.carrier.com

s=Sesson SDP

c=IN IP4 gatewayone.carrier.com

t=0 0

m=audio 3456 RTP/AVP 0

a=rtpmap:0 PCMU/8000

Content-Type: mime/isup

7452a43564a4d566736fa343503837f168a383b84f706474404568783746463ff

Encapsulation: PSTN to PSTN tunneling20

PSTN switchSIP-T gateway

SIP-T gateway PSTN switch

1 IAM

2 INVITE (IAM)3 IAM

4 100 Trying

5 ACM6 183 Session

Progress (ACM)

7 ACMOne-way

RTP MediaOne-way speechOne-way speech

8 ANM

9 200 OK(ANM)

10 ANM

11 ACK

Two-way speech RTP Media Session Two-way speech

12 REL13 BYE(REL)

14 REL

15 RLC16 200 OK(RLC)17 RLC

No Speech Path

No Media Session No Speech Path

SIP with Encapsulated ISUP21

� SIP-I (by ITU-T, based on SIP-T) is more accurate and explicitly defines the parameters between PSTN and SIP, also detailedly defines the supplementary services for telecommunication interconnection, which is not support by SIP-T.

� Defined in Q.1912.5.

� SIP-I is widely accepted by manufacturers, carriers and organizations (e.g., 3GPP) instead of SIP-T.

Examples for differences betweenSIP-T and SIP-I

22

� Encapsulation� RLC (Release Complete)

� SIP-T: This message is not interworked.

� SIP-I: This is encapsulated in 200 OK (BYE) when the BYE contained an encapsulated REL.

� Translation� Called Party Number

� SIP-T: Request-URI can be either a SIP URI with the user=phone parameter or a tel: URI

� SIP-I: Request-URI is assumed to be a SIP URI with the user=phone parameter, a gateway will never receive tel: URIs in the Request URI because proxies will change them

Example for media processing

� Waiting for the packet to arrive

� Receiving RTP packet on UDP port

� Converts received sample from GSM to µ-law PCM

� Copying sample to firmware buffer, and notifying Gatenet library by setting play event

� Waiting for the record event

� Encoding sample from µ-law PCM to GSM

� Sending RTP packet

� Setting current firmware buffer as invalid

23

From IP to PSTN From PSTN to IP

RTPReceive()RTPReceive() gsmdecode()gsmdecode() set play event

set play event

RTPSend()RTPSend() gsmencode()gsmencode() detect record event

detect record event

Channel 3 firmware buffer

Channel 3 firmware buffer

Channel 1 firmware buffer

Channel 1 firmware buffer

Echo cancel channel 1

Echo cancel channel 1

RTPLib GSMLib Gatenet

encoded voice sample

PCM

PCM Analog voice

RTP packet

Application Dialogic Voice Board

Calling Party Number display

Remote-Party-ID

Authentication and trust

Gateway location – TRIP, ENUM/DNS

DTMF

Integration challenges24

Calling Party Number display25

� SS7 allows Calling Party Number, or caller id, to be displayed on the phone of the callee

� With SIP, caller id display can be difficult� SIP endpoint identity can be a text in url format, it does not have a digital

phone number in E164 format

� Even a phone number in digit format can be set to header, the callee side generally do not trust this information

� If SIP is just one hop away� the carrier will set the caller id to the SIP header

� forward to PSTN in terminating side

� in such case subscribers hardly notice SIP is involved

� When more than one SIP proxy exist in the communication link which� next-hop proxy does not always trust the caller id set in the header and may

remove it

� This causes the problem that caller id will not be displayed to callee� IETF proposed to add a Remote-Party-ID in the SIP header

Remote-Party-ID26

SIP UA

User ID / pho

ne num

ber DB

Proxy with CLID support

PSTN gateway

INVITE sip:1234@gw.com

From: sip:a@bc.de;tag=12

To: sip:1234@gw.com

INVITE sip:1234@gw.com

From: sip:a@bc.de;tag=12

To: sip:1234@gw.com

INVITE sip:1234@

gw.com

From: sip:a@

bc.de;tag=12

To: sip:1234@gw

.com

Remote-Party-ID

:

<sip:+

49179123123@gw

.com>

INVITE sip:1234@

gw.com

From: sip:a@

bc.de;tag=12

To: sip:1234@gw

.com

Remote-Party-ID

:

<sip:+

49179123123@gw

.com>

aa

+49-179

-123123

+49-179

-123123

Authentication and trust27

� PSTN endpoints are attached to the system and the identity is recognized by the switch

� SIP devices are highly programmable and the interfaces are open

� Displaying proper caller ID is a legal requirement for operators� A gateway may only display caller ID issued by a trustworthy source

� Trust needed to solve other problems too: Does the callcome from a source to whom my gateway can creditinternational calls?

Trust: Interdomain versus Intradomain28

� Intradomain scenario� Trust can be implemented using physical security and

knowledge of identity of local users

� Proxy servers verify identity of local users using digest and gateways trust local proxies

� Interdomain scenario� The terminating provider can’t verify identity of remote

users and can’t trust information passed over the publicInternet

� RPID alone can’t be trusted as it can be changed anywhere on the transit

� Stronger security protocols come in for interdomain operation: TLS

TLS for Interdomain Security

� Originating domain verifies identity of local user (digest).� If ok, it appends RPID and uses TLS

for secure inter-domain communication

� Terminating proxy verifies incoming TLS connection against list of trustworthy domains.� If ok, SIP request is forwarded to

PSTN gateway

� TLS use for SIP solves other trust problems too:� With trust mechanisms, interdomain

accounting can be also implemented securely

� Signaling can be no longer sniffed during transport

29

Internet

PSTN

Originating domain

Public internet

Terminating domain with local trust

TLS

Gateway location - TRIP30

� When PSTN initiates a call to SIP with its E.164 number, the called number needs to be mapped to the gateway that serves this SIP endpoint. This mapping is not easy to achieve as SIP phone can be anywhere and choosing best serving gateway is not as apparent asthe country code for PSTN number plans.

� IETF defined TRIP (Telephony Routing over IP) to tackle this problem.� TRIP requires the gateways to exchange local database for advertising

routes to certain destinations.

� TRIP, used to distribute telephony routing information between telephony administrative domains, is modeled after the Border Gateway Protocol.

� TRIP uses an intra-domain flooding mechanism similar to that used in OSPF.

� The problem with TRIP protocol is that it is complex to deploy.

Gateway location – ENUM/DNS

� Another solution on this is to enumerate the mapping between all the numbers and SIP addresses. This is considered less scalable but easy to deploy.

� Lookup mechanism: DNS maps E.164 numbers to aset of user-provisioned URIs.

� DNS/ENUM helps ingress gateway to resolve SIP address from E.164 number.

31

DNS / ENUM

Gateway with ENUM resolution

+4917…

+4917…

…7.1

.9.4.e

164.a

rpa

…7.1

.9.4.e

164.a

rpa

sip: jiri@

iptel.org

sip: jiri@

iptel.org

INVITE: sip: jiri@iptel.org

INVITE: sip: jiri@iptel.org

DTMF support (RFC2833)32

� DTMF (Dual Tone Multi-Frequency) can provide faster dialing, also it enables enhanced services such as dialing credit card, voice menu, etc

� To support DTMF in packet switched network, various solutions were proposed� DTMF signals can be transported in SIP signaling or media

� Since SIP signaling and media are transported separately, DTMF signals in SIP signaling may be out of synchronization with media

� DTMF can also be transported together with other audio media to guarantee synchronization� If the DTMF signals are packetized in normal packets, each packet

needs to be checked to identify which is DTMF signal� This works if the bandwidth is sufficient

� More efficiently, a special header is introduced for DTMF packets in media. Only packet headers need to be checked

Questions?