Internet Draft R. Stastny
IETF IPTEL WG OeFEG
R. Shockey
Neustar
L. Conroy
Siemens Roke Manor Research
Document:draft-stastny-iptel-tel-enumdi-00.txt
Expires: March 2005 October 2004
New parameter for the "tel" URI to support ENUM
<draft-stastny-iptel-tel-enumdi-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I 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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a new parameter "enumdi" in the "tel" Uniform
Resource Identifier (URI) 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 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.
Conventions used in this document
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 [1].
Table of Contents
1. Introduction
2. Formal Syntax
3. Normative Rules
4. Example
5. Security considerations
6. IANA Considerations
7. Normative References
8. Informative References
9. Acknowledgments
10.Author's Addresses
1. Introduction
VoIP network elements (including UAs) 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, the "enumdi" parameter is used,
to prevent the next VoIP network element from repeating redundant
queries.
2. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC2234 [4].
enumdi = *1(enum-dip-indicator)
enum-dip-indicator = ";enumdi"
The "enum-dip-indicator" can appear in the "tel" URI at most once.
3. 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.
3.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 MUST 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.
3.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
- the result of the query includes a NAPTR RR containing a "tel" URI
that has the same E.164 number, or
- the result of the query includes a NAPTR RR containing a "tel" URI
with the "enumdi" parameter set,
and that "tel" URI is chosen to be passed to the next network
element, the VoIP network element MUST pass on the retrieved URI
with the "enumdi" parameter set.
4. Examples
A. A VoIP network element "server.provider.net" 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 "gw.provider.net".
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.provider.net;user=phone>.
B. A VoIP network element "server.provider.net" 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.provider.net".
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.provider.net;user=phone>.
5. Security considerations
In addition to those security implications discussed in the revised
"tel" URI [6], 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.
6. IANA Considerations
This document requires no IANA actions.
7. Normative References
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
2 ITU-T Recommendation E.164, "The international public
telecommunication numbering plan", May 1997.
3 Faltstrom, P. and Mealling M., "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
4 D. Crocker and P. Overell, RFC2234, "Augmented BNF for Syntax
Specifications: ABNF", November 1997.
5 J. Rosenberg, et al., RFC3261, "SIP: Session Initiation
Protocol", June 2002.
6 H. Schulzrinne, draft-ietf-iptel-rfc2806bis-07.txt, "The tel URI
for Telephone Calls", April 9, 2004. (work in progress)
8. Informative References
7 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
8 Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC3668, February 2004
9 Bradner, S., "IETF Rights in Contributions", BCP 78, RFC3667,
February 2004
9. Acknowledgments
The authors would like to thank James Yu for his comments.
10. Author's Addresses
Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lwc@roke.co.uk
Richard Shockey
Neustar Inc.
46000 Center Oak Plaza
Sterling, VA 20166
Phone: +1.571.434.5651
Email:richard.shockey@neustar.biz
Richard Stastny
OeFEG
Arsenal Objekt 24, Postbox 147
1140 Vienna
Austria
Phone: +43 664 420 4100
Email: richard.stastny@oefeg.at
This draft expires in March 2005.
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Disclaimer of Warranty
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.
Disclaimer of Validity
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.