ITU-T H 460 21-2006 Message broadcast for H 323 systems《H 323信息广播》.pdf

《ITU-T H 460 21-2006 Message broadcast for H 323 systems《H 323信息广播》.pdf》由会员分享，可在线阅读，更多相关《ITU-T H 460 21-2006 Message broadcast for H 323 systems《H 323信息广播》.pdf（16页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T H.460.21TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (05/2006) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Supplementary services for multimedia Message broadcast for H.323 systems ITU-T Recommendation H.460.21 IT

2、U-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 Cod

3、ing 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.369 S

4、upplementary 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 H.

5、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 MULTIMEDI

6、A SERVICES Broadband multimedia services over VDSL H.610H.619 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. H.460.21 (05/2006) i ITU-T Recommendation H.460.21 Message broadcast for H.323 systems Summary This Recommendation defines a feature wherein H.323 devices

7、may broadcast (using multicast) a message to one or more remote H.323 terminals, such as providing an “intercom“ function for enterprise telephones, a “paging“ service through an enterprise, or a notification system to geographically dispersed terminals. Since the method utilizes standard Internet m

8、ulticast procedures, the feature may be used on a wide scale to reach any number of H.323 endpoints in a geographic region or even the entire world. Source ITU-T Recommendation H.460.21 was approved on 29 May 2006 by ITU-T Study Group 16 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii I

9、TU-T Rec. H.460.21 (05/2006) 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, operat

10、ing 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 turn, pro

11、duce 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 ISO and IEC. NOTE In th

12、is 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. inter

13、operability 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 c

14、ompliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, vali

15、dity 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 Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be requ

16、ired 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 database. ITU 2006 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, wit

17、hout the prior written permission of ITU. ITU-T Rec. H.460.21 (05/2006) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Normative references 1 2.2 Informative references 1 3 Abbreviations and acronyms 2 4 Functional overview . 2 5 Message content . 3 6 Message priority . 3 7 Gateway considerations 4

18、 8 Capability advertisement 4 8.1 Endpoint advertisement 5 8.2 Gatekeeper acknowledgement 5 Annex A ASN.1 definitions 7 ITU-T Rec. H.460.21 (05/2006) 1 ITU-T Recommendation H.460.21 Message broadcast for H.323 systems 1 Scope This Recommendation describes the signalling and procedures to provide a m

19、essage broadcast feature for H.323 systems. The message broadcast feature is one wherein a message server or H.323 endpoint in the network transmits a message to one or more endpoints in a predefined multicast group. The message may result in alerting the user or playing audio to a speaker on the ph

20、one without alerting. Messages sent to an H.323 device may interrupt active communication or may be discarded, depending on priority. Messages are not limited to audio: messages may be audio, video, or text messages, the choices of which are negotiated through the procedures described herein. These

21、procedures use the H.323 Generic Extensible Framework (GEF). 2 References 2.1 Normative 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

22、 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 IT

23、U-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 Recommendation H.225.0 (2006), Call signalling protocols and media stream packetization for packet-based multimedia co

24、mmunication systems. ITU-T Recommendation H.245 (2006), Control protocol for multimedia communication. ITU-T Recommendation H.323 (2006), Packet-based multimedia communications systems. ITU-T Recommendation H.460.1 (2002), Guidelines for the Use of the Generic Extensible Framework. ITU-T Recommendat

25、ion X.680 (2002) | ISO/IEC 8824-1:2002, Information technology Abstract Syntax Notation One (ASN.1): Specification of basic notation. ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002, Information technology ASN.1 encoding rules Specification of Packed Encoding Rules (PER). IETF RFC 3376 (2002

26、), Internet Group Management Protocol, Version 3. IETF RFC 3550 (2003), RTP: A Transport Protocol for Real-Time Applications. IETF RFC 3810 (2004), Multicast Listener Discovery Version 2 (MLDv2) for IPv6. IETF RFC 4103 (2005), RTP Payload for Text Conversation. 2.2 Informative references IETF RFC 35

27、69 (2003), An Overview of Source-Specific Multicast (SSM). 2 ITU-T Rec. H.460.21 (05/2006) 3 Abbreviations and acronyms This Recommendation uses the following abbreviations: ASM Any-Source Multicast ASN.1 Abstract Syntax Notation One GEF Generic Extensible Framework GUID Globally Unique Identifier P

28、ER Packed Encoding Rules RAS Registration, Admission and Status RCF Registration Confirm RRQ Registration Request SSM Source-Specific Multicast 4 Functional overview Devices within an H.323 network that advertise support for the message broadcast feature do so through advertisements in the RRQ messa

29、ges sent to the Gatekeeper. An endpoint may advertise that it is a receiver, a transmitter, or both. This allows a device to serve only to send out broadcast messages or perhaps provide intercom functionality as part of the other telephony functions. Special devices in the network may serve as messa

