idnits 2.17.1 draft-vemuri-sip-t-context-02.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 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.) ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 904 looks like a reference -- Missing reference section? '1' on line 901 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft Aparna Vemuri 4 draft-vemuri-sip-t-context-02.txt Jon Peterson 5 February 2001 Level (3) Communications 6 Expires: August 2001 8 SIP for Telephones (SIP-T): Context and Architectures 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 SIP-T (earlier referred to as the SIP-BCP-T) is a mechanism that uses 34 SIP to facilitate the interconnection of the PSTN with IP. This 35 document explains the context and the architectures in which SIP-T 36 may be used. This document has to be studied in conjunction with the 37 existing SIP-T (referred to in some older documents as SIP-BCP-T) 38 literature. 40 1. Introduction 42 The Session Initiation Protocol (SIP) is an application-layer control 43 protocol that can establish, modify and terminate multimedia sessions 44 or calls. These multimedia sessions include multimedia conferences, 45 Internet telephony and similar applications. SIP is one of the key 46 protocols used to implement VoIP. Although performing telephony call 47 signaling and transporting the associated audio media over IP beget 48 significant advantages, a VoIP network cannot exist in isolation. It 49 is vital for a SIP network to be smoothly interfaced to the PSTN. 51 An important characteristic of any VoIP SIP network is FEATURE 52 TRANSPARENCY with respect to the PSTN. Traditional telecom services 53 such as call waiting, 800 numbers, etc. implemented in SS7 should be 54 offered by a SIP network in a manner that precludes any debilitating 55 difference in the user experience. It is necessary that SIP support 56 the primitives for the delivery of such services where the 57 terminating point is a regular SIP-phone (see definition in section 2 58 below). However, it is essential that SS7 information be available at 59 the points of PSTN inter-connection to ensure transparency of 60 features not otherwise supported in SIP. SS7 information should be 61 available in its entirety and without any loss to the SIP network 62 across the PSTN-IP interface. A compelling need to do so also arises 63 from the fact that certain networks utilize proprietary ISUP 64 parameters to transmit certain information through their networks. 65 Another requirement is ROUTABILITY in the SIP network - a SIP message 66 that is used to set up a telephone call should bear sufficient 67 information that would enable it to be appropriately routed to its 68 destination by proxy servers in the SIP network. The SIP-T (SIP for 69 Telephones) effort provides a framework for the integration of legacy 70 telephony signaling into SIP messages. SIP-T fulfils the above two 71 requirements through ENCAPSULATION and TRANSLATION respectively. At 72 the point of inter-connection SS7 ISUP messages are encapsulated 73 within SIP in order that information necessary for services is not 74 discarded. Also, certain information is translated from an SS7 ISUP 75 message to generate the corresponding SIP header information in order 76 to facilitate the routing of SIP messages. 78 While pure SIP has all the requisite instruments for the 79 establishment and termination of calls, it does not have any 80 mechanism to carry any MID-CALL CONTROL INFORMATION along the SIP 81 signaling path during the session. This mid-call information does not 82 result in any change in the state of SIP calls or the parameters of 83 the sessions that SIP initiates. A provision to transmit such 84 optional application layer information is also needed. Thus, SIP-T 85 also has to cater to this requirement of transferring mid-call 86 signaling information. 88 Problem definition: To provide ISUP transparency across PSTN-IP 89 ------------------- inter-connections 91 PSTN-IP Inter-connection Requirements SIP-T Functions 92 ================================================================== 93 Availability of ISUP Encapsulation of ISUP in the 94 information SIP body 95 Routability of SIP messages with Translation of ISUP information 96 ISUP dependencies into the SIP header 98 Transfer of mid-call ISUP signaling Use of the INFO Method for mid- 99 messages call signaling 100 (See section 4.d) 102 Table 1: SIP-T features that fulfill PSTN-IP inter-connection 103 requirements 105 Note: 107 1. Many modes of signaling are used in telephony (SS7 ISUP, BTNUP, 108 ISDN, etc.). This document concentrates only on SS7 ISUP and aims to 109 specify the behavior across ISUP-SIP interfaces only. 111 2. SIP-T details the methods and tools necessary for the PSTN and 112 VoIP networks to inter-operate via the SIP protocol. This paper 113 provides a context for the usage of SIP-T and characterizes 114 architectures that employ SIP-T. It also highlights the functions of 115 the different elements in a SIP-T-enabled network. This document is 116 to be assessed in conjunction with the SIP-BCP-T (presently known as 117 SIP-T) document-set. 119 2. SIP-T for PSTN-IP Interconnections 121 SIP-T is not a new protocol. It embodies the manner in which SIP must 122 be used to provide ISUP transparency across PSTN-IP inter- 123 connections. It is to be used in situations where an IP network (SIP 124 network, for the purposes of our discussion) interfaces with the 125 PSTN. Such a network may frequently need to hand a call over to 126 another network in order to terminate it. Therefore, such networks do 127 not normally exist in isolation. They have business relationships 128 with each other resulting in them being peered together in order to 129 terminate calls. Thus, SIP-T originates from networks and it 130 terminates at other sites within the network or at a peer network. It 131 is therefore an intra- network or inter-network mechanism that uses 132 SIP. Networks that are peered together adhere to certain rules as 133 specified in their agreements with each other. Thus, SIP-T may not 134 traverse networks arbitrarily. The originator of a SIP-T message 135 could have a relationship with the receiver of the message. 137 It follows that a network should have PSTN access in order to 138 originate SIP-T (PSTN origination). However, a network need not have 139 PSTN access in order to receive SIP-T. A network can terminate calls 140 directed at IP-based end-user devices that are homed to it or to the 141 PSTN. Or, a network may just serve as a transit network with IP 142 inter-connections to other networks that have PSTN interfaces. Such a 143 transit network will accept VoIP calls from one network and hand them 144 off to another network where they may be terminated. And, the 145 originating network most often will not know whether the receiving 146 (i.e. next-hop) network is a terminating network or a transit 147 network. (See Note 1.) 149 The PSTN interfaces that a particular network is associated with 150 define the ISUP variants that that network supports. This capability 151 of a network to be able to support a particular version of ISUP 152 determines whether it can provide feature transparency while 153 terminating a call. 155 The following are the components of a SIP-T-enabled network. 157 1. PSTN: This is the Public Switched Telephone Network. It may 158 either refer to the entire inter-connected collection of local, 159 long- distance and international phone companies or some subset 160 thereof. 162 2. IP-endpoint: Any sort of device that originates SIP-calls to the 163 network may be considered an IP end-point for the purposes of this 164 document. Thus, the following devices may classify as 166 IP-end-points: a. MGC UA: A Media Gateway Controller (MGC) is an 167 entity used to control a gateway (that is typically used to provide 168 conversion between the audio signals carried on telephone circuits 169 and data packets carried over packet networks). The term MGC is 170 thus used in this document to typify entities that control the 171 point of inter-connection between the PSTN and the IP-network. An 172 MGC speaks ISUP to the PSTN and SIP to the IP-network and converts 173 between the two. 175 b. SIP-phone: The term used to represent all end-user devices that 176 originate SIP calls. 178 c. Firewalls or edge-elements through which calls may enter the 179 network from that of a peer network. 181 3. Proxy: A proxy is a SIP entity that helps route SIP signaling 182 messages to their destinations. Consequently, a proxy might route 183 SIP messages to other proxies (some of which may be co-located with 184 firewalls), MGCs and SIP-phones. 186 ******************** 187 *** *** 188 * * 189 * ------- * 190 * |proxy| * 191 * ------- * 192 |----| |----| 193 /|MGC1| VoIP Network |MGC2|\ 194 / ---- ---- \ 195 SS7 / * * \ SS7 196 / * ------- * \ 197 / * |proxy| * \ 198 -------- * ------- * --------- 199 | LEC1 | ** ** | LEC2 | 200 -------- ********************* --------- 202 Figure 1: Necessity for SIP-T in PSTN-IP inter-connection 204 In the above figure the IP network (see Note 2) bridges two LECs 205 together. SIP is employed as the VoIP protocol used to set up and 206 tear down VoIP sessions and calls. The VoIP network receives SS7 207 messages from one PSTN interface (the PSTN origination) and sends 208 them out on another (PSTN termination). Let a call originate from 209 LEC1 and be terminated by LEC2. The originator is defined as the 210 generator of the SIP setup signaling and the terminator is defined as 211 the consumer of the SIP setup signaling. MGC1 is thus the originator 212 and MGC2, the terminator. One or more proxies may be used to route 213 the call from the originator to the terminator. 215 In order to seamlessly integrate the IP network with the PSTN, it is 216 important to retain the SS7 information at the points of inter- 217 connection and use this information for the purpose of call 218 establishment. By including ISUP information in the SIP signaling the 219 network automatically leverages the call establishment capability of 220 SIP while trying to establish a session whose attributes may be 221 influenced by the ISUP information. 223 SIP-T is employed in order to leverage the intrinsic benefits of 224 utilizing SIP: call control and establishment via proxies, capability 225 to enable new services, etc. However, if only the transportation of 226 ISUP was relevant here, any protocol for the transport of signaling 227 information may be used to achieve this, obviating the need for SIP 228 and consequently that of SIP-T. SIP-T thus facilitates call 229 establishment and the enabling of new services over the IP network 230 while simultaneously providing a method of inter- connection with the 231 PSTN. 233 SIP-T preserves the ISUP information received by the originator by 234 encapsulating it in the SIP messages that it uses to establish a 235 session with the terminator. Translation of information from the 236 received ISUP messages to the SIP header fields enables these 237 messages to be effectively routed to the terminator. The terminator 238 then generates the ISUP message from the received SIP message and 239 sends it to the PSTN at the terminating end. 241 Voice calls do not always have to originate and terminate in the PSTN 242 (via MGCs). They may either originate and/or terminate in SIP phones. 243 The alternatives for call origination and termination suggest the 244 following possibilities for calls that traverse through an IP 245 network: 247 Note: The words originator and terminator used in the following text 248 are used with reference to the SIP setup signaling (as explained 249 above). The words origination and termination as in 'PSTN 250 origination', 'IP termination', etc. are used to refer to the call 251 from the actual, physical origination to the termination, i.e., 252 between the two end-users that communicate.) 254 1. PSTN origination - PSTN termination: The originator (ingress- 255 MGC) receives ISUP from the PSTN and it retains this information 256 (via encapsulation and translation) in the SIP messages that it 257 transmits towards the terminator (egress-MGC). The terminator 258 extracts the ISUP content from the SIP message that it receives and 259 it dispatches this to the PSTN. 261 2. PSTN origination - IP termination: The originator (MGC) receives 262 ISUP from the PSTN and it preserves this ISUP information in the 263 SIP messages (via encapsulation and translation) that it directs 264 towards the terminator (SIP-phone). The terminator has no use for 265 the encapsulated ISUP and ignores it. 267 3. IP origination - PSTN termination: A SIP-phone originates the 268 call towards the network. A SIP message is thus received at the 269 point of entry to the IP network and is routed to the appropriate 270 terminating end-point (terminator). The terminator (MGC) tries to 271 terminate the call to the appropriate PSTN interface, based on 272 information that is present in the received SIP header. The ISUP 273 message that is to be sent to the LEC must be generated from 274 information gleaned from the SIP header. 276 4. IP origination - IP termination: This is a case for pure SIP. 277 SIP-T does not come into play as there is no PSTN involvement. 279 Thus, there are three distinct elements (from a functional point of 280 view) in a SIP VoIP network offering PSTN inter-connection: 282 1. The originator of SIP signaling 283 2. The terminator of SIP signaling 284 3. The network of proxies that routes calls from the originator to 285 the terminator. 287 The capabilities required of these entities are ascertained by 288 exploring the path that a SIP message takes from its generation to 289 its final consumption. This is discussed in the next section. 291 3. SIP-T Configurations and Roles 293 For the purposes of this document, an MGC is the point of inter- 294 connection between the PSTN and the IP network and ISUP is the 295 protocol used for call signaling in SS7 networks. SIP is the protocol 296 used for the establishment and termination of sessions in the IP 297 world. The IP body (as portrayed in all the illustrations in this 298 document) may encompass a mass of distinct SIP-enabled IP networks, 299 inter-connected to each other through SIP proxies and a firewall 300 infrastructure. Proxies are employed to facilitate the routing of the 301 SIP messages, both within and across the IP networks. Firewalls may 302 be deployed at the point of inter-connection in order to insure that 303 the transfer of calls does not constitute a security breach for 304 either network. 306 The different configurations that are possible in a SIP-T network are 307 presented in section 3.1 below. Originator, terminator and proxy 308 requirements are addressed in section 3.2. 310 3.1 SIP-T Configurations 312 The different configurations that are possible in PSTN-IP inter- 313 connections are presented below. 315 3.1.1 SIP bridging (PSTN - IP - PSTN) 316 ******************** 317 *** *** 318 * * 319 * ------- * 320 * |proxy| * 321 * ------- * 322 |---| |---| 323 /|MGC| VoIP Network |MGC|\ 324 / --- --- \ 325 / * * \ 326 / * ------- * \ 327 / * |proxy| * \ 328 -------- * ------- * --------- 329 | PSTN | *** *** | PSTN | 330 -------- ********************* --------- 332 Figure 2: PSTN origination - PSTN termination (SIP Bridging) 334 A situation in which a SIP network connects two instances of the 335 telephone network is an example of 'SIP bridging'. A telephone call 336 originates in the PSTN and an SS7 ISUP message is dispatched to the 337 MGC that is the point of interconnection with the PSTN network. This 338 MGC is the point of origination (or ingress) for message flows over 339 the IP network for this call. The call progresses in the IP network 340 (through proxies that route the call) until it is terminated at the 341 appropriate PSTN interface. The MGC that interconnects to the PSTN at 342 the egress is the point of termination of the IP message flow. This 343 egress-MGC then uses ISUP to communicate with the PSTN at the 344 terminating end. SIP is used in the IP network to determine the 345 appropriate point of termination and to establish a session between 346 the origination and termination in order to carry the call through 347 the IP network. 349 A very elementary call-flow for SIP bridging is as shown below. 351 PSTN MGC#1 Proxy MGC#2 PSTN 352 |-------IAM------>| | | | 353 | |-----INVITE---->| | 354 | | | |-----IAM----->| 355 | |<--100 TRYING---| | 356 | | | |<----ACM------| 357 | |<-----18x-------| | 358 |<------ACM-------| | | | 359 | | | |<----ANM------| 360 | |<----200 OK-----| | 361 |<------ANM-------| | | | 362 | |------ACK------>| | 363 |====================Conversation=================| 364 |-------REL------>| | | | 365 |<------RLC-------|------BYE------>| | 366 | | | |-----REL----->| 367 | |<----200 OK-----| | 368 | | | |<----RLC------| 369 | | | | | 371 3.1.2 PSTN origination - IP termination 373 ******************** 374 *** *** 375 * * 376 * * 377 * * 378 * * 379 |----| |-----| 380 /|MGC | VoIP Network |proxy|\ 381 / ---- ----- \ 382 / * * \ 383 / * * \ 384 / * * \ 385 -------- * * ------------- 386 | PSTN | ** ** | SIP-phone | 387 -------- ********************* ------------- 389 Figure 3: PSTN origination - IP termination 391 A call originates from the PSTN and terminates at a SIP-phone. 393 A simple call-flow depicting the ISUP and SIP signaling for a PSTN- 394 originated call terminating in IP as follows: 396 PSTN MGC Proxy SIP-phone 397 |----IAM----->| | | 398 | |--------INVITE------>| | 399 | | |-------INVITE------->| 400 | |<------100 TRYING----| | 401 | | |<-------18x----------| 402 | |<---------18x--------| | 403 |<----ACM-----| | | 404 | | |<-------200 OK-------| 405 | |<-------200 OK-------| | 406 |<----ANM-----| | | 407 | |---------ACK-------->| | 408 | | |---------ACK-------->| 409 |=====================Conversation========================| 410 |-----REL---->| | | 411 | |----------BYE------->| | 412 |<----RLC-----| |---------BYE-------->| 413 | | |<-------200 OK-------| 414 | |<-------200 OK-------| | 415 | | | | 417 3.1.3 IP origination - PSTN termination 419 ******************** 420 *** *** 421 * * 422 * * 423 * * 424 * * 425 |-----| |----| 426 /|proxy| VoIP Network |MGC |\ 427 / ----- ---- \ 428 / * * \ 429 / * * \ 430 / * * \ 431 ------------ * * --------- 432 |SIP-phone | ** ** | PSTN | 433 ------------ ********************* --------- 435 Figure 4: IP origination - PSTN termination 437 A call originates from a SIP-phone and terminates in the PSTN. There 438 is no telephony interface at call-origination. 440 A simple call-flow illustrating the different legs in the call is as 441 shown below. 443 SIP-phone Proxy MGC PSTN 444 |-----INVITE----->| | | 445 | |--------INVITE-------->| | 446 |<---100 TRYING---| |-------IAM------>| 447 | |<------100 TRYING------| | 448 | | |<------ACM-------| 449 | |<---------18x----------| | 450 |<------18x-------| | | 451 | | |<------ANM-------| 452 | |<--------200 OK--------| | 453 |<-----200 OK-----| | | 454 |-------ACK------>| | | 455 | |----------ACK--------->| | 456 |==========================Conversation=====================| 457 |-------BYE------>| | | 458 | |----------BYE--------->| | 459 | | |-------REL------>| 460 | |<--------200 OK--------| | 461 |<-----200 OK-----| |<------RLC-------| 463 3.2 SIP-T Roles 465 Originator and terminator requirements are derived in sections 3.2.1 466 and 3.2.2 respectively. Proxy requirements are described in section 467 3.2.3. 469 3.2.1 Originator 471 The fundamental function of the originator is to generate the SIP 472 call-setup signaling. The MGC is the originator for PSTN 473 originations, while the SIP-phone is the originator for IP- 474 originations. In either case, it should be noted that the originator 475 is not certain of the nature of the termination, i.e. whether it is 476 in IP or the PSTN. 478 In the case of calls originating in the PSTN (figures 2 and 3), the 479 originator (MGC) takes the necessary steps to preserve the ISUP 480 information. It formulates the SIP INVITE from the ISUP that it has 481 received from the PSTN. The originator is entrusted with the 482 responsibility of identifying the nature of the ISUP (ETSI, ANSI, 483 etc.) that it has received, depending on the nature of the PSTN 484 interface. This ISUP is correctly classified to be a particular ISUP 485 variant that the originating network supports. The MGC then 486 translates certain ISUP information into the SIP headers (see Note 487 3), so as to enable the SIP message to be routed. This might, for 488 instance, involve setting the 'To' field in the INVITE to the dialed 489 number (Called Party Number) of the ISUP IAM. The MGC then 490 encapsulates the ISUP IAM into the SIP INVITE and ships it out. 492 The originator is not certain of the entity that will terminate the 493 call - the fact that the terminating entity could be a SIP-phone that 494 does not need ISUP is not known to the originator, and it proceeds 495 with ISUP encapsulation. It is the responsibility of the terminator 496 to determine whether it wants to utilize the encapsulated ISUP or 497 not. 499 In case of an IP-origination (figure 4) the SIP-phone is the 500 originator. The SIP-phone issues the SIP signaling that is directed 501 to a SIP proxy that allows it entry into the network. There is no 502 ISUP to encapsulate, as there is no PSTN interface. Although the call 503 may terminate in the telephone network and need ISUP in order that 504 that may take place, the originator may not be aware of this and 505 consequently, should not be burdened with the task of generating the 506 ISUP. It is the responsibility of the terminator to generate ISUP if 507 necessary (i.e. for PSTN terminations only, and not for IP 508 terminations). 510 Thus, an originator must generate the SIP signaling while performing 511 ISUP encapsulation and translation (ISUP to SIP) wherever possible 512 (PSTN originations). This must be done irrespective of the nature of 513 the termination (whether SIP or SS7). 515 Originator requirements: encapsulate ISUP, translate information from 516 ISUP to SIP 518 3.2.2 Terminator 520 The terminator is the consumer of the SIP signaling. The terminator 521 is a SIP UA that must be capable of standard SIP processing. The MGC 522 is the terminator in case of PSTN terminations and is responsible for 523 terminating the call to the LEC via ISUP. The SIP-phone is the 524 terminator for IP terminations. 526 In case of PSTN terminations (figures 2 and 4) the MGC at the egress 527 tries to terminate the call to the appropriate PSTN interface. The 528 terminator generates the ISUP from the incoming SIP message. The ISUP 529 may either be extracted directly from the SIP message that 530 encapsulates it or gleaned from the SIP headers . In order to make 531 the determination about the PSTN termination the terminator looks 532 either into the encapsulated ISUP that it has received, or the SIP 533 header. In some instances the ISUP that has been retrieved from the 534 SIP message may need to be modified before it is sent out to the LEC. 535 (See Note 4) 537 In case of an IP termination (figure 3) the SIP-phone that receives 538 ISUP-encapsulated SIP messages from the network disregards the ISUP 539 as it does not hold any significance for an IP-termination. 541 Terminator requirements: standard SIP processing, interpretation of 542 encapsulated ISUP (multi-part MIME; see 4.b.1), ignorance of unknown 543 MIME content (specifically ISUP) 545 3.2.3 Proxy 547 Proxies are entrusted with the task of routing messages to other 548 proxies, both within and at the edges of the network (the latter may 549 be co-located with firewalls that monitor the point of inter- 550 connection with external elements), MGCs and SIP-phones. 552 A call that enters a given network (say network A) may be terminated 553 at the appropriate PSTN interface (MGC) or SIP-phone homed to network 554 A (intra-network), or, it may be handed off to a peer network for 555 termination through an edge proxy (inter-network). The proxies make 556 this determination based on their evaluation of the routable elements 557 in the SIP message. The routable elements could be the dialed number 558 or the ISUP variant or any other parameter (See Note 5.) The edge 559 elements (both MGCs and proxies) must be cognizant of the potential 560 (capabilities) of their interfaces (PSTN interfaces and peer proxies 561 respectively) in order to facilitate routing. 563 Feature transparency of ISUP is central to the notion of SIP-T. 564 Compatibility between the ISUP variants of the originating and 565 terminating PSTN interfaces automatically leads to feature 566 transparency. The termination of a call at a point that results in 567 greater proximity to the final destination (rate considerations) is 568 also preferable. The preference of one over the other results in a 569 trade-off between simplicity of operation and cost. (See Note 6.) The 570 requirement of procuring a reasonable rate may dictate that a SIP-T 571 call spans dissimilar PSTN interfaces (SIP bridging across different 572 ISUP variants). Two different possibilities arise here: 574 a) The need for ISUP feature transparency may necessitate ISUP 575 translation (conversion), i.e. conversion from one version of ISUP 576 to another in order to facilitate the termination of that call over 577 an interface (MGC) that does not support the ISUP variant of the 578 originating PSTN interface. (See Note 7.) Although in theory 579 conversion may be performed at any point in the path, it is viable 580 to perform it at a point that is at the greatest proximity to the 581 terminating MGC. This may be accomplished by transferring the call 582 to an Application Server (See Note 8) that spawns an application to 583 perform the conversion. Feature transparency in this case is 584 contingent on the availability of resources to perform ISUP 585 conversion, and, is secured as a result of an increase in the call- 586 set up time. 588 b) The alternative would be to sacrifice ISUP transparency by 589 handing the call off to an interface (MGC) that does not support 590 the version of the originating ISUP. The terminating MGC would then 591 just ignore the encapsulated ISUP and use the information in the 592 SIP header to terminate the call. 594 Thus, the proxy must have the intelligence to make a judicious choice 595 given the options available to it. The task of determining which peer 596 proxy or MGC to hand off the call to is a routing problem that is 597 contingent upon the choice of the routable elements. 599 Proxy requirements: ability to route based on choice of routable 600 elements 602 In summary: 604 The ORIGINATOR must try to perform ISUP encapsulation and translation 605 irrespective of the nature of the termination. 607 The TERMINATOR must either interpret the multipart MIME or ignore it 608 while performing standard SIP processing. The TERMINATOR must 609 regenerate the ISUP if the call terminates in the PSTN. Two 610 possibilities arise: 612 a) The ISUP may be extracted from the SIP message body, or, 613 b) The ISUP may be generated from information in the SIP headers. 614 The TERMINATOR must ignore any ISUP present in the SIP-T message in 615 case of IP termination. 617 A PROXY must be able to route a call based on the choice of routable 618 elements. 620 4. Components of the SIP-T proposal: 622 The key items of the specification that would address each of the 623 requirements in detail are as follows: 625 a. Core SIP SIP-T uses the methods and procedures of pure SIP as 626 defined by RFC 2543. 628 b. Encapsulation 630 b.1 The ISUP MIME type 632 Encapsulation of the PSTN signaling is one of the major 633 requirements of SIP-T. SIP-T uses MIME multi-part to enable SIP 634 messages to contain multiple payloads (SDP, ISUP, etc.). 635 Numerous ISUP variants are in existence today and the ISUP MIME 636 type should be such that it enables ISUP recognition in the 637 simplest manner possible. The ISUP nomenclature scheme should 638 meet the design goals of simplicity and extensibility while 639 providing a complete ISUP description. A scheme for performing 640 ISUP encapsulation using multi-part MIME has been described in 641 [2]. 643 c. Translation 645 ISUP is used between the IP network and the PSTN, while SIP is used 646 within the IP network. The MGC acts as a protocol converter between 647 SIP and ISUP. This dictates that signaling information be shared 648 across the two protocols so that VoIP sessions and SS7 connections 649 may be established appropriately. 651 c.1 ISUP SIP message mapping 652 This describes a mapping between ISUP and SIP. At the PSTN-IP 653 interface the MGC is entrusted with the task of generating an 654 ISUP message for each SIP message received and vice versa. It is 655 necessary to specify the rules that govern the mapping between 656 ISUP and SIP messages (i.e., what ISUP messages may be 657 encapsulated in a particular SIP message: an IAM must be 658 encapsulated in an INVITE, a REL in a BYE, etc.) 660 A potential mapping between ISUP and SIP messages has been 661 described in draft-camarillo-sip-isup-bcp-00.txt (Best Current 662 Practice for ISUP to SIP mapping). 664 c.2 ISUP parameter-SIP header mapping 666 A SIP message that is used to set up a telephone call should 667 contain sufficient information that would enable it to be 668 appropriately routed to its destination by proxy servers in the 669 SIP network. This implies that a certain amount of ISUP 670 information would have to be present in the SIP headers. It is 671 important to lay down a set of rules that defines the procedure 672 for translation of information from ISUP to SIP (for example, the 673 Called Party Number in an ISUP IAM must be mapped onto the SIP To 674 field, etc.) and also the interpretation of both elements (SIP 675 headers and encapsulated ISUP) at the terminating entity. This 676 issue becomes inherently more complicated by virtue of the fact 677 that a message (especially an INVITE) may undergo transformation 678 at the hands of an Application Server (AS), and consequently, one 679 or both of the following may result: 681 a) the SIP headers and ISUP content are in conflict (an example 682 in the Future Work section), or, b) a part of the encapsulated 683 ISUP may be rendered irrelevant and obsolete. 685 Rules that delineate the preferred behavior of the entities in 686 question (whether originating or terminating) and under the 687 specific circumstances surrounding each such case need to be 688 outlined. 690 d. Support for mid-call signaling 692 The INFO method 694 Pure SIP does not have any provision for carrying any mid-call 695 control information that is generated during a session. The INFO 696 method (defined in draft-ietf-sip-info-method-04.txt (The SIP INFO 697 Method) should be used for this purpose. 699 5. SIP Content Negotiation 701 The originator of a SIP-T request might package both SDP and ISUP 702 elements into the same SIP message by using the MIME multipart 703 format. If the terminator device did not support a multipart payload 704 (multipart/mixed) or the ISUP MIME type, it would reject the SIP 705 request with a 415 Unsupported Media Type specifying the media types 706 it supports (default - SDP). The originator would then have to re- 707 send the SIP request after stripping out the ISUP payload (i.e. with 708 only the SDP payload) and this would then be accepted. 710 This is a rather cumbersome flow and it is highly desirable to have a 711 mechanism by which the originator could signify which bodies are 712 required and which are optional so that the terminator can silently 713 discard optional bodies that it does not understand (like a SIP-phone 714 ignoring the ISUP payload). This is contingent upon the terminator 715 having support for a Content-type of multipart/mixed. The Content- 716 Disposition header referenced in [1] should be applied to each of the 717 MIME bodies in a MIME multipart to correctly specify how a given body 718 must be interpreted by the UAS. The ISUP MIME type using the 719 Content-Disposition header has been defined in [2]. An INVITE with a 720 multipart payload (such as SDP and ISUP) can thus specify how each of 721 the payloads may be processed, leading to call-flows such as the 722 following: 724 1. Support for ISUP is optional. Therefore, UA2 accepts the INVITE 725 irrespective of whether it can process the ISUP. 727 UA1 UA2 728 INVITE--> 729 (Content-type:multipart/mixed; 730 Content-type: application/sdp; 731 Content-disposition: session; handling=required; 732 Content-type: application/isup; 733 Content-disposition: signal; handling=optional;) 735 <--18x 737 2. Support for ISUP is preferred. UA2 does not support the ISUP and 738 rejects the INVITE with a 415 Unsupported Media Type. UA1 strips off 739 the ISUP and re-sends the INVITE with SDP only and this is then accepted. 741 UA1 UA2 742 INVITE--> 743 (Content-type:multipart/mixed; 744 Content-type: application/sdp; 745 Content-disposition: session; handling=required; 746 Content-type: application/isup; 747 Content-disposition: signal; handling=required;) 749 <--415 750 (Accept: application/sdp) 752 INVITE--> 753 (Content-type: application/sdp) 755 <--18x 757 3. Support for ISUP is mandatory for call establishment. UA2 does 758 not support the ISUP and rejects the INVITE with a 415 Unsupported 759 Media type. UA1 then directs its request to UA3. 761 UA1 UA2 762 INVITE--> 763 (Content-type:multipart/mixed; 764 Content-type: application/sdp; 765 Content-disposition: session; handling=required; 766 Content-type: application/isup; 767 Content-disposition: signal; handling=required;) 769 <--415 770 (Accept: application/sdp) 772 ACK--> 774 UA1 UA3 775 INVITE--> 776 (Content-type:multipart/mixed; 777 Content-type: application/sdp; 778 Content-disposition: session; handling=required; 779 Content-type: application/isup; 780 Content-disposition: signal; handling=required;) 782 Note: 1. These call-flows are not complete. Only the messages 783 relevant to this discussion are shown. 2. Specifics of the ISUP 784 MIME type can be obtained from [2]. The accordance with the rules 785 of [2]. 787 6. Security 789 SIP-T is an intra-network or inter-network signaling mechanism that 790 may be subject to pre-existing relationships between the networks. 791 The originator of a SIP-T message could have a relationship with the 792 receiver of the message. Each network should have the adequate 793 security apparatus (firewalls, etc.) in place to ensure that the 794 transfer of calls does not result in any security violations. 796 It has to be noted that the transit of ISUP in SIP bodies may provide 797 opportunities for abuse and fraud, especially by untrusted SIP 798 endpoints that are potential recipients of SIP-T traffic. Different 799 solutions to this problem are most likely applicable to different 800 networks. Completely trusted networks obviously need not be concerned 801 with this matter. For networks with many untrusted elements, 802 encapsulated ISUP MIME bodies could be encrypted to alleviate this 803 problem - although this requires the maintenance of a public key 804 infrastructure, it affords significant protection without any 805 additional element costs. Alternatively, encapsulated ISUP could also 806 be deleted by some entity within the originating network (an 807 Application Server, for example) before any SIP messages are 808 transmitted to untrusted elements or networks; however, this requires 809 some foresight into the destination of signaling traffic. It would 810 also help if networks that have untrusted SIP elements homed to them 811 managed the registration of these end-points and enforced trust 812 relationships and policy with users. (See Note 9.) 814 7. Future Work 816 There are many issues associated with SIP-T that need resolution. 817 Some of these have been identified and are presented below. This is 818 in no way an exhaustive list. Additions to this list are anticipated 819 as study progresses in the SIP-T space. 821 7.1 Network inter-connection architecture: 823 The SIP-T mechanism may be used between peer networks. The 824 structure of inter-connection of the peers (use of a NAP 825 architecture, etc.) may affect the manner in which an edge- proxy 826 selects the next-hop network, and consequently, the routing 827 process. 829 7.2 Application architecture: 831 A SIP-T message is a SIP message produced as a result of ISUP 832 encapsulation and translation via a PSTN-originated call. Not only 833 does it enclose ISUP within its body, but it also has some of its 834 header fields populated with information that has been translated 835 from the ISUP message. When a call invokes a number translating 836 application in an AS (Application Server) the application would 837 normally only modify the fields in the SIP-T header to reflect a 838 change in the call-destination. This could result in a SIP-T 839 message in which the information in the header does not agree with 840 the encapsulated ISUP and this is a violation. A possible solution 841 is to have the application alter the encapsulated ISUP (or even 842 delete it in case of termination to a SIP-phone) in addition to 843 amending the SIP-T header. 845 8. List of notes: 847 1. A call that originates in the IP domain (IP origination) and 848 terminates in the PSTN (PSTN termination) needs special consideration 849 and is explored in detail in a subsequent section of this document. 851 2. The IP network depicted here is representative of an inter- 852 connected mesh of SIP-enabled networks. Call hand-off procedures 853 between any two networks that are inter-connected are subject to the 854 terms and conditions of the contractual agreements between them. 856 3. This document only details the functions of the different entities 857 in the SIP-T signaling path. The specifics of the translation from 858 ISUP to SIP and vice versa are to be addressed in the forthcoming 859 ISUP parameter-SIP header mapping and other associated documents. See 860 the SIP-T Components section for details. 862 4. Some terminating MGCs may alter the encapsulated ISUP (or might 863 even delete it if necessary (see Note 7 below)) in order to remove 864 any conditions specific to the originating circuit; for example, 865 continuity test flags in the Nature of Connection Indicators, etc. 867 5. Routable elements are to be addressed in depth in the forth- 868 coming ISUP parameter-SIP header draft. 870 6. It is not the intention of this document to lay down rules for 871 inter-network call hand-off. This document attempts only to assess 872 the relative merits and demerits of a routing policy based on each 873 choice. 875 7. Even so, the relevance of ANSI-specific information in an ETSI 876 network (or vice versa) is questionable. Clearly, the strength of 877 SIP-T is realized when the encapsulated ISUP involves the usage of 878 proprietary parameters. 880 8. An Application Server (AS) is an entity that hosts applications 881 that offer calls enhanced services. An AS receives SIP signaling from 882 the network and invokes applications that produce certain 883 application-layer responses to the signaling, before transferring the 884 call back to the network. 886 9. These and other security-related issues will be explored in a 887 draft (forthcoming) dealing with security in networks that employ 888 SIP-T. 890 9. Revision history 892 9.1 Changes from the 00 version: 1. Addition of a section on SIP 893 content negotiation. 2. Several editorial changes. 895 9.2 Changes from the 01 version: 1. Changes in the security section 896 (encryption, presentation restriction, etc.). 2. Several editorial 897 changes. 899 10. References: 901 [1] Handley, et al, 'SIP: Session Initiation Protocol', RFC 2543, 902 Internet Engineering Task Force, March 1999. 904 [2] Zimmerer, et al, "MIME Media Types for ISUP and QSIG Objects', 905 draft-ietf-sip-isup-mime-07.txt, Internet Engineering Task Force, 906 January 2001. 908 11. Acknowledgements: 910 We thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan 911 Rosenberg and Dean Willis for their valuable comments. 913 12. Authors' addresses 915 Aparna Vemuri 916 Jon Peterson 917 1025 Eldorado Blvd, 918 Broomfield, 919 CO 80021. 920 Aparna.Vemuri@level3.com 921 Jon.Peterson@level3.com 923 Full Copyright Statement 925 Copyright (c) The Internet Society (2000). All Rights Reserved. 927 This document and translations of it may be copied and furnished to 928 others, and derivative works that comment on or otherwise explain it 929 or assist in its implementation may be prepared, copied, published 930 and distributed, in whole or in part, without restriction of any 931 kind, provided that the above copyright notice and this paragraph are 932 included on all such copies and derivative works. However, this 933 document itself may not be modified in any way, such as by removing 934 the copyright notice or references to the Internet Society or other 935 Internet organizations, except as needed for the purpose of 936 developing Internet standards in which case the procedures for 937 copyrights defined in the Internet Standards process must be 938 followed, or as required to translate it into languages other than 939 English. 941 The limited permissions granted above are perpetual and will not be 942 revoked by the Internet Society or its successors or assigns. 944 This document and the information contained herein is provided on an 945 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 946 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 947 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 948 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 949 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.