idnits 2.17.1 draft-ietf-iptel-trunk-group-07.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (February 20, 2006) is 6630 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-06 == Outdated reference: A later version (-06) exists of draft-ietf-iptel-tel-reg-01 Summary: 4 errors (**), 0 flaws (~~), 4 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 Lucent Technologies, Inc./Bell 4 Expires: August 24, 2006 Laboratories 5 C. Jennings 6 Cisco Systems 7 February 20, 2006 9 Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs) 10 draft-ietf-iptel-trunk-group-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 24, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes a standardized mechanism to convey trunk 44 group parameters in sip and tel Uniform Resource Identifiers (URIs). 45 An extension to the tel URI is defined for this purpose. 47 Table of Contents 49 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Problem statement . . . . . . . . . . . . . . . . . . . . . 4 52 4. Requirements and rationale . . . . . . . . . . . . . . . . . 4 53 4.1 sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 5 54 4.2 Trunk group namespace: global or local? . . . . . . . . . 5 55 4.3 Originating trunk group and terminating trunk group . . . 5 56 4.4 Intermediary processing of trunk groups . . . . . . . . . 6 57 5. Trunk group identifier: ABNF and examples . . . . . . . . . 6 58 6. Normative behavior of SIP entities using trunk groups . . . 8 59 6.1 Client behavior . . . . . . . . . . . . . . . . . . . . . 9 60 6.2 Server behavior . . . . . . . . . . . . . . . . . . . . . 9 61 7. Example call flows . . . . . . . . . . . . . . . . . . . . . 10 62 7.1 Reference architecture . . . . . . . . . . . . . . . . . . 10 63 7.2 Basic Call Flow . . . . . . . . . . . . . . . . . . . . . 11 64 7.3 Inter-domain Call Flow . . . . . . . . . . . . . . . . . . 13 65 8. Security considerations . . . . . . . . . . . . . . . . . . 14 66 9. IANA considerations . . . . . . . . . . . . . . . . . . . . 14 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 11.1 Normative References . . . . . . . . . . . . . . . . . . 15 70 11.2 Informative References . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 72 Intellectual Property and Copyright Statements . . . . . . . 17 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. 103 Digital Signal 0 (DS0): Digital Signal X is a term for a series 104 of standard digital transmission rates based on DS0, a 105 transmission rate of 64kbps (the bandwidth normally used for one 106 telephone voice channel). The European E-carrier system of 107 transmission also operates using the DS series as a base multiple. 109 Since the introduction of ubiquitous digital trunking, which resulted 110 in the allocation of DS0s between end offices in minimum groups of 24 111 (in North America), it has become common to refer to bundles of DS0s 112 as a trunk. Strictly speaking, however, a trunk is a single DS0 113 between two PSTN end offices - however, for the purposes of this 114 document, the PSTN interface of a gateway acts effectively as an end 115 office (i.e. if the gateway interfaces with Signaling System 7 (SS7), 116 it has its own SS7 point code, and so on). A trunk group, then, is a 117 bundle of DS0s (that need not be numerically contiguous in an SS7 118 Trunk Circuit Identification Code numbering scheme) which are grouped 119 under a common administrative policy for routing. 121 A Session Initiation Protocol (SIP) [3] to PSTN gateway may have 122 trunks that are connected to different carriers. It is entirely 123 reasonable for a SIP proxy to choose -- based on factors not 124 enumerated in this document -- which carrier a call is sent to when 125 it proxies a session setup request to the gateway. Since multiple 126 carriers can transport a call to a particular phone number, the phone 127 number itself is not sufficient enough to identify the carrier at the 128 gateway. An additional piece of information in the form of a trunk 129 group can be used to further pare down the choices at the gateway. 130 How the proxy picked a particular trunk group is outside the scope of 131 this document ([6] provides one such way); once the trunk group has 132 been decided upon, this document provides a standardized means to 133 represent it. 135 3. Problem statement 137 Currently, there isn't any standardized manner of transporting trunk 138 groups between Internet signaling entities. This leads to ambiguity 139 on at least two fronts: 141 1. Positional ambiguity: A SIP proxy that wants to send a call to 142 an egress Voice over IP (VoIP) gateway may insert the trunk group 143 as a parameter in the user portion of the Request-URI (R-URI), or 144 it may insert it as a parameter to the R-URI itself. This 145 ambiguity persists in the reverse direction as well, that is, 146 when an ingress VoIP gateway wants to send a incoming call 147 notification to its default outbound proxy. 148 2. Semantic ambiguity: The lack of any standardized grammar to 149 represent trunk groups leads to the unfortunate choice of ad hoc 150 names and values. 152 VoIP routing entities in the Internet, such as SIP proxies, may be 153 interested in using trunk groups for normal operations. To that 154 extent, any standards-driven requirements will enable proxies from 155 one vendor to interoperate with gateways from yet another vendor. 156 Absent such guidelines, interoperability will suffer as a proxy 157 vendor must conform to the expectations of a gateway as to where it 158 expects trunk group parameters to be present (and vice versa). 160 The aim of this specification is to outline how to structure and 161 represent the trunk group parameters as an extension to the tel URI 162 [4] in a standardized manner. 164 4. Requirements and rationale 166 This section captures the motivations for the design decisions for 167 the specification of a trunk group. These motivations are captured 168 as a set of requirements that are used to guide the eventual trunk 169 group specification contained in this document. 171 4.1 sip URI or tel URI? 173 REQ 1: Trunk group parameters must be defined as an extension to the 174 tel URI [4]. 176 The trunk group parameters can be carried in either the sip URI or 177 the tel URI. Since trunk groups are intimately associated with the 178 PSTN, it seems reasonable to define them as extensions to the tel URI 179 (any SIP request that goes to a gateway could reasonably be expected 180 to have a tel URI, in whole or in part, in its R-URI anyway). 181 Furthermore, using the tel URI also allows this format to be reused 182 by non-SIP VoIP protocols (which could include anything from MGCP or 183 Megaco to H.323, if the proper information elements are created). 185 Finally, once the trunk group is defined for a tel URI, the normative 186 procedures of Section 19.1.6 of [3] can be used to derive an 187 equivalent sip URI from a tel URI, complete with the trunk group 188 parameters. 190 4.2 Trunk group namespace: global or local? 192 REQ 2: Inter-domain trunk group name collisions must be prevented. 194 Under normal operations, trunk groups are pertinent only within an 195 administrative domain (i.e. local scope). However, given that 196 inadvertent cross-domain trunk group name collisions may occur, it is 197 desirable to prevent these. The judicious use of namespaces is a 198 solution to this problem. Thus, it seems appropriate to scope the 199 trunk group through a namespace. 201 At first glance, it would appear that the use of the tel URI's 202 "phone-context" parameter provides a satisfactory means of 203 imposing a namespace on a trunk group. The "phone-context" 204 parameter identifies the scope of validity of a local telephone 205 number. And therein lies the problem. Semantically, a "phone- 206 context" tel URI parameter is applicable only to a local telephone 207 number and not a global one (i.e., one preceded by a '+'). Trunk 208 groups, on the other hand, may appear in local or global telephone 209 numbers. Thus, what is needed is a new parameter with equivalent 210 functionality of the "phone-context" parameter of the tel URI, but 211 one that is equally applicable to local and global telephone 212 numbers. 214 4.3 Originating trunk group and terminating trunk group 216 REQ 3: Originating trunk group and destination trunk group must be 217 able to appear separately and concurrently in a SIP message. 219 SIP routing entities can make informed routing decisions based on 220 either the originating or the terminating trunk groups. Thus a 221 requirement that both of these trunk groups need to be carried in SIP 222 requests. 224 4.4 Intermediary processing of trunk groups 226 REQ 4: SIP network intermediaries (proxy server and redirect 227 servers) should be able to add the destination trunk group attribute 228 to SIP sessions as a route is selected for a call. 230 5. Trunk group identifier: ABNF and examples 232 The Augmented Backus Naur Form [2] syntax for a trunk group 233 identifier is given below and extends the "par" production rule of 234 the tel URI defined in [4]: 236 par = parameter / extension / isdn-subaddress / trunk-group / 237 trunk-context 239 trunk-group = ";tgrp=" trunk-group-label 240 trunk-context = ";trunk-context=" descriptor 242 trunk-group-label = 1*( unreserved / escaped / 243 trunk-group-unreserved ) 244 trunk-group-unreserved = "/" / "&" / "+" / "$" 246 descriptor is defined in [4]. 247 unreserved is defined in [3] and [4]. 248 escaped is defined in [3]. 250 Trunk groups are identified by two parameters: "tgrp" and "trunk- 251 context"; both of these parameters MUST be present in a tel URI to 252 identify a trunk group. Collectively, these two parameters are 253 called "trunk group parameters" in this specification. 255 All implementations conforming to this specification MUST generate 256 both of these parameters when using trunk groups. If an 257 implementation receives a tel URI with only one of the "tgrp" or 258 "trunk-context" parameter, it MUST act as if there were not any trunk 259 group parameters present at all in that URI. Whether or not to 260 further process such an URI is up to the discretion of the 261 implementation, however, if a decision is made to process it, the 262 implementation MUST act as if there were not any trunk group 263 parameters present in the URI. 265 The "trunk-context" and "tgrp" parameter SHOULD use lower-case 266 characters as tel URIs may be used within contexts where comparisons 267 are case sensitive. 269 The "trunk-context" parameter imposes a namespace on the trunk group 270 by specifying a global number or any number of its leading digits 271 (e.g., +33), or a domain name. Syntactically, it is modeled after 272 the "phone-context" parameter of the tel URI [4], except that unlike 273 the "phone-context" parameter, the "trunk-context" parameter can 274 appear in either a local or global tel URI. 276 Semantically, the "trunk-context" parameter establishes a scope of 277 the trunk group specified in the "tgrp" parameter, i.e., whether it 278 is valid at a single gateway, a set of gateways, or an entire domain 279 managed by a service provider. The "trunk-context" can contain four 280 discrete value types: 282 1. The value in the "trunk-context" literally identifies a host (a 283 gateway), in which case the trunk groups are scoped to the 284 specific host. 285 2. The value in the "trunk-context" is a subdomain (e.g., 286 "north.example.com"), which identifies a subset of the gateways 287 in a domain across which the trunk groups are shared. 288 3. The value in the "trunk-context" is a service provider domain 289 (e.g., "example.com"), which identifies all gateways in the 290 specific domain. 291 4. The value in the "trunk-context" is a global number or any number 292 of its leading digits; this is useful for provider-wide scoping 293 and does not lend itself very well to specifying trunk groups 294 across a gateway or a set of gateways. 296 If the receiver of a SIP request is not authoritatively responsible 297 for the value specified in the "trunk-context", it MUST treat the 298 value in the "tgrp" parameter as if it was not there. Whether or not 299 to process the request further is up to the discretion of the 300 processing entity; the request MAY be rejected with a 404 final 301 response. Alternatively, if a decision is made to process the 302 request further, the processing entity MUST disregard the values in 303 the "trunk-context" and the "tgrp" parameters since it is not 304 authoritatively responsible for the value specified in "trunk- 305 context". 307 For equivalency purposes, two URIs containing trunk group parameters 308 are equivalent according to the base comparison rules of the URIs AND 309 the values of their "tgrp" and "trunk-context" parameters MUST match. 310 The base comparison rules of a tel URI are specified in Section 4 of 311 [4], and the base comparison rules of a sip URI are specified in 312 Section 19.1.4 of [3]. 314 Note that the base comparison rules for a sip or sips URI that has 315 been derived from a tel URI mandate that the telephone-subscriber 316 parameters be ordered lexically by parameter name (see Section 317 19.1.6 of [3]). Thus, when comparing a sip URI that has been 318 derived from a tel URI, implementations MUST NOT assume that the 319 "tgrp" and "trunk-context" parameters will appear in a consecutive 320 manner because parameters defined by other tel URI extensions may 321 lexically fit between "tgrp" and "trunk-context". 323 Examples: 325 1. Trunk group in a local number, with a phone-context parameter 326 (mind the line breaks added for readability): 328 tel:5551212;phone-context=+1-630;tgrp=TG-1; 329 trunk-context=example.com 331 Transforming this tel URI to a sip URI yields: 332 sip:5551212;phone-context=+1-630;tgrp=TG-1; 333 trunk-context=example.com;user=phone@isp.example.net 335 2. Trunk group in a global number: 337 tel:+16305551212;tgrp=TG-1;trunk-context=example.com 339 Transforming this tel URI to a sip URI yields: 340 sip:+16305551212;tgrp=TG-1;trunk-context=example.com; 341 user=phone@isp.example.net 343 3. Trunk group in a global number: 345 tel:+16305551212;tgrp=TG-1;trunk-context=+1-630 347 Transforming this tel URI to a sip URI yields: 348 sip:+16305551212;tgrp=TG-1;trunk-context=+1-630; 349 user=phone@isp.example.net 351 6. Normative behavior of SIP entities using trunk groups 353 In order to satisfy REQ 3, the placement of the trunk group 354 parameters in a SIP Contact header or a R-URI, respectively, 355 signifies the intent. The terminating (or egress) trunk group 356 parameters MUST be specified in the R-URI. This is an indication 357 from a SIP entity to the next downstream entity that a specific 358 terminating (or egress) trunk group should be used. 360 This is consistent with using the R-URI as a routing element; SIP 361 routing entities may use the trunk group parameter in the R-URI to 362 make intelligent routing decisions. Furthermore, this also 363 satisfies REQ 4, since a SIP network intermediary can modify the 364 R-URI to include the trunk group parameters. 366 Conversely, the appearance of the trunk group parameters in the 367 Contact header signifies the trunk group over which the call arrived 368 on, i.e., the originating (or ingress) trunk group. Thus, the 369 originating (or ingress) trunk group MUST appear in the Contact 370 header of a SIP request. 372 6.1 Client behavior 374 A User Agent Client (UAC), or the proxy half of a UAC that initiates 375 a call that uses trunk groups and supports this specification MUST 376 include the trunk group parameters in the Contact header. The trunk 377 group parameters in the Contact header represents the originating 378 trunk group. Subsequent requests destined to that UAC MUST copy the 379 trunk group parameters from the Contact header into the R-URI. Note 380 that a Contact URI MUST be a sip or sips URI, thus, what appears in 381 the Contact header is a SIP translation of the tel URI, complete with 382 the trunk group parameters. 384 Arguably, the originating trunk group can be part of the From URI. 385 However, semantically, the URI in a From header is an abstract 386 identifier which represents the resource thus identified on a 387 long-term basis. The presence of a trunk group, on the other 388 hand, signifies a binding that is valid for the duration of the 389 session only; a trunk group has no significance once the session 390 is over. Thus, the Contact URI is the best place to impart this 391 information since it has exactly those semantics. 393 6.2 Server behavior 395 To the processing User Agent Server (UAS) associated with a gateway, 396 the trunk group parameters in the R-URI implies that it should use 397 the named trunk group for the outbound call. If a UAS supports trunk 398 groups but is not configured with the particular trunk group 399 identified in the R-URI, it SHOULD NOT use any other trunk group 400 other than the one specified in the parameters. In such a case, it 401 MAY reject the request with a 404 final response; or if it makes a 402 decision to process the request in any case, it MUST disregard the 403 values in the "trunk-context" and the "tgrp" parameters. 405 A processing UAS associated with a proxy SHOULD NOT change the trunk 406 group parameters on requests traversing through it. Doing so may 407 have adverse consequences, since the UAC that populated the 408 parameters did so on some authoritative knowledge that the proxy may 409 not be privy to. Instead, the proxy should pass the trunk group 410 parameters unchanged towards the next downstream server. 412 7. Example call flows 414 7.1 Reference architecture 416 Consider Figure 1, which depicts a SIP proxy in a routing 417 relationship with three gateways in its domain, GW1, GW2, and GW3. 418 Requests arrive at the SIP proxy through GW1. Gateways GW2 and GW3 419 are used as egress gateways from the domain. GW2 has two trunk 420 groups configured, TG2-1 and TG2-2. GW3 has only one trunk group 421 configured (TG3-1). 423 +-----+ TG2-1 424 | |--------> To 425 TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN 426 From ----->| | | SIP | | | |--------> 427 PSTN | GW1 |--->| Proxy |-----+ +-----+ 428 ----->| | +-------+ | +-----+ TG3-1 429 +-----+ | | |--------> To 430 +---->| GW3 | PSTN 431 | |--------> 432 +-----+ 433 Figure 1: Reference architecture 435 GW1 in Figure 1 is always cognizant of any requests that arrive over 436 trunk group TG1-1. If it wishes to propagate the ingress trunk group 437 to the proxy, it must arrange for the trunk group to appear in the 438 Contact header of the SIP request destined to the proxy. The proxy 439 will, in turn, propagate the ingress trunk group in the Contact 440 header further downstream. 442 The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is 443 assumed that the proxy has access to a routing table for GW2 and GW3 444 which includes the appropriate trunk groups to use when sending a 445 call to the PSTN (exactly how this table is constructed is out of 446 scope for this specification; [6] is one way to do so, a manually 447 created and maintained routing table is another). When the proxy 448 sends a request to either of the egress gateways, and the gateway 449 routing table is so configured that a trunk group is required by the 450 gateway, the proxy must arrange for the trunk group to appear in the 451 SIP R-URI of the request destined to that gateway. 453 7.2 Basic Call Flow 455 This example uses the reference architecture of Figure 1. Gateways 456 GW1, GW2, GW3 and the SIP proxy are assumed to be owned by a service 457 provider whose domain is example.com. 459 GW1 SIP Proxy GW2 460 From | | | 461 PSTN-->| | | 462 +---F1--------->| | 463 | +---F2----------->| 464 ... ... ... 465 | | | Send to PSTN 466 | | | --> and receive Answer 467 | | | Complete Message 468 ----------------------------------------- 469 Call in progress 470 ----------------------------------------- 471 | | | 472 | |<-----------F3---+ 473 +<--------------+ | 474 ... ... ... 476 In the call flow below, certain headers and messages have been 477 omitted for brevity. In F1, GW1 receives a call setup request from 478 the PSTN over a certain trunk group. GW1 arranges for this trunk 479 group to appear in in the Contact header of the request destined to 480 the SIP proxy. 482 F1: 483 INVITE sip:+16305554554@example.com;user=phone SIP/2.0 484 ... 485 Contact: 487 ... 489 In F2, the SIP proxy translates the R-URI and adds a destination 490 trunk group to the R-URI. The request is then sent to GW2. 492 F2: 493 INVITE sip:+16305554554;tgrp=TG2-1;trunk-context=example.com; 494 user=phone@gw2.example.com SIP/2.0 495 ... 496 Record-Route: 497 Contact: 499 ... 501 Once the call is established, either end can tear the call down. For 502 illustrative purposes, F3 depicts GW2 tearing the call down. Note 503 that the Contact from F1, including the trunk group parameters, is 504 now the R-URI of the request. When GW1 gets this request, it can 505 associate the call with the appropriate trunk group to deallocate 506 resources. 508 F3: 509 BYE sip:4554;phone-context=example.com;tgrp=TG1-1; 510 trunk-context=example.com;user=phone@gw1.example.com SIP/2.0 511 Route: 512 ... 514 It is worth documenting the behavior when an incoming call from the 515 PSTN is received at a gateway without a calling party number. 516 Consider Figure 1; in it, GW1 gets a call request from the PSTN 517 without a calling party number. This is not an uncommon case, and 518 may happen for a variety of reasons, including privacy and 519 interworking between different signaling protocols before the request 520 reached GW1. Under normal circumstances (i.e., instances where the 521 calling party number is present in signaling), GW1 would derive a sip 522 URI to insert into the Contact header. This sip URI may contain, as 523 its user portion, the calling party number from from the incoming SS7 524 signaling information. The trunk group parameters then becomes part 525 of the user portion as discussed previously. 527 If a gateway receives an incoming call where the calling party number 528 is not available, it MUST create a sip URI that has, as its user 529 portion, a token that is generated locally and has local significance 530 to the gateway. Details of generating such a token are 531 implementation dependent; potential candidates include the gateway 532 line number or port number where the call was accepted. This sip URI 533 is subsequently inserted in the Contact header of the SIP request 534 going downstream from the gateway. 536 The tel scheme does not allow for an empty URI; thus the global- 537 number or local-number production rule of the tel URI [4] cannot 538 contain an empty string. Consequently, the behavior in the above 539 paragraph is mandated for cases where the incoming SS7 signaling 540 message does not contain a calling party number. 542 7.3 Inter-domain Call Flow 544 This example demonstrates the advantage of namespaces in trunk group. 545 In the example flow below, GW1 and SIP Proxy 1 belong to the 546 example.com domain and SIP Proxy 2 belongs to another domain, 547 example.net. A call arrives at GW1 (F1) and is routed to the 548 example.net domain. In the call flow below, certain headers and 549 messages have been omitted for brevity. 551 example.com example.net 552 /-------------------------\ /-----------\ 553 GW1 SIP Proxy 1 SIP Proxy 2 554 From | | | 555 PSTN-->| | | 556 +---F1--------->| | 557 | +---F2----------->| 558 ... ... ... 560 F1: 561 INVITE sip:+16305554554@example.com;user=phone SIP/2.0 562 ... 563 Contact: 565 ... 567 In F2, the SIP proxy executes its routing logic and re-targets the 568 R-URI to refer to a resource in example.net domain. 570 F2: 571 INVITE sip:+16305554554@example.net;user=phone SIP/2.0 572 ... 573 Record-Route: 574 Contact: 576 ... 578 8. Security considerations 580 The trunk group parameters are carried in R-URIs and Contact headers; 581 it is simply a modifier of an address, and any existing trust 582 relationship between the originator of a request and an intermediary 583 (or final recipient) that processes the request is not affected by 584 such a modifier. Maliciously modifying a trunk group of a R-URI in 585 transit may cause the receiving entity, say a gateway, to prefer one 586 trunk over another; thus leading to attacks that use resources not 587 privy to the call. For example, an attacker who knows the name of a 588 toll-free trunk on a gateway may modify the trunk group in the R-URI 589 to effectively receive free service, or he may modify the trunk group 590 in a R-URI to affect the flow of traffic across trunks. Similarly, 591 modifying the trunk group in a Contact header may cause the routing 592 intermediary to erroneously associate a call with a different source 593 than it would normally be associated with. 595 Although this specification imparts more information to the R-URI and 596 the Contact header in the form of trunk groups, the class of attacks 597 and possible protection mechanism are the same as that specified for 598 baseline SIP systems [3]. Transport Layer Security (TLS) SHOULD be 599 used to provide integrity protection, thereby mitigating these 600 attacks. 602 The privacy information revealed with a trunk group does not 603 generally advertise much information about a particular (human) user. 604 It does, however, convey two pieces of potentially private 605 information which may be considered sensitive by carriers. First, it 606 may reveal how a carrier may be performing least-cost routing and 607 peering; and secondly, it does introduce an additional means for 608 network topology and information of a carrier. It is up to the 609 discretionary judgment of the carrier if it wants to include the 610 trunk group parameters and reveal potentially sensitive information 611 on its network topology. If confidentiality is desired, TLS SHOULD 612 be used to protect this information while in transit. 614 9. IANA considerations 616 This specification requires no IANA actions beyond those specified in 617 [7]. 619 10. Acknowledgments 621 The authors would like to acknowledge the efforts of the participants 622 of the SIPPING and IPTEL working group, especially Bryan Byerly, John 623 Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon Peterson, Mike 624 Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, Dave Oran, 625 Takuya Sawada, Tom Taylor, and Al Varney. 627 Alex Mayrhofer brought up the issue of lexicographic ordering of tel 628 URI parameters when it is converted to a sip or sips URI. 630 11. References 632 11.1 Normative References 634 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 635 Levels", BCP 14, RFC 2119, March 1997. 637 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 638 Specifications: ABNF", RFC 4234, October 2005. 640 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 641 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 642 Session Initiation Protocol", RFC 3261, June 2002. 644 [4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966, 645 December 2004. 647 11.2 Informative References 649 [5] "Bellcore Notes on the Network", Telcordia SR2275, Dec 1997, 650 . 652 [6] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H., and D. 653 Shah, "A Telephony Gateway REgistration Protocol (TGREP)", 654 draft-ietf-iptel-tgrep-06.txt (work in progress), July 2005. 656 [7] Jennings, C. and V. Gurbani, "The Internet Assigned Number 657 Authority (IANA) tel Uniform Resource Identifier (URI) Parameter 658 Registry", draft-ietf-iptel-tel-reg-01.txt (work in progress), 659 February 2006. 661 Authors' Addresses 663 Vijay Gurbani 664 Lucent Technologies, Inc./Bell Laboratories 665 2701 Lucent Lane 666 Rm 9F-546 667 Lisle, IL 60532 668 USA 670 Phone: +1 630 224 0216 671 Email: vkg@lucent.com 672 Cullen Jennings 673 Cisco Systems 674 170 West Tasman Drive 675 Mailstop SJC-21/3 676 San Jose, CA 95134 677 USA 679 Phone: +1 408 421 9990 680 Email: fluffy@cisco.com 682 Intellectual Property Statement 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 Disclaimer of Validity 708 This document and the information contained herein are provided on an 709 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 710 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 711 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 712 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 713 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 714 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 Copyright Statement 718 Copyright (C) The Internet Society (2006). This document is subject 719 to the rights, licenses and restrictions contained in BCP 78, and 720 except as set forth therein, the authors retain all their rights. 722 Acknowledgment 724 Funding for the RFC Editor function is currently provided by the 725 Internet Society.