idnits 2.17.1 draft-ietf-iptel-trunk-group-06.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 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 633. ** 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: To the processing User Agent Server (UAS), a trunk group in the R-URI implies that it should use the named trunk group for the outbound call. If a UAS supports trunk groups but is not configured with the particular trunk group identified in the R-URI, it SHOULD not use any other trunk group other than the one requested. -- 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 (Dec 06, 2005) is 6713 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 2234 (ref. '2') (Obsoleted by RFC 4234) == 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-00 Summary: 4 errors (**), 0 flaws (~~), 5 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: June 9, 2006 Laboratories 5 C. Jennings 6 Cisco Systems 7 Dec 06, 2005 9 Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs) 10 draft-ietf-iptel-trunk-group-06.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 June 9, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes a standardized mechanism to convey trunk 44 group-related information in sip and tel Uniform Resource Identifiers 45 (URIs). 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? . . . . . . . . . . . . . . . . . . . 4 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. Reference architecture . . . . . . . . . . . . . . . . . . . 7 58 6. Trunk group identifier: ABNF and examples . . . . . . . . . 8 59 7. Example call flows . . . . . . . . . . . . . . . . . . . . . 9 60 7.1 Basic Call Flow . . . . . . . . . . . . . . . . . . . . . 10 61 7.2 Inter-domain Call Flow . . . . . . . . . . . . . . . . . . 11 62 8. Security considerations . . . . . . . . . . . . . . . . . . 12 63 9. IANA considerations . . . . . . . . . . . . . . . . . . . . 13 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 11.1 Normative References . . . . . . . . . . . . . . . . . . 13 67 11.2 Informative References . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . 15 71 1. Conventions 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC-2119 [1]. 77 2. Definitions 79 Call routing in the Public Switched Telephone Network (PSTN) is 80 accomplished by routing calls over specific circuits (commonly 81 referred to as "trunks") between Time Division Multiplexed (TDM) 82 circuit switches. In large switches, a group of trunks that connects 83 to the same target switch or network is called a "trunk group." 84 Consequently, trunk groups have labels, which are used as the main 85 indication for the previous and next TDM switch participating in 86 routing the call. 88 Formally, we define a trunk and trunk group and related terminology 89 as follows (definition of "trunk" and "trunk group" is from [5]). 91 Trunk: In a network, a communication path connecting two 92 switching systems used in the establishment of an end-to-end 93 connection. In selected applications, it may have both its 94 terminations in the same switching system. 96 Trunk Group: A set of trunks, traffic engineered as a unit, for 97 the establishment of connections within or between switching 98 systems in which all of the paths are interchangeable. 100 Digital Signal 0 (DS0): Digital Signal X is a term for a series 101 of standard digital transmission rates based on DS0, a 102 transmission rate of 64kbps (the bandwidth normally used for one 103 telephone voice channel). The European E-carrier system of 104 transmission also operates using the DS series as a base multiple. 106 Since the introduction of ubiquitous digital trunking, which resulted 107 in the allocation of DS0s between end offices in minimum groups of 24 108 (in North America), it has become common to refer to bundles of DS0s 109 as a trunk. Strictly speaking, however, a trunk is a single DS0 110 between two PSTN end offices - however, for the purposes of this 111 document, the PSTN interface of a gateway acts effectively as an end 112 office (i.e. if the gateway interfaces with Signaling System 7 (SS7), 113 it has its own SS7 point code, and so on). A trunk group, then, is a 114 bundle of DS0s (that need not be numerically contiguous in an SS7 115 Trunk Circuit Identification Code numbering scheme) which are grouped 116 under a common administrative policy for routing. 118 A Session Initiation Protocol (SIP) [3] to PSTN gateway may have 119 trunks that are connected to different carriers. It is entirely 120 reasonable for a SIP proxy to choose -- based on factors not 121 enumerated in this document -- which carrier a call is sent to when 122 it proxies a session setup request to the gateway. Since multiple 123 carriers can terminate a particular PSTN phone number, the phone 124 number itself is not sufficient enough to identify the carrier at the 125 gateway. An additional piece of information in the form of a trunk 126 group can be used to further pare down the choices at the gateway. 127 How the proxy picked a particular trunk group is outside the scope of 128 this document ([6] provides one such way); once the trunk group has 129 been decided upon, this document provides a standardized means to 130 represent it. 132 3. Problem statement 134 Currently, there isn't any standardized manner of transporting trunk- 135 groups between Internet signaling entities. This leads to ambiguity 136 on at least two fronts: 138 1. Positional ambiguity: A SIP proxy that wants to send a call to 139 an egress Voice over IP (VoIP) gateway may insert the trunk-group 140 as a parameter in the user portion of the Request-URI (R-URI), or 141 it may insert it as a parameter to the R-URI itself. This 142 ambiguity persists in the reverse direction as well, that is, 143 when an ingress VoIP gateway wants to send a incoming call 144 notification to its default outbound proxy. 145 2. Semantic ambiguity: The lack of any standardized grammar to 146 represent trunk groups leads to the unfortunate choice of ad hoc 147 names and values. 149 VoIP routing entities in the Internet, such as SIP proxies, may be 150 interested in using trunk-group information for normal operations. 151 To that extent, any standards-driven requirements will enable proxies 152 from one vendor to interoperate with gateways from yet another 153 vendor. Absent such guidelines, inter-operability will suffer as a 154 proxy vendor must conform to the expectations of a gateway as to 155 where it expects trunk-group information to be present (and vice 156 versa). 158 The aim of this specification is to outline how to structure and 159 represent the trunk group information as an extension to the tel URI 160 [4] in a standardized manner. 162 4. Requirements and rationale 164 4.1 sip URI or tel URI? 166 REQ 1: Trunk group information MUST be defined as an extension to 167 the "tel" URI [4]. 169 The trunk group information can be carried in either the "sip" URI or 170 the "tel" URI. Since trunks groups are intimately associated with 171 the PSTN, it seems reasonable to define them as extensions to the 172 "tel" URI (any SIP request that goes to a gateway could reasonably be 173 expected to have a tel URL, in whole or in part, in its R-URI 174 anyway). Furthermore, using the tel URL also allows this format to 175 be reused by non-SIP VoIP protocols (which could include anything 176 from MGCP or Megaco to H.323, if the proper information elements are 177 created). 179 Finally, once the trunk-group is defined for a "tel" URI, the 180 normative procedures of Section 19.1.6 of [3] can be used to derive 181 an equivalent "sip" URI from a "tel" URI, complete with the trunk 182 group information. 184 4.2 Trunk group namespace: global or local? 186 REQ 2: Inter-domain trunk group name collisions MUST be prevented. 188 Under normal operations, trunk groups are pertinent only within an 189 administrative domain (i.e. local scope). However, given that 190 inadvertent cross-domain trunk group name collisions may occur, it is 191 desirable to to prevent these. The judicious use of namespaces is a 192 solution to this problem. A trunk group in a URI MUST belong to a 193 namespace. 195 At first glance, it would appear that the use of the tel URI's 196 "phone-context" parameter provides a satisfactory means of 197 imposing a namespace on a trunk group. The "phone-context" 198 parameter identifies the scope of validity of a local telephone 199 number. And therein lies the problem. Semantically, a "phone- 200 context" tel URI parameter is applicable only to a local telephone 201 number and not a global one (i.e., one preceeded by a '+'). Trunk 202 groups, on the other hand, may appear in local or global telephone 203 numbers. Thus, what is needed is a new parameter with equivalent 204 functionality of the "phone-context" parameter of the tel URI, but 205 one that is equally applicable to local and global telephone 206 numbers. 208 4.3 Originating trunk group and terminating trunk group 210 REQ 3: Originating trunk group and destination trunk group SHOULD be 211 able to appear separately and concurrently in a SIP message. 213 SIP routing entities can make informed routing decisions based on 214 either the originating or the terminating trunk groups. Thus a 215 requirement that both of these trunk groups need to be carried in SIP 216 requests. 218 Instead of having two parameters, one for the originating trunk group 219 and the other for a terminating trunk group, the placement of the 220 trunk group parameter in a SIP Contact header or the R-URI, 221 respectively, signifies the intent. A proxy (or any other 222 intermediary -- see next section) MAY insert a trunk group appears in 223 the R-URI; to the next downstream entity this signifies an egress (or 224 terminating) trunk group to be used. 226 Conversely, when a trunk group parameter appears in the Contact 227 header, this signifies the trunk group over which the call came over, 228 i.e., the ingress (or orgininating) trunk group. 230 4.4 Intermediary processing of trunk groups 232 REQ 4: SIP network intermediaries (proxy server and redirect 233 servers) should be able to add the destination trunk group attribute 234 to SIP sessions as a route is selected for a call. 236 If the trunk group parameter appears in a R-URI of a request, it 237 represents the destination trunk group. 239 This is consistent with using the R-URI as a routing element; SIP 240 routing entities may use the trunk group parameter in the R-URI to 241 make intelligent routing decisions. Furthermore, this also 242 satisfies REQ 4, since a SIP network intermediary can modify the 243 R-URI to include the trunk group information. 245 To the processing User Agent Server (UAS), a trunk group in the R-URI 246 implies that it should use the named trunk group for the outbound 247 call. If a UAS supports trunk groups but is not configured with the 248 particular trunk group identified in the R-URI, it SHOULD not use any 249 other trunk group other than the one requested. 251 A User Agent Client (UAC) that initiates a call and supports this 252 specification MAY include the trunk group in the Contact header. If 253 it does so, the trunk group in the Contact header represents the 254 originating trunk group. Subsequent requests destined to that UAC 255 MUST copy the trunk group from the Contact header into the R-URI. 256 Note that a Contact URI MUST be a sip or sips URI, thus, what appears 257 in the Contact header is a SIP translation of the tel URI, complete 258 with the trunk group information. 260 Arguably, the originating trunk group can be part of the From URI. 261 However, semantically, the URI in a From header is an abstract 262 identifier which represents the resource thus identified on a 263 long-term basis. The presence of a trunk group, on the other 264 hand, signifies a binding that is valid for the duration of the 265 session only; a trunk group has no significance once the session 266 is over. Thus, the Contact URI is the best place to impart this 267 information since it has exactly those semantics. 269 5. Reference architecture 271 Consider Figure 1, which depicts a SIP proxy in a routing 272 relationship with three gateways in its domain, GW1, GW2, and GW3. 273 Among other sources of request arrival (not shown in Figure) at the 274 proxy is GW1. Gateways GW2 and GW3 are used as egress gateways from 275 the domain. GW2 has two trunk groups configured, TG2-1 and TG2-2. 276 GW3 has only one trunk group configured (TG3-1). 278 +-----+ TG2-1 279 | |--------> To 280 TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN 281 From ----->| | | SIP | | | |--------> 282 PSTN | GW1 |--->| Proxy |-----+ +-----+ 283 ----->| | +-------+ | +-----+ TG3-1 284 +-----+ | | |--------> To 285 +---->| GW3 | PSTN 286 | |--------> 287 +-----+ 288 Figure 1: Reference architecture 290 GW1 in Figure 1 is always cognizant of any requests that arrive over 291 trunk group TG1-1. If it wishes to propagate the ingress trunk group 292 to the proxy, it MUST arrange for the trunk group to appear in the 293 Contact header of the SIP request destined to the proxy. The proxy 294 will, in turn, propagate the ingress trunk group in the Contact 295 header further downstream. 297 The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is 298 assumed that the proxy has access to a routing table for GW2 and GW3 299 which includes the appropriate trunk groups to use when sending a 300 call to the PSTN (exactly how this table is constructed is out of 301 scope for this specification; [6] is one way to do so, a manually 302 created and maintained routing table is another). When the proxy 303 sends a request to either of the egress gateways, and the gateway 304 routing table is so configured that a trunk group is required by the 305 gateway, the proxy MUST arrange for the trunk group to appear in the 306 SIP R-URI of the request destined to that gateway. 308 6. Trunk group identifier: ABNF and examples 310 The Augmented Backus Naur Form [2] syntax for a trunk group 311 identifier is given below and extends the "par" production rule of 312 the tel URI defined in [4]: 314 par = parameter / extension / isdn-subaddress / trunk-group / 315 trunk-context 317 trunk-group = ";tgrp=" trunk-group-label 318 trunk-context = ";trunk-context=" descriptor 320 trunk-group-label = *1( unreserved / escaped / 321 trunk-group-unreserved ) 322 trunk-group-unreserved = "/" / "&" / "+" / "$" 324 trunk-group-unreserved is the intersection of param-unreserved 325 defined in [4] and user-unreserved defined in [3]. Since the 326 trunk group is an extension to the tel URI and will end up as the 327 user portion of a SIP URI, the ABNF for it has to ensure that it 328 can be adequately represented in both the constructs. 329 descriptor is defined in [4]. 331 Trunk groups are identified by two parameters: "tgrp" and "trunk- 332 context"; both of these parameters MUST be present in a tel URI to 333 identify a trunk group. All implementations conforming to this 334 specification MUST generate both of these parameters when using trunk 335 groups. If an implementation receives a tel URI with only one of the 336 "tgrp" or "trunk-context" parameters, it MUST act as if there were 337 not any trunk group identifiers present at all in that URI. Whether 338 or not to further process such an URI is up to the discretion of the 339 implementation, however, if a decision is made to process it, the 340 implementation must act as if there were not any trunk group 341 identifiers present in the URI. 343 The "trunk-context" and "tgrp" parameter SHOULD use lower-case 344 characters as tel URIs may be used within contexts where comparisons 345 are case sensitive. 347 The "trunk-context" parameter imposes a namespace on the trunk group 348 by specifying a global number or any number of its leading digits 349 (e.g., +33), or a domain name. Syntactically, it is modeled after 350 the "phone-context" parameter of the tel URI [4], and semantically, 351 it serves an equivalent function except that unlike the "phone- 352 context" parameter, the "trunk-context" parameter can appear in 353 either a local or global tel URI. 355 If the receiver of a SIP request is not the owner of the domain (or 356 global prefix) specified in the "trunk-context", it MUST treat the 357 trunk group as if it was not there. 359 For equivalency purposes, two URIs containing trunk group identifiers 360 are equivalent according to the base comparison rules of the URIs AND 361 the values of their "tgrp" and "trunk-context" parameters MUST match. 362 The base comparison rules of a tel URI are specified in Section 4 of 363 [4], and the base comparison rules of a sip URI are specified in 364 Section 19.1.4 of [3]. 366 Note that the base comparison rules for a sip or sips URI that has 367 been derived from a tel URI mandate that the telephone-subscriber 368 parameters be ordered lexically by parameter name (see Section 369 19.1.6 of [3]). Thus, when comparing a sip URI that has been 370 derived from a tel URI, implementations MUST NOT assume that the 371 "tgrp" and "trunk-context" parameters will appear in a consecutive 372 manner because parameters defined by other tel URI extensions may 373 lexically fit between "tgrp" and "trunk-context". 375 Examples: 377 1. Trunk group in a local number, with a phone-context parameter 378 (mind the line breaks added for readibility): 380 tel:5551212;phone-context=+1-630;tgrp=TG-1; 381 trunk-context=example.com 382 Transforming this tel URI to a sip URI yields: 383 sip:5551212;phone-context=+1-630;tgrp=TG-1; 384 trunk-context=example.com@isp.example.net 386 2. Trunk group in a global number: 388 tel:+16305551212;tgrp=TG-1;trunk-context=example.com 389 Transforming this tel URI to a sip URI yields: 390 sip:+16305551212;tgrp=TG-1;trunk-context=example.com@ 391 isp.example.net 393 3. Trunk group in a global number: 395 tel:+16305551212;tgrp=TG-1;trunk-context=+1-630 396 Transforming this tel URI to a sip URI yields: 397 sip:+16305551212;tgrp=TG-1;trunk-context=+1-630@isp.example.net 399 7. Example call flows 400 7.1 Basic Call Flow 402 This example uses the reference architecture of Figure 1. Gateways 403 GW1, GW2, GW3 and the SIP proxy are assumed to be owned by a service 404 provider whose domain is example.com. 406 GW1 SIP Proxy GW2 407 From | | | 408 PSTN-->| | | 409 +---F1--------->| | 410 | +---F2----------->| 411 ... ... ... 412 | | | Send to PSTN 413 | | | --> and receive Answer 414 | | | Complete Message 415 ----------------------------------------- 416 Call in progress 417 ----------------------------------------- 418 | | | 419 | |<-----------F3---+ 420 +<--------------+ | 421 ... ... ... 423 In the call flow below, certain headers and messages have been 424 omitted for brevity. In F1, GW1 receives a call setup request from 425 the PSTN over a certain trunk group. GW1 arranges for this trunk 426 group to appear in in the Contact header of the request destined to 427 the SIP proxy. 429 F1: 430 INVITE sip:+16305554554@example.com 431 ... 432 Contact: 435 In F2, the SIP proxy translates the R-URI and adds a destination 436 trunk group to the R-URI. The request is then sent to GW2. 438 F2: 439 INVITE sip:+16305554554;tgrp=TG2-1;trunk-context=example.com@ 440 gw2.example.com 441 ... 442 Record-Route: 443 Contact: 446 Once the call is established, either end can tear the call down. For 447 illustrative purposes, F3 depicts GW2 tearing the call down. Note 448 that the Contact from F1, including the trunk group information, is 449 now the R-URI of the request. When GW1 gets this request, it can 450 associate the call with the appropriate trunk group to deallocate 451 resources. 453 F3: 454 BYE sip:4554;phone-context=example.com;tgrp=TG1-1; 455 trunk-context=example.com@gw1.example.com 456 Route: 458 It is worth documenting the behavior when an incoming call from the 459 PSTN is received at a gateway without a calling party number. 460 Consider Figure 1; in it, GW1 gets a call request from the PSTN 461 without a calling party number. This is not an uncommon case, and 462 may happen for a variety of reasons, including privacy and 463 interworking between different signaling protocols before the request 464 reached GW1. Under normal circumstances (i.e., instances where the 465 calling party number is present in signaling), GW1 would derive a sip 466 URI to insert into the Contact header. This sip URI may contain, as 467 its user portion, the calling party number from from the incoming SS7 468 signaling information. The trunk group information then becomes part 469 of the user portion as discussed previously. 471 If a gateway receives an incoming call where the calling party number 472 is not available, it MUST create a sip URI that has, as its user 473 portion, a token that is generated locally and has local significance 474 to the gateway. Details of generating such a token are 475 implementation dependent; potential candidates include the gateway 476 line number or port number where the call was accepted. This sip URI 477 is subsequently inserted in the Contact header of the SIP request 478 going downstream from the gateway. 480 The tel scheme does not allow for an empty URI; thus the global- 481 number or local-number production rule of the tel URI [4] cannot 482 contain an empty string. Consequently, the behavior in the above 483 paragraph is mandated for cases where the incoming SS7 signaling 484 message does not contain a calling party number. 486 7.2 Inter-domain Call Flow 488 This example demonstrates the advantage of namespaces in trunk group. 489 In the example flow below, GW1 and SIP Proxy 1 belong to the 490 example.com domain and SIP Proxy 2 belongs to another domain, 491 example.net. A call arrives at GW1 (F1) and is routed to the 492 example.net domain. In the call flow below, certain headers and 493 messages have been omitted for brevity. 495 example.com example.net 496 /-------------------------\ /-----------\ 497 GW1 SIP Proxy 1 SIP Proxy 2 498 From | | | 499 PSTN-->| | | 500 +---F1--------->| | 501 | +---F2----------->| 502 ... ... ... 504 F1: 505 INVITE sip:+16305554554@example.com 506 ... 507 Contact: 510 In F2, the SIP proxy executes its routing logic and re-targets the 511 R-URI to refer to a resource in example.net domain. 513 F2: 514 INVITE sip:+16305554554@example.net 515 ... 516 Record-Route: 517 Contact: 520 Once the request is in the domain of example.net, the namespace 521 imposed by the "trunk-context" parameter in the Contact header 522 prevents collisions with similiar trunk groups maintained by the 523 example.net domain. 525 8. Security considerations 527 The extension defined in this document does not add any additional 528 security concerns beyond those already enumerated in [3]. The trunk 529 group information is carried in R-URIs and Contact headers; it is 530 simply a modifier of an address, and the trust imparted to that 531 address is not affected by such a modifier. The privacy information 532 revealed with trunk groups does not generally advertise much 533 information about a particular (human) user. It does, however, 534 convey two pieces of potentially private information which may be 535 considered sensitive by carriers. First, it may reveal how a carrier 536 may be performing least-cost routing and peering; and secondly, it 537 does introduce an additional means for network topology and 538 information of a carrier. It is up to the discretionary judgment of 539 the carrier if it wants to include the trunk group information and 540 reveal potentially sensitive information on its network topology. 542 9. IANA considerations 544 This specification requires no IANA actions beyond those specified in 545 [7]. 547 10. Acknowledgments 549 The authors would like to acknowledge the efforts of the participants 550 of the SIPPING and IPTEL working group, especially Bryan Byerly, John 551 Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon Peterson, Mike 552 Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, Dave Oran, 553 Takuya Sawada, Tom Taylor, and Al Varney. 555 Alex Mayrhofer brought up the issue of lexicographic ordering of tel 556 URI parameters when it is converted to a sip or sips URI. 558 11. References 560 11.1 Normative References 562 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 563 Levels", BCP 14, RFC 2119, March 1997. 565 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 566 Specifications: ABNF", RFC 2234, November 1997. 568 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 569 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 570 Session Initiation Protocol", RFC 3261, June 2002. 572 [4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966, 573 December 2004. 575 11.2 Informative References 577 [5] "Bellcore Notes on the Network", Telcordia SR2275, Dec 1997, 578 . 580 [6] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H., and D. 581 Shah, "A Telephony Gateway REgistration Protocol (TGREP)", 582 draft-ietf-iptel-tgrep-06.txt (work in progress), July 2005. 584 [7] Jennings, C. and V. Gurbani, "The Internet Assigned Number 585 Authority (IANA) tel Uniform Resource Identifier (URI) Parameter 586 Registry", draft-ietf-iptel-tel-reg-00.txt (work in progress), 587 December 2005. 589 Authors' Addresses 591 Vijay Gurbani 592 Lucent Technologies, Inc./Bell Laboratories 593 2000 Lucent Lane 594 Rm 6G-440 595 Naperville, IL 60566 596 USA 598 Phone: +1 630 224 0216 599 Email: vkg@lucent.com 601 Cullen Jennings 602 Cisco Systems 603 170 West Tasman Drive 604 Mailstop SJC-21/3 605 San Jose, CA 95134 606 USA 608 Phone: +1 408 421 9990 609 Email: fluffy@cisco.com 611 Intellectual Property Statement 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; nor does it represent that it has 618 made any independent effort to identify any such rights. Information 619 on the procedures with respect to rights in RFC documents can be 620 found in BCP 78 and BCP 79. 622 Copies of IPR disclosures made to the IETF Secretariat and any 623 assurances of licenses to be made available, or the result of an 624 attempt made to obtain a general license or permission for the use of 625 such proprietary rights by implementers or users of this 626 specification can be obtained from the IETF on-line IPR repository at 627 http://www.ietf.org/ipr. 629 The IETF invites any interested party to bring to its attention any 630 copyrights, patents or patent applications, or other proprietary 631 rights that may cover technology that may be required to implement 632 this standard. Please address the information to the IETF at 633 ietf-ipr@ietf.org. 635 Disclaimer of Validity 637 This document and the information contained herein are provided on an 638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 640 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 641 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 642 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Copyright Statement 647 Copyright (C) The Internet Society (2005). This document is subject 648 to the rights, licenses and restrictions contained in BCP 78, and 649 except as set forth therein, the authors retain all their rights. 651 Acknowledgment 653 Funding for the RFC Editor function is currently provided by the 654 Internet Society.