One document matched: draft-ietf-iptel-tel-enumdi-03.txt
Differences from draft-ietf-iptel-tel-enumdi-02.txt
IPTEL R. Stastny
Internet-Draft Oefeg
Expires: June 22, 2006 R. Shockey
Neustar Inc.
L. Conroy
Roke Manor Research
December 19, 2005
The ENUM Dip Indicator parameter for the "tel" URI
<draft-ietf-iptel-tel-enumdi-03.txt>
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of 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 June 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a new parameter "enumdi" for the "tel" Uniform
Resource Identifier (URI) to support the handling of ENUM queries in
VoIP (Voice over Internet Protocol) network elements. A VoIP network
element may receive an URI containing an E.164 number, where that URI
contains an "enumdi" parameter. The presence of the "enumdi"
Stastny, et al. Expires June 22, 2006 [Page 1]
Internet-Draft ENUM Dip Indicator "tel" URI parameter December 2005
parameter indicates that an ENUM query has already been performed on
the E.164 number by a previous VoIP network element. Equally, if a
VoIP network element sends such an URI, it asserts that an ENUM query
has been carried out on this number.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Normative Rules . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Handling an URI with the "enumdi" parameter . . . . . . . . 4
4.2. Adding the "enumdi" parameter to URIs . . . . . . . . . . . 4
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Stastny, et al. Expires June 22, 2006 [Page 2]
Internet-Draft ENUM Dip Indicator "tel" URI parameter December 2005
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 BCP 14, RFC2119
[1].
2. Introduction
VoIP network elements (including User Agent Servers and User Agent
Clients) may be set up in different ways to handle E.164 [3] numbers
during call setup, depending on the capabilities provided. One
common approach is to query ENUM as defined in RFC3761 [4], and to
use the set of NAPTR (Naming Authority Pointer to resource) resource
records that is returned.
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 be routed to the PSTN
(Public Switched Telecommunications Network). 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 [5]), the "enumdi"
parameter is used, to prevent the next VoIP network element from
repeating redundant queries.
3. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in RFC2234 [2].
enumdi = *1(enum-dip-indicator)
enum-dip-indicator = ";enumdi"
The ENUM Dip Indicator is an optional parameter for the "tel" URI,
and so the enumdi production above is an example of the parameter
syntax element described in [5], with enum-dip-indicator being an
example of the pname production described there.
4. Normative Rules
This section discusses how a VoIP network element handles a received
"tel" URI that contains the "enumdi" parameter or has queried ENUM in
e164.arpa. for a given E.164 number and needs to add the parameter to
Stastny, et al. Expires June 22, 2006 [Page 3]
Internet-Draft ENUM Dip Indicator "tel" URI parameter December 2005
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 queries ENUM in e164.arpa. for a given
E.164 number and the result of the query is NXDOMAIN, if that 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 queries ENUM in e164.arpa. for a given
E.164 number and either:
o the result of the query includes a NAPTR resource record
containing a "tel" URI that has the same E.164 number, or
o the result of the query includes a NAPTR resource record
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.
5. Examples
a. A VoIP network element called server.example.com receives a "tel"
URI tel:+441632960038. The VoIP network element queries the DNS
for NAPTR resource records 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 [6] section 19.1.6):
sip:+441632960038;enumdi@gw.example.com;user=phone
Stastny, et al. Expires June 22, 2006 [Page 4]
Internet-Draft ENUM Dip Indicator "tel" URI parameter December 2005
b. A VoIP network element called server.example.com receives a "tel"
URI tel:+441632960038. The VoIP network element queries the DNS
for NAPTR resource records 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 called gw.example.com.
It therefore signals to this next VoIP network element with:
tel:+441632960038;enumdi
or (using the procedures of RFC3261 [6] section 19.1.6):
sip:+441632960038;enumdi@gw.example.com;user=phone
6. Security Considerations
In addition to those security implications discussed in the "tel" URI
[5] specification, there are new security implications associated
with the defined parameter.
If the "enumdi" is illegally inserted into the "tel" URI when the
signalling 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 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 unauthorised
changes to the content of the "tel" URI and other information.
7. IANA Considerations
This document does not itself require any IANA actions.
It does define a parameter for the "tel" URI. Further information on
a registry for such parameters is covered in
draft-ietf-iptel-tel-reg-00 [10].
8. Acknowledgements
Stastny, et al. Expires June 22, 2006 [Page 5]
Internet-Draft ENUM Dip Indicator "tel" URI parameter December 2005
Many thanks for the thorough review provided by Alex Mayrhofer.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997.
[4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[5] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[6] 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.
9.2. Informative References
[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.
[10] Jennings, C. and V. Gurbani, "The Internet Assigned Number
Authority (IANA) tel Uniform Resource Identifier (URI)
Parameter Registry", draft-ietf-iptel-tel-reg-00.txt (work in
progress), December 2005.
Stastny, et al. Expires June 22, 2006 [Page 6]
Internet-Draft ENUM Dip Indicator "tel" URI parameter December 2005
Authors' Addresses
Richard Stastny
Oefeg
Postbox 147
1103 Vienna
Austria
Phone: +43-664-420-4100
Email: Richard.stastny@oefeg.at
Richard Shockey
Neustar Inc.
46000 Center Oak Plaza
Sterling, VA 20166
United States
Phone: +1-571-434-5651
Email: richard.shockey@neustar.biz
Lawrence Conroy
Roke Manor Research
Roke Manor
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lconroy@insensate.co.uk
Stastny, et al. Expires June 22, 2006 [Page 7]
Internet-Draft ENUM Dip Indicator "tel" URI parameter December 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, et al. Expires June 22, 2006 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 15:35:15 |