Network Working Group V. Gurbani Request for Comments: 4904 Bell Laboratories, Alcatel-Lucent Category: Standards Track C. Jennings Cisco Systems June 2007 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThis document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose.
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements and Rationale . . . . . . . . . . . . . . . . . . 5 4.1. sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 5 4.2. Trunk Group Namespace: Global or Local? . . . . . . . . . 5 4.3. Originating Trunk Group and Terminating Trunk Group . . . 6 4.4. Intermediary Processing of Trunk Groups . . . . . . . . . 6 5. Trunk Group Identifier: ABNF and Examples . . . . . . . . . . 6 6. Normative Behavior of SIP Entities Using Trunk Groups . . . . 8 6.1. User Agent Client Behavior . . . . . . . . . . . . . . . . 9 6.2. User Agent Server Behavior . . . . . . . . . . . . . . . . 10 6.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10 7. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Reference Architecture . . . . . . . . . . . . . . . . . . 11 7.2. Basic Call Flow . . . . . . . . . . . . . . . . . . . . . 12 7.3. Inter-Domain Call Flow . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
5]). Trunk: In a network, a communication path connecting two switching systems used in the establishment of an end-to-end connection. In selected applications, it may have both its terminations in the same switching system. Trunk Group: A set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable. A single trunk group can be shared across multiple switches for redundancy purposes. Digital Signal 0 (DS0): Digital Signal X is a term for a series of standard digital transmission rates based on DS0, a transmission rate of 64 kbps (the bandwidth normally used for one telephone voice channel). The European E-carrier system of transmission also operates using the DS series as a base multiple. Since the introduction of ubiquitous digital trunking, which resulted in the allocation of DS0s between end offices in minimum groups of 24 (in North America), it has become common to refer to bundles of DS0s as a trunk. Strictly speaking, however, a trunk is a single DS0 between two PSTN end offices; however, for the purposes of this document, the PSTN interface of a gateway acts effectively as an end office (i.e., if the gateway interfaces with Signaling System 7 (SS7), it has its own SS7 point code, and so on). A trunk group, then, is a bundle of DS0s (that need not be numerically contiguous in an SS7 Trunk Circuit Identification Code numbering scheme) that are grouped under a common administrative policy for routing. A Session Initiation Protocol (SIP)  to PSTN gateway may have trunks that are connected to different carriers. It is entirely reasonable for a SIP proxy to choose -- based on factors not enumerated in this document -- which carrier a call is sent to when it proxies a session setup request to the gateway. Since multiple
carriers can transport a call to a particular phone number, the phone number itself is not sufficient to identify the carrier at the gateway. An additional piece of information in the form of a trunk group can be used to further pare down the choices at the gateway. As used in this document, trunks are necessarily tied to gateways, and a proxy that uses trunk groups during routing of the request to a particular gateway knows and controls which gateway the call will be routed to, and knows what trunking resources are present on that gateway. As another example, consider the case where an IP network is being used as a transit network between two PSTN networks. Here, a SIP proxy can apply the originating trunk group to its routing logic to ensure that the same ingress and egress carrier is chosen. How the proxy picked a particular trunk group is outside the scope of this document ( provides one such way); however, once trunk group has been decided upon, this document provides a standardized means to represent it in the signaling messages.
The aim of this specification is to outline how to structure and represent the trunk group parameters as an extension to the tel URI  in a standardized manner. RFC 2119 . 4]. The trunk group parameters can be carried in either the sip URI or the tel URI. Since trunk groups are intimately associated with the PSTN, it seems reasonable to define them as extensions to the tel URI (any SIP request that goes to a gateway could reasonably be expected to have a tel URI, in whole or in part, in its R-URI anyway). Furthermore, using the tel URI also allows this format to be reused by non-SIP VoIP protocols (which could include anything from MGCP or Megaco to H.323, if the proper information elements are created). Finally, once the trunk group is defined for a tel URI, the normative procedures of Section 19.1.6 of  can be used to derive an equivalent sip URI from a tel URI, complete with the trunk group parameters.
Note: At first glance, it would appear that the use of the tel URI's "phone-context" parameter provides a satisfactory means of imposing a namespace on a trunk group. The "phone-context" parameter identifies the scope of validity of a local telephone number. And therein lies the problem. Semantically, a "phone- context" tel URI parameter is applicable only to a local telephone number and not a global one (i.e., one preceded by a '+'). Trunk groups, on the other hand, may appear in local or global telephone numbers. Thus, what is needed is a new parameter with equivalent functionality of the "phone-context" parameter of the tel URI, but one that is equally applicable to local and global telephone numbers. 2] syntax for a trunk group identifier is given below and extends the "par" production rule of the tel URI defined in : par = parameter / extension / isdn-subaddress / trunk-group / trunk-context trunk-group = ";tgrp=" trunk-group-label trunk-context = ";trunk-context=" descriptor trunk-group-label = 1*( unreserved / escaped / trunk-group-unreserved ) trunk-group-unreserved = "/" / "&" / "+" / "$" descriptor is defined in . unreserved is defined in  and . escaped is defined in .
Trunk groups are identified by two parameters: "tgrp" and "trunk- context"; both parameters MUST be present in a tel URI to identify a trunk group. Collectively, these two parameters are called "trunk group parameters" in this specification. All implementations conforming to this specification MUST generate both of these parameters when using trunk groups. If an implementation receives a tel URI with only one of the "tgrp" or "trunk-context" parameter, it MUST act as if there were not any trunk group parameters present at all in that URI. Whether or not to further process such an URI is up to the discretion of the implementation; however, if a decision is made to process it, the implementation MUST act as if there were not any trunk group parameters present in the URI. The "trunk-context" parameter imposes a namespace on the trunk group by specifying a global number or any number of its leading digits (e.g., +33), or a domain name. Syntactically, it is modeled after the "phone-context" parameter of the tel URI , except that unlike the "phone-context" parameter, the "trunk-context" parameter can appear in either a local or global tel URI. Semantically, the "trunk-context" parameter establishes a scope of the trunk group specified in the "tgrp" parameter, i.e., whether it is valid at a single gateway, a set of gateways, or an entire domain managed by a service provider. The "trunk-context" can contain four discrete value types: 1. The value in the "trunk-context" literally identifies a host (a gateway), in which case, the trunk groups are scoped to the specific host. 2. The value in the "trunk-context" is a subdomain (e.g., "north.example.com"), which identifies a subset of the gateways in a domain across which the trunk groups are shared. 3. The value in the "trunk-context" is a service provider domain (e.g., "example.com"), which identifies all gateways in the specific domain. 4. The value in the "trunk-context" is a global number or any number of its leading digits; this is useful for provider-wide scoping and does not lend itself very well to specifying trunk groups across a gateway or a set of gateways.
For equivalency purposes, two URIs containing trunk group parameters are equivalent according to the base comparison rules of the URIs. The base comparison rules of a tel URI are specified in Section 4 of , and the base comparison rules of a sip URI are specified in Section 19.1.4 of . Examples: 1. Trunk group in a local number, with a phone-context parameter (line breaks added for readability): tel:5550100;phone-context=+1-630;tgrp=TG-1; trunk-context=example.com Transforming this tel URI to a sip URI yields: sip:5550100;phone-context=+1-630;tgrp=TG-1; email@example.com;user=phone 2. Trunk group in a global number, with a domain name trunk-context: tel:+16305550100;tgrp=TG-1;trunk-context=example.com Transforming this tel URI to a sip URI yields: sip:+16305550100;tgrp=TG-1; firstname.lastname@example.org;user=phone 3. Trunk group in a global number, with a number prefix trunk- context: tel:+16305550100;tgrp=TG-1;trunk-context=+1-630 Transforming this tel URI to a sip URI yields: sip:+16305550100;tgrp=TG-1; email@example.com;user=phone
Note: This is consistent with using the R-URI as a routing element; SIP routing entities may use the trunk group parameter in the R-URI to make intelligent routing decisions. Furthermore, this also satisfies REQ 4, since a SIP network intermediary can modify the R-URI to include the trunk group parameters. Conversely, the appearance of the trunk group parameters in the Contact header URI signifies the trunk group over which the call arrived on, i.e., the originating (or ingress) trunk group. Thus, the originating (or ingress) trunk group MUST appear in the Contact header of a SIP request. The behavior described in this section effectively addresses REQ 3. RFC 3261 , subsequent requests in the dialog towards this user agent will contain this Contact URI in the R-URI. Note that the user part of this URI, which contains the trunk group parameters, will be copied as a consequence of this processing. Note: Arguably, the originating trunk group can be part of the From URI. However, semantically, the URI in a From header is an abstract identifier that represents the resource thus identified on a long-term basis. The presence of a trunk group, on the other hand, signifies a binding that is valid for the duration of the session only; a trunk group has no significance once the session is over. Thus, the Contact URI is the best place to impart this information since it has exactly those semantics. If the UAC is aware of the routing topology, it MAY insert the destination trunk group parameters in the R-URI of the request. However, in most deployments, the UAC will use the services of a proxy to further route the request, and it will be up to the proxy to insert such parameters in the R-URI (see Section 6.3).
Sections 7.1 and 7.2 for an example). However, if destination trunk group parameters are already present in the R-URI, the proxy SHOULD NOT change them unless it has further authoritative information about the routing topology than the upstream client did when it originally inserted the trunk group parameters in the R-URI.
Depending on the specific situation, it is perfectly reasonable for a proxy not to insert the destination trunk group parameters in the R-URI. Consider, for instance, a proxy that understands the originating trunk group parameters and, in accordance with local policy, uses these to route the request to a destination other than a PSTN gateway. Figure 1, which depicts a SIP proxy in a routing relationship with three gateways in its domain, GW1, GW2, and GW3. Requests arrive at the SIP proxy through GW1. Gateways GW2 and GW3 are used as egress gateways from the domain. GW2 has two trunk groups configured, TG2-1 and TG2-2. GW3 also has two trunk groups configured, TG3-1 and TG2-2 (TG2-2 is shared between gateways GW2 and GW3). +-----+ TG2-1 | |--------> To TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN From ----->| | | SIP | | | |--------> PSTN | GW1 |--->| Proxy |-----+ +-----+ ----->| | +-------+ | +-----+ TG3-1 +-----+ | | |--------> To +---->| GW3 | TG2-2 PSTN | |--------> +-----+ Reference Architecture GW1 in Figure 1 is always cognizant of any requests that arrive over trunk group TG1-1. If it wishes to propagate the ingress trunk group to the proxy, it must arrange for the trunk group to appear in the Contact header of the SIP request destined to the proxy. The proxy will, in turn, propagate the ingress trunk group in the Contact header further downstream. The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is assumed that the proxy has access to a routing table for GW2 and GW3 that includes the appropriate trunk groups to use when sending a call to the PSTN (exactly how this table is constructed is out of scope for this specification;  is one way to do so, a manually created and maintained routing table is another). When the proxy sends a request to either of the egress gateways, and the gateway routing
table is so configured that a trunk group is required by the gateway, the proxy must arrange for the trunk group to appear in the SIP R-URI of the request destined to that gateway. Figure 1. Gateways GW1, GW2, and GW3, and the SIP proxy are assumed to be owned by a service provider whose domain is example.com. GW1 SIP Proxy GW2 From | | | PSTN-->| | | +---F1--------->| | | +---F2----------->| ... ... ... | | | Send to PSTN | | | --> and receive Answer | | | Complete Message ----------------------------------------- Call in progress ----------------------------------------- | | | | |<-----------F3---+ +<--------------+ | ... ... ... Basic Call Flow In the call flow below, certain headers and messages have been omitted for brevity. In F1, GW1 receives a call setup request from the PSTN over a certain trunk group. GW1 arranges for this trunk group to appear in the Contact header of the request destined to the SIP proxy. F1: INVITE sip:+firstname.lastname@example.org;user=phone SIP/2.0 ... Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1; email@example.com;user=phone> ... In F2, the SIP proxy translates the R-URI and adds a destination trunk group to the R-URI. The request is then sent to GW2.
F2: INVITE sip:+16305550100;tgrp=TG2-1; firstname.lastname@example.org;user=phone SIP/2.0 ... Record-Route: <sip:proxy.example.com;lr> Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1; email@example.com;user=phone> ... Once the call is established, either end can tear the call down. For illustrative purposes, F3 depicts GW2 tearing the call down. Note that the Contact from F1, including the trunk group parameters, is now the R-URI of the request. When GW1 gets this request, it can associate the call with the appropriate trunk group to deallocate resources. F3: BYE sip:0100;phone-context=example.com;tgrp=TG1-1; firstname.lastname@example.org;user=phone SIP/2.0 Route: <sip:proxy.example.com;lr> ... It is worth documenting the behavior when an incoming call from the PSTN is received at a gateway without a calling party number. Consider Figure 1, and assume that GW1 gets a call request from the PSTN without a calling party number. This is not an uncommon case, and may happen for a variety of reasons, including privacy and interworking between different signaling protocols before the request reached GW1. Under normal circumstances (i.e., instances where the calling party number is present in signaling), GW1 would derive a sip URI to insert into the Contact header. This sip URI will contain, as its user portion, the calling party number from the incoming SS7 signaling information. The trunk group parameters then becomes part of the user portion as discussed previously. If a gateway receives an incoming call where the calling party number is not available, it MUST create a tel URI containing a token that is generated locally and has local significance to the gateway. Details of generating such a token are implementation dependent; potential candidates include the gateway line number or port number where the call was accepted. This tel URI is subsequently converted to a sip URI to be inserted in the Contact header of the SIP request going downstream from the gateway.
Note: The tel scheme does not allow for an empty URI; thus, the global-number or local-number production rule of the tel URI  cannot contain an empty string. Consequently, the behavior in the above paragraph is mandated for cases where the incoming SS7 signaling message does not contain a calling party number. example.com example.net /-------------------------\ /-----------\ GW1 SIP Proxy 1 SIP Proxy 2 From | | | PSTN-->| | | +---F1--------->| | | +---F2----------->| | | | ... ... ... | +<--F3------------+ ... ... ... Inter-Domain Call Flow F1: INVITE sip:+email@example.com;user=phone SIP/2.0 ... Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1; firstname.lastname@example.org;user=phone> ... In F2, the SIP proxy executes its routing logic and re-targets the R-URI to refer to a resource in example.net domain. F2: INVITE sip:+email@example.com;user=phone SIP/2.0 ... Record-Route: <sip:proxy.example.com;lr> Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1; firstname.lastname@example.org;user=phone> ...
In F3, the example.net domain sends a request in the backwards direction. The example.net domain does not interpret the trunk group parameters in the Contact header since they do not belong to that domain. The Contact header, including the trunk group parameters, is simply used as the R-URI in a subsequent request going towards the example.com domain. F3: BYE sip:0100;phone-context=example.com;tgrp=TG1-1; email@example.com;user=phone Route: <sip:proxy.example.com;lr> ... 3]. The Security Session Initiation Protocol Secure (SIPS) scheme and the resulting Transport Layer Security (TLS) mechanism SHOULD be used to provide integrity protection, thereby mitigating these attacks. A question naturally arises: how does the receiver determine whether the sender is authorized to use the resources represented by the trunk group parameters? There are two cases to consider: intra- domain signaling exchange as discussed in Section 7.2, and inter- domain signaling exchange as discussed in Section 7.3.
In the intra-domain case, a proxy receiving trunk group parameters from an upstream user agent (typically a gateway) should only accept them using the SIPS URI scheme; furthermore, it should use HTTP Digest to challenge and properly authorize the sender. A user agent (or a gateway) receiving the trunk group parameters from a proxy will not be able to challenge the proxy using HTTP Digest, but it should examine the X.509 certificate of the proxy to determine whether the proxy is authorized to insert the resources represented by the trunk group parameters into the signaling flow. In the inter-domain case, a receiving proxy may depend on the identity stored in the X.509 certificate of the sending proxy to determine whether the sender is authorized to insert the resources represented by the trunk group parameters in the signaling message. Because of these considerations, the trunk group parameters are only applicable within a set of network nodes among which there is mutual trust. If a node receives a call signaling request from an upstream node that it does not trust, it SHOULD remove the trunk group parameters. The privacy information revealed with a trunk group does not generally advertise much information about a particular (human) user. It does, however, convey two pieces of potentially private information that may be considered sensitive by carriers. First, it may reveal how a carrier may be performing least-cost routing and peering; and secondly, it does introduce an additional means for network topology and information of a carrier. It is up to the discretionary judgment of the carrier if it wants to include the trunk group parameters and reveal potentially sensitive information on its network topology. If confidentiality is desired, TLS SHOULD be used to protect this information while in transit. 7].
Jon Peterson was also instrumental in the original formulation of this work. Alex Mayrhofer brought up the issue of lexicographic ordering of tel URI parameters when it is converted to a sip or sips URI. Ted Hardie, Sam Hartman, and Russ Housley took pains to ensure that the text around URI comparisons and security considerations was as unambiguous as possible.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.  Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966, December 2004.  "Telcordia Notes on the Network", Telcordia SR-2275, Issue 04, October 2000, <http://telecom-info.telcordia.com>.  Bangalore, M., Kumar, R., Rosenberg, J., Salama, H., and D. Shah, "A Telephony Gateway REgistration Protocol (TGREP)", Work in Progress, January 2007.  Jennings, C. and V. Gurbani, "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", Work in Progress, December 2006.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.