1、INTERNATIONAL TELECOMMUNICATION UNION ITU=T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU J.121 (0212002) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER M U LTI M EDIA SIGNALS Interactive systems for digital television distribution Quality control protocol for w
2、ebcasting ITU-T Recommendation J. 121 ITU-T J-SERIES RECOMMENDATIONS CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS General Recommendations General specifications for analogue sound-programme transmission Performance characteristics of analogue sound-prog
3、ramme circuits Equipment and lines used for analogue sound-programme circuits Digital encoders for analogue sound-programme signals Digital transmission of sound-programme signals Circuits for analogue television transmission Analogue television transmission over metallic lines and interconnection w
4、ith radio-relay links Digital transmission of television signals Ancillary digital services for television transmission Operational requirements and methods for television transmission Interactive systems for digital television distribution Transport of MPEG-2 signals on packetised networks Measurem
5、ent of the quality of service Digital television distribution through local subscriber networks IPCablecom Miscellaneous Application for Interactive Digital Television J. 1-J.9 J. 10-5.19 J.30-J.39 J.40-J.49 J.60-J.69 J.70-J.79 J.80-J.89 J.90-J.99 5.110-5.129 J.20-J.29 J.50-J.59 J.100-J.109 J. 130-J
6、. 139 J. 140-J. 149 J.150-J.159 J. 160-J. 179 J. 180-J. 199 J.200-J.209 I For further details, please refer to the list of ITU-T Recommendations. ITU-T Recommendation 5.121 Quality control protocol for webcasting Summary This Recommendation defines protocols between a server and a client in order to
7、 distribute sound and television programs by J.120, i.e. perform “webcasting“, over a general IP network, which is a non-QoS guaranteed network where data error or packet losses may occur. The use of these protocols results in an improvement of quality. A scheme is provided wherein a quality report
8、is sent from a client to the server, and the server performs optimum data distributions according to the clients report. This Recommendation defines the kinds of parameters that a client should report to the server, as well as a transmission protocol that is used for sending the report from the clie
9、nt to the server. This Recommendation also defines transmission of supporting parameters that are useful for the server to analyze the clients report. Source ITU-T Recommendation J. 121 was prepared by ITU-T Study Group 9 (2001 -2004) and approved under the WTSA Resolution 1 procedure on 13 February
10、 2002. ITU-T Rec. 5.121 (02/2002) 1 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 for studying technical,
11、 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 study groups which, in tu
12、rn, 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 with IS0 and IEC. NOT
13、E 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 this Recommendation may
14、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 development process. As of the date of approval of this
15、Recommendation, ITU had not 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 TSB patent databa
16、se. O ITU 2002 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. 11 ITU-T Rec. 5.121 (02/2002) CONTENTS Page Scope . 1 References . 1 2.1 Normative references 1 2.2 Informative references 1 Terms and definitions
17、1 . 1 Abbreviations and conventions . 4.1 Abbreviations . 1 4.2 Conventions 2 System definition 2 5.1 Procedure for the server 3 5.1.1 Transmission of measurement support information . 3 5.1.2 Reception of the clients report . 3 5.1.3 Distribution of media data 3 5.2 Procedure for the client . 3 5.2
18、.1 Monitoring of transmission quality 3 5.2.2 Transmission of the clients report to the server . 3 Definition of a Report Packet . 6.1 Sender Report (SR) . 4 6.2 Receiver Report (RR) . 5 4 RTCP transmission interval 7 Appendix I - Algorithms . Appendix II - RTP header validity checks 8 11 14 14 17 A
19、ppendix III - Determining the number of RTP packets expected and lost . Appendix IV - Computing the RTCP transmission interval . Appendix V - Estimating the inter-arrival jitter ITU-T Rec. 5.121 (02/2002) . 111 ITU-T Recommendation 5.121 Quality control protocol for webcasting 1 Scope The response o
20、f the server after receiving the clients report is outside the scope of this Recommendation. 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 e
21、ditions 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 v
22、alid ITU-T Recommendations is regularly published. 2.1 Normative references - ITU-T Recommendation H.225.0 (2000), Call signallingprotocols and media stream packetization for packet- based multimedia communication systems. ITU-T Recommendation J. 120 (2000), Distribution of sound and television prog
23、rams over the IP network. - 2.2 Informative references - IETF RFC 1889, (1996), RTP: A Transport Protocol for Real-Time Applications. 3 Terms and definitions This Recommendation defines the following terms: 3.1 defined in ITU-T Rec. H.225.0. 3.2 H.225.0. 3.3 television programs over the IP network.
24、real-time transport protocol (RTP): A transport protocol for real-time applications RTP control protocol (RTCP): A control protocol for RTP packets defined in ITU-T Rec. webcasting: “Webcasting“ is defined in ITU-T Rec. 5.120. Distribution of sound and 4 Abbreviations and conventions 4.1 Abbreviatio
25、ns This Recommendation uses the following abbreviations: IP Internet Protocol RTCP RTP Control Protocol RTP Real-time Transport Protocol TCP Transmission Control Protocol UDP User Datagram Protocol ITU-T Rec. 5.121 (02/2002) 1 4.2 Conventions If this Recommendation is implemented, the key words “MUS
26、T“ and “SHALL“ as well as “REQUIRED“ are to be interpreted as indicating a mandatory aspect of this specification. The keywords indicating a certain level of significance of a particular requirement that are used throughout this Recommendation are summarized below. “MUST“ “MUST NOT“ It SHOULD“ “SHOU
27、LD NOT“ “MAY I This word or the adjective WEQUIRED“ means that the item is an absolute requirement of this specification. This phrase means that the item is an absolute prohibition of this specification. This word or the adjective “RECOMMENDED“ means that there may exist valid reasons in particular
28、circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full im
29、plications should be understood and the case carefully weighed before implementing any behavior described with this label. This word or the adjective “OPTIONAL“ means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because i
30、t enhances the product, for example; another vendor may omit the same item. 5 System definition Figure 1 shows the system and its signal flow between the server and the clients. In this scheme, Sender Report (SR) and Receiver Report (RR) of RTCP are used for exchanging information between the server
31、 and the client. The RTCP is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the media data packets. The underlying protocol shall provide multiplexing of the data and control packets, for example using separate port
32、numbers with UDP. 2 Webcasting server c Media data SR (Sender RR (Receiver TO91423042 Figure 115.121 - Block diagram of quality control scheme for webcasting ITU-T Rec. 5.121 (02/2002) 5.1 Procedure for the server 5.1.1 First of all, the server transmits measurement support information which include
33、s a reference time and information regarding the transmitted packets to the client. This measurement information is used by the client to make a clients report and used by the server to analyze the clients report. Although the transmission interval for this information is not defined by this Recomme
34、ndation, clause 7 describes recommended transmission interval. This information is conveyed by a SR (Sender Report) packet defined in 6.1. The SR packet is sent using a separate port number from the media data (video/audio). The port number is given by the session initiation of the J. 120 protocol,
35、which is just after (plus one) the Media Data RTP port number. 5.1.2 The server shall always be in such a state as to be able to receive the report packet from the client. 5.1.3 Distribution of media data The server should perform optimum distribution of media data (audiohideo) according to the resu
36、lts of analyzing the report packet from the client. The actual method of controlling distribution is a matter of implementation, and is outside the scope of this Recommendation. Transmission of measurement support information Reception of the clients report 5.2 Procedure for the client 5.2.1 Monitor
37、ing of transmission quality The client monitors the condition under which the media data is received and measures the transmission quality. The parameters to be measured are described in 6.2. In the measurement, the client shall calculate these parameters based on the aforesaid measurement support i
38、nformation transmitted from the server. 5.2.2 The transmission quality measured at the client is transmitted to the server as a clients report. The clients report shall be conveyed as an RR (Receiver Report) packet defined in 6.2. The RR packet is sent using given port number by the session initiati
39、on of the J. 120 protocol. Transmission of the clients report to the server ITU-T Rec. 5.121 (02/2002) 3 6 Definition of a Report Packet O11 I v=2 I 6.1 Sender Report (SR) 2 314151617 81910(112131415 61718191011121314151617181910(1 P RC=O PT=2OO(SR) Length IlII IlIIIII IIIIIIIIIIIIIII IlII IlIIIII I
40、IIIIIIIIIIIIII IlII IlIIIII IIIIIIIIIIIIIII Figure 2/5.121- Packet format of the Sender Report (SR) The sender report packet consists of two sections. The first section, the header, is 8 octets long. The fields have the following meaning: version (V): 2 bits. Identifies the version of RTP, which is
41、the same in RTCP packets as in RTP data packets. The version defined by this Recommendation is two (2). padding (P): 1 bit. If the padding bit is set, this RTCP packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a
42、 count of how many padding octets should be ignored. Padding may be needed by some encryption algorithms with fixed block sizes. In a compound RTCP packet, padding should only be required on the last individual packet because the compound packet is encrypted as a whole. reception report count (RC):
43、5 bits. The number of reception report blocks contained in this packet. A value is always zero. packet type (PT): 8 bits. Contains the constant 200 to identifj this as an RTCP SR packet. length: 16 bits. The length of this RTCP packet in 32-bit words minus one, including the header and any padding.
44、(The offset of one makes zero a valid length and avoids a possible infinite loop in scanning a compound RTCP packet, while counting 32-bit words avoids a validity check for a multiple of 4.) SSRC: 32 bits. The synchronization source identifier for the originator of this SR packet. The second section
45、, the sender information, is 20 octets long and is present in every sender report packet. It summarizes the data transmissions fiom this sender. The fields have the following meaning: NTP time-stamp: 64 bits. Indicates the wallclock time when this report was sent so that it may be used in combinatio
46、n with time-stamps returned in reception reports from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the time-stamp may be limited to far less than the resolution of the NTP time-stamp. The measurement uncertainty of the
47、 time-stamp is not indicated as it may not be known. A sender that can keep track of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is 4 ITU-T Rec. 5.121 (02/2002)
48、 permissible to use the sampling clock to estimate elapsed wallclock time. A sender that has no notion of wallclock or elapsed time may set the NTP time-stamp to zero. RTP time-stamp: 32 bits. Corresponds to the same time as the NTP time-stamp (above), but in the same units and with the same random
49、offset as the RTP time-stamps in data packets. This correspondence may be used for intra- and inter-media synchronization for sources whose NTP time-stamps are synchronized, and may be used by media-independent receivers to estimate the nominal RTP clock frequency. Note that in most cases this time-stamp will not be equal to the RTP time-stamp in any adjacent data packet. Rather, it is calculated from the corresponding NTP time- stamp using the relationship between the RTP time-stamp counter and real time as maintained by periodically checking the wallclock time at a sampling
