idnits 2.17.1 draft-ietf-iptel-trunk-group-00.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 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 120: '... REQ 1: Trunk group information MUST be carried in the "tel" URI [2]....' RFC 2119 keyword, line 145: '...ns, a name space MUST be defined which...' RFC 2119 keyword, line 152: '... and destination trunk group SHOULD be...' RFC 2119 keyword, line 181: '...tined to that UA MUST copy the trunk g...' RFC 2119 keyword, line 214: '...eir trunk groups MUST register a globa...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '2' is mentioned on line 315, but not defined == Missing Reference: '1' is mentioned on line 310, but not defined == Missing Reference: '3' is mentioned on line 318, but not defined Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT IPTEL WG 3 October 2002 Vijay K. Gurbani 4 Expires: April 2003 Lucent Technologies, Inc. 5 Cullen Jennings 6 Cisco Systems, Inc. 7 Jon Peterson 8 NeuStar 10 Document: draft-ietf-iptel-trunk-group-00.txt 12 Representing trunk groups in sip/tel Uniform Resource Identifiers (URIs) 14 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 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 35 This document describes a standardized mechanism to convey trunk 36 group- related information in SIP and TEL URIs. An extension to the 37 "tel" URI is defined for this purpose. 39 1 Problem 41 Currently, there isn't any standardized manner of transporting 42 trunk-groups between Internet signaling entities. This leads to 43 ambiguity on at least two fronts: 45 (1) Positional ambiguity: A SIP proxy that wants to send a call to 46 an egress VoIP gateway may insert the trunk-group as a parameter 47 in the user portion of the Request-URI (R-URI), or it may insert 48 it as a parameter to the R-URI itself. This ambiguity persists in 50 Representing trunk groups in sip/tel URIs October 2002 52 the reverse direction as well, that is, when an ingress VoIP 53 gateway wants to send a incoming call notification to its default 54 outbound proxy. 56 (2) Semantic ambiguity: There isn't any standardized grammar to 57 represent trunk groups, leading to the choice of ad hoc names and 58 values. 60 VoIP routing entities in the Internet, such as SIP proxies, may be 61 interested in using trunk-group information for normal operations. 62 To that extent, any standards-driven requirements will enable proxies 63 from one vendor to interoperate with gateways from yet another 64 vendor. Absence such guidelines, inter-operability will suffer as a 65 proxy vendor must conform to the expectations of a gateway as to 66 where it expects trunk-group information to be present (and vice 67 versa). 69 The aim of this I-D is to outline how to structure and represent the 70 trunk group information in URIs. The next section contains 71 definitions for trunks, trunk groups and presents a reference 72 architecture to aid in the discussion that follows. Section 3 73 contains the various issues we have identified thus far and derives 74 requirements from these. It also provides recommendations on how to 75 meet the requirements. Section 4 provides the ABNF and examples for 76 a trunk group identifier. Section 5 has a call flow, and section 6 77 contains security considerations. 79 2 Introduction 81 2.1 Definitions 83 Before we take the discussion of trunks any further, we must define 84 both a trunk and a trunk group and explain the difference between the 85 two. The following definitions are taken from [4]. 87 Trunk: In a network, a communication path connecting two switching 88 systems used in the establishment of an end-to-end connection. 89 In selected applications, it may have both its terminations in 90 the same switching system. 92 Trunk Group: A set of trunks, traffic engineered as a unit, for 93 the establishment of connections within or between switching 94 systems in which all of the paths are interchangeable except 95 where subgrouped. 97 Since the introduction of ubiquitous digital trunking, which resulted 98 in the allocation of DS0s between end offices in minimum groups of 24 99 (in North America), it has become common to refer to bundles of DS0s 101 Representing trunk groups in sip/tel URIs October 2002 103 as a trunk. Strictly speaking, however, a trunk is a single DS0 104 between two PSTN end offices - however, for the purposes of this 105 document, the PSTN interface of a gateway acts effectively as an end 106 office (i.e. if the gateway interfaces with SS7, it has its own SS7 107 point code, and so on). A trunk group, then, is a bundle of DS0s 108 (that need not be numerically contiguous in an SS7 Trunk Circuit 109 Identification Code (TCIC) numbering scheme) which are grouped under 110 a common administrative policy for routing. 112 2.2 Architecture 114 116 3 Issues 118 3.1 "sip" URI or "tel" URI? 120 REQ 1: Trunk group information MUST be carried in the "tel" URI [2]. 122 The trunk group information can be carried in either the "sip" URI 123 [1] or the "tel" URI [2, 3]. Since trunks groups are intimately 124 associated with the PSTN (Public Switched Telephone Network), it 125 seems reasonable to define them as extensions to the "tel" URI (any 126 SIP request that goes to a gateway could reasonably be expected to 127 have a tel URL, in whole or in part, in its R-U anyway). 128 Furthermore, using the tel URL also allows this format to be re-used 129 by non-SIP VoIP protocols (which could include anything from MGCP or 130 Megaco to H.323, if the proper IEs are created). 132 Finally, once the trunk-group is defined for a "tel" URI, the 133 normative procedures of Section 19.1.6 in [1] can be used to derive 134 an equivalent "sip" URI from a "tel" URI, complete with the trunk- 135 group parameter. 137 3.2 Trunk-group namespace: global or local? 139 Under normal operations, trunk groups have meaning only within an 140 administrative domain (i.e. local scope). However, to prevent 141 inadvertent cross-domain trunk group collisions (which, given 142 Murphy's law, will happen), a global scope appears to be useful. 144 REQ 2: To prevent inadverdent inter-domain trunk group naming 145 collisions, a name space MUST be defined which must be flexible 146 enough to both accomodate local naming conventions and provide global 147 naming semantics. 149 3.3 Originating trunk group and terminating trunk group 150 Representing trunk groups in sip/tel URIs October 2002 152 REQ 3: Originating trunk group and destination trunk group SHOULD be 153 able to appear separately and concurrently in a SIP message. 155 SIP routing entities can make informed routing decisions based on 156 either the originating or the terminating trunk groups. Thus a 157 requirement that both of these trunk groups need to be carried in SIP 158 requests. Instead of having two parameters, one for the originating 159 trunk group and the other for a terminating trunk group, the 160 placement of the trunk group parameter in a SIP Contact header or the 161 R-URI, respectively, signifies the intent. 163 REQ 4: SIP network intermediaries (proxy server and redirect servers) 164 should be able to add the destination trunk group attribute to SIP 165 sessions as a route is selected for a call. 167 If the trunk group parameter appears in a R-URI of a request, it 168 represents the destination trunk group. 170 This is consistent with using the R-URI as a routing 171 element; SIP routing entities may use the trunk group 172 parameter in the R-URI to make intelligent routing 173 decisions. Furthermore, this also satisfies REQ 4, since 174 a SIP network intermediary can modify the R-URI to 175 include the trunk group information. 177 If the trunk group parameter appears in a Contact header of a request 178 establishing a session (for the purpose of this I-D, that request is 179 an INVITE only), then it represents the trunk group that a UAC is 180 using for that dialog (originating trunk group). Subsequent requests 181 destined to that UA MUST copy the trunk group from the Contact header 182 into the R-URI. 184 Arguably, the originating trunk group can be part of the 185 From URI. However, semantically, the URI in a From 186 header is an abstract identifier which represents the 187 resource thus identified on a long-term basis. The 188 presence of a trunk group, on the other hand, signifies a 189 binding that is valid for the duration of the session 190 only; a trunk group has no significance once the session 191 is over. Thus, the Contact URI is the best place to 192 impart this information since it has exactly those 193 semantics. 195 4 Trunk group identifier: ABNF and examples 197 The syntax for a trunk group identifier is as follows: 199 trunk-group = "tgrp" EQUAL trunk-group-token 201 Representing trunk groups in sip/tel URIs October 2002 203 trunk-group-token = trunk-group-namespace "=" trunk-group-label 204 trunk-group-namespace = "local" / trunk-group-namespace-name 205 trunk-group-namespace-name = *1(unreserved / escaped / 206 trunk-group-unreserved ) 207 trunk-group-label = *1( unreserved / escaped / 208 trunk-group-unreserved / "=" ) 209 trunk-group-unreserved = "&" / "+" / "$" / "," / "?" / "/" 211 This I-D defines a "local" namespace for trunk group names having 212 local significance only (i.e. the name is valid for a particular 213 administrative domain). Organizations that need a global namespace 214 for their trunk groups MUST register a global namespace string with 215 IANA, thus guaranteeing uniqueness for the namespace. 217 Example: tel:+14085551212;tgrp=local=tg55/3 219 The example URI above extends the tel URI with a trunk group 220 identifier having local significance only. Transforming this "tel" 221 URI to a "sip" URI yields: 223 sip:+14085551212;tgrp=local=tg55/3@someprovider.il.us 225 5 Example call flows 227 The following call flow depicts a call request arriving at a SIP 228 proxy through a PSTN gateway on a certain trunk group. The gateway 229 treats the trunk group over which the call arrives as an originating 230 trunk group and stores this information in the Contact header (F1). 231 It then formats and sends an INVITE request to its controlling proxy 232 for further routing (F1). The proxy chooses an appropriate next hop 233 server (which may be yet another gateway) and modifies the R-URI, 234 adding a destination trunk group before sending it downstream (F2). 236 After the session has been established, the UA playing the part of 237 the UAS during session establishment sends a BYE request to teardown 238 the session (F3). Note that the R-URI of this request is the Contact 239 header from the INVITE request, complete with the trunk group 240 parameter. 242 Ingress Next downstream 243 PSTN Gateway Proxy SIP server 244 | | | | 245 | Call Request | | | 246 +------------->| F1 | | 247 | +--------------->| F2 | 248 | | +------------->| 249 ... ... ... ... 251 Representing trunk groups in sip/tel URIs October 2002 253 | | | F3 | 254 | | |<-------------+ 255 | | | | 257 F1: 259 INVITE sip:+12025551212@someprovider.il.us SIP/2.0 260 ... 261 Contact: 263 F2: 265 INVITE sip:+12025551212;tgrp=local=tg89@UA.someprovider.il.us SIP/2.0 266 ... 267 Contact: 269 F3: 270 BYE sip:gateway1.someprovider.il.us;tgrp=local=1001BSTAOMA01MN SIP/2.0 271 ... 273 6 Security considerations 275 The extension defined in this I-D does not add any additional 276 security concerns beyond the normal SIP one. The trunk group 277 information is carried in Request-URIs and Conatct headers; it is 278 simply a modifier of an address, and the trust imparted to that 279 address is not affected by such a modifier. It does, however, 280 introduce an additional means for network topology and information 281 about which trunks a domain uses to be propagated beyond that domain. 282 If this is a privacy concern, then the domain should take precautions 283 to hide that information before it leaves their trust boundary. 285 7 IANA considerations 287 289 8 Acknowledgments 291 The authors would like to acknowledge the efforts of all the 292 participants in the SIPPING and IPTEL working group. Special thanks 293 to John Hearty, Alan Johnston, Rohan Mahy, Mike Pierce, Adam Roach, 294 Jonathan Rosenberg, Tom Taylor, and Al Varney for insightful 295 discussions and comments. 297 AUTHORS' ADDRESSES 299 Vijay K. Gurbani Cullen Jennings 301 Representing trunk groups in sip/tel URIs October 2002 303 Email: vkg@lucent.com Email: fluffy@cisco.com 305 Jon Peterson 306 jon.peterson@neustar.biz 308 Normative References: 310 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 311 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 312 Session Initiation Protocol", IETF RFC 3216, June 2002, 313 315 [2] A. Vaha-Sipila, "URLs for Telephone Calls", IETF RFC 2806, 316 April 2000, 318 [3] H. Sculzrinne, A. Vaha-Sipila, "The tel URI for Telephone 319 Calls", IETF Internet-Draft, Expires December 2002, Work in 320 Progress, 322 Informative References 324 [4] Telcordia, "SR2275: Bellcore Notes on the Network", December 325 1997, . 327 FULL COPYRIGHT STATEMENT 329 "Copyright (C) The Internet Society (date). All Rights Reserved. This 330 document and translations of it may be copied and furnished to 331 others, and derivative works that comment on or otherwise explain it 332 or assist in its implementation may be prepared, copied, published 333 and distributed, in whole or in part, without restriction of any 334 kind, provided that the above copyright notice and this paragraph are 335 included on all such copies and derivative works. However, this 336 document itself may not be modified in any way, such as by removing 337 the copyright notice or references to the Internet Society or other 338 Internet organizations, except as needed for the purpose of 339 developing Internet standards in which case the procedures for 340 copyrights defined in the Internet Standards process must be 341 followed, or as required to translate it into followed, or as 342 required to translate it into languages other than English. 344 The limited permissions granted above are perpetual and will not be 345 revoked by the Internet Society or its successors or assigns. 347 This document and the information contained herein is provided on an 348 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 350 Representing trunk groups in sip/tel URIs October 2002 352 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 353 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 354 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 355 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.