The H.323 specification [2] defines a means for building multimedia
communication services over an arbitrary Packet Based Network,
including the Internet. When H.323 is used in the context of the
Internet, it would be useful to take advantages of such services as
domain name system (DNS) and ENUM in order to help facilitate the
completion of multimedia calls.
This document registers an ENUM service for H.323 according to
specifications and guidelines in RFC 3761 [3].
As defined in [3], the following is a template covering information
needed for the registration of the enumservice specified in this
document.
- Service Name: "E2U+H323"
- URI Scheme(s): "h323:"
- Functional Specification: see section "3. The E2U+H323 ENUM
Service"
- Security considerations: see section "5. Security Considerations"
- Intended usage: COMMON
- Author: Orit Levin
- Any other information that the author deems interesting: None
This document defines the "E2U+H323" service to be used in the
"service" sub-field of the "enumservice" as defined in [3].
The H.323 related ENUM record MUST be populated with a standard H.323
URL as defined in [2]. This URL MAY include parameters specifying
the specific protocols and the transport means the H.323 entity
supports.
The H.323 entity MUST fully comply with the procedures defined in [3]
for both record retrieval and processing by the DNS client.
If, as a result of the ENUM DNS lookup, an H.323 URL matching local
policies and capabilities is retrieved, the procedure defined in
section O.8.1 "Locating H.323 Destination" of [5] SHOULD be
performed.
Levin Standards Track [Page 2]
RFC 3762 ENUM Service Registration for H.323 April 2004
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, RFC 2119 [1].
The h323-URL information, once populated in the DNS, effectively
becomes publicly accessible. The access to the H.323 destinations
(published using ENUM) can be secured by techniques and procedures
defined in H.235 [4] - the security framework for H.323. The
framework defines means for achieving integrity, authentication,
non-repudiation, encryption, etc. for H.323 calls. An analysis of
threats specific to the dependence of ENUM on the DNS, and the
applicability of DNSSEC [6] to these, is provided in [3].
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] "Packet-based multimedia communications systems", ITU-T
Recommendation H.323, 2003.
[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] "Security and encryption for H-Series(H.323 and other H.245-
based) multimedia terminals", ITU-T Recommendation H.235, 2003.
[5] "Usage of URLs and DNS", ITU-T Recommendation H.323 Annex O,
2003.
[6] R. Arends, et al., "Protocol Modifications for the DNS Security
Extensions", Work in Progress, February 2004.
Levin Standards Track [Page 3]
RFC 3762 ENUM Service Registration for H.323 April 2004
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: oritl@microsoft.com
Levin Standards Track [Page 4]
RFC 3762 ENUM Service Registration for H.323 April 2004
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.
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.
Intellectual Property
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.
Levin Standards Track [Page 5]