idnits 2.17.1 draft-zimmerer-sip-bcp-t-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 34 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 205 has weird spacing: '...ly like appli...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '7-11' on line 166 == Unused Reference: '7' is defined on line 495, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 498, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 501, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 504, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 507, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566) -- No information found for draft-zimmerer-sip - is the name correct? -- No information found for draft-ietf-mmusic-sip-info - is the name correct? ** Obsolete normative reference: RFC 2048 (ref. '10') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2044 (ref. '12') (Obsoleted by RFC 2279) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Eric Zimmerer 2 Category: Informational ipVerse, Inc. 3 Aparna Vemuri 4 Date: October 1999 Level 3 Communications 5 Expires: April 2000 Vijay Nadkarni 6 ipVerse, Inc. 7 Brian Morgan 8 ipVerse, Inc. 9 Steven Mayer 10 dynamicsoft 11 Gonzalo Camarillo 12 L M Ericsson Ab 14 SIP Best Current Practice for Telephony Interworking 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance 19 with all provisions of Section 10 of RFC 2026. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes Inter Media Gateway Controller (MGC) 39 communication using the Session Initiation Protocol (SIP, 40 [1]). SIP, with certain extensions, facilitates the exchange 41 of signaling information between an Originating MGC and a 42 Terminating MGC to complete calls. This document describes 43 the best current practice for using SIP to perform this 44 function. Where possible this draft references necessary 45 documents, and details the concepts and methods of 46 encapsulating PSTN signaling information in SIP messages. 48 Internet Draft SIP-BCP-T Oct 99 50 Note: 51 This document obseletes the 'SIP+: Inter-MGC Protocol'. 52 The ideas expressed in the SIP+ document have now taken 53 the shape of the SIP BCP-T. 55 1. Introduction 57 This document describes Inter Media Gateway Controller 58 communication using SIP[1]. SIP can be used to communicate 59 from a SIP end-point (Note: Here, 'SIP end-point' has to be 60 interpreted as a non-MGC SIP User Agent) to another SIP 61 end-point, from a SIP end-point to a Media Gateway 62 Controller (MGC), and from one MGC to another MGC. This 63 document details how to best use SIP to communicate 64 from one MGC to another MGC. 66 This document DOES NOT describe a new protocol. The 67 intention of this document is to detail or reference 68 the methods, standards and tools necessary to enable 69 MGCs to interoperate via the SIP protocol. The SIP 70 BCP-T replaces SIP+ (which was unfortunately viewed 71 as being a new protocol). The SIP BCP-T describes 72 the best current practice for using SIP for Inter-MGC 73 communication. 75 The SIP BCP-T facilitates the exchange of information 76 between an Originating Media Gateway Controller and 77 a Terminating Media Gateway Controller so that calls 78 may be completed. When SIP is used in the MGC-to-MGC 79 space, there are many cases where it must "bridge" PSTN 80 networks with IP networks. To do this, SIP must be extended 81 to transport PSTN signaling information. By extending SIP 82 messaging, and adding PSTN signaling encapsulation 83 functionality, the SIP BCP-T satisfies the requirements 84 for MGC-to-MGC communication. 86 SIP provides the methods to set up, tear down and manage 87 voice and data sessions. The extensions described and/or 88 referenced in this document enable SIP to encapsulate a 89 variety of PSTN signaling types including but not limited 90 to SS7, and Q.931. 92 Internet Draft SIP-BCP-T Oct 99 94 +--------+ +--------+ +--------+ 95 | |<--SIP--->| Proxy |<--SIP--->| | 96 +---| MGC | +--------+ | MGC |---+ 97 | | |<------------SIP------------->| | | 98 | +--------+ +--------+ | 99 SS7 | | SS7 100 Signal | | Signal 101 Link +------+ IP +------+ Link 102 | | MG |------------ Network ------------| MG | | 103 | +------+ +------+ | 104 | | \ / | | 105 | | Q.931 trunk CAS trunk | | 106 | SS7 trunk \ / SS7 trunk | 107 | | \ / | | 108 | +-----------------------------------------------+ | 109 +----| PSTN |---+ 110 +-----------------------------------------------+ 112 Figure 1: Use of the SIP BCP-T 114 Figure 1 shows a basic network configuration using SIP BCP-T. 115 In this example Media Gateways are connected to the Public 116 Switched Telephone Network (PSTN) via SS7 trunks, Q.931 trunks, 117 and Channel Associated Signaling (CAS) trunks. The Originating 118 Media Gateway Controller may receive a call over any of these 119 trunks. The signaling information from these trunks must be 120 processed by the MGC to establish the originating half of the 121 call, and to determine the identity of the Terminating MGC 122 required to complete the call. The originating MGC uses SIP 123 to communicate the necessary information to the terminating 124 MGC to complete the call. The terminating MGC must be able to 125 establish the terminating call half on any of the supported 126 trunk types. 128 The PSTN has many regional and national signaling variants 129 which make interoperability difficult. A key design goal of 130 the SIP BCP-T is to document a single standard method for MGCs 131 to interoperate. Therefore, the SIP BCP-T will use international 132 digit analysis, dialing plans, and interoperability standards 133 from the PSTN rather than any single National or regional variants. 134 To guard against regional variations, the SIP BCP-T is being designed 135 for international use from the start. The basic method of routing 136 calls will use ITU-T E.164 [2] numbering, and will adhere to 137 international routing of telephone numbers. 139 Internet Draft SIP-BCP-T Oct 99 141 The SIP BCP-T focuses on communication between MGCs, but must also 142 address the security concerns of SIP end-points communicating 143 with MGCs. The information contained in MGC-to-MGC messages is 144 sensitive, and must be secured from SIP end-points accessing 145 the network. 147 The SIP BCP-T reflects the design goals of efficient call setup and 148 scalability. This document describes a SIP implementation that is 149 intended to scale to millions of calls per hour for a world-wide 150 network. In addition to these ambitious goals, SIP BCP-T must 151 facilitate "bridging" PSTN networks with IP networks. To do this, 152 SIP BCP-T must be capable of transporting PSTN signaling information. 153 SIP BCP-T provides the methods for MGCs to set up, tear down and 154 manage voice and data calls. The extensions detailed here allow 155 SIP to accommodate a variety of in bound and out bound PSTN 156 signaling types including but not limited to SS7, Q.931, and CAS. 158 2. SIP BCP-T Components 160 2.1. SIP as defined in RFC 2543. 162 2.2. MIME multipart 164 Encapsulating PSTN signaling is a major function of the SIP BCP-T. 165 MIME multipart payloads enable SIP to carry any PSTN signaling 166 information required. SIP BCP-T uses MIME multipart [7-11] 167 (RFCs 2045-2049) to enable SIP messages to contain multiple 168 payloads in the body of the message. The multipart body 169 can consists of any combination of the following units: 170 SDP (Session Description Protocol) payload 171 ISUP payload 172 One or more units of any MIME type payload. 174 The following are the suggested encoding formats for the above- 175 mentioned units: 176 a) the SDP payload (text): 177 Content-Type: application/SDP; charset:ISO-10646 179 The SDP [3] payload is plain-text. Although the default for plain- 180 texts in MIME is US-ASCII, ISO-10646 is recommended here for the 181 following reasons: Both SIP and SDP use ISO 10646, and the ISO 10646 182 character set with UTF-8 encoding can be considered a superset of 183 the US-ASCII character set per RFC 2044 [12]. 185 Internet Draft SIP-BCP-T Oct 99 187 b) the ISUP payload (arbitrary binary data): 188 Content-Type: application/ISUP; version: one of (ETSI1, ANSI, 189 etc) 190 Content-Transfer-Encoding: binary 192 Encapsulating SS7 and other PSTN signaling messages inside SIP BCP-T 193 allows MGCs to be compatible with the PSTN. SIP BCP-T encapsulates and 194 transmits the native signaling messages from one PSTN to another, 195 essentially tunneling the PSTN signaling messages through the IP 196 network. To this end, SIP BCP-T has been extended with application/ 197 ISUP versions for several variants of ISUP. The use of ISUP 198 encapsulation with Content-Type "application/ISUP" allows ISUP 199 signaling messages to be tunneled between MGCs. The use of 'version' 200 allows differentiation between different ISUP variants. This enables 201 the terminating MGC to recognize and parse the messages correctly, 202 or (possibly) to reject the message if the particular ISUP variant 203 is not supported. The idea here is to allow MGCs to specify a 204 preference of version, so that the following scenarios are possible: 205 "I only like application/isup; version=ETSI1" or "I accept 206 application/isup (but don't know the details; I just pass them on to 207 some other tool that uses them)". The tools detailed in this document 208 allow MGCs to encpsulate any variant of ISUP. 210 The MGC network architecture makes possible the direct 211 connection of the originating MGC and the terminating MGC without 212 intermediate MGCs. This makes possible the scenario where 213 an MGC in one country must be able to "speak" the ISUP variants of 214 all other countries in order to complete calls, (as opposed to an 215 intermediate international gateway MGC). Alternatively, the 216 given MGC could use only a superset ISUP protocol, or an agreed 217 -upon "lowest common denominator" ISUP variant, which all 218 other MGCs connected to that MGC would have to use. The 219 ability to encapsulate any version of ISUP inside SIP messages 220 enables any of these scenarios. The optimal interworking of protocol 221 variants can be determined by the network operator. A superset 222 approach, an agreed upon (lowest common denominator) interworking 223 variant approach, or support of all variants approach can all be 224 implemented using the SIP BCP-T. 226 For example, when a call arrives at an MG on an SS7 trunk, the 227 Originating MGC encapsulates the IAM in the INVITE 228 message body that is sent to the terminating MGC. This MGC reads 229 the IAM from the INVITE payload and may use it when creating its 230 signaling message to the terminating telephone network. 232 Internet Draft SIP-BCP-T Oct 99 234 Subsequent ACM and ANM messages are passed back to the Originating 235 MGC along with other necessary information via 100 Trying and 200 236 OK messages. The version tells the receiving MGC which type of 237 ISUP message has been encoded. 239 Note: 100 responses aren't forwarded by intermediate servers and 240 this constitutes a problem while trying to encapsulate the ISUP 241 ACM. One method to get around this is to introduce a new 100 242 class message that would go right upto the originating MGC, and 243 use this to carry the ACM. It should be noted that this idea 244 is still in a nascent stage and warrants more discussion at this 245 point of time. Efforts are on to determine whether a proposal to 246 deal with this currently exists, or if the formulation of a new 247 one is necessary. 249 c) One or more units of any MIME type payload 250 (dependent on use): 252 No rules have been defined here. The Content-Type and 253 Content-Transfer-Encoding parameters would be determined by the 254 MIME type and the kind of data sent compliant with the rules of 255 RFCs 2045, 2046. 257 Note: The Content-Type specification is mandatory in all instances 258 to differentiate between the different payload types. This is because 259 there is no guarantee of a specific order or required type of the 260 payloads. 262 2.2.1 An illustrative example: 264 SIP message format requires a Request line followed by Header lines 265 followed by a CRLF separator followed by the message body. To 266 illustrate the use of multipart payload message body, below is 267 an INVITE message which has the originating SDP information and 268 an encapsulated ISUP IAM: 270 INVITE sip:13035553142@Den1.level3.com SIP/2.0 271 From: sip:13035553355@den3.level3.com 272 To: sip:13035553142@Den1.level3.com 273 Call-ID: DEN1231999021712095500999@Den1.level3.com 274 Content-Length: 377 275 Content-Type: multipart/mixed; boundary=unique-boundary-1 276 MIME-Version: 1.0 278 --unique-boundary-1 279 Content-Type: application/SDP; charset=ISO-10646 281 Internet Draft SIP-BCP-T Oct 99 283 v=0 284 o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 285 s=SDP seminar 286 c=IN IP4 MG122.level3.com 287 t= 2873397496 2873404696 288 m=audio 9092 RTP/AVP 0 3 4 290 --unique-boundary-1 291 Content-type:application/ISUP; version=ETSI1 292 Content-Transfer-Encoding: binary 294 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 296 --unique-boundary-1-- 298 Note: 299 Since binary encoding is used for the ISUP payload, each byte is 300 encoded as a byte, and not as a two-character hex representation. 301 Hex digits were used in the draft because a literal encoding of 302 those bytes would have been confusing and unreadable. 304 2.3. ISUP MIME Type 305 The ISUP MIME type is required to encapsulate the PSTN ISUP signaling 306 information. See Internet draft: draft-zimmerer-sip-isup-mime-00.txt 307 [4] 309 2.4. INFO method 310 The intent of the INFO method is to allow for SIP to carry session 311 related control information that is generated during a session. 312 The INFO method is added specifically to allow PSTN signaling messages 313 beyond call setup and teardown to be transmitted between MGCs. This 314 method may be used by either originating or terminating MGC to 315 communicate additional information such as mid-call telephony 316 signaling messages resulting from the interworking between an ISUP 317 or ISDN network device and a SIP controlled network. 319 This has been described in an Internet Draft: 320 draft-ietf-mmusic-sip-info-method-01.txt. [5] 322 Note: This draft references draft-ietf-sigtran-mime-isup-00.txt 323 proposal for encapsulating telephony signaling control information as 324 part of an ISUP attachment to the INFO message. It is recommended to 325 use the format outlined above in section 2.2. MIME Multipart instead. 327 2.5. ISUP-SIP mapping 328 (Internet draft pending) 329 The SIP BCP-T recommends the ISUP-SIP mapping detailed in the 330 Internet draft: draft-camarillo-mmusic-sip-isup-bcp-00.txt. 331 [6]. 333 Internet Draft SIP-BCP-T Oct 99 335 2.6. Network Access Point (NAP) architecture 336 (Internet draft pending) 338 3. Security 340 The security provided by SIP is sufficient for the initial deployment 341 of inter-MGC communication. There are issues requiring further study 342 with regard to the interoperation of MGCs and SIP end-points. There 343 is an interesting line that must be drawn between giving too much 344 control to the endpoint clients and not enough control. The notion 345 of a secure proxy between SIP end-points and the network MGCs 346 requires more study. 348 4. Glossary 350 ACM Address Complete Message. One of the ISUP call setup 351 messages.A message sent in the backward direction 352 indicating that all the address signals required for 353 routing the call to the called party have been received. 355 ANM ANswer Message. Another one of the ISUP call setup 356 messages. A message sent in the backward direction 357 indicating that the call has been answered. 359 CAS Channel Associated Signaling. Signaling (for example, 360 in a T-1 line) in which control signals, are carried 361 in the same channel along with voice and data signals. 363 IAM Initial Address Message in the ISUP call set up 364 messages. A mandatory message sent in the forward 365 direction to initiate seizure of an outgoing circuit. 367 ISDN Integrated Services Digital Network in concept is the 368 integration of both analog or voice data together with 369 digital data over the same network. 371 ISUP ISDN User Part. This defines the methods and protocols 372 used in the establishment and tear-down of voice and 373 data calls over the public switched network, and to 374 manage the trunk network on which they rely. It is 375 used for both ISDN and non-ISDN calls. 377 MGC Media Gateway Controller. Also known as a Call Agent 378 or a SoftSwitch. This is the unit that controls the media 379 gateways and is responsible for all the control signaling 380 necessary for call set-up. 382 Internet Draft SIP-BCP-T Oct 99 383 MIME Multipurpose Internet Mail Extensions. This set of 384 documents redefines the format of mail messages to 385 allow for multipart message bodies, textual message 386 bodies and header information in character sets other 387 than US-ASCII, etc. 389 PSTN Public Switched Telephone Network. It refers to the 390 world's collection of interconnected voice-oriented 391 public telephone networks, both commercial and 392 government-owned. 394 SDP Session Description Protocol. It is a protocol that is 395 used to transfer information between interested parties 396 to discover and participate in a multimedia session. 397 Fully specified as a standard in RFC 2327 ([3]). 399 SIP BCP-T Best Current Practices for using SIP in Telephony. It is 400 an extension of SIP (as specified in RFC 2543) to 401 facilitate inter-MGC communication. 403 SS7 Signaling System 7. It is a global standard for tele- 404 communications that defines the architecture for performing 405 the call-establishment, billing, routing, and information- 406 exchange functions of the PSTN. 408 Q.931 This ITU-T recommendation is the signaling protocol in 409 the PRI ISDN D channel. It describes what goes into a 410 signaling packet and defines the message type and content. 412 UTF-8 Unicode Standard Transformation Format. This is a 413 transformation format that retains the full US-ASCII 414 range and provides compatibility with file systems, 415 parsers and other software that rely on US-ASCII 416 values but are transparent to other values. 418 5. Acknowledgements 420 Many people have contributed to this document. In particular Henning 421 Schulzrinne, Ike Elliott, Andrew Dugan, Henry Sinnreich, Vipul Patel, 422 Matt Cannon, John Wetherbie, and Dent Steve Dent. 424 6. Authors 426 Eric Zimmerer 427 ipVerse, Inc. 428 1901 Landings Drive, 429 Mountain View, CA 94043, USA 430 Phone: 650-919-0648 431 EMail: ericz@ipverse.com 433 Internet Draft SIP-BCP-T Oct 99 435 Aparna Vemuri 436 Level 3 Communications, 437 1450 Infinite Drive, 438 Louisville, CO, 80027, USA 439 Phone: 303-926-3768 440 EMail: aparna.vemuri@level3.com 442 Vijay Nadkarni 443 ipVerse, Inc. 444 1901 Landings Drive 445 Mountain View, CA 94043, USA 446 Phone: 650-919-0604 447 Email: vijayn@ipverse.com 449 Brian Morgan 450 ipVerse, Inc. 451 1901 Landings Drive 452 Mountain View, CA 94043, USA 453 Phone: 650-919-0631 454 Email: bfmorgan@ipverse.com 456 Steven Mayer 457 dynamicsoft 458 200 Executive Drive 459 Suite 120 460 West Orange, NJ 07052 461 Phone: 732-741-7244 462 Email: smayer@dynamicsoft.com 464 Gonzalo Camarillo 465 Oy L M Ericsson Ab 466 Telecom R&D 467 FIN-02420 Jorvas Finland 468 Phone : +358 9 299 33 71 469 Email : Gonzalo.Camarillo@ericsson.com 471 7. References 473 [1] Handley, Schulzrinne, Schooler and Rosenberg, "Session Initiation 474 Protocol (SIP)", RFC 2543, IETF, March 1999. 476 [2] ITU-T E.164, "The International Public Telecommunication Numbering 477 Plan", May 1997. 479 [3] M. Handley and V. Jacobson, "SDP: Session Description Protocol", 480 RFC 2327, IETF, April 1998. 482 Internet Draft SIP-BCP-T Sep 99 484 [4] Zimmmerer, Vemuri, "The SIP/ISUP MIME TYPE", draft-zimmerer-sip 485 -isup-mime-00.txt, Internet Draft, IETF, October 1999, Work in 486 Progress. 488 [5] Donovan, Cannon, "The SIP INFO method", draft-ietf-mmusic-sip-info 489 -method-01.txt, Internet Draft, IETF, June 1999, Work in Progress. 491 [6] Camarillo, "Best Current Practices for ISUP to SIP Mapping", draft 492 -camarillo-mmusic-sip-isup-bcp-00.txt, Internet Draft, IETF, 493 August 1999, Work in Progress. 495 [7] Freed, Borenstein, "MIME Part One: Format of Internet Message 496 Bodies", RFC 2045, IETF, November 1996. 498 [8] Freed, Borenstein, "MIME Part Two: Media Types", RFC 2046, IETF, 499 November 1996. 501 [9] Moore, "MIME Part Three: Message Header Extensions for Non-ASCII 502 Text", RFC 2047, IETF, November 1996. 504 [10] Freed, Klensin, Postel, "MIME Part Four: Registration 505 Procedures", RFC 2048, IETF, November 1996. 507 [11] Freed, Borenstein, "MIME Part Five: Conformance Criteria and 508 Examples", RFC 2049, IETF, November 1996. 510 [12] Yergeau, "UTF-8, A Transformation Format of Unicode and ISO 511 10646", RFC 2044, IETF, October 1996.