ITU-T H 460 9-2002 Support for Online QoS-Monitoring Reporting within H 323 Systems Series H Audiovisual and Multimedia Systems Supplementary Servies for Multimedia《H 323系统在线服务质量的监.pdf

1、INTERNATIONAL TELECOMMUNICATION UNION ITU=T TELECOMMU N CATION STAN DARD IZATION SECTOR OF ITU H.460.9 (1 1 /2002) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Su p pl em e n ta ry servi ces for m u It i medi a Support for online QoS-monitoring reporting within H.323 systems ITU-T Recommendation H.4

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

3、240-H.259 Coding of moving video H.260-H.279 Related systems aspects H.280-H.299 H.300-H.399 SYSTEMS AND TERMINAL EQUIPMENT FOR AUDIOVISUAL SERVICES SUPPLEMENTARY SERVICES FOR IIkLWDIA 450-H.499 Overview of Mobility and Collaboration, definitions, protocols and procedures H.500-H.509 Mobility for H-

4、Series multimedia systems and services H.5 10-H.519 Mobile multimedia collaboration applications and services H.520-H.529 Security for mobile multimedia systems and services H.530-H.539 Security for mobile multimedia collaboration applications and services H.540-H.549 Mobility interworking procedure

5、s H.550-H.559 Mobile multimedia collaboration inter-working procedures H.560-H.569 MOBILITY AND COLLABORATION PROCEDUIES Forfirrther details, please refer to the list of ITU-T Recommendations. ITU-T Recommendation H.460.9 Support for online QoS-monitoring reporting within H.323 systems Summary This

6、Recommendation describes the procedures and the signalling protocol for reporting online Quality of Service (QoS) monitoring on a call-by-call basis within the H.323 system. This monitoring is performed by the end-points based on real time traffic statistics and reported to the gatekeeper at periodi

7、c intervals, or at call conclusion. These procedures use the H.323 Generic Extensibility Framework (GEF) and therefore do not require any changes to the base standards. Source ITU-T Recommendation H.460.9 was prepared by ITU-T Study Group 16 (2001-2004) and approved under the WTSA Resolution 1 proce

8、dure on 29 November 2002. ITU-T Rec. H.460.9 (11/2002) i FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible fo

9、r studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T stud

10、y 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 of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis

11、with IS0 and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of thi

12、s Recommendation may involve the use of a claimed Intellectual Property Right. IT 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 development process. As of the date

13、of approval of this Recommendation, ITU had received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the T

14、SB patent database. O ITU 2003 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ii ITU-T Rec. H.460.9 (11/2002) CONTENTS Page Scope References . 2.1 Normative references 2.2 Informative reference . Abbreviations

15、 and Acronyms . Feature descnption The QoS-monitoring reporting endpoint procedure . 4.1 Negotiation of the feature . 4.2 4.2.1 Initiation ofthe procedure 4.2.2 Contiquation ofthe procedure 4.2.3 Termination ofthe procedure . 4.2.4 4.3 4.4 Generic data usage Single QoS-monitoring report only at the

16、end of the call The QoS-monitoring reporting gatekeeper (Annex Gm.225.0) procedure . 4.5 Extensibility . Description ofASN.l types and fields . 5.1 End-to-End delay measures 5.2 Packet loss measures 5.3 Throughput measures . 5.4 Network jitter measures Annex A . ASN . 1 definitions ITU-T Rec . H.460

17、.9 (11/2002) 1 1 1 2 2 2 2 3 3 3 3 4 4 4 5 7 iii ITU-T Recommendation H.460.9 Support for online QoS-monitoring reporting within H.323 systems 1 Scope This Recommendation describes the procedures and the signalling protocol based on H.225.ORAS for reporting of per call, online Quality of Service (Qo

18、S) monitoring. QoS for real-time traffic like Voice over IP (VoIP) relies on the QoS of the underlying IP-network. The VoIP user may experience bad voice quality if the network does not meet the requirements for real-time traffic in respect to end-to-end delay, network jitter, and packet loss. Curre