30、ge broadcast servers and do not necessarily have to be H.323 entities: they only need to have the capacity to send media to multicast groups that may be properly received by H.323 entities operating in accordance with this Recommendation. Such servers are expected to share some information, such as

31、multicast addresses and media attributes, with the Gatekeeper. How the Gatekeeper becomes aware of these servers or how information is shared with them is outside the scope of this Recommendation. Gatekeepers have the ability to provide each endpoint with a list of multicast groups to which the endp

32、oint may join. The list may be unique to each endpoint or a small group of endpoints, perhaps subdividing endpoints according to some logical association, such as a corporate department or geographic region. The way in which groups are defined and placed into the RCF is outside the scope of this Rec

33、ommendation. The addresses provided via the groupAddress field is a multicast address representing the multicast group (G). There is a second, optional, unicast address called sourceAddress representing the source (S) for media transmission. When no particular source is specified for the multicast g

34、roup (referred to as Any-Source Multicast or ASM), a receiving endpoint will accept message content from any device that transmits to that multicast group. No two entities should broadcast messages to the multicast group simultaneously, as that would induce some confusion. Nonetheless, such an event

35、 can occur and when it does, the message received from the highest priority group should be played, or from the first group to deliver a message in the case that the group priorities are the same. How the endpoint handles lower priority messages is implementation dependent; the device may choose to

36、play the contents of the higher priority message, record and play the lower priority message after playing the higher priority message, discard the lower priority message, or take some other action. When a source address is specified for the multicast group (referred to as Source-Specific Multicast

37、or SSM), the endpoint accepts message content only from the source IP address specified. IGMPv3 and MLDv2 both provide mechanisms to allow the endpoint to signal to the network its desire to join the multicast group (S, G). By using SSM, a network administrator can better control the transmission of

38、 broadcast messages by restricting transmission to a small set of broadcast servers. ITU-T Rec. H.460.21 (05/2006) 3 Endpoints may serve as receivers (most common), transmitters, or both. Figure 1 depicts a network with a server transmitting a media flow to a multiplicity of H.323 terminals and gate

39、ways. IPIPIADIPVFigure 1/H.460.21 Multicast message delivered to endpoints 5 Message content Since there may be dozens, hundreds, or tens of thousands of devices that join a multicast group in order to receive broadcast messages, it is impractical to attempt to negotiate media capabilities with all

40、of these devices in order to discover a common subset. As such, all devices that adhere to this Recommendation shall support, at a minimum, G.711 A-law and G.711 -law and shall be prepared to receive messages in either encoding with up to 240 samples (30 ms) of audio per packet. Devices should suppo

41、rt RFC 4103 in order to receive broadcast text messages at a rate up to 30 characters per second. The message content shall be streamed to the endpoint via RTP. However, since messages are intended to be relatively short and transmitted infrequently, the use of RTCP is not considered useful and shal

42、l not be employed with this feature. NOTE H.323 endpoints may indicate a language preference for broadcast messages it receives by including an ordered list of language preferences in the RRQ message transmitted to the Gatekeeper. 6 Message priority In some cases, messages should not disrupt users o

43、n a call and there are other cases when users should be alerted. The alertUser field serves to provide guidance. When the alertUser field is set to TRUE, the receiving H.323 device shall alert the user to the message as if it were an incoming call (e.g., ring the phone). If the H.323 device is engag

44、ed in a 4 ITU-T Rec. H.460.21 (05/2006) call, the message shall be delivered to the user, perhaps replacing one media stream for another. If the alertUser field is FALSE, the message should either be discarded or, if possible, played to the user interface (speaker or display) without alerting the us

45、er. In the case that the H.323 device is actively engaged in a call and the alertUser field is FALSE, the message should be discarded or recorded for later playback. The choice in behaviour is left to the implementer. The priority field is used to provide guidance in dealing with multiple messages t

46、hat may arrive at the same time or overlap in time. Once an endpoint starts delivering a message, the message should not be interrupted by another message unless that other message has a higher priority value. The lower the numeric value of the priority, the higher the priority (i.e., 0 is the highe

47、st priority). User actions may disrupt message delivery. For example, if a departmental page is being delivered to the phones speaker and the user lifts the handset on the phone to place a call, the message should stop playing unless the alertUser field is set to TRUE. In that case, it should contin

48、ue delivery unless deliberately stopped. Methods for control of delivery and termination of delivery through the user interface are outside the scope of this Recommendation. 7 Gateway considerations A gateway is a special device in that it has the capacity to reach a multiplicity of users, though pr

49、esenting itself as a single H.323 entity to the Gatekeeper. The behaviour a gateway takes when it receives a message should be parallel to that of other H.323 devices. For example, if it receives a message for a group for which the user should be alerted, the gateway should attempt to alert users connected to the Gateway. For small gateway devices with ports that connect directly to analog phones, for example, alerting all of the phones is straightforward. However, for larger gateways that are connected to the PSTN without a well-defi