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]