1、 International Telecommunication Union ITU-T Series HTELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Supplement 5(11/2006) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSGateway control protocol: Guidelines for resource management of IP Address Q.1970 in BICC CS2-controlled VoRTP media gateways; SIP/SD
2、P in SIP VoRTP media gateways or terminals; RTSP; or others. 2 References ITU-T H.248.1 ITU-T Recommendation H.248.1 (2005), Gateway control protocol: Version 3. 3 Terms and definitions This Supplement uses the following terms and definitions: 3.1 5-tuple: The commonly used tuple of IP protocol cont
3、rol information fields. A 5-tuple is a subset of an address tuple. 3.2 address tuple: It is defined in section 2.3.5/IETF RFC 3989. 3.3 RTP 3-tuple (R3T): The specifically used address tuple in this Supplement of for characterizing the main logical RTP endpoint resources. NOTE There are four RTP 3-t
4、uples (abbreviated as R3TRx,L, R3TTx,L, R3TRx,Rand R3TTx,R) in a bidirectional RTP/RTCP Session from end-to-end perspective (Figure 1). 2 H series Supplement 5 (11/2006) Figure 1 RTP 3-tuples in a bidirectional RTP/RTCP session 3.4 symmetric RTP/RTCP: Identical values of address and ports in the two
5、 local RTP 3-tuples in case of a bidirectional RTP/RTCP session, i.e., R3TRx,Lequals to R3TTx,L. NOTE There is no condition of symmetry at remote side, i.e., remote RTP 3-tuples could be asymmetrical (R3TRx,Rnot equal to R3TTx,R). 4 Abbreviations This Supplement uses the following abbreviations: BIC
6、C Bearer Independent Call Control CAHT Call Holding Time COHT Context Holding Time CRD Call Release Delay CS2 Capability Set 2 (BICC) CSD Call Setup Delay CSN Circuit-Switched Network DA Destination Address (IP) DP Destination Port (IP) IPRxIP traffic in receive direction (“ingress traffic“) IPTxIP
7、traffic in transmit direction (“egress traffic“) IS In-Service (H.248) IT Idle Time LD Local Descriptor (H.248) MG Media Gateway H series Supplement 5 (11/2006) 3 MGC Media Gateway Controller NGN Next Generation Network OoS Out-of-Service (H.248) PSN Packet Switched Network R3T RTP 3-Tuple RCT Resou
8、rce Cycle Time RD Remote Descriptor (H.248) RTCP RTP Control Protocol RTP Real-time Transport Protocol RTPRx,LLocal sink for RTP traffic RTPRx,RRemote sink for RTP traffic RTPTx,LLocal source for RTP traffic RTPTx,RRemote source for RTP traffic RTSP Real-time Streaming Protocol SA Source Address (IP
9、) SC ServiceChange (H.248) SDP Session Description Protocol SIP Session Initiation Protocol SP Source Port (IP) VoRTP Voice-over-RTP 5 Background: Still active RTP source of a released RTP session The problem may be illustrated as follows. A point-to-point bidirectional RTP session is part of an end
10、-to-end communication service, for instance, a speech telephony call between participants A and B in Figure 2. Figure 2 First call A-B 4 H series Supplement 5 (11/2006) The scope of this Supplement corresponds to the RTP endpoints located in H.248 entities, like VoIP media gateways (MG) or media ser
11、vers (MS). Figure 2 shows such an example whereby H.248 termination RB represents one RTP endpoint. The peer RTP endpoint RA is located in a generic “RTP entity“, which may be for instance again a H.248 MG or a SIP terminal. Both RTP endpoints are in state “sendreceive“. The resource RTP is mainly c
12、haracterized by different resource component types: 1) a transport connection endpoint given by the IP address and UDP port pair for RTP and RTCP (all three connection elements are also known as “RTP 3-tuple“); 2) further RTP protocol control information fields (particularly the SSRC/CSRC and SDES (
13、Note 1) fields for source description); and 3) transport capacity (bit rate reservations and allocations). NOTE 1 There are eight items defined by IETF RFC 3551 (see sections 6.4.1 to 6.4.8) to describe (and identify) an RTP source: CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE, PRIV. If the RTP source
14、 description information is used in an RTP session, then will be this kind of information exchanged via RTCP SDES packets. The scope of this Supplement corresponds to the logical resource type of the first list item, the 3-tuple of IP address and the two ports for RTP and RTCP. The number of such 3-
15、tuples is limited per H.248 MG (e.g., circuit-to-packet H.248 MGs like TDM-to-RTP or ALN-to-RTP for VoIP, or packet-to-packet H.248 MGs like IP-to-IP, UDP-to-UDP or RTP-to-RTP), defining its theoretical maximum capacity of parallel RTP sessions. NOTE 2 It is usually a theoretical maximum due to the
16、16-bit port range per IP address. The entire port range is typically not used in todays technique. If the required port capacity is very high, or even greater than the 16-bit range, then more than one IP address will be used. A physical IP interface for RTP traffic is then overloaded with multiple l
17、ogical IP interfaces. Call A-B shall then be released. Figure 3 shows the snapshot after the H.248 SUBTRACT command of RBand release of Context C1. Send process or RTP RBis then stopped and received RTP packets for RBwill be silently discarded. Peer RTP endpoint RAis not yet released, thus still tra
18、nsmitting RTP and RTCP packets towards RB. Figure 3 Call legs/context release finished in MG H series Supplement 5 (11/2006) 5 The H.248 MG then receives a new context request attempt (for new call C-D) by H.248 ADD commands for TDM and RTP resources for Context C2 (Figure 4). Figure 4 MG allocates
19、“RBresources“ for RD in next context The MG allocates the previously deallocated resources (“3-tuple“) of RBto new H.248 termination RD. This leads to an RTP crosstalk situation at RTP receiver RD, as long as RTP endpoint RAremains active (Figure 5). RTP crosstalks are a serious issue because the co
20、mmunication in that direction may be completely disturbed (e.g., different codec types, packetization times, etc.). It is typically not straightforward for the RTP receiver process RDto filter out and discard all received packets from source RA. Such a filter process requires a correspondent policy
21、rule (see clause 6.3.2.3.1, describing a possible rule). Figure 5 RTP crosstalk situation at RD receiver RTP crosstalk situations must be avoided or resolved as soon as detected. 6 H series Supplement 5 (11/2006) 6 Problems and solution proposals There might be different reasons for RTP crosstalk si
22、tuations. 6.1 Cause “Hanging termination“ 6.1.1 Problem statement A hanging H.248 termination is defined in clause 3.1/H.248.36. This is a failure situation, e.g., due to data synchronization issues between MGC and MG. Such data inconsistencies may be in principle on MGC and MG level. Relevant here
23、is only the MG case because only a “hanging RTP termination on MG level“ may generate RTP packets. A hanging RTP termination should be a rather exceptional event because “successful bearer release“ procedures are supposed: there is a positive acknowledgement by the MG with a SUBTRACT.reply on the SU
24、BTRACT.request command from the MGC. The hanging RTP termination within the VoRTP MG is therefore caused by MG-internal synchronization issues here. 6.1.2 Solution: H.248.36 for “Hanging Termination“ Package H.248.36 is designed for hanging terminations. A timer resource will be additionally associa
25、ted with the RTP resource. The MG notifies the MGC in case of timer expirations. ITU-T Rec. H.248.36 recommends timer configuration in the range “of a multiple of the typical context lifetime“ (see clause 5.2.1.1.1/H.248.36). A detected hanging H.248 termination may not be autonomously released by t
26、he MG, this action is still under the responsibility of the MGC. 6.2 Cause “Disconnected VoRTP media gateway“ 6.2.1 Problem statement A MG may be temporarily disconnected from his MGC, either by an interrupted H.248 transport connection, or an out-of-service MGC. The MG then tries to reconnect to th
27、e primary or a secondary MGC by the corresponding ServiceChange procedures (see Annex F of ITU-T H.248.1). The states of established contexts and terminations in the MG are unaffected in this situation: during the period of disconnection, H.248 contexts will be all active and their allocated termina
28、tion will remain in-service. RTP terminations, enabled for send, will consequently continue to transmit RTP packets. Disconnection is typically only a very short-term period (Note 1) in networks designed for very high service availability. The H.248 model (Note 2) itself assumes that a disconnected
29、MG will be shortly reconnected to an MGC. NOTE 1 For example, disconnect period mean CAHT. A worst-case situation is the case, when the k RTP Terminations of a disconnected MG, with correspondent k active Phy-to-RTP Contexts (Note 4), will continue RTP packet generation, whereas the k peer RTP endpo
30、ints are already released. NOTE 4 Or k/2 active RTP-to-RTP Contexts as another example. H series Supplement 5 (11/2006) 7 6.2.2 Solution There are not any specific solutions defined so far (because of the “short-term disconnect“ assumption). 6.3 Cause “Fast reuse of RTP termination“ 6.3.1 Problem st
31、atement This relates to the case pointed out in clause 5. Such situations may occur due to the “loose synchronization“ of quasi-parallel RTP endpoint release actions for an RTP session, despite the fact of successful call release and bearer release procedures. The probability of such events primaril
32、y is related to the MGs resource management strategy, the engineered MG capacity for RTP sessions, the rate of RTP ADD.request commands(Note), and the operation of the IP network (“MGs IP interfaces for RTP traffic“). NOTE Related to call attempt rate and context attempt rate (see also Supplement 6
33、to ITU-T H-series Recommendations). Any MG “RTP resource“ is either “busy“ or “idle“. The “busy time“ is typically related to the Context holding time (COHT). The “idle time“ is related to the probability of crosstalk events. 6.3.2 Solution(s) 6.3.2.1 Minimum idle time (Waiting period) The problem m
34、ay be solved by sufficient idle time (IT), or an explicit waiting period elapses between the end of an RTP termination and the reuse of the same (3-tuple) RTP resource in a new context. The cycle of busy and idle phase may be characterized by parameter resource cycle time (RCTRTP). The expected mean
35、 idle time IT may be then estimated by RCTRTPminus COHT. It is then recommended that a VoRTP MG implementation guarantee a minimum idle time ITRTP,min. Such a guarantee may be achieved by following design rules. It should be noted that the design rules listed in clause 6.3.2.2 are only exemplary and
36、 non-exhaustive. The minimum idle time ITRTP,minshould be correlated with performance parameter end-to-end connection release delay (CRDE2E) due to assumed cause of the crosstalk problem here. The following qualitative rule may be then stated: ITRTP,min CRDE2ENOTE Provisional values for CRDE2Emay be
37、 for instance derived from ITU-T Recs Y.1530 or I.352, or Telcordia GR-3059-CORE. A value of approximately 10 seconds for ITRTP,minmay be for instance a sufficient estimate (when considering quantiles of CRD). 6.3.2.2 Some design rules 6.3.2.2.1 Resource management policy The pool of idle RTP “3-tup
38、le“ resources must not be accessed randomly, because such a policy does not allow any idle time guarantees. A “first-in, first-out“ policy maximizes the idle time. 6.3.2.2.2 Theoretical maximum of RTP “3-tuples“ Every IP interface provides a theoretical space of 32K port pairs for RTP/RTCP sessions
39、(“32.768 3-tuples per IP interface“). Multiple IP addresses may be assigned to a physical IP interface. There are then multiple logical IP addresses per physical IP interface. Assignment of additional IP addresses may be used to multiply the number of available RTP “3-tuple“ resources. 8 H series Su
40、pplement 5 (11/2006) NOTE An IP interface in a VoIP MG may be either used for RTP traffic only, i.e., complete space of 32K port pairs is usable, or operated as general-purpose IP interface, i.e., the available space is then reduced by well-known ports, reserved ports, etc. 6.3.2.3 Filter rules 6.3.
41、2.3.1 Source filtering in general Figure 6 recalls again the H.248 process for configuration of the IP DA for incoming RTP traffic via the H.248 LD, and the IP DA for outgoing RTP traffic via the H.248 RD of a H.248 RTP Termination. Figure 6 H.248 LD and A2 the H.248 RD “DA“ with the IPRx“SA“ beside
42、s the IPTx“DA“. Such a correlation may be the natural consequence of a single (physical or logical) IP interface. H series Supplement 5 (11/2006) 9 Figure 7 Correlation between IP DA or two separate commands by first ADD.request with LD and a subsequent MODIFY.request with RD, due to the (potential)
43、 asymmetry of RTP session establishment. The worst case is the second scenario from an RTP crosstalk point of view. The period between the two H.248 commands does not allow source port filtering, or more general, source port filtering may not start until the availability of the complete specified RD
44、 in the MG. There are two possible extensions of the filter rule concerning handling of incoming RTP traffic during this transition period: 1) promiscuous receipt of RTP and RTCP packets irrespective of the source RTP 3-tuple; or 2) rejection of all RTP and RTCP packets until IPEgress“DA“ is availab
45、le via H.248 RD in MG. It is recommended to follow the first rule extension, primarily due to the exceptional character of RTP crosstalk, short-term nature of transition period, consistency with H.248.1 (see also next subclause) and potential VoRTP services with “early media“. NOTE The above transit
46、ion period is typically in a time range much smaller than 100 ms when considering CRDE2Eperformance objectives (and for calls in the 95%-quantile of CSD). 6.3.2.3.3 Applicability statements for source port filtering Source port filtering may not be applied in general. The following aspects may limit
47、 the applicability: dedicated StreamMode settings (e.g., RecvOnly) in LocalControl descriptor of RTP termination; specific topology descriptor settings; RTP traffic passing NAT/FW device(s); 10 H series Supplement 5 (11/2006) H.248.37 enabled IP terminations (“ingress traffic required for latching“)
48、; or others. 6.3.2.3.4 Explicit support of source port filtering Explicit support of source port filtering capability is within the scope of dedicated H.248 packages for gate management. The gm package defines corresponding H.248 properties. The gm-controlled source port filtering is an explicit mec
49、hanism in H.248 profiles for packet-to-packet MGs (e.g., ETSI TS 102 333, ETSI ES 283 018). 6.3.2.3.5 Explicit indication of source filtering via SDP source-filter attribute IETF RFC 4570 defines an SDP extension for a dedicated attribute with regard to source filtering. This attribute must correlate with an existing value in the session description. Syntax and semantics of the SDP source-filter attribute are defined in section 3/RFC 4570, as well as applicability limitations. The usage of this SDP at
