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:[email protected]; user=phone SIP/2.0
Via: SIP/2.0/UDP gw1.carrier.com:5060
To: sip:[email protected];user=phone
From: sip:[email protected];user=phone
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected];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:[email protected]
From: sip:[email protected];tag=12
To: sip:[email protected]
INVITE sip:[email protected]
From: sip:[email protected];tag=12
To: sip:[email protected]
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: [email protected]
INVITE: sip: [email protected]
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?