ITU-T J 175-2005 Audio server protocol (Study Group 9)《音频服务器协议 研究组9》.pdf

《ITU-T J 175-2005 Audio server protocol (Study Group 9)《音频服务器协议 研究组9》.pdf》由会员分享，可在线阅读，更多相关《ITU-T J 175-2005 Audio server protocol (Study Group 9)《音频服务器协议 研究组9》.pdf（62页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T J.175TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2005) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom Audio server protocol ITU-T Recommendation J.175 ITU-T Rec. J.175 (11/2005) i I

2、TU-T Recommendation J.175 Audio server protocol Summary This Recommendation describes the architecture and protocols that are required for playing announcements in Voice-over-IP (VoIP) IPCablecom networks. Announcements are typically needed for calls that do not complete. Additionally, they may be u

3、sed to provide enhanced information services to the caller. Different carrier service feature sets require different announcement sets and announcement formats. Announcements can be as basic as fixed-content announcements (e.g., all circuits busy) or as complex as those provided by intelligent IVR (

4、Interactive Voice Response) systems. The IPCablecom service model requires that all announcements be provisioned and signalled in a standard manner for all supported call features and use case scenarios. Source ITU-T Recommendation J.175 was approved on 29 November 2005 by ITU-T Study Group 9 (2005-

5、2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. J.175 (11/2005) 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

6、. 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 Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics fo

7、r 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 of information technology which fall within ITU-Ts purview, the necessary standards are prepared

8、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 operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may con

9、tain 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“ or some other obligatory language such as “must“ and the negative equivalents are used to express

10、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 practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property

11、 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 Recommendation, ITU had received notice of intelle

12、ctual 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 database. ITU 2006 All rights reserved. No part of this publ

13、ication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. J.175 (11/2005) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Normative references 1 2.2 Informative references 2 3 Terms and conventions. 2 3.1 Terms 2 3.2 Conventions 2 4 Abbreviations and

14、 acronyms 3 5 Technical overview. 4 5.1 Architectural requirements . 4 5.2 Announcement definitions 5 5.3 Interface specifications. 5 6 Ann-1 interface: CMS-MTA and MGC-MG 6 6.1 CMS-MTA interface 6 6.2 MGC-MG interface 8 7 Ann-2 interface: MPC-MP . 8 7.1 Introduction 8 7.2 Audio Package concepts. 8

15、7.3 Base Audio Package. 12 7.4 Advanced Audio Package. 25 7.5 Speech recognition . 28 7.6 Formal syntax description 33 Appendix I Call flow for network announcement 37 Appendix II Call flow for MTA-stored announcement 50 II.1 Call flow details 51 BIBLIOGRAPHY 54 ITU-T Rec. J.175 (11/2005) 1 ITU-T Re

16、commendation J.175 Audio server protocol 1 Scope This Recommendation describes the architecture and protocols that are required for playing announcements in Voice-over-IP (VoIP) IPCablecom networks. Announcements are typically needed for calls that do not complete. Additionally, they may be used to

17、provide enhanced information services to the caller. Different carrier service feature sets require different announcement sets and announcement formats. Announcements can be as basic as fixed-content announcements (e.g., all circuits busy) or as complex as those provided by intelligent Interactive

18、Voice Response (IVR) systems. The IPCablecom service model requires that all announcements be provisioned and signalled in a standard manner for all supported call features and use case scenarios. This Recommendation defines a set of signalling protocols that are used to provide announcement service

19、s within a cable network. For one of these protocols the IPCablecom Network Call Signalling (NCS) protocol (ITU-T Rec. J.162) this Recommendation defines two new event packages: a Base Audio Package; an Advanced Audio Package. NOTE There may be cases where audio server implementations are based on p

20、rotocols other than that specified in this Recommendation. If other protocols are implemented, those implementations MUST adhere to IPCablecom-specified architectural and functional requirements, such as security and Quality of Service (QoS), and the required features/capabilities to support interop

21、erability. A variety of such protocols exists, including protocols such as INAP, ITU-T Rec. H.248 and others. 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 Recomme

22、ndation. At the 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 referenc

23、es listed below. 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. ITU-T Recommendation J.161 (2001), Audio codec requirements for the provisi

24、on of bidirectional audio service over cable television networks using cable modems. ITU-T Recommendation J.162 (2005), Network call signalling protocol for the delivery of time-critical services over cable television networks using cable modems. ITU-T Recommendation J.170 (2005), IPCablecom securit

25、y specification. ISO 639-2:1998, Codes for the representation of names of languages Part 2: Alpha-3 code. IETF RFC 2396 (1998), Uniform Resource Identifiers (URI): Generic Syntax. 2 ITU-T Rec. J.175 (11/2005) 2.2 Informative references ITU-T Recommendation J.160 (2005), Architectural framework for t

26、he delivery of time-critical services over cable television networks using cable modems. ITU-T Recommendation J.163 (2005), Dynamic quality of service for the provision of real-time services over cable television networks using cable modems. ITU-T Recommendation J.171.x series (2005), IPCablecom tru

27、nking gateway control protocol (TGCP). Hunt, McGlashan, Speech Recognition Grammar Specification for the W3C Speech Interface Framework, W3C, March 2004. IETF RFC 2234 (1997), Augmented BNF for Syntax Specifications: ABNF. IETF RFC 3435 (2003), Media Gateway Control Protocol (MGCP). ISO 4217:2001, C

28、odes for the representation of currencies and funds. ISO 8601:2004, Data elements and interchange formats Information interchange Representation of dates and times. Sun Microsystems, Java Speech Grammar Format Specification, JSGF, Copyright 1998-99. 3 Terms and conventions 3.1 Terms This Recommendat

29、ion defines the following term: 3.1.1 announcement servers: Also known as Audio Servers, Announcement Servers are network components that manage and play informational tones and messages in response to events that occur in the network. Most announcements are media streams that originate from servers

30、 in the network. Some simple tones and short announcements can also reside at the MTA and in the MG. 3.2 Conventions If this Recommendation is implemented, the keywords “MUST“ and “SHALL“ as well as “REQUIRED“ are to be interpreted as indicating a mandatory aspect of this Recommendation. The keyword

31、s indicating a certain level of significance of particular requirements that are used throughout this Recommendation are summarized below. “MUST“ This word or the adjective “REQUIRED“ means that the item is an absolute requirement of this Recommendation. “MUST NOT“ This phrase means that the item is

32、 an absolute prohibition of this Recommendation. “SHOULD“ This word or the adjective “RECOMMENDED“ means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different cours

33、e. “SHOULD NOT“ This phrase means that there may exist valid reasons in particular circumstances when the listed behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label. ITU-T Re

34、c. J.175 (11/2005) 3 “MAY“ 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 it enhances the product, for example; another vendor may omit the same item. 4 Abbreviations and

35、acronyms This Recommendation uses the following abbreviations: ASP Audio Server Protocol CMS Call Management Server CMTS Cable Modem Termination System DNS Domain Name System DTMF Dual Tone Multi-Frequency E-MTA Embedded MTA H.248 An ITU-T/IETF protocol for media gateway control. Also known as MEGAC

36、O. See www.itu.int. IANA Internet Assigned Numbers Authority IVR Interactive Voice Response MEGACO An IETF/ITU-T protocol for media gateway control. Also known as ITU-T Rec. H.248. See www.ietf.org for details. MGCP Media Gateway Control Protocol MIB Management Information Base MP Media Player MPC M

37、edia Player Controller MTA Media Terminal Adapter NCS Network-based Call Signalling PSTN Public Switched Telephone Network RTP Real-Time Protocol SDP Session Description Protocol SID Service ID. A 14-bit number assigned by a CMTS to identify an upstream virtual circuit. Each SID separately requests

38、and is granted the right to use upstream bandwidth. SNMP Simple Network Management Protocol S-MTA Stand-alone MTA a single node which contains an MTA and a non-J.112 MAC (e.g., Ethernet). TGCP Trunking Gateway Control Protocol TN Telephone Number URI Universal Resource Identifier VoIP Voice-over-IP

39、4 ITU-T Rec. J.175 (11/2005) 5 Technical overview This Recommendation defines a suite of signalling protocols for providing announcement and media services in an IPCablecom network. This clause: defines the architectural requirements for providing IPCablecom announcement and media services; defines

40、and categorizes announcement and media types; defines the components and their roles in the IPCablecom audio server architecture; and describes the signalling and media interfaces. 5.1 Architectural requirements The architectural requirements and assumptions for providing audio and media services fo

41、r an IPCablecom network are listed below. These requirements are based upon the specifications and technical reports that define the IPCablecom architecture. The reference architecture for the IPCablecom network is shown in Figure 1. Figure 1/J.175 IPCablecom network component reference model 5.1.1

42、Call destination This Recommendation defines how announcements are provided for IPCablecom on-net to off-net and on-net to on-net calls1. _ 1Announcements for off-net to on-net calls will usually be handled by the PSTN as a result of SS7 clearing messages. However, when appropriate, they may also be

43、 played from the IPCablecom Media Gateway (MG). ITU-T Rec. J.175 (11/2005) 5 5.1.2 Media formats A Media Player MUST be able to generate the required announcements in any of the code formats required by the IPCablecom Codecs specification (see ITU-T Rec. J.161). 5.1.3 Security Audio MUST be signalle

44、d and played in a secure manner. Security protocols defined in the IPCablecom security specification (see ITU-T Rec. J.170) MUST be supportable in this Recommendation. 5.1.4 Operational support systems Audio servers may be required to support the IPCablecom billing and event message protocols as def

45、ined in ITU-T Rec. J.164. At the current time, no requirement had been identified for support of event reporting by the Media Player. 5.2 Announcement definitions Announcements can be divided into four distinct categories: tones, fixed-content, variable content, and interactive announcements. 5.2.1

46、Tones Includes tones such as reorder, busy, and ringback. 5.2.2 Fixed-content announcements Fixed-content announcements consist of audio messages with fixed-content that require no user interaction. For example, “Your call did not go through. Please hang up and try your call again“. 5.2.3 Variable-c

47、ontent announcements Variable-content announcements are messages that contain a customizing parameter(s) yet require no user interaction. For example, “The number you have dialled, 321-9876, has been changed. The new number is 321-6789“. 5.2.4 Interactive announcements Interactive announcements are

48、announcements that require user interaction, DTMF (Dual Tone Multi-Frequency) or IVR. For example, “The number you have dialled, 541-321-9876, has been changed. The new number is 541-321-6789. To be connected to the new number, at a cost of thirty-five cents, please press 1“. 5.2.5 Naming convention

49、s for endpoint identifiers A flat name space for endpoints is used, with audio ports indicated by the prefix aud and the port number, e.g., aud/12audio-server-. Wild cards ($, *) MAY by used in place of the port numbers in accordance with standard NCS rules for wild card use. Systems that support announcements only (i.e., no digit collection, no recording, and no speech recognition ability) MAY use the prefix ann instead of aud. Some systems may use one additional level in the naming scheme