T Rec H.460.23 200912 I!!pdf e
T Rec H.460.23 200912 I!!pdf e
ITU-T H.460.23
TELECOMMUNICATION (12/2009)
STANDARDIZATION SECTOR
OF ITU
Summary
Recommendation ITU-T H.460.23 enables an ITU-T H.323 endpoint residing behind a NAT/FW
device to report NAT/FW characteristics to the gatekeeper. When used with Recommendation
ITU-T H.460.24, a gatekeeper may utilize NAT/FW information in order to formulate a decision as
to how to enable direct media flow between two devices. In most cases, following these procedures
will allow the gatekeeper to avoid the need for a media proxy as described in Recommendation
ITU-T H.460.19, as media can be successfully transmitted directly between two endpoints residing
behind distinct NAT/FW devices.
History
Edition Recommendation Approval Study Group
1.0 ITU-T H.460.23 2009-12-14 16
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.
ITU 2010
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.
1 Scope
This Recommendation defines the capability and procedures for determining whether an endpoint is
located behind a network address translator (NAT) or firewall (FW) and to determine the
characteristics of the NAT/Firewall device. This feature detects the NAT/Firewall characteristics in
order to allow a gatekeeper to determine whether it is possible to stream media directly between two
endpoints. If used in conjunction with [ITU-T H.460.24], the scalability of
[ITU-T H.460.18]/[ITU-T H.460.19] may be extended to allow media to flow directly between
ITU-T H.323 endpoints, thus avoiding the necessity to proxy media through an ITU-T H.460.19
server.
2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T H.225.0] Recommendation ITU-T H.225.0 (2009), Call signalling protocols and media
stream packetization for packet-based multimedia communication systems.
[ITU-T H.245] Recommendation ITU-T H.245 (2009), Control protocol for multimedia
communication.
[ITU-T H.323] Recommendation ITU-T H.323 (2009), Packet-based multimedia
communications systems.
[ITU-T H.460.1] Recommendation ITU-T H.460.1 (2002), Guidelines for the use of the generic
extensible framework.
[ITU-T H.460.17] Recommendation ITU-T H.460.17 (2005), Using H.225.0 call signalling
connection as transport for H.323 RAS messages.
[ITU-T H.460.18] Recommendation ITU-T H.460.18 (2005), Traversal of H.323 signalling
across network address translators and firewalls.
[ITU-T H.460.19] Recommendation ITU-T H.460.19 (2005), Traversal of H.323 media across
network address translators and firewalls.
[ITU-T H.460.24] Recommendation ITU-T H.460.24 (2009), Point-to-point media through
network address translators and firewalls within ITU-T H.323 systems.
3 Definitions
4 Abbreviations
This Recommendation uses the following abbreviations:
FW Firewall
GCF Gatekeeper Confirmation
GRQ Gatekeeper Request
NAT Network Address Translator
RCF Registration Confirm
RRQ Registration Request
STUN Simple Traversal of User datagram protocol (UDP) through Network address translators
5 Feature description
This Recommendation defines a procedure wherein a gatekeeper may detect whether a registering
endpoint is behind a NAT/FW. This Recommendation provides instructions for a gatekeeper to
instruct an endpoint to detect if it is behind a NAT/FW and to collect characteristics of the
intervening NAT/FW device. These findings are then reported back to the gatekeeper, which can
then be used as input into [ITU-T H.460.24] point-to-point media (P2Pnat media) traversal
calculations.
6 Capability advertisement
Endpoints capable of supporting NAT/FW determination shall advertise this capability via the
generic extensibility framework (GEF) defined in [ITU-T H.323] and [ITU-T H.460.1].
This feature is to be used in conjunction with [ITU-T H.460.18] or optionally [ITU-T H.460.17].
[ITU-T H.323] devices wishing to use this feature shall also support either [ITU-T H.460.18] or
[ITU-T H.460.17], respectively.
In supporting the various NAT/FW conditions and configurations covered in [ITU-T H.460.18], a
client gatekeeper (refer to Figure 3 of [ITU-T H.460.18]) or a client proxy (refer to Figure 2 of
[ITU-T H.460.18]) residing behind a NAT/FW providing direct NAT traversal support through the
NAT/FW shall be considered as an endpoint for the purpose of this Recommendation.
An endpoint, which performs gatekeeper, discovery, shall set the supportedFeatures field of its
GRQ to include NAT/FW determination as defined in Table 1. If the gatekeeper responds with a
GCF, it shall include NAT/FW determination in the supportedFeatures field.
Endpoints shall send an RRQ to the gatekeeper, including NAT/FW determination in the
supportedFeatures field. Endpoints shall omit NAT/FW determination from the supportedFeatures
field of lightweight RRQs.
Table 1 defines the NAT/FW determination feature in this Recommendation.
Parameters associated with the advertisement of this capability are specified in the following
clauses. In consideration of backward compatibility with further revisions to this Recommendation,
the recipient shall simply ignore any parameters received other than those specified in this
Recommendation.
For the purpose of this Recommendation, where an optional parameter of type bool is to be omitted
then it shall automatically be deemed to have a default value of FALSE.
Comparing the endpoint's supplied RAS address with the returned RASPresentation, an endpoint
may detect a discrepancy which possibly indicates that an intermediary device is acting on its behalf
to facilitate NAT/FW traversal. Where such a device may be present, the implementer shall ignore
clause 11 and report back to the gatekeeper a NAT type of Type 1 (Open NAT) as indicated in
Table 8. It shall also report an amended RemoteNAT value (refer to Table 2) of FALSE to indicate
to the gatekeeper the indeterminate remote NAT/FW behaviour of the intermediary device.
An endpoint shall not use a predefined STUN server; STUN server support shall be included in the
endpoint, but shall only be activated upon receipt of a positive NATPresent and only tested against
the address and port contained in the NATTest.
For the purpose of interoperability with [ITU-T H.460.18], when using STUN in accordance with
this Recommendation or [ITU-T H.460.24], an endpoint shall conduct no network address
translation on either RAS or ITU-T H.225.0 call signalling messages, and only where instructed in
the ITU-T H.245 OLC, shall contain the STUN detected public IP address and STUN opened
pinhole ports.
STUN test shall be conducted in accordance with [IETF RFC 3489].
Table 8 – NATType parameter values (as detected via clause 10.1 of [IETF RFC 3489])
Value NAT Type
0 Unknown NAT (Indeterminate/Reserved, refer to clause 9.1 of [ITU-T H.460.24])
1 Open Internet (No NAT/FW detected)
2 Full Cone NAT (as defined in clause 5 of [IETF RFC 3489])
3 Restricted Cone NAT (as defined in clause 5 of [IETF RFC 3489])
4 Port Restricted Cone NAT (as defined in clause 5 of [IETF RFC 3489])
5 Symmetric NAT/FW (as defined in clause 5 of [IETF RFC 3489])
6 UDP Blocked NAT (No UDP connectivity)
7 Partial UDP Blocked NAT (Inconsistent UDP connectivity)
The STUN NAT type reported back to the gatekeeper may be used as the inputs for the calculation
of media pathways as specified in clause 9 of [ITU-T H.460.24].
13 General considerations
Although not specified in [IETF RFC 3489], it is recommended that the UDP ports used to initiate
the STUN test be in the same local UDP port range as allocated for RTP/RTCP to provide greater
accuracy in testing results. STUN tests may also be carried out periodically to detect any changes in
the NAT/FW device behaviour over time and these changes are to be reported back to the
gatekeeper as per clause 12.
In environments where ITU-T H.460.19 media proxy is permanently disabled and the NAT type is
greater than 2, it is recommended that the endpoint user be notified that not all calls will connect.
This is because there is a probability that the ITU-T H.460.24 media pathway calculation will return
a media strategy indicator value of 100 (refer to Table 9 of [ITU-T H.460.24]); which means that
there is no resolvable media pathway between the devices.
A test value of 0 shall indicate that the STUN test returned an indeterminate result and this feature
shall be disabled and proceed with the standard [ITU-T H.460.18]/[ITU-T H.460.19] NAT traversal
mechanism.
A test value of 1 shall indicate that the endpoint is not detected as being behind a NAT/FW device
and if necessary both this feature and [ITU-T H.460.18]/[ITU-T H.460.19] may be disabled for the
endpoint.
Series E Overall network operation, telephone service, service operation and human factors
Series J Cable networks and transmission of television, sound programme and other multimedia signals
Series L Construction, installation and protection of cables and other elements of outside plant
Series Y Global information infrastructure, Internet protocol aspects and next-generation networks
Printed in Switzerland
Geneva, 2010