Dispatch D. Malas Internet-Draft CableLabs Intended status: Informational March 1, 2010 Expires: September 2, 2010 SIP Egress Route Use in ENUM draft-malas-dispatch-sip-egress-route-00 Abstract In some cases a UA (or proxy) within a Session Initiation Protocol [RFC3261] Service Provider (SSP) has multiple parallel egress proxy options to reach an ingress proxy within another SSP to reach the target UA. If the originating SSP uses ENUM to identify the ingress proxy of the target SSP, there is currently no way for the ENUM NAPTR response to identify a specific preferred egress proxy from the set of multiple parallel proxies. This draft solves this problem by defining a method for returning deterministic routing information within an ENUM NAPTR response enabling the UA (or proxy) to choose a preferred egress proxy. Using this information, the originating UA now sends the SIP request through the predetermined preferred egress proxy to reach the target SSP's proxy. This document describes several methods to make this determination by incorporating variables into a SIP service URI contained in the E.164 Number Mapping (ENUM) response. 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. Malas Expires September 2, 2010 [Page 1] Internet-Draft SIP Egress Route Use in ENUM March 2010 This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Malas Expires September 2, 2010 [Page 2] Internet-Draft SIP Egress Route Use in ENUM March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Methods for Including Egress Routing Information for SIP in ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Using Trunk Group Contexts . . . . . . . . . . . . . . . . 6 3.2. Using the SIP Route Header . . . . . . . . . . . . . . . . 8 3.3. Create a new ENUM Service Type . . . . . . . . . . . . . . 8 4. ENUM Client, Proxy, and User Agent Considerations . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Malas Expires September 2, 2010 [Page 3] Internet-Draft SIP Egress Route Use in ENUM March 2010 1. Introduction ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms E.164 numbers into 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. There are three methods defined in this document for specifying an egress route. First, it defines the use of trunk group contexts as defined in [RFC4904] as additional parameters in the E2U+SIP enumservice NAPTR record [RFC3403] URI. Second, it defines the use of adding a SIP Route header as an additional header in the E2U+SIP enumservice NAPTR record URI. Third, it describes a new enumservice type TRUNK. While all of these options are included, the document asserts adding trunk group contexts as the preferred method. The reason this is the preferred method is due to existing production implementations. While this is the case, today, it does not mean another method or set of methods may become the preferred option(s) in the industry. To illustrate the problem further, the following diagram describes a scenario where 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. Malas Expires September 2, 2010 [Page 4] Internet-Draft SIP Egress Route Use in ENUM March 2010 +=====================++ ++====================+ || || SSP1 Network +--------+ || SSP2 Network ssp1.example.com | | || ssp2.example.com +--->| SBE1 |---+ || | | | | || | +--------+ | || | || | || | || | || +-------+ | || | +--------+ +-------+ | |---+ || +---->| |---->| | | Proxy | || | SBE3 | | Proxy | | |---+ || +---->| |---->| | +-------+ | || | +--------+ +-------+ | || | || | || | || | +--------+ | || | | | | || +--->| SBE2 |---+ || | | || +--------+ || || || +=====================++ ++====================+ 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 could use a private, customized method (e.g. private DNS) to discover and manipulate a preferred call routing path to SBE3, it prefers to use an industry defined method in ENUM to specify SBE2 as the egress point to reach SBE3. This document defines multiple methods for SSP1 to specify the preferred call routing path to reach SBE3 through the results of an ENUM query. In all of the following methods, the provisioning of the additional information in an ENUM server is outside the scope of this draft; however, it should be assumed, the additional information added will be used exclusively by the querying SSP. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Malas Expires September 2, 2010 [Page 5] Internet-Draft SIP Egress Route Use in ENUM March 2010 "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]. 3. Methods for Including Egress Routing Information for SIP in ENUM 3.1. Using Trunk Group Contexts 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. In the following 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 to route the call. The following figure and subsequent explanation illustrates this in more detail: Malas Expires September 2, 2010 [Page 6] Internet-Draft SIP Egress Route Use in ENUM March 2010 +=====================++ ++====================+ || || 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 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. The Trunk Context is 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: 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. $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; trunk-context=sbe3@ssp2.example.com @sbe2.ssp1.example.com;user=phone!" . If SSP1 desires SBE1 to be a fail-over solution to SBE2, then this would be an example response: Malas Expires September 2, 2010 [Page 7] Internet-Draft SIP Egress Route Use in ENUM March 2010 $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; trunk-context=sbe3@ssp2.example.com @sbe2.ssp1.example.com;user=phone!" . NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=SBE3; trunk-context=sbe3@ssp2.example.com @sbe1.ssp1.example.com;user=phone!" . Using the example figure, 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. 3.2. Using the SIP Route Header Another method for identifying a preferred egress route could be to include the SIP Route header field information as a parameter in ENUM query returned E2U+SIP NAPTR. The following is an example of a returned SIP URI NAPTR with the SIP Route header field information included in the response: 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. $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; user=phone!?route=sbe1.ssp1.example.com" . NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1@sbe3.ssp2.example.com; user=phone!?route=sbe2.ssp1.example.com" . 3.3. 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 Malas Expires September 2, 2010 [Page 8] Internet-Draft SIP Egress Route Use in ENUM March 2010 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. 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@ssp2.example.com!" . NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1@ssp2.example.com!" . NAPTR 11 100 "u" "E2U+trunk" "!^.*$!trunk:sip\1;tgrp=SBE3; trunk-context=sbe3@ssp2.example.com @sbe2.ssp1.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). Malas Expires September 2, 2010 [Page 9] Internet-Draft SIP Egress Route Use in ENUM March 2010 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. 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 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. 5. Acknowledgments I would like to recognize Kevin Johns, David Hancock, Jean-Francois Mule, Vikas Sarawat and Tom Creighton for their input. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations This draft contains no additional security considerations other than those already defined within [RFC3764], [RFC4904], and [RFC3761]. 8. 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. Malas Expires September 2, 2010 [Page 10] Internet-Draft SIP Egress Route Use in ENUM March 2010 [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 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. Author's Address Daryl Malas CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Phone: +1 303 661 3302 Email: d.malas@cablelabs.com Malas Expires September 2, 2010 [Page 11]