idnits 2.17.1 draft-ietf-iptel-trunk-group-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 798. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 822. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (January 17, 2007) is 6281 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (ref. '2') (Obsoleted by RFC 5234) == Outdated reference: A later version (-09) exists of draft-ietf-iptel-tgrep-08 == Outdated reference: A later version (-06) exists of draft-ietf-iptel-tel-reg-04 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL WG V. Gurbani 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Standards Track C. Jennings 5 Expires: July 21, 2007 Cisco Systems 6 January 17, 2007 8 Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs) 9 draft-ietf-iptel-trunk-group-10.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 21, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2007). 40 Abstract 42 This document describes a standardized mechanism to convey trunk 43 group parameters in sip and tel Uniform Resource Identifiers (URIs). 44 An extension to the tel URI is defined for this purpose. 46 Table of Contents 48 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Requirements and rationale . . . . . . . . . . . . . . . . . . 5 52 4.1. sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 5 53 4.2. Trunk group namespace: global or local? . . . . . . . . . 5 54 4.3. Originating trunk group and terminating trunk group . . . 6 55 4.4. Intermediary processing of trunk groups . . . . . . . . . 6 56 5. Trunk group identifier: ABNF and examples . . . . . . . . . . 6 57 6. Normative behavior of SIP entities using trunk groups . . . . 8 58 6.1. User Agent Client behavior . . . . . . . . . . . . . . . . 9 59 6.2. User Agent Server behavior . . . . . . . . . . . . . . . . 10 60 6.3. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 10 61 7. Example call flows . . . . . . . . . . . . . . . . . . . . . . 11 62 7.1. Reference architecture . . . . . . . . . . . . . . . . . . 11 63 7.2. Basic Call Flow . . . . . . . . . . . . . . . . . . . . . 12 64 7.3. Inter-domain Call Flow . . . . . . . . . . . . . . . . . . 14 65 8. Security considerations . . . . . . . . . . . . . . . . . . . 15 66 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 72 Intellectual Property and Copyright Statements . . . . . . . . . . 19 74 1. Conventions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC-2119 [1]. 80 2. Definitions 82 Call routing in the Public Switched Telephone Network (PSTN) is 83 accomplished by routing calls over specific circuits (commonly 84 referred to as "trunks") between Time Division Multiplexed (TDM) 85 circuit switches. In switches, a group of trunks that connect to the 86 same target switch or network is called a "trunk group." 87 Consequently, trunk groups have labels, which are used as the main 88 indication for the previous and next TDM switch participating in 89 routing the call. 91 Formally, we define a trunk and trunk group and related terminology 92 as follows (definition of "trunk" and "trunk group" is from [5]). 94 Trunk: In a network, a communication path connecting two 95 switching systems used in the establishment of an end-to-end 96 connection. In selected applications, it may have both its 97 terminations in the same switching system. 99 Trunk Group: A set of trunks, traffic engineered as a unit, for 100 the establishment of connections within or between switching 101 systems in which all of the paths are interchangeable. A single 102 trunk group can be shared across multiple switches for redundancy 103 purposes. 105 Digital Signal 0 (DS0): Digital Signal X is a term for a series 106 of standard digital transmission rates based on DS0, a 107 transmission rate of 64kbps (the bandwidth normally used for one 108 telephone voice channel). The European E-carrier system of 109 transmission also operates using the DS series as a base multiple. 111 Since the introduction of ubiquitous digital trunking, which resulted 112 in the allocation of DS0s between end offices in minimum groups of 24 113 (in North America), it has become common to refer to bundles of DS0s 114 as a trunk. Strictly speaking, however, a trunk is a single DS0 115 between two PSTN end offices - however, for the purposes of this 116 document, the PSTN interface of a gateway acts effectively as an end 117 office (i.e. if the gateway interfaces with Signaling System 7 (SS7), 118 it has its own SS7 point code, and so on). A trunk group, then, is a 119 bundle of DS0s (that need not be numerically contiguous in an SS7 120 Trunk Circuit Identification Code numbering scheme) which are grouped 121 under a common administrative policy for routing. 123 A Session Initiation Protocol (SIP) [3] to PSTN gateway may have 124 trunks that are connected to different carriers. It is entirely 125 reasonable for a SIP proxy to choose -- based on factors not 126 enumerated in this document -- which carrier a call is sent to when 127 it proxies a session setup request to the gateway. Since multiple 128 carriers can transport a call to a particular phone number, the phone 129 number itself is not sufficient to identify the carrier at the 130 gateway. An additional piece of information in the form of a trunk 131 group can be used to further pare down the choices at the gateway. 132 As used in this document, trunks are necessarily tied to gateways, 133 and a proxy that uses trunk groups during routing the request to a 134 particular gateway knows and controls which gateway the call is going 135 to be routed to, and knows what trunking resources are present on 136 that gateway. 138 As another example, consider the case where an IP network is being 139 used as a transit network between two PSTN networks. Here, a SIP 140 proxy can apply the originating trunk group to its routing logic to 141 ensure that the same ingress and egress carrier is chosen. 143 How the proxy picked a particular trunk group is outside the scope of 144 this document ([6] provides one such way); however, once trunk group 145 has been decided upon, this document provides a standardized means to 146 represent it in the signaling messages. 148 3. Problem statement 150 Currently, there isn't any standardized manner of transporting trunk 151 groups between Internet signaling entities. This leads to ambiguity 152 on at least two fronts: 154 1. Positional ambiguity: A SIP proxy that wants to send a call to 155 an egress Voice over IP (VoIP) gateway may insert the trunk group 156 as a parameter in the user portion of the Request-URI (R-URI), or 157 it may insert it as a parameter to the R-URI itself. This 158 ambiguity persists in the reverse direction as well, that is, 159 when an ingress VoIP gateway wants to send a incoming call 160 notification to its default outbound proxy. 161 2. Semantic ambiguity: The lack of any standardized grammar to 162 represent trunk groups leads to the unfortunate choice of ad hoc 163 names and values. 165 VoIP routing entities in the Internet, such as SIP proxies, may be 166 interested in using trunk groups for normal operations. To that 167 extent, any standards-driven requirements will enable proxies from 168 one vendor to interoperate with gateways from yet another vendor. 169 Absent such guidelines, interoperability will suffer as a proxy 170 vendor must conform to the expectations of a gateway as to where it 171 expects trunk group parameters to be present (and vice versa). 173 The aim of this specification is to outline how to structure and 174 represent the trunk group parameters as an extension to the tel URI 175 [4] in a standardized manner. 177 4. Requirements and rationale 179 This section captures the motivations for the design decisions for 180 the specification of a trunk group. These motivations are captured 181 as a set of requirements that are used to guide the eventual trunk 182 group specification contained in this document. 184 4.1. sip URI or tel URI? 186 REQ 1: Trunk group parameters must be defined as an extension to the 187 tel URI [4]. 189 The trunk group parameters can be carried in either the sip URI or 190 the tel URI. Since trunk groups are intimately associated with the 191 PSTN, it seems reasonable to define them as extensions to the tel URI 192 (any SIP request that goes to a gateway could reasonably be expected 193 to have a tel URI, in whole or in part, in its R-URI anyway). 194 Furthermore, using the tel URI also allows this format to be reused 195 by non-SIP VoIP protocols (which could include anything from MGCP or 196 Megaco to H.323, if the proper information elements are created). 198 Finally, once the trunk group is defined for a tel URI, the normative 199 procedures of Section 19.1.6 of [3] can be used to derive an 200 equivalent sip URI from a tel URI, complete with the trunk group 201 parameters. 203 4.2. Trunk group namespace: global or local? 205 REQ 2: Inter-domain trunk group name collisions must be prevented. 207 Under normal operations, trunk groups are pertinent only within an 208 administrative domain (i.e. local scope). However, given that 209 inadvertent cross-domain trunk group name collisions may occur, it is 210 desirable to prevent these. The judicious use of namespaces is a 211 solution to this problem. Thus, it seems appropriate to scope the 212 trunk group through a namespace. 214 At first glance, it would appear that the use of the tel URI's 215 "phone-context" parameter provides a satisfactory means of 216 imposing a namespace on a trunk group. The "phone-context" 217 parameter identifies the scope of validity of a local telephone 218 number. And therein lies the problem. Semantically, a "phone- 219 context" tel URI parameter is applicable only to a local telephone 220 number and not a global one (i.e., one preceded by a '+'). Trunk 221 groups, on the other hand, may appear in local or global telephone 222 numbers. Thus, what is needed is a new parameter with equivalent 223 functionality of the "phone-context" parameter of the tel URI, but 224 one that is equally applicable to local and global telephone 225 numbers. 227 4.3. Originating trunk group and terminating trunk group 229 REQ 3: Originating trunk group and destination trunk group must be 230 able to appear separately and concurrently in a SIP message. 232 SIP routing entities can make informed routing decisions based on 233 either the originating or the terminating trunk groups. Thus a 234 requirement that both of these trunk groups need to be carried in SIP 235 requests. 237 4.4. Intermediary processing of trunk groups 239 REQ 4: SIP network intermediaries (proxy servers and redirect 240 servers) should be able to add the destination trunk group attribute 241 to SIP sessions as a route is selected for a call. 243 5. Trunk group identifier: ABNF and examples 245 The Augmented Backus Naur Form [2] syntax for a trunk group 246 identifier is given below and extends the "par" production rule of 247 the tel URI defined in [4]: 249 par = parameter / extension / isdn-subaddress / trunk-group / 250 trunk-context 252 trunk-group = ";tgrp=" trunk-group-label 253 trunk-context = ";trunk-context=" descriptor 255 trunk-group-label = 1*( unreserved / escaped / 256 trunk-group-unreserved ) 257 trunk-group-unreserved = "/" / "&" / "+" / "$" 258 descriptor is defined in [4]. 259 unreserved is defined in [3] and [4]. 260 escaped is defined in [3]. 262 par = parameter / extension / isdn-subaddress / trunk-group / 263 trunk-context 265 trunk-group = ";tgrp=" trunk-group-label 266 trunk-context = ";trunk-context=" descriptor 268 trunk-group-label = 1*( unreserved / escaped / 269 trunk-group-unreserved ) 270 trunk-group-unreserved = "/" / "&" / "+" / "$" 272 Trunk groups are identified by two parameters: "tgrp" and "trunk- 273 context"; both of these parameters MUST be present in a tel URI to 274 identify a trunk group. Collectively, these two parameters are 275 called "trunk group parameters" in this specification. 277 All implementations conforming to this specification MUST generate 278 both of these parameters when using trunk groups. If an 279 implementation receives a tel URI with only one of the "tgrp" or 280 "trunk-context" parameter, it MUST act as if there were not any trunk 281 group parameters present at all in that URI. Whether or not to 282 further process such an URI is up to the discretion of the 283 implementation, however, if a decision is made to process it, the 284 implementation MUST act as if there were not any trunk group 285 parameters present in the URI. 287 The "trunk-context" parameter imposes a namespace on the trunk group 288 by specifying a global number or any number of its leading digits 289 (e.g., +33), or a domain name. Syntactically, it is modeled after 290 the "phone-context" parameter of the tel URI [4], except that unlike 291 the "phone-context" parameter, the "trunk-context" parameter can 292 appear in either a local or global tel URI. 294 Semantically, the "trunk-context" parameter establishes a scope of 295 the trunk group specified in the "tgrp" parameter, i.e., whether it 296 is valid at a single gateway, a set of gateways, or an entire domain 297 managed by a service provider. The "trunk-context" can contain four 298 discrete value types: 300 1. The value in the "trunk-context" literally identifies a host (a 301 gateway), in which case the trunk groups are scoped to the 302 specific host. 303 2. The value in the "trunk-context" is a subdomain (e.g., 304 "north.example.com"), which identifies a subset of the gateways 305 in a domain across which the trunk groups are shared. 307 3. The value in the "trunk-context" is a service provider domain 308 (e.g., "example.com"), which identifies all gateways in the 309 specific domain. 310 4. The value in the "trunk-context" is a global number or any number 311 of its leading digits; this is useful for provider-wide scoping 312 and does not lend itself very well to specifying trunk groups 313 across a gateway or a set of gateways. 315 For equivalency purposes, two URIs containing trunk group parameters 316 are equivalent according to the base comparison rules of the URIs. 317 The base comparison rules of a tel URI are specified in Section 4 of 318 [4], and the base comparison rules of a sip URI are specified in 319 Section 19.1.4 of [3]. 321 Examples: 323 1. Trunk group in a local number, with a phone-context parameter 324 (the line breaks added for readability): 326 tel:5550100;phone-context=+1-630;tgrp=TG-1; 327 trunk-context=example.com 329 Transforming this tel URI to a sip URI yields: 330 sip:5550100;phone-context=+1-630;tgrp=TG-1; 331 trunk-context=example.com@isp.example.net;user=phone 333 2. Trunk group in a global number, with a domain name trunk-context: 335 tel:+16305550100;tgrp=TG-1;trunk-context=example.com 337 Transforming this tel URI to a sip URI yields: 338 sip:+16305550100;tgrp=TG-1; 339 trunk-context=example.com@isp.example.net;user=phone 341 3. Trunk group in a global number, with a number prefix trunk- 342 context: 344 tel:+16305550100;tgrp=TG-1;trunk-context=+1-630 346 Transforming this tel URI to a sip URI yields: 347 sip:+16305550100;tgrp=TG-1; 348 trunk-context=+1-630@isp.example.net;user=phone 350 6. Normative behavior of SIP entities using trunk groups 352 The terminating (or egress) trunk group parameters MUST be specified 353 in the R-URI. This is an indication from a SIP entity to the next 354 downstream entity that a specific terminating (or egress) trunk group 355 should be used. 357 This is consistent with using the R-URI as a routing element; SIP 358 routing entities may use the trunk group parameter in the R-URI to 359 make intelligent routing decisions. Furthermore, this also 360 satisfies REQ 4, since a SIP network intermediary can modify the 361 R-URI to include the trunk group parameters. 363 Conversely, the appearance of the trunk group parameters in the 364 Contact header URI signifies the trunk group over which the call 365 arrived on, i.e., the originating (or ingress) trunk group. Thus, 366 the originating (or ingress) trunk group MUST appear in the Contact 367 header of a SIP request. 369 The behavior described in this section effectively addresses REQ 3. 371 6.1. User Agent Client behavior 373 A User Agent Client (UAC) initiating a call that uses trunk groups 374 and supports this specification MUST include the trunk group 375 parameters in the Contact header URI (a Contact URI MUST be a sip or 376 sips URI, thus, what appears in the Contact header is a SIP 377 translation of the tel URI, complete with the trunk group 378 parameters). The trunk group parameters in the Contact header 379 represents the originating trunk group. As a consequence of the 380 processing rules for the Contact header defined in RFC 3261 [3], 381 subsequent requests in the dialog towards this user agent will 382 contain this Contact URI in the R-URI. Note that the user part of 383 this URI, which contains the trunk group parameters, will be copied 384 as a consequence of this processing. 386 Arguably, the originating trunk group can be part of the From URI. 387 However, semantically, the URI in a From header is an abstract 388 identifier which represents the resource thus identified on a 389 long-term basis. The presence of a trunk group, on the other 390 hand, signifies a binding that is valid for the duration of the 391 session only; a trunk group has no significance once the session 392 is over. Thus, the Contact URI is the best place to impart this 393 information since it has exactly those semantics. 395 If the UAC is aware of the routing topology, it MAY insert the 396 destination trunk group parameters in the R-URI of the request. 397 However, in most deployments, the UAC will use the services of a 398 proxy to further route the request, and it will be up to the proxy to 399 insert such parameters in the R-URI (see Section 6.3) 401 6.2. User Agent Server behavior 403 To the processing User Agent Server (UAS) associated with a gateway, 404 the trunk group parameters in the R-URI implies that it should use 405 the named trunk group for the outbound call. If a UAS supports trunk 406 groups, but finds that all the trunk circuit identification codes for 407 that particular trunk group are occupied, it MAY send a 603 Decline 408 final response. 410 If a UAS supports trunk groups but is not configured with the 411 particular trunk group identified in the R-URI, it SHOULD NOT use any 412 other trunk group other than the one specified in the parameters. In 413 such a case, it MAY reject the request with a 404 final response; or 414 if it makes a decision to process the request in any case, it MUST 415 disregard the values in the "trunk-context" and the "tgrp" 416 parameters. 418 If the receiver of a SIP request is not authoritatively responsible 419 for the value specified in the "trunk-context", it MUST treat the 420 value in the "tgrp" parameter as if it was not there. Whether or not 421 to process the request further is up to the discretion of the 422 processing entity; the request MAY be rejected with a 404 final 423 response. Alternatively, if a decision is made to process the 424 request further, the processing entity MUST disregard the values in 425 the "trunk-context" and the "tgrp" parameters since it is not 426 authoritatively responsible for the value specified in "trunk- 427 context". 429 6.3. Proxy behavior 431 A proxy server receiving a request that contains the trunk group 432 parameter in the Contact header SHOULD NOT change these parameters as 433 the request traverses through it. Doing so may have adverse 434 consequences, since the UAC that populated the parameters did so on 435 some authoritative knowledge that the proxy may not be privy to. 436 Instead, the proxy SHOULD pass the trunk group parameters in the 437 Contact header unchanged to the client transaction that the proxy 438 creates to send the request downstream. 440 A proxy that is aware of the routing topology and supports this 441 specification, MAY insert destination trunk group parameters in the 442 R-URI if none are present (see Section 7.1 and Section 7.2 for an 443 example). However, if destination trunk group parameters are already 444 present in the R-URI, the proxy SHOULD NOT change them unless it has 445 further authoritative information about the routing topology than the 446 upstream client did when it originally inserted the trunk group 447 parameters in the R-URI. 449 Depending on the specific situation, it is perfectly reasonable 450 for a proxy not to insert the destination trunk group parameters 451 in the R-URI. Consider, for instance, a proxy that understands 452 the originating trunk group parameters and, in accordance with 453 local policy, uses these to route the request to an alternative 454 destination than a PSTN gateway. 456 7. Example call flows 458 7.1. Reference architecture 460 Consider Figure 1, which depicts a SIP proxy in a routing 461 relationship with three gateways in its domain, GW1, GW2, and GW3. 462 Requests arrive at the SIP proxy through GW1. Gateways GW2 and GW3 463 are used as egress gateways from the domain. GW2 has two trunk 464 groups configured, TG2-1 and TG2-2. GW3 also has two trunk groups 465 configured, TG3-1 and TG2-2 (TG2-2 is shared between gateways GW2 and 466 GW3). 468 +-----+ TG2-1 469 | |--------> To 470 TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN 471 From ----->| | | SIP | | | |--------> 472 PSTN | GW1 |--->| Proxy |-----+ +-----+ 473 ----->| | +-------+ | +-----+ TG3-1 474 +-----+ | | |--------> To 475 +---->| GW3 | TG2-2 PSTN 476 | |--------> 477 +-----+ 478 Figure 1: Reference architecture 480 GW1 in Figure 1 is always cognizant of any requests that arrive over 481 trunk group TG1-1. If it wishes to propagate the ingress trunk group 482 to the proxy, it must arrange for the trunk group to appear in the 483 Contact header of the SIP request destined to the proxy. The proxy 484 will, in turn, propagate the ingress trunk group in the Contact 485 header further downstream. 487 The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is 488 assumed that the proxy has access to a routing table for GW2 and GW3 489 which includes the appropriate trunk groups to use when sending a 490 call to the PSTN (exactly how this table is constructed is out of 491 scope for this specification; [6] is one way to do so, a manually 492 created and maintained routing table is another). When the proxy 493 sends a request to either of the egress gateways, and the gateway 494 routing table is so configured that a trunk group is required by the 495 gateway, the proxy must arrange for the trunk group to appear in the 496 SIP R-URI of the request destined to that gateway. 498 7.2. Basic Call Flow 500 This example uses the reference architecture of Figure 1. Gateways 501 GW1, GW2, GW3 and the SIP proxy are assumed to be owned by a service 502 provider whose domain is example.com. 504 GW1 SIP Proxy GW2 505 From | | | 506 PSTN-->| | | 507 +---F1--------->| | 508 | +---F2----------->| 509 ... ... ... 510 | | | Send to PSTN 511 | | | --> and receive Answer 512 | | | Complete Message 513 ----------------------------------------- 514 Call in progress 515 ----------------------------------------- 516 | | | 517 | |<-----------F3---+ 518 +<--------------+ | 519 ... ... ... 521 In the call flow below, certain headers and messages have been 522 omitted for brevity. In F1, GW1 receives a call setup request from 523 the PSTN over a certain trunk group. GW1 arranges for this trunk 524 group to appear in in the Contact header of the request destined to 525 the SIP proxy. 527 F1: 528 INVITE sip:+16305550100@example.com;user=phone SIP/2.0 529 ... 530 Contact: 532 ... 534 In F2, the SIP proxy translates the R-URI and adds a destination 535 trunk group to the R-URI. The request is then sent to GW2. 537 F2: 538 INVITE sip:+16305550100;tgrp=TG2-1; 539 trunk-context=example.com@gw2.example.com;user=phone SIP/2.0 540 ... 541 Record-Route: 542 Contact: 544 ... 546 Once the call is established, either end can tear the call down. For 547 illustrative purposes, F3 depicts GW2 tearing the call down. Note 548 that the Contact from F1, including the trunk group parameters, is 549 now the R-URI of the request. When GW1 gets this request, it can 550 associate the call with the appropriate trunk group to deallocate 551 resources. 553 F3: 554 BYE sip:0100;phone-context=example.com;tgrp=TG1-1; 555 trunk-context=example.com@gw1.example.com;user=phone SIP/2.0 556 Route: 557 ... 559 It is worth documenting the behavior when an incoming call from the 560 PSTN is received at a gateway without a calling party number. 561 Consider Figure 1, and assume that GW1 gets a call request from the 562 PSTN without a calling party number. This is not an uncommon case, 563 and may happen for a variety of reasons, including privacy and 564 interworking between different signaling protocols before the request 565 reached GW1. Under normal circumstances (i.e., instances where the 566 calling party number is present in signaling), GW1 would derive a sip 567 URI to insert into the Contact header. This sip URI will contain, as 568 its user portion, the calling party number from from the incoming SS7 569 signaling information. The trunk group parameters then becomes part 570 of the user portion as discussed previously. 572 If a gateway receives an incoming call where the calling party number 573 is not available, it MUST create a tel URI containing a token that is 574 generated locally and has local significance to the gateway. Details 575 of generating such a token are implementation dependent; potential 576 candidates include the gateway line number or port number where the 577 call was accepted. This tel URI is subsequently converted to a sip 578 URI to be inserted in the Contact header of the SIP request going 579 downstream from the gateway. 581 The tel scheme does not allow for an empty URI; thus the global- 582 number or local-number production rule of the tel URI [4] cannot 583 contain an empty string. Consequently, the behavior in the above 584 paragraph is mandated for cases where the incoming SS7 signaling 585 message does not contain a calling party number. 587 7.3. Inter-domain Call Flow 589 This example demonstrates the advantage of namespaces in trunk 590 groups. In the example flow below, GW1 and SIP Proxy 1 belong to the 591 example.com domain and SIP Proxy 2 belongs to another domain, 592 example.net. A call arrives at GW1 (F1) and is routed to the 593 example.net domain. In the call flow below, certain headers and 594 messages have been omitted for brevity. 596 example.com example.net 597 /-------------------------\ /-----------\ 598 GW1 SIP Proxy 1 SIP Proxy 2 599 From | | | 600 PSTN-->| | | 601 +---F1--------->| | 602 | +---F2----------->| 603 | | | 604 ... ... ... 605 | +<--F3------------+ 606 ... ... ... 608 F1: 609 INVITE sip:+16305550100@example.com;user=phone SIP/2.0 610 ... 611 Contact: 613 ... 615 In F2, the SIP proxy executes its routing logic and re-targets the 616 R-URI to refer to a resource in example.net domain. 618 F2: 619 INVITE sip:+16305550100@example.net;user=phone SIP/2.0 620 ... 621 Record-Route: 622 Contact: 624 ... 626 In F3, the example.net domain sends a request in the backwards 627 direction. The example.net domain does not interpret the trunk group 628 parameters in the Contact header since they do not belong to that 629 domain. The Contact header, including the trunk group parameters, is 630 simply used as the R-URI in a subsequent request going towards the 631 example.com domain. 633 F3: 634 BYE sip:0100;phone-context=example.com;tgrp=TG1-1; 635 trunk-context=example.com@gw1.example.com;user=phone 636 Route: 637 ... 639 8. Security considerations 641 The trunk group parameters are carried in R-URIs and Contact headers; 642 it is simply a modifier of an address, and any existing trust 643 relationship between the originator of a request and an intermediary 644 (or final recipient) that processes the request is not affected by 645 such a modifier. 647 Maliciously modifying a trunk group of a R-URI in transit may cause 648 the receiving entity, say a gateway, to prefer one trunk over 649 another; thus leading to attacks that use resources not privy to the 650 call. For example, an attacker who knows the name of a toll-free 651 trunk on a gateway may modify the trunk group in the R-URI to 652 effectively receive free service, or he may modify the trunk group in 653 a R-URI to affect the flow of traffic across trunks. Similarly, 654 modifying the trunk group in a Contact header may cause the routing 655 intermediary to erroneously associate a call with a different source 656 than it would normally be associated with. 658 Although this specification imparts more information to the R-URI and 659 the Contact header in the form of trunk groups, the class of attacks 660 and possible protection mechanism are the same as that specified for 661 baseline SIP systems [3]. The Security Session Initiation Protocol 662 Secure (SIPS) scheme and the resulting Transport Layer Security (TLS) 663 mechanism SHOULD be used to provide integrity protection, thereby 664 mitigating these attacks. 666 A question naturally arises on how does the receiver determine 667 whether the sender is authorized to use the resources represented by 668 the trunk group parameters? There are two cases to consider: intra- 669 domain signaling exchange as discussed in Section 7.2, and inter- 670 domain signaling exchange as discussed in Section 7.3. 672 In the intra-domain case, a proxy reciving trunk group parameters 673 from an upstream user agent (typically a gateway) should only accept 674 them using the SIPS URI scheme, and furthermore, it should use HTTP 675 Digest to challenge and properly authorize the sender. A user agent 676 (or a gateway) receiving the trunk group parameters from a proxy will 677 not be able to challenge the proxy using HTTP Digest, but it should 678 examine the X.509 certificate of the proxy to determine whether the 679 proxy is authorized to insert the resources represented by the trunk 680 group parameters into the signaling flow. 682 In the inter-domain case, a receiving proxy may depend on the 683 identity stored in the X.509 certificate of the sending proxy to make 684 a determination whether the sender is authorized to insert the 685 resources represented by the trunk group parameters in the signaling 686 message. 688 Because of these considerations, the trunk group parameters are only 689 applicable within a set of network nodes among which there is mutual 690 trust. If a node receives a call signaling request from an upstream 691 node that it does not trust, it SHOULD remove the trunk group 692 parameters. 694 The privacy information revealed with a trunk group does not 695 generally advertise much information about a particular (human) user. 696 It does, however, convey two pieces of potentially private 697 information which may be considered sensitive by carriers. First, it 698 may reveal how a carrier may be performing least-cost routing and 699 peering; and secondly, it does introduce an additional means for 700 network topology and information of a carrier. It is up to the 701 discretionary judgment of the carrier if it wants to include the 702 trunk group parameters and reveal potentially sensitive information 703 on its network topology. If confidentiality is desired, TLS SHOULD 704 be used to protect this information while in transit. 706 9. IANA considerations 708 This specification does not require any IANA considerations. 710 The tel URI parameters introduced in this document are registered 711 with IANA through the tel URI parameter registry document [7]. 713 10. Acknowledgments 715 The authors would like to acknowledge the efforts of the participants 716 of the SIPPING and IPTEL working group, especially Jeroen van Bemmel, 717 Bryan Byerly, John Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon 718 Peterson, Mike Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, 719 Dave Oran, Takuya Sawada, Tom Taylor, and Al Varney. 721 Jon Peterson was also instrumental in the original formulation of 722 this work. 724 Alex Mayrhofer brought up the issue of lexicographic ordering of tel 725 URI parameters when it is converted to a sip or sips URI. 727 Ted Hardie, Sam Hartman, and Russ Housley took pains to ensure that 728 the text around URI comparisons and security considerations was as 729 unambiguous as possible. 731 11. References 733 11.1. Normative References 735 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 736 Levels", BCP 14, RFC 2119, March 1997. 738 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 739 Specifications: ABNF", RFC 4234, October 2005. 741 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 742 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 743 Session Initiation Protocol", RFC 3261, June 2002. 745 [4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966, 746 December 2004. 748 11.2. Informative References 750 [5] "Bellcore Notes on the Network", Telcordia SR2275, Dec 1997, 751 . 753 [6] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H., and D. 754 Shah, "A Telephony Gateway REgistration Protocol (TGREP)", 755 draft-ietf-iptel-tgrep-08.txt (work in progress), January 2007. 757 [7] Jennings, C. and V. Gurbani, "The Internet Assigned Number 758 Authority (IANA) tel Uniform Resource Identifier (URI) Parameter 759 Registry", draft-ietf-iptel-tel-reg-04.txt (work in progress), 760 December 2006. 762 Authors' Addresses 764 Vijay K. Gurbani 765 Bell Laboratories, Alcatel-Lucent 766 2701 Lucent Lane 767 Rm 9F-546 768 Lisle, IL 60532 769 USA 771 Phone: +1 630 224 0216 772 Email: vkg@alcatel-lucent.com 774 Cullen Jennings 775 Cisco Systems 776 170 West Tasman Drive 777 Mailstop SJC-21/3 778 San Jose, CA 95134 779 USA 781 Phone: +1 408 421 9990 782 Email: fluffy@cisco.com 784 Full Copyright Statement 786 Copyright (C) The Internet Society (2007). 788 This document is subject to the rights, licenses and restrictions 789 contained in BCP 78, and except as set forth therein, the authors 790 retain all their rights. 792 This document and the information contained herein are provided on an 793 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 794 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 795 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 796 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 797 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 798 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 800 Intellectual Property 802 The IETF takes no position regarding the validity or scope of any 803 Intellectual Property Rights or other rights that might be claimed to 804 pertain to the implementation or use of the technology described in 805 this document or the extent to which any license under such rights 806 might or might not be available; nor does it represent that it has 807 made any independent effort to identify any such rights. Information 808 on the procedures with respect to rights in RFC documents can be 809 found in BCP 78 and BCP 79. 811 Copies of IPR disclosures made to the IETF Secretariat and any 812 assurances of licenses to be made available, or the result of an 813 attempt made to obtain a general license or permission for the use of 814 such proprietary rights by implementers or users of this 815 specification can be obtained from the IETF on-line IPR repository at 816 http://www.ietf.org/ipr. 818 The IETF invites any interested party to bring to its attention any 819 copyrights, patents or patent applications, or other proprietary 820 rights that may cover technology that may be required to implement 821 this standard. Please address the information to the IETF at 822 ietf-ipr@ietf.org. 824 Acknowledgment 826 Funding for the RFC Editor function is provided by the IETF 827 Administrative Support Activity (IASA).