IPTEL WG V. Gurbani Internet-Draft Lucent Technologies Expires: April 23, 2005 C. Jennings Cisco Systems J. Peterson NeuStar October 23, 2004 Representing trunk groups in tel/sip URIs draft-ietf-iptel-trunk-group-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 23, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a standardized mechanism to convey trunk group- related information in SIP and TEL URIs. An extension to the "tel" URI is defined for this purpose. This work is being discussed on the iptel@ietf.org mailing list. Gurbani, et al. Expires April 23, 2005 [Page 1] Internet-Draft Trunk groups in tel/sip URIs October 2004 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem statement . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements and rationale . . . . . . . . . . . . . . . . . 4 4.1 sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 4 4.2 Trunk group namespace: global or local? . . . . . . . . . 5 4.3 Originating trunk group and terminating trunk group . . . 5 4.4 Intermediary processing of trunk groups . . . . . . . . . 5 5. Reference architecture . . . . . . . . . . . . . . . . . . . 6 6. Trunk group identifier: ABNF and examples . . . . . . . . . 7 7. Example call flows . . . . . . . . . . . . . . . . . . . . . 8 7.1 Trunk group in a Contact header . . . . . . . . . . . . . 8 7.2 Trunk group in the R-URI . . . . . . . . . . . . . . . . . 9 8. Security considerations . . . . . . . . . . . . . . . . . . 9 9. IANA considerations . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1 Changes from draft-ietf-trunk-group-01 . . . . . . . . . 10 11.2 Changes from trunk-group-00 . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1 Normative References . . . . . . . . . . . . . . . . . . . 10 12.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . 13 Gurbani, et al. Expires April 23, 2005 [Page 2] Internet-Draft Trunk groups in tel/sip URIs October 2004 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 2. Problem statement Currently, there isn't any standardized manner of transporting trunk-groups between Internet signaling entities. This leads to ambiguity on at least two fronts: 1. Positional ambiguity: A SIP proxy that wants to send a call to an egress VoIP gateway may insert the trunk-group as a parameter in the user portion of the Request-URI (R-URI), or it may insert it as a parameter to the R-URI itself. This ambiguity persists in the reverse direction as well, that is, when an ingress VoIP gateway wants to send a incoming call notification to its default outbound proxy. 2. Semantic ambiguity: The lack of any standardized grammar to represent trunk groups leads to the unfortunate choice of ad hoc names and values. VoIP routing entities in the Internet, such as SIP proxies, may be interested in using trunk-group information for normal operations. To that extent, any standards-driven requirements will enable proxies from one vendor to interoperate with gateways from yet another vendor. Absence such guidelines, inter-operability will suffer as a proxy vendor must conform to the expectations of a gateway as to where it expects trunk-group information to be present (and vice versa). The aim of this Internet draft is to outline how to structure and represent the trunk group information as an extension to the tel URI [5] in a standardized manner. 3. Definitions Before we take the discussion of trunks any further, we must define both a trunk and a trunk group and explain the difference between the two. The following definitions are taken from [6]. 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 Gurbani, et al. Expires April 23, 2005 [Page 3] Internet-Draft Trunk groups in tel/sip URIs October 2004 systems in which all of the paths are interchangeable except where subgrouped. 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 Public Switched Telephone Network (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 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 (TCIC) numbering scheme) which are grouped under a common administrative policy for routing. A SIP-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 terminate a particular PSTN phone number, the phone number itself is not sufficient enough 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. How the proxy picked a particular trunk group is outside the scope of this document (reference [7] provides one such way); once the trunk group has been decided upon, this document provides a standardized means to represent it. 4. Requirements and rationale 4.1 sip URI or tel URI? REQ 1: Trunk group information MUST be carried in the "tel" URI [5]. The trunk group information can be carried in either the "sip" URI [3] or the "tel" URI [4,5]. Since trunks groups are intimately associated with the PSTN (Public Switched Telephone Network), 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 URL, in whole or in part, in its R-U anyway). Furthermore, using the tel URL also allows this format to be re-used by non-SIP VoIP protocols (which could include anything from MGCP or Megaco to H.323, if the proper IEs are created). Finally, once the trunk-group is defined for a "tel" URI, the normative procedures of Section 19.1.6 in [3] can be used to derive an equivalent "sip" URI from a "tel" URI, complete with the trunk Gurbani, et al. Expires April 23, 2005 [Page 4] Internet-Draft Trunk groups in tel/sip URIs October 2004 group information. 4.2 Trunk group namespace: global or local? REQ 2: To prevent inadvertent inter-domain trunk group naming collisions, a name space MUST be defined which must be flexible enough to both accommodate local naming conventions and provide global naming semantics. Under normal operations, trunk groups have meaning only within an administrative domain (i.e. local scope). However, to prevent inadvertent cross-domain trunk group collisions (which, given Murphy's law, will happen), a global scope appears to be useful. The "phone-context" parameter of the tel URI is used to impose a namespace by specifying a domain where the trunk groups are understood. The use of the "phone-context" parameter in conjunction with this draft is mandatory; implementations choosing to include trunk groups in SIP signaling MUST be capable of parsing and generating the "phone-context" parameter of the tel URI. If a receiver of a SIP request is not the owner of the domain specified in the "phone-context", it MUST treat the trunk group as if it was not there. 4.3 Originating trunk group and terminating trunk group REQ 3: Originating trunk group and destination trunk group SHOULD be able to appear separately and concurrently in a SIP message. SIP routing entities can make informed routing decisions based on either the originating or the terminating trunk groups. Thus a requirement that both of these trunk groups need to be carried in SIP requests. Instead of having two parameters, one for the originating trunk group and the other for a terminating trunk group, the placement of the trunk group parameter in a SIP Contact header or the R-URI, respectively, signifies the intent. 4.4 Intermediary processing of trunk groups REQ 4: SIP network intermediaries (proxy server and redirect servers) should be able to add the destination trunk group attribute to SIP sessions as a route is selected for a call. If the trunk group parameter appears in a R-URI of a request, it represents the destination trunk group. Gurbani, et al. Expires April 23, 2005 [Page 5] Internet-Draft Trunk groups in tel/sip URIs October 2004 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 information. 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. A UAC that initiates a call and supports this draft MAY include the trunk group in the Contact header. If it does so, the trunk group in the Contact header represents the originating trunk group. Subsequent requests destined to that UAC MUST copy the trunk group from the Contact header into the R-URI. Note that a Contact URI MUST be a sip URI, thus, what appears in the Contact header is a SIP-translation of the tel URI, complete with the trunk group information. Arguably, the originating trunk group can be part of the From URI. However, semantically, the URI in a From header is an abstract identifier which 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. 5. Reference architecture Consider Figure 1, which depicts a SIP proxy in a routing relationship with three gateways in its domain, GW1, GW2, and GW3. Among other sources of request arrival (not shown in Figure) at the proxy is 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 has only one trunk group configured TG3-1. Gurbani, et al. Expires April 23, 2005 [Page 6] Internet-Draft Trunk groups in tel/sip URIs October 2004 +-----+ TG2-1 | |--------> To TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN From ----->| | | SIP | | | |--------> PSTN | GW1 |--->| Proxy |-----+ +-----+ ----->| | +-------+ | +-----+ TG3-1 +-----+ | | |--------> To +---->| GW3 | PSTN | |--------> +-----+ Figure 1: Reference architecture On requests arriving to the proxy from GW1, the proxy will have access to the trunk group TG1-1 if the request arrived on that particular trunk. If the receiving gateway (GW1, in this case) wants 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 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 which 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 draft; [7] 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. 6. Trunk group identifier: ABNF and examples The ABNF syntax [2] for a trunk group identifier is given below and extends the "par" production rule of the tel URI defined in [5]: par = parameter / extension / isdn-subaddress / trunk-group trunk-group = ";tgrp=" trunk-group-label trunk-group-label = *1( unreserved / escaped / trunk-group-unreserved ) trunk-group-unreserved = "/" / "&" / "+" / "$" trunk-group-unreserved is the intersection of param-unreserved defined in [5] and user-unreserved defined in [3]. Since the trunk group is an extension to the tel URI and will end up as the Gurbani, et al. Expires April 23, 2005 [Page 7] Internet-Draft Trunk groups in tel/sip URIs October 2004 user portion of a SIP URI, the ABNF for it has to ensure that it can be adequately representated in both the constructs. Examples: tel:+15555551212;tgrp=tg55;phone-context=telco.example.com tel:0216;tgrp=TG-1;phone-context=+1-555-555 The example URIs above extends the tel URI with a trunk group identifier. Transforming these "tel" URI to "sip" URIs yields, respectively: sip:+15555551212;tgrp=tg55;phone-context=telco.example.com@isp.example.net sip:0216;tgrp=TG-1;phone-context=+1-555-555@isp.example.net 7. Example call flows 7.1 Trunk group in a Contact header This call flow depicts a gateway accepting a call from the PSTN and conversing with its SIP proxy in order to further route the call (F1). At some later time after the call has been established, the gateway receives a BYE (F2) to tear down the call (note the R-URI in the BYE). PSTN Ingress Proxy Gateway | | | |Call Request | | +------------->| | | +---F1----->| ... ... ... | | | |<----F2--- F1: INVITE sip:40216@isp.example.net SIP/2.0 ... Contact: ... F2: BYE sip:40216;tgrp=tg55;phone-context=isp.example.net@igwy.isp.example.net Gurbani, et al. Expires April 23, 2005 [Page 8] Internet-Draft Trunk groups in tel/sip URIs October 2004 ... 7.2 Trunk group in the R-URI This call flow depicts a proxy sending a request to a gateway with a particular trunk group (F1). The gateway sends the request to the PSTN; when the callee picks up the phone, a 200 OK is generated towards the UAC (F2). Note the Contact of the 200 OK; it contains the trunk group information. Subsequent requests from the UAC will contain this URI as the R-URI. UAC Proxy Egress Gateway | | | |Call Request | | +------------->| | | +---F1------>| | | |---> Interface with PSTN and | | | received Answer Complete Message (ACM) | +<-------F2--+ | | | ... ... ... F1: INVITE sip:+15555551212;tgrp=TG2-1;phone-context=isp.example.net@egwy.isp.example.net SIP/2.0 ... F2: SIP/2.0 200 OK ... Contact: 8. Security considerations The extension defined in this document does not add any additional security concerns beyond those already enumerated in [3] . The trunk group information is carried in Request-URIs and Contact headers; it is simply a modifier of an address, and the trust imparted to that address is not affected by such a modifier. The privacy information revealed with trunk groups does not generally reveal much information about a particular (human) user. It does, however, reveal two pieces of potentially private information which 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. If revealing this information is considered a privacy concern by a Gurbani, et al. Expires April 23, 2005 [Page 9] Internet-Draft Trunk groups in tel/sip URIs October 2004 carrier, it should take precautions to hide it. 9. IANA considerations Section 9 of [5] creates a registry for tel URI parameters. This document updates the registry with the following entry: Parameter name: tgrp Description: A trunk group on which an incoming call was received at an ingress gateway or a trunk group on which an outgoing call should be placed at an egress gateway. This parameter is not mandatory. Syntax restrictions: Details on the syntax are explained in RFC AAAA. A phone-context parameter must occur in any tel URL that contains a tgrp parameter. Reference: RFC AAAA [Note to RFC editor: Please replace AAAA with the RFC number assigned to this document.] 10. Acknowledgments The authors would like to acknowledge the efforts of all the participants in the SIPPING and IPTEL working group. Special thanks to John Hearty, Alan Johnston, Rohan Mahy, Mike Pierce, Adam Roach, Jonathan Rosenberg, Bryan Byerly, Dave Oran, Tom Taylor, and Al Varney for insightful discussions and comments. 11. Changes 11.1 Changes from draft-ietf-trunk-group-01 1. Changed file name. 11.2 Changes from trunk-group-00 1. Changed tgrp=local syntax. 2. Introduction of "phone-context" parameter. 3. Redid the Examples section and added an architecture diagram. 12. References 12.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Gurbani, et al. Expires April 23, 2005 [Page 10] Internet-Draft Trunk groups in tel/sip URIs October 2004 Session Initiation Protocol", RFC 3261, June 2002. [4] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [5] Schulzrinne, H. and A. Vaha-Sipila, "The tel URI for Telephone Calls", draft-ietf-iptel-rfc2806bis-02 (work in progress), July 2003. 12.2 Informative References [6] "Bellcore Notes on the Network", Telcordia SR2275, Dec 1997, . [7] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H. and D. Shah, "A Telephony Gateway REgistration Protocol (TGREP)", draft-ietf-iptel-tgrep-02.txt (work in progress), December 2003. Authors' Addresses Vijay Gurbani Lucent Technologies 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566 USA Phone: +1 630 224 0216 EMail: vkg@lucent.com Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/3 San Jose, CA 95134 USA Phone: +1 408 421 9990 EMail: fluffy@cisco.com Gurbani, et al. Expires April 23, 2005 [Page 11] Internet-Draft Trunk groups in tel/sip URIs October 2004 Jon Peterson NeuStar 1800 Sutter St. Suite 570 Concord, CA 94520 USA Phone: +1 925 363 8720 EMail: jon.peterson@neustar.biz Gurbani, et al. Expires April 23, 2005 [Page 12] Internet-Draft Trunk groups in tel/sip URIs October 2004 Intellectual Property Statement 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 ietf-ipr@ietf.org. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gurbani, et al. Expires April 23, 2005 [Page 13]