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