19、ntly, dedicated network probes have to be installed in the network. This Recommendation proposes that the H.323 endpoints capture QoS-monitoring measures, as provided by means of Real-time Transport Control Protocol (RTCP - RFC 1889) per call for a period of time, and forward this information period

20、ically andor at the end of the call to the gatekeeper. NOTE - RTCP conveys feedback about RTP streams directly between endpoints; the gatekeeper does not get this information. Therefore, the gatekeeper has no way of judging the quality of media channels directly. At the gatekeeper this information c

21、an be processed and registered per call, e.g. in the Call Detail Record (CDR), or be forwarded to a dedicated network element for post processing. The registration and post processing of these reports are beyond the scope of this Recommendation. Based on this information the service provider can tak

22、e appropriate actions if these reports show insufficient QoS for real-time traffic at certain communication relations. 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

23、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.

24、 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. 2.1 Normative references 11 2 3 4 5 6 7 IT-T Recommendation H.323 Version 4 (2000), Packet-

25、based multimedia communications systems. ITU-T Recommendation H.225 .O Version 4 (2000), Call signalling protocols and media stream packetization for packet-based multimedia communication systems. ITU-T Recommendation X.680 (2002), Information technology -Abstract Syntax Notation One (ASNI): Speciji

26、cation of basic notation. ITU-T Recommendation X.69 1 (2002), Information technology - ASN. I encoding rules: Specijication of Packed Encoding Rules (PER). ITU-T Recommendation H.460.1 (2002), Guidelines for the use of the Generic Extensible Framework (GEF) . IT-T Recommendation H.225.0 Annex G (199

27、9), Communication between administrative domains. ITU-T Recommendation H.50 1 (2002), Protocol for mobility management and intrahnter- domain communication in multimedia systems. ITU-T Rec. H.460.9 (11/2002) 1 8 IETF RFC 1889 (1996), RTP: A Transport Protocol for Real-Time Applications. 2.2 Informat

28、ive reference - IETF RFC 1305 (1992), Network Time Protocol (Version 3) SpeciJcation, Implementation and analysis. 3 Abbreviations and Acronyms This Recommendation uses the following abbreviations: ACF (RAS) Admission Confirm ARQ (RAS) Admission Request ASN. 1 CDR Call Detail Record DCF (RAS) Diseng

29、age Confirm DRQ (RAS) Disengage Request GEF Generic Extensible Framework IETF Internet Engineering Task Force IRR (RAS) Inforrnation Request Response NTP PER QOS Quality of Service RAS Registration, Admission and Status RCF (RAS) Registration Confirm RFC Request for Comments RR (RTCP) Receiver Repor

30、t RRQ (RAS) Registration Request RTCP RTP Control Protocol RTP Real-time Transport Protocol RTT Round Trip Time SR (RTCP) Sender Report UDP User Datagram Protocol Abstract Syntax Notation One Network Time Protocol (RFC 1305) (ASN. 1) Packed Encoding Rules 4 Feature description 4.1 Negotiation of the

31、 feature Usage of the QoS-monitoring reporting feature is negotiated between endpoint and gatekeeper at call Set-up time as part of the admission request procedure. For this purpose, an endpoint that supports this feature shall include the feature descriptor defined in 4.4 (see Table 1) in featureSe

32、t.supportedFeatures of the ARQ message. If the gatekeeper also supports this feature, it may include the same feature descriptor in the featureset of the ACF message, either as neededFeature if the feature is required for the call, as desiredFeature if the feature is only desired, or as supportedFea

33、ture if the gatekeeper does not 2 ITU-T Rec. H.460.9 (11/2002) care. Omission of the feature indicator from the ACF message means that this feature is not supported or its use is not wanted for this call. An endpoint may also indicate support of this feature when registering with a gatekeeper, by in

34、cluding the feature descriptor in the RRQ message in the same way as described above for ARQ. Likewise, a gatekeeper may indicate its support by including the feature descriptor in the RCF message. 4.2 4.2.1 Initiation of the procedure The procedure is initiated during the H.225.0 Admission procedur

