ITU-T H 248 37-2008 Gateway control protocol IP NAPT traversal package (Study Group 16)《网关控制协议 IP NAPT障碍包》.pdf

《ITU-T H 248 37-2008 Gateway control protocol IP NAPT traversal package (Study Group 16)《网关控制协议 IP NAPT障碍包》.pdf》由会员分享，可在线阅读，更多相关《ITU-T H 248 37-2008 Gateway control protocol IP NAPT traversal package (Study Group 16)《网关控制协议 IP NAPT障碍包》.pdf（26页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T H.248.37TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (06/2008) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Communication procedures Gateway control protocol: IP NAPT traversal package Recommendation ITU-T H.248.37

2、 ITU-T H-SERIES RECOMMENDATIONS AUDIOVISUAL AND MULTIMEDIA SYSTEMS CHARACTERISTICS OF VISUAL TELEPHONE SYSTEMS H.100H.199 INFRASTRUCTURE OF AUDIOVISUAL SERVICES General H.200H.219 Transmission multiplexing and synchronization H.220H.229 Systems aspects H.230H.239 Communication procedures H.240H.259

3、Coding of moving video H.260H.279 Related systems aspects H.280H.299 Systems and terminal equipment for audiovisual services H.300H.349 Directory services architecture for audiovisual and multimedia services H.350H.359 Quality of service architecture for audiovisual and multimedia services H.360H.36

4、9 Supplementary services for multimedia H.450H.499 MOBILITY AND COLLABORATION PROCEDURES Overview of Mobility and Collaboration, definitions, protocols and procedures H.500H.509 Mobility for H-Series multimedia systems and services H.510H.519 Mobile multimedia collaboration applications and services

5、 H.520H.529 Security for mobile multimedia systems and services H.530H.539 Security for mobile multimedia collaboration applications and services H.540H.549 Mobility interworking procedures H.550H.559Mobile multimedia collaboration inter-working procedures H.560H.569 BROADBAND AND TRIPLE-PLAY MULTIM

6、EDIA SERVICES Broadband multimedia services over VDSL H.610H.619 Advanced multimedia services and applications H.620H.629 IPTV MULTIMEDIA SERVICES AND APPLICATIONS FOR IPTV General aspects H.700H.719 IPTV terminal devices H.720H.729 For further details, please refer to the list of ITU-T Recommendati

7、ons. Rec. ITU-T H.248.37 (06/2008) i Recommendation ITU-T H.248.37 Gateway control protocol: IP NAPT traversal package Summary Session border controllers (SBCs) are an important part of the Internet infrastructure. Some of these session border controllers are being split into media gateway controlle

8、r (MGC) and media gateway (MG) components. One important function of an SBC is to perform network address and port translation (NAPT). This Recommendation allows the MGC to instruct an MG to latch to an address provided by an incoming Internet protocol (IP) application data stream rather than the ad

9、dress provided by the call/bearer control. This enables the MG to open a pinhole for data flow. This revision of Recommendation ITU-T H.248.37 adds clarifications for latch and re-latch behaviour and new packages for address reporting and statistics. Source Recommendation ITU-T H.248.37 was approved

10、 on 13 June 2008 by ITU-T Study Group 16 (2005-2008) under Recommendation ITU-T A.8 procedure. ii Rec. ITU-T H.248.37 (06/2008) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technolo

11、gies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommu

12、nication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas

13、of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operat

14、ing 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“ o

15、r 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. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practic

16、e or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation developme

17、nt process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore

18、strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2009 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T H.248.37 (06/2008) iii CONTENTS Page 1 Scope 1 1.1 Adaptati

19、on on new or changes of remote source address information. 1 1.2 Reporting of new or detected changes of remote address information 3 1.3 Counting the packets dropped based on implicit filtering 4 2 References. 4 3 Definitions 4 3.1 Terms defined elsewhere 4 3.2 Terms defined in this Recommendation.

20、 4 4 Abbreviations and acronyms 4 5 Conventions 5 6 IP NAPT traversal package 5 6.1 Properties 6 6.2 Events . 6 6.3 Signals 6 6.4 Statistics 6 6.5 Error codes 6 6.6 Procedures 7 7 Address reporting package . 12 7.1 Properties 12 7.2 Events . 12 7.3 Signals 14 7.4 Statistics 14 7.5 Procedures 14 8 La

