ENUM D. Malas, Ed. Internet-Draft CableLabs Intended status: Informational T. Creighton Expires: September 5, 2009 Comcast March 4, 2009 Trunk Group Use in ENUM draft-malas-enum-trunk-sip-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 September 5, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document concludes that incorporating trunk group parameters into an Electronic Number (ENUM) response for the Session Initiation Malas & Creighton Expires September 5, 2009 [Page 1] Internet-Draft Trunk Group Use in ENUM March 2009 Protocol (SIP) [RFC3261] service URI is a more effective approach compared to defining a new ENUM service type for a 'trunk'. Upon further review of the existing ENUM trunk group draft [I-D.ietf-enum-trunkgroup] and practical operator experience, this draft recommends the use of the current trunk group contexts as defined in [RFC4904] as additional parameters in the E2U+SIP enumservice NAPTR record [RFC3403] URI. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.2. Rationale for Trunk use in the 'E2U+SIP' enumservice URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Malas & Creighton Expires September 5, 2009 [Page 2] Internet-Draft Trunk Group Use in ENUM March 2009 1. Introduction ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms E.164 numbers into domain names and then uses DNS [RFC1034] features such as delegation through NS records, and the use of Naming Authority Pointer (NAPTR) records, to look up the communication services available for a specific domain name. This draft refers to the look up of the SIP enumservice NAPTR record type. The use of trunk groups is well described in [RFC4904] for IP to PSTN gateway scenarios. In addition to this trunk group usage, more and more SIP service providers (SSPs) are defining trunk groups as SIP IP network end-points. This can be thought of as a SIP trunk group. While there have been other attempts to define a SIP trunk group, in this draft, they are simply referred to as the numerical or contextual representation of the IP address of a SIP UA or proxy. It is becoming a popular use in SIP peering for determining for a peer's ingress SBE or SF an appropriate egress SBE or SF to exit the SSPs network. One method for identifying a trunk group in ENUM is defined in the work in progress [I-D.ietf-enum-trunkgroup]. This draft defines a new service type "trunk". This new service type returns a tel URI containing the "tgrp" and "trunk context" parameters that can then be carried in IP signaling to control trunk group selection in downstream gateways. While this new ENUM service type may work in production environments, it places an unnecessary burden on ENUM clients to either assume a trunk group exists by always initiating a second ENUM query for the "trunk" service type, or evaluating the entire list of NAPTRs in the response for additional service types, potentially beyond what it originally queried for. Ultimately, this draft concludes there is no need to define a new 'trunk' service type, because the trunk group is already defined as a URI parameter in [RFC4904] and is not a new service such as H.323. With this in mind, the additional URI parameters can simply be indicated within the returned SIP URI, which simplifies the work an ENUM client must do and provides the same end result. 1.1. Requirements Language 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 [RFC2119]. Malas & Creighton Expires September 5, 2009 [Page 3] Internet-Draft Trunk Group Use in ENUM March 2009 1.2. Rationale for Trunk use in the 'E2U+SIP' enumservice URI An evaluation of [RFC3402], [RFC3403], and the work in progress [RFC5483] reveals there is no clear definition that says an ENUM client MUST only determine the use of one returned NAPTR and ignore any other NAPTRs returned by the server. While this may be true, it can also be argued that an ENUM client will only choose one NAPTR (and ignore the rest) after evaluating the Services field value, along with the ORDER and PREFERENCE/PRIORITY values, and assuming the NAPTR identifies an acceptable URI that is not rejected by the client due to some other circumstance. Assuming the ENUM client accepts a NAPTR based on this criteria, it is possible a client may never evaluate additional service field values. The primary argument for this draft takes into consideration that trunk group information is defined in [RFC4904] as URI parameters, and how it accomplishes the same approach as the 'trunk' service type in a more simplified manner. This should not be considered an additional service. This is illustrated in the following two examples of a client querying the server for a SIP URI available for the telephone number +442079460148. The first example (Example-1) illustrates the mechanism defined in [I-D.ietf-enum-trunkgroup], where the trunk group parameters are returned in a new ENUM 'trunk' service type. The second example (Example-2) shows how the same result can be achieved by simply returning the 'trunk group' parameters in the existing 'SIP' ENUM service type. NOTE: The NAPTR records shown in this section are intended for illustration purposes only, and are not intended as good examples of how to do ENUM provisioning. The following example illustrates a potential scenario indicating how an ENUM client MAY not ever evaluate a NAPTR with the 'trunk' service type. Example-1 (returning 'trunk group' parameters in a new 'trunk' service type): $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1@sbe1.example.com!" . NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1@sbe2.example.com!" . NAPTR 11 100 "u" "E2U+trunk" "!^.*$!trunk:sip\1;tgrp=TG-1; trunk-context=+44-207@sbe1.example.com;user=phone!" . In this example, the ENUM client will likely select the first NAPTR, because of a match on the queried Services field value, and the ORDER Malas & Creighton Expires September 5, 2009 [Page 4] Internet-Draft Trunk Group Use in ENUM March 2009 and PREFERENCE/PRIORITY value. It will never evaluate the 'trunk' NAPTR unless the previous two fail for some other circumstance. Even if the client does not specify a service in the original query, the ENUM client will likely choose one of the first two NAPTRs due to the inherent choice based on the clients understanding of the preferred service. In order for the client to choose the 'trunk' NAPTR, it would need to either evaluate two NAPTRs in the response based on a client configuration to look for both, or it would have to place a query specifically for the 'trunk' service regardless of knowing whether trunk parameters exist or not. This is due to the fact the client will always have to assume trunk parameters exist as to avoid routing failures due to not having the complete information associated with the destination SIP URI. It is recognized that one potential option is to change the order of the service types to process the 'trunk' service type first. While more and more SIP user agents are supporting ENUM clients, they are only supporting a subset of ENUM service types (primarily SIP). Adding a new service requires two changes to the SIP ENUM client o it needs to support the new URI type (in this case 'trunk:'), and o a new ENUM service type and processing logic. Eliminating the new service type in favor of embedding the parameters in the SIP URIs now only requires the SIP ENUM client to support the URI extensions with no impact to how it processes NAPTR records or how it queries the ENUM server. The following example demonstrates how trunk parameters in a 'SIP' service URI yields the exact same result without additional rules or processing required on the client. Example-2 (returning 'trunk group' parameters in the existing 'SIP' service type): $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=TG-1; trunk-context=+44-207@sbe1.example.com;user=phone!" . NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=TG-2; trunk-context=+44-207@sbe2.example.com;user=phone!" . NAPTR 11 100 "u" "E2U+trunk" "!^.*$!trunk:sip\1;tgrp=TG-1; trunk-context=+44-207@sbe1.example.com;user=phone!" . In this example, the additional 'trunk' parameters defined in [RFC4904] are included in the SIP URI NAPTR response. Since, the result of the query provides a URI response for the Service field 'E2U+sip', the client now has all of the information available to it Malas & Creighton Expires September 5, 2009 [Page 5] Internet-Draft Trunk Group Use in ENUM March 2009 to route the call appropriately without having to look at additional service NAPTRs or place a specific query for the 'trunk' service type. In addition, it is noticeable that the first and third NAPTRs yield the same result for the ENUM client. 2. Acknowledgments The authors of this draft would like to recognize Kevin Johns, David Hancock, and Jean-Francois Mule for their comments. 3. IANA Considerations This memo includes no request to IANA. 4. Security Considerations This draft contains no additional security considerations other than those already defined within [RFC3764], [RFC4904], and [RFC3761]. 5. Normative References [I-D.ietf-enum-trunkgroup] Shockey, R. and T. Creighton, "IANA Registration for an Enumservice Trunkgroup", draft-ietf-enum-trunkgroup-00 (work in progress), July 2008. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. Malas & Creighton Expires September 5, 2009 [Page 6] Internet-Draft Trunk Group Use in ENUM March 2009 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [RFC3764] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. [RFC4904] Gurbani, V. and C. Jennings, "Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, June 2007. [RFC5483] Conroy, L. and K. Fujiwara, "ENUM Implementation Issues and Experiences", RFC 5483, March 2009. Authors' Addresses Daryl Malas (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Phone: +1 303 661 3302 Email: d.malas@cablelabs.com Tom Creighton Comcast One Comcast Center Philadelphia, PA 19103 US Phone: +1 215 286 8617 Email: tom_creighton@cable.comcast.com Malas & Creighton Expires September 5, 2009 [Page 7]