35、e. The Admission Confm (ACF) message contains the following fields that will be set as part of the procedure: featureset - Depending on the content of this field the endpoint: The QoS-monitoring reporting endpoint procedure o shall include QoS-monitoring report parameters in the genericData field of

36、 IRR message(s) should include QoS-monitoring report parameters in the genericData field of IRR may include QoS-monitoring report parameters in the genericData field of IRR message(s) shall not include any QoS-monitoring report parameters in IRR or DRQ/DCF message(s) if andor the DRQDCF message if t

37、he feature is indicated in neededFeatures; message(s) andor the DRQDCF message if the feature is indicated in desiredFeatures; andor the DRQ/DCF message if the feature is indicated in supportedFeatures; the feature is not indicated at all in featureset. o o o irrFrequency - The frequency, in seconds

38、, that the endpoint shall send Information Request Response (IRR) messages to the gatekeeper during a call. The frequency, in seconds, is an implementation - dependent time interval for gathering QoS-monitoring statistics. Since RTCP packets are generated at a rate of one packet per five seconds for

39、 unicast point-to-point connections at a random variation of OS . . . 1.51 times, the time interval should not be less than eight seconds in order to guarantee that the statistics will be meaningful. 4.2.2 Continuation of the procedure For each media connection a unidirectional RTP data flow is gene

40、rated by the endpoint. At a separate transport address (default: UDP/RTP-port number plus one) RTCP messages are exchanged containing feedback information from which network transport service QoS can be derived. See RFC 1889 for details regarding RTP and RTCP. For the time interval specified in irrF

41、requency of the Admission Confirm (ACF) message and conveyed during the initiation procedure, this information shall be gathered and statistically processed in terms of short-term and long-term measures. The resulting values shall be populated and included in the genericData field of Information Req

42、uest Response (IRR) messages that are issued to the gatekeeper at a frequency of irrFrequency. If the optional parameter qosMonitoringFinalOnly was included when the feature was initiated, then no QoS monitoring reporting data shall be included in any IRR messages. NOTE - If no irrFrequency value wa

43、s returned in the ACF message, no unsolicited IRR messages and thus no periodic QoS-monitoring reports will be sent, but a final report will be included in DRQ or DCF if the QoS-monitoring reporting feature was initiated. 4.2.3 Termination of the procedure When the call is released, either a Disenga

44、ge Request (DRQ) message is issued by the endpoint that carries in the genericData field the information for the final time interval, or the endpoint includes this information in the DCF message if it received a DRQ message from the gatekeeper. ITU-T Rec. H.460.9 (11/2002) 3 4.2.4 In order to allow

45、an endpoint to send only a summary QoS-monitoring report at the end of the call, regardless of the value of irrFrequency, parameter qosMonitoringFinalOnly may be included when negotiating the feature. The genericData for QoS-monitoring reporting will then be included only in the DRQ or DCF message.

46、Single QoS-monitoring report only at the end of the call Feature name: Feature Description: Feature identifier type: Feature identifier value: 4.3 Since one gatekeeper obtains information only from H.323 endpoints registered to it, it is necessary to exchange complementary QoS-monitoring report info

47、rmation for bidirectional media connections between the two gatekeepers involved in a particular call. This can be done by means of the usage information exchange procedures specified in Annex GlH.225 .O, by including the genericData for QoS-monitoring reporting in UsageIndication messages. The data

48、 sent by a gatekeeper in a QoS- monitoring report are those gathered by this gatekeeper locally for a specific call from an endpoints QoS-monitoring reports. Exchange of genericData for QoS-monitoring reporting is negotiated between gatekeepers on a per-call basis as described in 4.1 above, except t

49、hat UsageRequesWsageConfirmation messages are used rather than ARQ/ACF. If reports are required in both directions, the usage information exchange procedures are initiated independently for each direction. The gatekeeper requesting QoS-monitoring reports indicates in the UsageRequest message when UsageIndication messages shall be sent; periodically or only at the end of the call. The interval for sending periodic reports may be different for each direction, and also different from the interval for IRR messages. Refer to ITU-T Rec. H.501 for details regarding the usage r