21、tch statistics package 15 8.1 Properties 15 8.2 Events . 15 8.3 Signals 16 8.4 Statistics 16 8.5 Error codes 16 8.6 Procedures 16 Appendix I Temporary interruptions of IP connection. 17 Rec. ITU-T H.248.37 (06/2008) 1 Recommendation ITU-T H.248.37 Gateway control protocol: IP NAPT traversal package

22、1 Scope This Recommendation allows a media gateway controller to control Internet protocol (IP) network address and port translation (NAPT) traversal. 1.1 Adaptation on new or changes of remote source address information The use of IP NAPT traversal (see clause 6) is especially useful in session bor

23、der controllers (SBCs) where media traversal is required. Figure 1 illustrates a model for NAT traversal processing. The media gateway (MG) latches or re-latches, respectively, using the incoming H.248 stream (see termination T1). The peer IP connection endpoint is behind a NA(P)T device. NAPT Devic

24、eIP Domain 1Media GatewayIP Connection EndpointIP Domain 2H.248GatewayControlProtocolIPTx,HostIPRx,HostIPRx,MGIPTx,MGT1IPTx, ,NAT,1IPRx,NAT,1IPRx, ,NAT,2IPTx, ,NAT,2A1 A2 A1 A2T2Note: One to N interim NA(P)T devices are modeled by a single entity.IP or non-IP networkIncoming Stream:DA = A1SA = A2Out

25、going Stream:DA = A2SA = A1Media Gateway Controller (MGC)Information exchange (if at all) between these entities is out of scope of this Recommendation.e.g. private/local/internal network(see clause 3.5/H.248.43)e.g. public/global/external network(see clause 3.6/H.248.43)Outgoing Stream:DA = A1SA =

26、A2Incoming Stream:DA = A2SA = A1NOTE The single H.248 stream at Termination T1 relates to the two IP flows of the bidirectional IP connection. Figure 1 Model for NAPT traversal processing The network assumptions for H.248.37 are as follows: Assumption 1 IP host equipment In scope are translated tran

27、sport addresses A2 to A2 by interim NAT devices. 2 Rec. ITU-T H.248.37 (06/2008) Assumption 2 Symmetry assumption for remote address A2 The remote IP connection endpoint is using symmetrical addresses (e.g., Figure 1: the network address and port values of IPTx,Hostand IPRx,Hostare identical). This

28、symmetry condition is valid both for latching and address reporting. Assumption 3 Dynamic of address changes The IP host does not change the transport address A2 during the lifetime of the IP transport connection. The host transport address A2 will be thus static and also not change during the lifet

29、ime of the H.248 stream/termination. NOTE 1 IP host equipment with autonomous source port changes (e.g., due to security reasons) for the same transport connection (i.e., same application data stream) are therefore not considered here. In this context “autonomous“ means that changes will not lead to

30、 any correspondent session control protocol (e.g., SIP) activity. Assumption 4 MGC awareness concerning address changes An MGC using the ipnapt package is “aware“ that there is a need for NAPT traversal support for the H.248 stream/termination. For this package, the MGC may not be aware of a) the tr

31、anslated transport address A2 by the NAPT device (Note 2), or b) the transport address changes by the IP endpoint after connection establishment. A consequence of this assumption is the fact that possible source address/port filtering by the MG is related to a static transport address A2, e.g., such

32、 a filter may not be autonomously adapted by the MG. NOTE 2 This function is in the particular scope of the adr package (see clause 7). Assumption 5 Validity of source endpoint address The MG is not aware of whether the source transport address (before or after latching) of the incoming stream repre

33、sents a “valid“ address (in the scope of that session). NOTE 3 The MGC could check, based on the adr package, whether the latched source transport address is valid or unknown. The latch/re-latch process could be extended, e.g., by additional consideration of given destination transport address infor

