Network Working Group D. Malas Internet-Draft CableLabs Intended status: Informational T. Creighton Expires: April 29, 2010 Comcast October 26, 2009 Trunk Group Use in ENUM draft-malas-enum-trunk-sip-01 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 April 29, 2010. 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 describes a method for incorporating trunk group parameters into an E.164 Number Mapping (ENUM) response for the Malas & Creighton Expires April 29, 2010 [Page 1] Internet-Draft Trunk Group Use in ENUM October 2009 Session Initiation Protocol (SIP) [RFC3261] service URI. It defines the use of 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Trunk use in the 'E2U+SIP' enumservice URI . . . . . . . . 4 1.3. Why Not Create a new ENUM Service Type? . . . . . . . . . . 6 1.4. ENUM Client, Proxy, and User Agent Considerations . . . . . 7 1.5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 1.6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 1.7. Security Considerations . . . . . . . . . . . . . . . . . . 8 2. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Malas & Creighton Expires April 29, 2010 [Page 2] Internet-Draft Trunk Group Use in ENUM October 2009 1. Introduction ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms E.164 numbers into SIP URIs and then uses DNS [RFC1034] features such as delegation through NS records, or the use of Naming Authority Pointer (NAPTR) records, to provide the communication services available for a specific domain name. This draft refers to the resulting SIP enumservice NAPTR record type received by an ENUM client request. Simplified methods for provisioning call routing data in ENUM servers have developed a desire among SIP Service Providers (SSPs) to manage all call routing data in an ENUM database versus managing some call routing in both ENUM and DNS. 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 an IPv4/v6 address or a fully qualified domain name (FQDN) representing the target SIP UA or proxy. In addition, SIP trunk groups are becoming popular for defining an associated egress Signaling Path Border Element (SBE) for preferred routing to a peer's ingress SBE. +=====================++ ++====================+ || || SSP1 Network +--------+ || SSP2 Network ssp1.example.com | | || ssp2.example.com +--->| SBE1 |---+ || | | | | || | +--------+ | || | || | || | || | || +-------+ | || | +--------+ +-------+ | |---+ || +---->| |---->| | | Proxy | || | SBE3 | | Proxy | | |---+ || +---->| |---->| | +-------+ | || | +--------+ +-------+ | || | || | || | || | +--------+ | || | | | | || +--->| SBE2 |---+ || | | || +--------+ || || || +=====================++ ++====================+ Malas & Creighton Expires April 29, 2010 [Page 3] Internet-Draft Trunk Group Use in ENUM October 2009 The above figure illustrates the problem. SSP1 has two options to send a request to SSP2. For reasons outside the scope of this draft, SSP1 would prefer to use SBE2 to send a request to SSP2. Based on the information from SSP2, an example ENUM response for SSP1 would look something like the following: $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1@sbe3.ssp2.example.com!" . While SSP1 can use a subsequent private DNS look-up on sbe3.ssp2.example.com to discover and manipulate a preferred call routing path to SBE3, it prefers to use defined trunk group parameters to specify SBE2 as the egress point to reach SBE3. Trunk group use is especially applicable if SSP2 uses an IPv4/v6 address to specify SBE3 with no additional DNS look-ups to discover the preferred path via SBE2. This draft defines a method for SSP1 to determine the preferred call routing path to reach SBE3 through the results of an ENUM query. 1.1. Terminology 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]. Additional terms used in this document for describing aspects of the problem and solution are defined in RFC 5486 [RFC5486]. 1.2. Trunk use in the 'E2U+SIP' enumservice URI The following example shows how the'trunk group' parameters are returned 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. Example: $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!" . In this example, the additional 'trunk' parameters defined in [RFC4904] are included in the SIP URI NAPTR response. Since, the Malas & Creighton Expires April 29, 2010 [Page 4] Internet-Draft Trunk Group Use in ENUM October 2009 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 to route the call. The following figure and subsequent explanation illustrates this in more detail: +=====================++ ++====================+ || || SSP1 Network +--------+ || SSP2 Network ssp1.example.com | | || ssp2.example.com +--->| SBE1 |---+ || | | | | || | +--------+ | || | || | || | || | || +-------+ | || | +--------+ +-------+ | |---+ || +---->| |---->| | | Proxy | || | SBE3 | | Proxy | | |---+ || +---->| |---->| | +-------+ | || | +--------+ +-------+ | || | || | || | || | +--------+ | || | | | | || +--->| SBE2 |---+ || | | || +--------+ || || || +=====================++ ++====================+ In the above figure, SSP2 notifies SSP1 to reach +442079460148, send your SIP request to sbe3.ssp2.example.com. SSP1 decides it prefers to send all requests to sbe3.ssp2.example.com via SBE2. In order to do this, it assigns a trunk group to SBE2. The trunk group, for example purposes, is SBE3-SSP2. The Trunk Context is sbe2.ssp1.example.com. In order for the request to be routed correctly from SBE2 to SSP2, there is a logical association on SBE2 to interpret sbe3-ssp2 to sbe3.ssp2.example.com. The trunk group and context are provisioned into the ENUM server, so when the Proxy (in this example, also the ENUM client) queries for +442079460148 it receives the following response: $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=SBE3-SSP2; trunk-context=sbe2.ssp1.example.com @sbe3.ssp2.example.com;user=phone!" . Malas & Creighton Expires April 29, 2010 [Page 5] Internet-Draft Trunk Group Use in ENUM October 2009 If SSP1 desires SBE1 to be a fail-over solution to SBE2, then this would be an example response: $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=TG1-SBE3-SSP2; trunk-context=sbe2.ssp1.example.com @sbe3.ssp2.example.com;user=phone!" . NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=TG2-SBE3-SSP2; trunk-context=sbe1.ssp1.example.com @sbe3.ssp2.example.com;user=phone!" . In the above fail-over solution a logical association to sbe3.ssp2.example.com would be required on both SBE1 and SBE2. 1.3. Why Not Create a new ENUM Service Type? One method for identifying a trunk group in ENUM could be to define a new service type "trunk". This new service type would return 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. An evaluation of [RFC3402], [RFC3403], and [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. This is illustrated in the following example of a client querying the server for a SIP URI available for the telephone number +442079460148. The example illustrates a potential additional service type mechanism, where the trunk group parameters are returned in a new ENUM 'trunk' 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. Malas & Creighton Expires April 29, 2010 [Page 6] Internet-Draft Trunk Group Use in ENUM October 2009 The following example illustrates a potential scenario indicating how an ENUM client MAY not ever evaluate a NAPTR with the '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@sbe3.ssp2.example.com!" . NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1@sbe3.ssp2.example.com!" . NAPTR 11 100 "u" "E2U+trunk" "!^.*$!trunk:sip\1;tgrp=SSP2-SBE3; trunk-context=sbe2.ssp1.example.com @sbe3.ssp2.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 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. 1.4. ENUM Client, Proxy, and User Agent Considerations It should not be assumed the originating proxy or user agent (UA), acting as the ENUM client, will perform an action based on the received trunk group information. With this in mind, it is recommended that if the proxy or UA does not know how to interpret or Malas & Creighton Expires April 29, 2010 [Page 7] Internet-Draft Trunk Group Use in ENUM October 2009 act on the trunk group parameters it should simply forward the URI as received from the ENUM server to the next downstream SIP signaling element. 1.5. Acknowledgments The authors of this draft would like to recognize Kevin Johns, David Hancock, and Jean-Francois Mule for their comments. 1.6. IANA Considerations This memo includes no request to IANA. 1.7. Security Considerations This draft contains no additional security considerations other than those already defined within [RFC3764], [RFC4904], and [RFC3761]. 2. Normative References [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. [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 Malas & Creighton Expires April 29, 2010 [Page 8] Internet-Draft Trunk Group Use in ENUM October 2009 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. [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009. Authors' Addresses Daryl Malas 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 April 29, 2010 [Page 9]