IPTEL R. Stastny
Internet-Draft Oefeg
Expires: August 5, 2005 L. Conroy
Siemens Roke Manor Research
February 2005
The ENUM Dip Indicator parameter for the "tel" URI
<draft-ietf-iptel-tel-enumdi-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 August 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a new parameter "enumdi" in the "tel" Uniform
Resource Identifier (URI) as defined in RFC3966 to support the
handling of ENUM queries in SIP proxies, H.323 gatekeepers and other
VoIP network elements. The presence of the "enumdi" parameter
indicates to the VoIP network element receiving an URI containing an
Stastny & Conroy Expires August 5, 2005 [Page 1]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
E.164 number that an ENUM query as defined in RFC3761 has already
been performed on the E.164 number indicated by the previous VoIP
network element.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Normative Rules . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Handling an URI with the "enumdi" parameter . . . . . . . 6
4.2 Adding the "enumdi" parameter to URIs . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1 Normative References . . . . . . . . . . . . . . . . . . . 10
8.2 Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12
Stastny & Conroy Expires August 5, 2005 [Page 2]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
thisdocument are to be interpreted as described in BCP 14, RFC2119
[1].
Stastny & Conroy Expires August 5, 2005 [Page 3]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
2. Introduction
VoIP network elements (including UAS and UAC) may be set up in
different ways to handle E.164 [2] numbers during call setup,
depending on the capabilities provided. One common approach is to
query ENUM as defined in RFC3761 [3].
If the ENUM query leads to a result, the call is set-up accordingly.
If the ENUM query does not lead finally to a result, another database
may be queried and/or the call may finally routed to the PSTN. In
doing so, the call may be routed to another VoIP network element. To
indicate in signalling to this next VoIP element that an ENUM query
has already be made for the "tel" URI (specified in RFC3966 [4]), the
"enumdi" parameter is used, to prevent the next VoIP network element
from repeating redundant queries.
Stastny & Conroy Expires August 5, 2005 [Page 4]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
3. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC2234 [6].
enumdi = *1(enum-dip-indicator)
enum-dip-indicator = ";enumdi"
The "enum-dip-indicator" can appear in the "tel" URI at most once.
Stastny & Conroy Expires August 5, 2005 [Page 5]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
4. Normative Rules
This section discusses how a VoIP network element handles a received
"tel" URI that contains the "enumdi" parameter or has accessed ENUM
in e164.arpa for a given E.164 number and needs to add the parameter
to a "tel" URI.
4.1 Handling an URI with the "enumdi" parameter
If a VoIP network element receives a "tel" URI containing the
"enumdi" parameter, the VoIP network element SHOULD NOT retrieve the
related information for this number from ENUM in e164.arpa even if it
would normally do so.
If the received "tel" URI is to be passed to the next network
element, the VoIP network element MUST pass on the received URI
containing the "enumdi" parameter unchanged.
4.2 Adding the "enumdi" parameter to URIs
When a VoIP network element accesses ENUM in e164.arpa for a given
E.164 number and the result of the query is NXDOMAIN, and the network
element chooses to pass the call to the next network element by using
a "tel" URI, the "enumdi" parameter MUST be set.
When a VoIP network element accesses ENUM in e164.arpa for a given
E.164 number and either:
o the result of the query includes a NAPTR RR containing a "tel" URI
that has the same E.164 number, or
o the result of the query includes a NAPTR RR containing a "tel" URI
with the "enumdi" parameter set,
then if that retrieved "tel" URI is chosen to be passed to the next
network element, the sending VoIP network element MUST pass on the
retrieved URI with the "enumdi" parameter set.
Stastny & Conroy Expires August 5, 2005 [Page 6]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
5. Examples
a. A VoIP network element "server.example.com" receives a "tel" URI
<tel:+441632960038>. The VoIP network element accesses the DNS
for NAPTR RR in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., and gets the
response NXDOMAIN. The VoIP network element decides to route the
call to the PSTN via another VoIP network element called
"gw.example.com".
It therefore signals to the next VoIP network element with:
<tel:+441632960038;enumdi>
or (using the procedures of RFC3261 [5] section 19.1.6):
<sip:+441632960038;enumdi@gw.example.com;user=phone>.
b. A VoIP network element "server.example.com" receives a "tel" URI
<tel:+441632960038>. The VoIP network element accesses the DNS
for NAPTR RR in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., and receives
the same "tel" URI in reply (i.e. <tel:+4416232960038>).
The VoIP network element decides to route the call to the PSTN
via another VoIP network element "gw.example.com".
It therefore signals to the next VoIP network element with:
<tel:+441632960038;enumdi>
or (using the procedures of RFC3261 [5] section 19.1.6):
<sip:+441632960038;enumdi@gw.example.com;user=phone>.
Stastny & Conroy Expires August 5, 2005 [Page 7]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
6. Security Considerations
In addition to those security implications discussed in the "tel" URI
[4] specification, there are new security implications associated
with the defined parameter.
If the "enumdi" is illegally inserted into the "tel" URI when the
signaling message carrying the "tel" URI is en route to the
destination entity, the call may be routed to the PSTN network,
incurring unexpected charges or the causing a downstream VoIP network
element to reject the call setup.
It is less a problem if the "enumdi" is illegally removed. An
additional ENUM query may be performed to retrieve the routing number
information and have the "enumdi" included again.
It is RECOMMENDED that protocols carrying the "tel" URI ensure
message integrity during the message transfer between the two
communicating network elements so as to detect any unauthorized
changes to the content of the "tel" URI and other information.
Stastny & Conroy Expires August 5, 2005 [Page 8]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
7. IANA Considerations
This document requires no IANA actions.
Stastny & Conroy Expires August 5, 2005 [Page 9]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997.
[3] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[4] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[5] 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.
8.2 Informative References
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[7] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[8] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[9] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3668, February 2004.
Authors' Addresses
Richard Stastny
Oefeg
Postbox 147
1103 Vienna
Austria
Phone: +43-664-420-4100
Email: Richard.stastny@oefeg.at
Stastny & Conroy Expires August 5, 2005 [Page 10]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lwc@roke.co.uk
Stastny & Conroy Expires August 5, 2005 [Page 11]
Internet-Draft ENUM Dip Indicator "tel" URI parameter February 2005
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 (2005). 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.
Stastny & Conroy Expires August 5, 2005 [Page 12]