34、mation (in the case that the MGC is unsure about a valid endpoint). Such a capability is for further study. NOTE 4 There is a possible security problem. The use case of intentionally injected IP packets by an attacker with “his“ source transport address may not be detected by the MG (in the scope of

35、 this Recommendation). Assumption 6 MG awareness concerning transport protocol type The MG may be aware of or be agnostic of the transport-protocol type of the H.248 stream. This may depend, e.g., in case of IP-to-IP MGs on the configured interworking mode (see, e.g., clause 3.2.6 of b-ITU-T Q.3303.

36、2). Nevertheless, the ipnapt package may be used for any type of transport protocol (e.g., UDP, TCP, SCTP, DCCP). Assumption 7 IP connection establishment This may be relevant for connection-oriented IP transport protocols (such as TCP, SCTP, DCCP). The IP connection may be either “internally initia

37、ted“ (the IP host in the internal network domain, i.e., relates to an “outgoing call“) or “externally initiated“ (“incoming call“). Assumption 8 MGC/MG awareness concerning UNSAF processes This Recommendation is not related to unilateral self-address fixing (UNSAF; see b-IETF RFC 3424 mechanisms lik

38、e, e.g., STUN b-IETF RFC 3489 or Teredo b-IETF RFC 4380). Support of UNSAF is FFS, e.g., in the future Rec. ITU-T H.248.37 (06/2008) 3 Recommendation ITU-T H.248.50 (UNSAF support could be, e.g., the support of UNSAF client or server functions by H.248 entities). The mechanism defined in this Recomm

39、endation is applicable to any IP data stream. It can be used for any type of UDP or TCP-based application-level framing protocol, for example: RTP/RTCP, T.38, MSRP, HTTP. 1.1.1 Applicability statements (for IP NAPT traversal package) The IP NAPT traversal package version 1 supports: the detection of

40、 the used remote source address/port and correspondent usage as destination address/port towards remote side, whereby the MGC enables LATCH mode; the detection of a single remote source address/port change and correspondent adaptation of the used destination address/port towards remote side, whereby

41、 the MGC must trigger each individual expected change via RELATCH mode; the implicit filtering of incoming packets so that only packets matching the detected address/port are admitted for further processing. The IP NAPT traversal package version 1 does not support the autonomous detection of a multi

42、ple remote source address/port changes and correspondent adaptation of the used destination address/port towards remote side; NOTE 1 Such a capability could be addressed by a new parameter for the latch signal. This is for further study. NOTE 2 A potential use case could be a continuous re-latching

43、mode for VoIP terminals, which apply frequent IP port changes (e.g., due to security reasons) during the lifetime of the bearer connection. the automatic adaptation of any filtering rules created by other packages. 1.1.2 Applicability statements concerning IP versions The packages of this Recommenda

44、tion, the IP NAPT traversal package version 1, the address reporting package version 1, and the statistics package for discarded packets due to latching version 1, are all applicable for IPv4 and IPv6 protocol versions. 1.1.3 Relation between packet filters and address latching For a particular term

45、ination/stream where latching is enabled, there may be an interaction between packet filters described in other Recommendations and the latching functionality described in this package. Such filters are, for instance, defined by b-ITU-T H.248.43 (Note). In particular, the scope here is filter types

46、with address-based policy rules. The conditions of such a filter type are based on a specific address/port value or a specific range of addresses/ports. If a filtering condition is specified for the incoming stream, the filtering is applied before latching, i.e., only packets that are permitted acco

47、rding to the filtering condition are considered for latching or re-latching. NOTE Filters are typically strictly controlled by the MGC, e.g., SIP/SDP-signalled source filtering according to b-IETF RFC 4570 would be first processed at the MGC level and, e.g., translated into a correspondent H.248.43

48、signalling. The transfer of RFC 4570 SDP “a=source-filter“ attribute from the SIP/SDP to the H.248/SDP interface is possible in principle, but is not in scope of this Recommendation and b-ITU-T H.248.43. The relation between address latching and implicit packet filtering is described in clause 6.6.7

49、. 1.2 Reporting of new or detected changes of remote address information The address reporting package (see clause 7) may be optionally used in addition to the IP NAPT traversal package. The usage of this capability could be beneficial for the MGC in order to get the following information: 4 Rec. ITU-T H.248.37 (06/2008) 1) when the event of address information changes occurred, if at all, i.e., when the MG successfully latched or re-latched respectively; or 2) what is the new address information; or