INTERNET DRAFT Eric Zimmerer Category: Informational ipVerse, Inc. Aparna Vemuri Date: September 1999 Level 3 Communications Expires: March 2000 Vijay Nadkarni ipVerse, Inc. Brian Morgan ipVerse, Inc. Gonzalo Camarillo L M Ericsson Ab SIP Best Current Practice for Telephony Interworking Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes inter Media Gateway Controller (MGC) communication using SIP. SIP, with certain extensions, facilitates the exchange of signaling information between an Originating MGC and a Terminating MGC to complete calls. This document describes the best current practice for using SIP to perform this function. Where possible this draft references necessary documents, and details the concepts and methods of encapsulating PSTN signaling information in SIP messages. Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 1] Internet Draft SIP-BCP-T Sep 99 1. Introduction This document describes Inter Media Gateway Controller communication using SIP[1]. SIP can be used to communicate from a SIP User Agent to another SIP User Agent, from a SIP User Agent to a Media Gateway Controller (MGC), and from one MGC to another MGC. This document details how to best use SIP to communicate from one MGC to another MGC. This document DOES NOT describe a new protocol. The intention of this document is to detail or reference the methods, standards and tools necessary to enable MGCs to interoperate via the SIP protocol. The SIP BCP-T facilitates the exchange of information between an Originating Media Gateway Controller and a Terminating Media Gateway Controller so that calls may be completed. When SIP is used in the MGC-to-MGC space, there are many cases where it must "bridge" PSTN networks with IP networks. To do this, SIP must be extended to transport PSTN signaling information. By extending SIP messaging, and adding PSTN signaling encapsulation functionality, the SIP BCP-T satisfies the requirements for MGC-to-MGC communication. SIP provides the methods to set up, tear down and manage voice and data sessions. The extensions described and/or referenced in this document enable SIP to encapsulate a variety of PSTN signaling types including but not limited to SS7, and Q.931. Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 2] Internet Draft SIP-BCP-T Sep 99 +--------+ +--------+ +--------+ | |<--SIP--->| Proxy |<--SIP--->| | +---| MGC | +--------+ | MGC |---+ | | |<------------SIP------------->| | | | +--------+ +--------+ | SS7 | | SS7 Signal | | Signal Link +------+ IP +------+ Link | | MG |------------ Network ------------| MG | | | +------+ +------+ | | | \ / | | | | Q.931 trunk CAS trunk | | | SS7 trunk \ / SS7 trunk | | | \ / | | | +-----------------------------------------------+ | +----| PSTN |---+ +-----------------------------------------------+ Figure 1: Use of the SIP BCP-T Figure 1 shows a basic network configuration using SIP BCP-T. In this example Media Gateways are connected to the Public Switched Telephone Network (PSTN) via SS7 trunks, Q.931 trunks, and Channel Associated Signaling (CAS) trunks. The Originating Media Gateway Controller may receive a call over any of these trunks. The signaling information from these trunks must be processed by the MGC to establish the originating half of the call, and to determine the identity of the Terminating MGC required to complete the call. The originating MGC uses SIP to communicate the necessary information to the terminating MGC to complete the call. The terminating MGC must be able to establish the terminating call half on any of the supported trunk types. The PSTN has many regional and national signaling variants which make interoperability difficult. A key design goal of the SIP BCP-T is to document a single standard method for MGCs to interoperate. Therefore, the SIP BCP-T will use international digit analysis, dialing plans, and interoperability standards from the PSTN rather than any single National or regional variants. To guard against regional variations, the SIP BCP-T is being designed Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 3] Internet Draft SIP-BCP-T Sep 99 for international use from the start. The basic method of routing calls will use ITU-T E.164 [2] numbering, and will adhere to international routing of telephone numbers. The SIP BCP-T focuses on communication between MGCs, but must also address the security concerns of SIP User Agents communicating with MGCs. The information contained in MGC-to-MGC messages is sensitive, and must be secured from SIP User Agents accessing the network. The SIP BCP-T reflects the design goals of efficient call setup and scalability. This document describes a SIP implementation that is intended to scale to millions of calls per hour for a world-wide network. In addition to these ambitious goals, SIP BCP-T must facilitate "bridging" PSTN networks with IP networks. To do this, SIP BCP-T must be capable of transporting PSTN signaling information. SIP BCP-T provides the methods for MGCs to set up, tear down and manage voice and data calls. The extensions detailed here allow SIP to accommodate a variety of in bound and out bound PSTN signaling types including but not limited to SS7, Q.931, and CAS. 2. SIP BCP-T Components 2.1. SIP as defined in RFC 2543. 2.2. MIME multipart Encapsulating PSTN signaling is a major function of the SIP BCP-T. MIME multipart payloads enable SIP to carry any PSTN signaling information required. SIP BCP-T uses MIME multipart [3] (RFCs 2045 - 2049) to enable SIP messages to contain multiple payloads in the body of the message. The multipart body can consists of any combination of the following units: SDP payload ISUP payload One or more units of any MIME type payload. The following are the suggested encoding formats for the above- mentioned units: a) the SDP payload (text): Content-Type: application/SDP; charset:ISO-10646 The SDP [4] payload is plain-text. Although the default for plain- Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 4] Internet Draft SIP-BCP-T Sep 99 texts in MIME is US-ASCII, ISO-10646 is recommended here for the following reasons: Both SIP and SDP use ISO 10646, and the ISO 10646 character set with UTF-8 encoding can be considered a superset of the US-ASCII character set per RFC 2044 [5]. b) the ISUP payload (arbitrary binary data): Content-Type: application/ISUP; version: one of (ETSI1, ANSI, etc) Content-Transfer-Encoding: binary Encapsulating SS7 and other PSTN signaling messages inside SIP BCP-T allows MGCs to be compatible with the PSTN. SIP BCP-T encapsulates and transmits the native signaling messages from one PSTN to another, essentially tunneling the PSTN signaling messages through the IP network. To this end, SIP BCP-T has been extended with application/ ISUP versions for several variants of ISUP. The use of ISUP encapsulation with Content-Type "application/ISUP" allows ISUP signaling messages to be tunneled between MGCs. The use of 'version' allows differentiation between different ISUP variants. This enables the terminating MGC to recognize and parse the messages correctly, or (possibly) to reject the message if the particular ISUP variant is not supported. The idea here is to allow MGCs to specify a preference of version, so that the following scenarios are possible: "I only like application/isup; version=ETSI1" or "I accept application/isup (but don't know the details; I just pass them on to some other tool that uses them)". The tools detailed in this document allow MGCs to encpsulate any variant of ISUP. The MGC network architecture makes possible the direct connection of the originating MGC and the terminating MGC without intermediate MGCs. This makes possible the scenario where an MGC in one country must be able to "speak" the ISUP variants of all other countries in order to complete calls, (as opposed to an intermediate international gateway MGC). Alternatively, the given MGC could use only a superset ISUP protocol, or an agreed -upon "lowest common denominator" ISUP variant, which all other MGCs connected to that MGC would have to use. The ability to encapsulate any version of ISUP inside SIP messages enables any of these scenarios. The optimal interworking of protocol variants can be determined by the network operator. A superset approach, an agreed upon (lowest common denominator) interworking variant approach, or support of all variants approach can all be implemented using the SIP BCP-T. Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 5] Internet Draft SIP-BCP-T Sep 99 For example, when a call arrives at an MG on an SS7 trunk, the Originating MGC encapsulates the IAM in the INVITE message body that is sent to the terminating MGC. This MGC reads the IAM from the INVITE payload and may use it when creating its signaling message to the terminating telephone network. Subsequent ACM and ANM messages are passed back to the Originating MGC along with other necessary information via 100 Trying and 200 OK messages. The version tells the receiving MGC which type of ISUP message has been encoded. c) One or more units of any MIME type payload (dependent on use): No rules have been laid out here. The Content-Type and Content-Transfer-Encoding parameters would be determined by the MIME type and the kind of data sent compliant with the rules of RFCs 2045, 2046). Note: The Content-Type specification is mandatory in all instances to differentiate between the different payload types. This is because there is no guarantee of a specific order or required type of the payloads. 2.2.1 An illustrative example: SIP message format requires a Request line followed by Header lines followed by a CRLF separator followed by the message body. To illustrate the use of multipart payload message body, below is an INVITE message which has the originating SDP information and an encapsulated ISUP IAM. INVITE sip:13039263142@Den1.level3.com SIP/2.0 From: sip:13034513355@den3.level3.com To: sip:13039263142@Den1.level3.com Call-ID: DEN1231999021712095500999@Den1.level3.com Content-Type: Application/ Multipart Content-Length: 327 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=unique-boundary-1 --unique-boundary-1 Content-Type: application/SDP; charset=ISO-10646 Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 6] Internet Draft SIP-BCP-T Sep 99 v=0 o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP seminar c=IN IP4 MG122.level3.com t= 2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-type:application/ISUP; version:ETSI1 Content-Transfer-Encoding: binary 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 --unique-boundary-1-- 2.3. ISUP MIME Type The ISUP MIME type is required to encapsulate the PSTN ISUP signaling information. See Internet draft: draft-zimmerer-mmusic-sip-isup-mime-00.txt [6] 2.4. INFO method The intent of the INFO method is to allow for SIP to carry session related control information that is generated during a session. The INFO method is added specifically to allow PSTN signaling messages beyond call setup and teardown to be transmitted between MGCs. This method may be used by either originating or terminating MGC to communicate additional information such as mid-call telephony signaling messages resulting from the interworking between an ISUP or ISDN network device and a SIP controlled network. This has been described in an Internet Draft: draft-ietf-mmusic-sip-info-method-01.txt. [7] Note: This draft references draft-ietf-sigtran-mime-isup-00.txt proposal for encapsulating telephony signaling control information as part of an ISUP attachment to the INFO message. It is recommended to use the format outlined above in section 2.2. MIME Multipart instead. 2.5. ISUP-SIP mapping (Internet draft pending) The SIP BCP-T recommends the ISUP-SIP mapping detailed in the Internet draft: draft-camarillo-mmusic-sip-isup-bcp-00.txt. Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 7] Internet Draft SIP-BCP-T Sep 99 2.6. Network Access Point (NAP) architecture (Internet draft pending) 3. Security The security provided by SIP is sufficient for the initial deployment of inter-MGC communication. There are issues requiring further study with regard to the interoperation of MGCs and SIP User Agents. There is an interesting line that must be drawn between giving too much control to the endpoint clients and not enough control. The notion of a secure proxy between SIP User Agents (endpoints) and the network MGCs requires more study. 4. Acknowledgements Many people have contributed to this document. In particular Henning Schulzrinne, Ike Elliott, Andrew Dugan, Henry Sinnreich, Matt Cannon, John Wetherbie, and Dent Steve Dent. 5. Authors Eric Zimmerer ipVerse, Inc. 1901 Landings Drive, Mountain View, CA 94043, USA Phone: 650-919-0648 EMail: ericz@ipverse.com Aparna Vemuri Level 3 Communications, 1450 Infinite Drive, Louisville, CO, 80027, USA Phone: 303-926-3768 EMail: aparna.vemuri@level3.com Vijay Nadkarni ipVerse, Inc. 1901 Landings Drive Mountain View, CA 94043, USA Phone: 650-919-0604 Email: vijayn@ipverse.com Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 8] Internet Draft SIP-BCP-T Sep 99 Brian Morgan ipVerse, Inc. 1901 Landings Drive Mountain View, CA 94043, USA Phone: 650-919-0631 Email: bfmorgan@ipverse.com Gonzalo Camarillo Oy L M Ericsson Ab Telecom R&D FIN-02420 Jorvas Finland Phone : +358 9 299 33 71 Email : Gonzalo.Camarillo@ericsson.com 6. References [1] Handley, Schulzrinne, Schooler and Rosenberg, "Session Initiation Protocol (SIP)", RFC 2543, IETF, March 1999. [2] ITU-T E.164, "The International Public Telecommunication Numbering Plan", May 1997. [3] M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, IETF, April 1998. [4] Zimmmerer, Vemuri, "The SIP/ISUP MIME TYPE", draft-ietf-mmusic-sip -isup-mime-00.txt, Internet Draft, IETF, August 1999, Work in Progress. [5] Donovan, Cannon, "The SIP INFO method", draft-ietf-mmusic-sip-info -method-01.txt, Internet Draft, IETF, June 1999, Work in Progress. [6] Camarillo, "Best Current Practices for ISUP to SIP Mapping", draft -camarillo-mmusic-sip-isup-bcp-00.txt, Internet Draft, IETF, August 1999, Work in Progress. [7] Freed, Borenstein, "MIME Part One: Format of Internet Message Bodies", RFC 2045, IETF, November 1996. [8] Freed, Borenstein, "MIME Part Two: Media Types", RFC 2046, IETF, November 1996. [9] Moore, "MIME Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, IETF, November 1996. Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 9] Internet Draft SIP-BCP-T Sep 99 [10] Freed, Klensin, Postel, "MIME Part Four: Registration Procedures", RFC 2048, IETF, November 1996. [11] Freed, Borenstein, "MIME Part Five: Conformance Criteria and Examples", RFC 2049, IETF, November 1996. [12] Yergeau, "UTF-8, A Transformation Format of Unicode and ISO 10646", RFC 2044, IETF, October 1996. Zimmerer, et al draft-ietf-mmusic-sip-bcp-t-00.txt [Page 10]