ARCHITECTURES TO SUPPORT PSTN SIP VOIP INTERCONNECTION

Transcription

1 ARCHITECTURES TO SUPPORT PSTN SIP VOIP INTERCONNECTION 10 April 2009 Gömbös Attila, Horváth Géza

2 About SIP-to-PSTN connectivity 2 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

3 Where is SIP and PSTN interworking 3 needed? (Bridging) 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. PSTN SIP transit network PSTN

4 Where is SIP and PSTN interworking 4 needed? (Gateway) 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

5 5 Key benefits of using VoIP

6 6 Session Initiation Protocol - MEMO

7 SIP memo - Architecture 7 IETF s application layer signalling protocol Setting up, modification and breaking down of multimedia sessions UA Registrar 1 Proxy/ Redirect 2 GW PSTN Media session Registrar 2 Location Server Internet Proxy/ Redirect 1 Router UA

8 SIP memo - Messages 8 Request INVITE, ACK, BYE, CANCEL, OPTIONS, REGISTER Response 1xx, 2xx, 3xx, 4xx, 5xx, 6xx E. g. 100 Trying 180 Ringing 200 Ok

9 9 Public Switched Telepone Network - MEMO

10 10 PSTN memo - Architecture DSS1 ISDN network SP signalling user plane STP SP SP SP: Signalling Point STP: Signalling Transfer Point ISDN ISDN interface interface End-to-end connection Common channel SS7 ISDN ISDN interface interface DSS1

11 PSTN memo - Signalling 11 ISDN terminal ISDN exchange ISDN exchange ISDN terminal Transactio n services Call control services Dialing Ringing Ringback tone Answer Hanging up B channel connection source: w3.tmit.bme.hu/thsz

12 12 Levels of interworking Singaling Media Gateway architecture Translation vs. Encapsulation SIP-T vs. SIP-I

13 Levels of SIP-PSTN interworking 13 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. SIP phones SIP servers PBX Media:RTP Media:TDM PCM IP network PSTN SIP servers Signaling:SIP Gateways SIP - enabled devices Signaling:ISUP,Q.931,CAS,etc Telephones

14 PSTN-SIP gateway architecture 14 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. PSTN side ISUP Voice stream ISUP/IP Signalling gateway Media gateway controller Megaco/MGCP Media gateway SIP Voice stream IP side

15 Affix: protocol stacks ISUP over IP 15 SS7 signalling point SCCP /ISUP MTP3 MTP2 Signalling gateway Interworking function MTP2 M2UA IP signalling point SCCP /ISUP MTP3 M2UA MTP1 MTP1 SCTP IP SCTP IP SS IP network 7 Adaptation protocol (xua, xpa) Common signalling transport (SCTP) SIGTRAN architectural model Standard Internet protocol (IP)

16 SIP for Telephones 16 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 the SIP request to be routed.

17 Translate: Process of SIP-PSTN call 17 PSTN-SIP call through gateway SIP-PSTN call through gateway

18 Mapping of SIP-PSTN messages 18 SIP message or response ISUP message ISDN message INVITE IAM or SAM Setup INFO USR User BYE REL Release CANCEL REL Release ACK - - REGISTER x ACM or CPG Alerting 200 (to INVITE) ANM or CON Connect 4xx, 5xx, 6xx REL Release 200 (to BYE) RLC Release complete

19 19 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. INVITE sip: @proxy.carrier.com; user=phone SIP/2.0 Via: SIP/2.0/UDP gw1.carrier.com:5060 To: sip: @proxy.carrier.com;user=phone From: sip: @gw1.carrier.wcom.com;user=phone Call-ID: @gw1.carrier.com CSeq: 1 INVITE Contact: sip: @gw1.carrier.wcom.com;user=phone Content-Type: application/sdp Content-Length: 156 v=0 o=gateway 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 7452a43564a4d566736fa f168a383b84f ff

20 Encapsulation: PSTN to PSTN tunneling 20 PSTN switch SIP-T gateway SIP-T gateway PSTN switch 1 IAM 7 ACM One-way speech 10 ANM 2 INVITE (IAM) Trying Session Progress (ACM) One-way RTP Media OK(ANM) 11 ACK 3 IAM 5 ACM One-way speech 8 ANM Two-way speech RTP Media Session Two-way speech 17 RLC 12 REL No Speech Path 13 BYE(REL) OK(RLC) No Media Session 14 REL 15 RLC No Speech Path

21 SIP with Encapsulated ISUP 21 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 SIP-I is widely accepted by manufacturers, carriers and organizations (e.g., 3GPP) instead of SIP-T.

22 22 Examples for differences between SIP-T and SIP-I 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

23 Example for media processing 23 From IP to PSTN From PSTN to IP 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 Application Dialogic Voice Board RTPReceive() RTP packet encoded voice sample gsmdecode() PCM set play event RTPSend() gsmencode() PCM detect record event RTPLib GSMLib Gatenet Channel 1 firmware buffer Channel 3 firmware buffer Analog voice Echo cancel channel 1

24 24 Integration challenges Calling Party Number display Remote-Party-ID Authentication and trust Gateway location TRIP, ENUM/DNS DTMF

25 Calling Party Number display 25 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

26 User ID / phone number DB 26 Remote-Party-ID SIP UA Proxy with CLID support PSTN gateway a INVITE sip:1234@gw.com sip:1234@gw.com From: sip:a@bc.de;tag=12 sip:a@bc.de;tag=12 To: sip:1234@gw.com sip:1234@gw.com INVITE sip:1234@gw.com From: sip:a@bc.de;tag=12 To: To: sip:1234@gw.com Remote-Party-ID: <sip: @gw.com>

27 Authentication and trust 27 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 call come from a source to whom my gateway can credit international calls?

28 Trust: Interdomain versus Intradomain 28 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 public Internet RPID alone can t be trusted as it can be changed anywhere on the transit Stronger security protocols come in for interdomain operation: TLS

29 TLS for Interdomain Security 29 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 Originating domain Internet Public internet TLS 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 Terminating domain with local trust PSTN

30 Gateway location - TRIP 30 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 as the 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.

31 Gateway location ENUM/DNS 31 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 a set of user-provisioned URIs. DNS/ENUM helps ingress gateway to resolve SIP address from E.164 number Gateway with ENUM resolution e164.arpa e164.arpa sip: sip: jiri@iptel.org jiri@iptel.org INVITE: sip: sip: jiri@iptel.org DNS / ENUM

32 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

33 Questions?