idnits 2.17.1 draft-ietf-iptel-trunk-group-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 27 characters in excess of 72. 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 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 (January 8, 2004) is 7413 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) ** Obsolete normative reference: RFC 2806 (ref. '4') (Obsoleted by RFC 3966) == Outdated reference: A later version (-09) exists of draft-ietf-iptel-rfc2806bis-02 == Outdated reference: A later version (-09) exists of draft-ietf-iptel-tgrep-02 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 4 Expires: July 8, 2004 C. Jennings 5 Cisco Systems 6 J. Peterson 7 NeuStar 8 January 8, 2004 10 Representing trunk groups in tel/sip URIs 11 draft-ietf-iptel-trunk-group-01 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 8, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes a standardized mechanism to convey trunk 42 group- related information in SIP and TEL URIs. An extension to the 43 "tel" URI is defined for this purpose. 45 This work is being discussed on the iptel@ietf.org mailing list. 47 Table of Contents 49 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Problem statement . . . . . . . . . . . . . . . . . . . . . 3 51 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . 5 57 5. Reference architecture . . . . . . . . . . . . . . . . . . . 6 58 6. Trunk group identifier: ABNF and examples . . . . . . . . . 7 59 7. Example call flows . . . . . . . . . . . . . . . . . . . . . 8 60 7.1 Trunk group in a Contact header . . . . . . . . . . . . . . 8 61 7.2 Trunk group in the R-URI . . . . . . . . . . . . . . . . . . 9 62 8. Security considerations . . . . . . . . . . . . . . . . . . 9 63 9. IANA considerations . . . . . . . . . . . . . . . . . . . . 10 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 65 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 11.1 Changes from trunk-group-00 . . . . . . . . . . . . . . . . 10 67 Normative References . . . . . . . . . . . . . . . . . . . . 10 68 Informative References . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 70 Intellectual Property and Copyright Statements . . . . . . . 12 72 1. Conventions 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC-2119 [1]. 78 2. Problem statement 80 Currently, there isn't any standardized manner of transporting 81 trunk-groups between Internet signaling entities. This leads to 82 ambiguity on at least two fronts: 84 1. Positional ambiguity: A SIP proxy that wants to send a call to an 85 egress VoIP gateway may insert the trunk-group as a parameter in 86 the user portion of the Request-URI (R-URI), or it may insert it 87 as a parameter to the R-URI itself. This ambiguity persists in 88 the reverse direction as well, that is, when an ingress VoIP 89 gateway wants to send a incoming call notification to its default 90 outbound proxy. 91 2. Semantic ambiguity: The lack of any standardized grammar to 92 represent trunk groups leads to the unfortunate choice of ad hoc 93 names and values. 95 VoIP routing entities in the Internet, such as SIP proxies, may be 96 interested in using trunk-group information for normal operations. 97 To that extent, any standards-driven requirements will enable proxies 98 from one vendor to interoperate with gateways from yet another 99 vendor. Absence such guidelines, inter-operability will suffer as a 100 proxy vendor must conform to the expectations of a gateway as to 101 where it expects trunk-group information to be present (and vice 102 versa). 104 The aim of this Internet draft is to outline how to structure and 105 represent the trunk group information as an extension to the tel URI 106 [5] in a standardized manner. 108 3. Definitions 110 Before we take the discussion of trunks any further, we must define 111 both a trunk and a trunk group and explain the difference between the 112 two. The following definitions are taken from [6]. 114 Trunk: In a network, a communication path connecting two switching 115 systems used in the establishment of an end-to-end connection. In 116 selected applications, it may have both its terminations in the 117 same switching system. 118 Trunk Group: A set of trunks, traffic engineered as a unit, for 119 the establishment of connections within or between switching 120 systems in which all of the paths are interchangeable except where 121 subgrouped. 123 Since the introduction of ubiquitous digital trunking, which resulted 124 in the allocation of DS0s between end offices in minimum groups of 24 125 (in North America), it has become common to refer to bundles of DS0s 126 as a trunk. Strictly speaking, however, a trunk is a single DS0 127 between two Public Switched Telephone Network (PSTN) end offices - 128 however, for the purposes of this document, the PSTN interface of a 129 gateway acts effectively as an end office (i.e. if the gateway 130 interfaces with SS7, it has its own SS7 point code, and so on). A 131 trunk group, then, is a bundle of DS0s (that need not be numerically 132 contiguous in an SS7 Trunk Circuit Identification Code (TCIC) 133 numbering scheme) which are grouped under a common administrative 134 policy for routing. 136 A SIP-PSTN gateway may have trunks that are connected to different 137 carriers. It is entirely reasonable for a SIP proxy to choose -- 138 based on factors not enumerated in this document -- which carrier a 139 call is sent to when it proxies a session setup request to the 140 gateway. Since multiple carriers can terminate a particular PSTN 141 phone number, the phone number itself is not sufficient enough to 142 identify the carrier at the gateway. An additional piece of 143 information in the form of a trunk group can be used to further pare 144 down the choices at the gateway. How the proxy picked a particular 145 trunk group is outside the scope of this document (reference [7] 146 provides one such way); once the trunk group has been decided upon, 147 this document provides a standardized means to represent it. 149 4. Requirements and rationale 151 4.1 sip URI or tel URI? 153 REQ 1: Trunk group information MUST be carried in the "tel" URI [5]. 155 The trunk group information can be carried in either the "sip" URI 156 [3] or the "tel" URI [4,5]. Since trunks groups are intimately 157 associated with the PSTN (Public Switched Telephone Network), it 158 seems reasonable to define them as extensions to the "tel" URI (any 159 SIP request that goes to a gateway could reasonably be expected to 160 have a tel URL, in whole or in part, in its R-U anyway). 161 Furthermore, using the tel URL also allows this format to be re-used 162 by non-SIP VoIP protocols (which could include anything from MGCP or 163 Megaco to H.323, if the proper IEs are created). 165 Finally, once the trunk-group is defined for a "tel" URI, the 166 normative procedures of Section 19.1.6 in [3] can be used to derive 167 an equivalent "sip" URI from a "tel" URI, complete with the trunk 168 group information. 170 4.2 Trunk group namespace: global or local? 172 REQ 2: To prevent inadvertent inter-domain trunk group naming 173 collisions, a name space MUST be defined which must be flexible 174 enough to both accommodate local naming conventions and provide 175 global naming semantics. 177 Under normal operations, trunk groups have meaning only within an 178 administrative domain (i.e. local scope). However, to prevent 179 inadvertent cross-domain trunk group collisions (which, given 180 Murphy's law, will happen), a global scope appears to be useful. The 181 "phone-context" parameter of the tel URI is used to impose a 182 namespace by specifying a domain where the trunk groups are 183 understood. 185 The use of the "phone-context" parameter in conjunction with this 186 draft is mandatory; implementations choosing to include trunk groups 187 in SIP signaling MUST be capable of parsing and generating the 188 "phone-context" parameter of the tel URI. If a receiver of a SIP 189 request is not the owner of the domain specified in the 190 "phone-context", it MUST treat the trunk group as if it was not 191 there. 193 4.3 Originating trunk group and terminating trunk group 195 REQ 3: Originating trunk group and destination trunk group SHOULD be 196 able to appear separately and concurrently in a SIP message. 198 SIP routing entities can make informed routing decisions based on 199 either the originating or the terminating trunk groups. Thus a 200 requirement that both of these trunk groups need to be carried in SIP 201 requests. Instead of having two parameters, one for the originating 202 trunk group and the other for a terminating trunk group, the 203 placement of the trunk group parameter in a SIP Contact header or the 204 R-URI, respectively, signifies the intent. 206 4.4 Intermediary processing of trunk groups 208 REQ 4: SIP network intermediaries (proxy server and redirect servers) 209 should be able to add the destination trunk group attribute to SIP 210 sessions as a route is selected for a call. 212 If the trunk group parameter appears in a R-URI of a request, it 213 represents the destination trunk group. 215 This is consistent with using the R-URI as a routing element; SIP 216 routing entities may use the trunk group parameter in the R-URI to 217 make intelligent routing decisions. Furthermore, this also 218 satisfies REQ 4, since a SIP network intermediary can modify the 219 R-URI to include the trunk group information. 221 To the processing UAS, a trunk group in the R-URI implies that it 222 should use the named trunk group for the outbound call. If a UAS 223 supports trunk groups but is not configured with the particular trunk 224 group identified in the R-URI, it SHOULD not use any other trunk 225 group other than the one requested. 227 A UAC that initiates a call and supports this draft MAY include the 228 trunk group in the Contact header. If it does so, the trunk group in 229 the Contact header represents the originating trunk group. 230 Subsequent requests destined to that UAC MUST copy the trunk group 231 from the Contact header into the R-URI. Note that a Contact URI MUST 232 be a sip URI, thus, what appears in the Contact header is a 233 SIP-translation of the tel URI, complete with the trunk group 234 information. 236 Arguably, the originating trunk group can be part of the From URI. 237 However, semantically, the URI in a From header is an abstract 238 identifier which represents the resource thus identified on a 239 long-term basis. The presence of a trunk group, on the other 240 hand, signifies a binding that is valid for the duration of the 241 session only; a trunk group has no significance once the session 242 is over. Thus, the Contact URI is the best place to impart this 243 information since it has exactly those semantics. 245 5. Reference architecture 247 Consider Figure 1, which depicts a SIP proxy in a routing 248 relationship with three gateways in its domain, GW1, GW2, and GW3. 249 Among other sources of request arrival (not shown in Figure) at the 250 proxy is GW1. Gateways GW2 and GW3 are used as egress gateways from 251 the domain. GW2 has two trunk groups configured, TG2-1 and TG2-2. 252 GW3 has only one trunk group configured TG3-1. 254 +-----+ TG2-1 255 | |--------> To 256 TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN 257 From ----->| | | SIP | | | |--------> 258 PSTN | GW1 |--->| Proxy |-----+ +-----+ 259 ----->| | +-------+ | +-----+ TG3-1 260 +-----+ | | |--------> To 261 +---->| GW3 | PSTN 262 | |--------> 263 +-----+ 264 Figure 1: Reference architecture 266 On requests arriving to the proxy from GW1, the proxy will have 267 access to the trunk group TG1-1 if the request arrived on that 268 particular trunk. If the receiving gateway (GW1, in this case) wants 269 to propagate the ingress trunk group to the proxy, it MUST arrange 270 for the trunk group to appear in the Contact header of the SIP 271 request destined to the proxy. 273 The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is 274 assumed that the proxy has access to a routing table for GW2 and GW3 275 which includes the appropriate trunk groups to use when sending a 276 call to the PSTN (exactly how this table is constructed is out of 277 scope for this draft; [7] is one way to do so, a manually created and 278 maintained routing table is another). When the proxy sends a request 279 to either of the egress gateways, and the gateway routing table is so 280 configured that a trunk group is required by the gateway, the proxy 281 MUST arrange for the trunk group to appear in the SIP R-URI of the 282 request destined to that gateway. 284 6. Trunk group identifier: ABNF and examples 286 The ABNF syntax [2] for a trunk group identifier is given below and 287 extends the "par" production rule of the tel URI defined in [5]: 289 par = parameter / extension / isdn-subaddress / trunk-group 291 trunk-group = ";tgrp=" trunk-group-label 292 trunk-group-label = *1( unreserved / escaped / 293 trunk-group-unreserved ) 294 trunk-group-unreserved = "/" / "&" / "+" / "$" 296 trunk-group-unreserved is the intersection of param-unreserved 297 defined in [5] and user-unreserved defined in [3]. Since the 298 trunk group is an extension to the tel URI and will end up as the 299 user portion of a SIP URI, the ABNF for it has to ensure that it 300 can be adequately representated in both the constructs. 302 Examples: 304 tel:+15555551212;tgrp=tg55;phone-context=telco.example.com 305 tel:0216;tgrp=TG-1;phone-context=+1-555-555 307 The example URIs above extends the tel URI with a trunk group 308 identifier. Transforming these "tel" URI to "sip" URIs yields, 309 respectively: 311 sip:+15555551212;tgrp=tg55;phone-context=telco.example.com@isp.example.net 312 sip:0216;tgrp=TG-1;phone-context=+1-555-555@isp.example.net 314 7. Example call flows 316 7.1 Trunk group in a Contact header 318 This call flow depicts a gateway accepting a call from the PSTN and 319 conversing with its SIP proxy in order to further route the call 320 (F1). At some later time after the call has been established, the 321 gateway receives a BYE (F2) to tear down the call (note the R-URI in 322 the BYE). 324 PSTN Ingress Proxy 325 Gateway 326 | | | 327 |Call Request | | 328 +------------->| | 329 | +---F1----->| 330 ... ... ... 331 | | 332 | |<----F2--- 334 F1: 335 INVITE sip:40216@isp.example.net SIP/2.0 336 ... 337 Contact: 338 ... 340 F2: 341 BYE sip:40216;tgrp=tg55;phone-context=isp.example.net@igwy.isp.example.net 342 ... 344 7.2 Trunk group in the R-URI 346 This call flow depicts a proxy sending a request to a gateway with a 347 particular trunk group (F1). The gateway sends the request to the 348 PSTN; when the callee picks up the phone, a 200 OK is generated 349 towards the UAC (F2). Note the Contact of the 200 OK; it contains 350 the trunk group information. Subsequent requests from the UAC will 351 contain this URI as the R-URI. 353 UAC Proxy Egress 354 Gateway 355 | | | 356 |Call Request | | 357 +------------->| | 358 | +---F1------>| 359 | | |---> Interface with PSTN and 360 | | | received Answer Complete Message (ACM) 361 | +<-------F2--+ 362 | | | 363 ... ... ... 365 F1: 366 INVITE sip:+15555551212;tgrp=TG2-1;phone-context=isp.example.net@egwy.isp.example.net SIP/2.0 367 ... 368 F2: 369 SIP/2.0 200 OK 370 ... 371 Contact: 373 8. Security considerations 375 The extension defined in this document does not add any additional 376 security concerns beyond those already enumerated in [3] . The trunk 377 group information is carried in Request-URIs and Contact headers; it 378 is simply a modifier of an address, and the trust imparted to that 379 address is not affected by such a modifier. The privacy information 380 revealed with trunk groups does not generally reveal much information 381 about a particular (human) user. It does, however, reveal two pieces 382 of potentially private information which may be considered sensitive 383 by carriers. First, it may reveal how a carrier may be performing 384 least-cost routing and peering; and secondly, it does introduce an 385 additional means for network topology and information of a carrier. 386 If revealing this information is considered a privacy concern by a 387 carrier, it should take precautions to hide it. 389 9. IANA considerations 391 Section 9 of [5] creates a registry for tel URI parameters. This 392 document updates the registry with the following entry: 393 Parameter name: tgrp 394 Description: A trunk group on which an incoming call was received 395 at an ingress gateway or a trunk group on which an outgoing call 396 should be placed at an egress gateway. 397 This parameter is not mandatory. 398 Syntax restrictions: Details on the syntax are explained in RFC 399 AAAA. A phone-context parameter must occur in any tel URL that 400 contains a tgrp parameter. 401 Reference: RFC AAAA 402 [Note to RFC editor: Please replace AAAA with the RFC number 403 assigned to this document.] 405 10. Acknowledgments 407 The authors would like to acknowledge the efforts of all the 408 participants in the SIPPING and IPTEL working group. Special thanks 409 to John Hearty, Alan Johnston, Rohan Mahy, Mike Pierce, Adam Roach, 410 Jonathan Rosenberg, Bryan Byerly, Dave Oran, Tom Taylor, and Al 411 Varney for insightful discussions and comments. 413 11. Changes 415 11.1 Changes from trunk-group-00 416 1. Changed tgrp=local syntax. 417 2. Introduction of "phone-context" parameter. 418 3. Redid the Examples section and added an architecture diagram. 420 Normative References 422 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 423 Levels", BCP 14, RFC 2119, March 1997. 425 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 426 Specifications: ABNF", RFC 2234, November 1997. 428 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 429 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 430 Session Initiation Protocol", RFC 3261, June 2002. 432 [4] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 433 2000. 435 [5] Schulzrinne, H. and A. Vaha-Sipila, "The tel URI for Telephone 436 Calls", draft-ietf-iptel-rfc2806bis-02 (work in progress), July 437 2003. 439 Informative References 441 [6] "Bellcore Notes on the Network", Telcordia SR2275, Dec 1997, 442 . 444 [7] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H. and D. Shah, 445 "A Telephony Gateway REgistration Protocol (TGREP)", 446 draft-ietf-iptel-tgrep-02.txt (work in progress), December 2003. 448 Authors' Addresses 450 Vijay Gurbani 451 Lucent Technologies 452 2000 Lucent Lane 453 Rm 6G-440 454 Naperville, IL 60566 455 USA 457 Phone: +1 630 224 0216 458 EMail: vkg@lucent.com 460 Cullen Jennings 461 Cisco Systems 462 170 West Tasman Drive 463 Mailstop SJC-21/3 464 San Jose, CA 95134 465 USA 467 Phone: +1 408 421 9990 468 EMail: fluffy@cisco.com 470 Jon Peterson 471 NeuStar 472 1800 Sutter St. 473 Suite 570 474 Concord, CA 94520 475 USA 477 Phone: +1 925 363 8720 478 EMail: jon.peterson@neustar.biz 480 Intellectual Property Statement 482 The IETF takes no position regarding the validity or scope of any 483 intellectual property or other rights that might be claimed to 484 pertain to the implementation or use of the technology described in 485 this document or the extent to which any license under such rights 486 might or might not be available; neither does it represent that it 487 has made any effort to identify any such rights. Information on the 488 IETF's procedures with respect to rights in standards-track and 489 standards-related documentation can be found in BCP-11. Copies of 490 claims of rights made available for publication and any assurances of 491 licenses to be made available, or the result of an attempt made to 492 obtain a general license or permission for the use of such 493 proprietary rights by implementors or users of this specification can 494 be obtained from the IETF Secretariat. 496 The IETF invites any interested party to bring to its attention any 497 copyrights, patents or patent applications, or other proprietary 498 rights which may cover technology that may be required to practice 499 this standard. Please address the information to the IETF Executive 500 Director. 502 Full Copyright Statement 504 Copyright (C) The Internet Society (2004). All Rights Reserved. 506 This document and translations of it may be copied and furnished to 507 others, and derivative works that comment on or otherwise explain it 508 or assist in its implementation may be prepared, copied, published 509 and distributed, in whole or in part, without restriction of any 510 kind, provided that the above copyright notice and this paragraph are 511 included on all such copies and derivative works. However, this 512 document itself may not be modified in any way, such as by removing 513 the copyright notice or references to the Internet Society or other 514 Internet organizations, except as needed for the purpose of 515 developing Internet standards in which case the procedures for 516 copyrights defined in the Internet Standards process must be 517 followed, or as required to translate it into languages other than 518 English. 520 The limited permissions granted above are perpetual and will not be 521 revoked by the Internet Society or its successors or assignees. 523 This document and the information contained herein is provided on an 524 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 525 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 526 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 527 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 528 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Acknowledgment 532 Funding for the RFC Editor function is currently provided by the 533 Internet Society.