Network Working Group J. Van Dyke
Request for Comments: 4722 E. Burger, Ed.
Category: Informational Cantata Technology, Inc.
A. Spitzer
Pingtel Corporation
November 2006
Network Working Group J. Van Dyke
Request for Comments: 4722 E. Burger, Ed.
Category: Informational Cantata Technology, Inc.
A. Spitzer
Pingtel Corporation
November 2006
Media Server Control Markup Language (MSCML) and Protocol
媒体服务器控制标记语言（MSCML）和协议
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.
媒体服务器控制标记语言（MSCML）是一种与SIP结合使用的标记语言，用于提供高级会议和交互式语音响应（IVR）功能。MSCML提供了一个应用程序级控制模型，而不是设备级控制模型。该协议的一个用途是用于IETF SIP会议框架中的会议焦点和混合器之间的通信。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. MSCML Approach ..................................................5
3. Use of SIP Request Methods ......................................6
4. MSCML Design ....................................................8
4.1. Transaction Model ..........................................8
4.2. XML Usage ..................................................9
4.2.1. MSCML Time Values ...................................9
5. Advanced Conferencing ..........................................10
5.1. Conference Model ..........................................10
5.2. Configure Conference Request <configure_conference> .......11
5.3. Configure Leg Request <configure_leg> .....................13
5.4. Terminating a Conference ..................................14
5.5. Conference Manipulation ...................................15
5.6. Video Conferencing ........................................16
5.7. Conference Events .........................................17
5.8. Conferencing with Personalized Mixes ......................18
5.8.1. MSCML Elements and Attributes for
Personalized Mixes .................................19
5.8.2. Example Usage of Personalized Mixes ................20
6. Interactive Voice Response (IVR) ...............................23
6.1. Specifying Prompt Content .................................24
6.1.1. Use of the Prompt Element ..........................24
6.2. Multimedia Processing for IVR .............................30
6.3. Playing Announcements <play> ..............................31
6.4. Prompt and Collect <playcollect> ..........................32
6.4.1. Control of Digit Buffering and Barge-In ............33
6.4.2. Mapping DTMF Keys to Special Functions .............33
6.4.3. Collection Timers ..................................35
6.4.4. Logging Caller DTMF Input ..........................36
6.4.5. Specifying DTMF Grammars ...........................36
6.4.6. Playcollect Response ...............................37
6.4.7. Playcollect Example ................................38
6.5. Prompt and Record <playrecord> ............................38
6.5.1. Prompt Phase .......................................38
6.5.2. Record Phase .......................................39
6.5.3. Playrecord Example .................................41
6.6. Stop Request <stop> .......................................42
7. Call Leg Events ................................................43
7.1. Keypress Events ...........................................43
7.1.1. Keypress Subscription Examples .....................45
7.1.2. Keypress Notification Examples .....................45
7.2. Signal Events .............................................46
7.2.1. Signal Event Examples ..............................47
8. Managing Content <managecontent> ...............................48
8.1. Managecontent Example .....................................50
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. MSCML Approach ..................................................5
3. Use of SIP Request Methods ......................................6
4. MSCML Design ....................................................8
4.1. Transaction Model ..........................................8
4.2. XML Usage ..................................................9
4.2.1. MSCML Time Values ...................................9
5. Advanced Conferencing ..........................................10
5.1. Conference Model ..........................................10
5.2. Configure Conference Request <configure_conference> .......11
5.3. Configure Leg Request <configure_leg> .....................13
5.4. Terminating a Conference ..................................14
5.5. Conference Manipulation ...................................15
5.6. Video Conferencing ........................................16
5.7. Conference Events .........................................17
5.8. Conferencing with Personalized Mixes ......................18
5.8.1. MSCML Elements and Attributes for
Personalized Mixes .................................19
5.8.2. Example Usage of Personalized Mixes ................20
6. Interactive Voice Response (IVR) ...............................23
6.1. Specifying Prompt Content .................................24
6.1.1. Use of the Prompt Element ..........................24
6.2. Multimedia Processing for IVR .............................30
6.3. Playing Announcements <play> ..............................31
6.4. Prompt and Collect <playcollect> ..........................32
6.4.1. Control of Digit Buffering and Barge-In ............33
6.4.2. Mapping DTMF Keys to Special Functions .............33
6.4.3. Collection Timers ..................................35
6.4.4. Logging Caller DTMF Input ..........................36
6.4.5. Specifying DTMF Grammars ...........................36
6.4.6. Playcollect Response ...............................37
6.4.7. Playcollect Example ................................38
6.5. Prompt and Record <playrecord> ............................38
6.5.1. Prompt Phase .......................................38
6.5.2. Record Phase .......................................39
6.5.3. Playrecord Example .................................41
6.6. Stop Request <stop> .......................................42
7. Call Leg Events ................................................43
7.1. Keypress Events ...........................................43
7.1.1. Keypress Subscription Examples .....................45
7.1.2. Keypress Notification Examples .....................45
7.2. Signal Events .............................................46
7.2.1. Signal Event Examples ..............................47
8. Managing Content <managecontent> ...............................48
8.1. Managecontent Example .....................................50
9. Fax Processing .................................................51
9.1. Recording a Fax <faxrecord> ...............................51
9.2. Sending a Fax <faxplay> ...................................53
10. MSCML Response Attributes and Elements ........................56
10.1. Mechanism ................................................56
10.2. Base <response> Attributes ...............................56
10.3. Response Attributes and Elements for <configure_leg> .....57
10.4. Response Attributes and Elements for <play> ..............57
10.4.1. Reporting Content Retrieval Errors ...............58
10.5. Response Attributes and Elements for <playcollect> .......59
10.6. Response Attributes and Elements for <playrecord> ........60
10.7. Response Attributes and Elements for <managecontent> .....61
10.8. Response Attributes and Elements for <faxplay>
and <faxrecord> ..........................................61
11. Formal Syntax .................................................62
11.1. Schema ...................................................62
12. IANA Considerations ...........................................73
12.1. IANA Registration of MIME Media Type application/
mediaservercontrol+xml ...................................73
13. Security Considerations .......................................74
14. References ....................................................75
14.1. Normative References .....................................75
14.2. Informative References ...................................76
Appendix A. Regex Grammar Syntax .................................78
Appendix B. Contributors .........................................79
Appendix C. Acknowledgements .....................................79
9. Fax Processing .................................................51
9.1. Recording a Fax <faxrecord> ...............................51
9.2. Sending a Fax <faxplay> ...................................53
10. MSCML Response Attributes and Elements ........................56
10.1. Mechanism ................................................56
10.2. Base <response> Attributes ...............................56
10.3. Response Attributes and Elements for <configure_leg> .....57
10.4. Response Attributes and Elements for <play> ..............57
10.4.1. Reporting Content Retrieval Errors ...............58
10.5. Response Attributes and Elements for <playcollect> .......59
10.6. Response Attributes and Elements for <playrecord> ........60
10.7. Response Attributes and Elements for <managecontent> .....61
10.8. Response Attributes and Elements for <faxplay>
and <faxrecord> ..........................................61
11. Formal Syntax .................................................62
11.1. Schema ...................................................62
12. IANA Considerations ...........................................73
12.1. IANA Registration of MIME Media Type application/
mediaservercontrol+xml ...................................73
13. Security Considerations .......................................74
14. References ....................................................75
14.1. Normative References .....................................75
14.2. Informative References ...................................76
Appendix A. Regex Grammar Syntax .................................78
Appendix B. Contributors .........................................79
Appendix C. Acknowledgements .....................................79
This document describes the Media Server Control Markup Language (MSCML) and its usage. It describes payloads that one can send to a media server using standard SIP INVITE and INFO methods and the capabilities these payloads implement. RFC 4240 [2] describes media server SIP URI formats.
本文档介绍媒体服务器控件标记语言（MSCML）及其用法。它描述了可以使用标准SIP INVITE和INFO方法发送到媒体服务器的有效负载以及这些有效负载实现的功能。RFC 4240[2]描述了媒体服务器SIP URI格式。
Prior to MSCML, there was not a standard way to deliver SIP-based enhanced conferencing. Basic SIP constructs, such as those described in RFC 4240 [2], serve simple n-way conferencing well. The SIP URI provides a natural mechanism for identifying a specific SIP conference, while INVITE and BYE methods elegantly implement conference join and leave semantics. However, enhanced conferencing applications also require features such as sizing and resizing, in-conference IVR operations (e.g., recording and playing participant names to the full conference), and conference event reporting. MSCML payloads within standard SIP methods realize these features.
在MSCML之前，没有一种标准的方式来提供基于SIP的增强型会议。基本的SIP构造，如RFC 4240[2]中所述，很好地服务于简单的n向会议。SIPURI提供了一种识别特定SIP会议的自然机制，而INVITE和BYE方法优雅地实现了会议加入和离开语义。但是，增强型会议应用程序还需要一些功能，如调整大小和大小、会议IVR操作（例如，在整个会议中录制和播放参与者姓名）以及会议事件报告。标准SIP方法中的MSCML有效负载实现了这些功能。
The structure and approach of MSCML satisfy the requirements set out in RFC 4353 [10]. In particular, MSCML serves as the interface between the conference server or focus and a centralized conference mixer. In this case, a media server has the role of the conference mixer.
MSCML的结构和方法满足RFC 4353[10]中规定的要求。特别是，MSCML充当会议服务器或焦点与集中式会议混合器之间的接口。在这种情况下，媒体服务器具有会议混合器的角色。
There are two broad classes of MSCML functionality. The first class includes primitives for advanced conferencing, such as conference configuration, participant leg manipulation, and conference event reporting. The second class comprises primitives for interactive voice response (IVR). These include collecting DTMF digits and playing and recording multimedia content.
有两大类MSCML功能。第一个类包括用于高级会议的原语，例如会议配置、参与者腿部操作和会议事件报告。第二类包括交互式语音响应（IVR）原语。其中包括收集DTMF数字和播放和录制多媒体内容。
MSCML fills the need for IVR and conference control with requests and responses over a SIP transport. VoiceXML [11] fills the need for IVR with requests and responses over a HTTP transport. This enables developers to use whatever model fits their needs best.
MSCML通过SIP传输的请求和响应来满足IVR和会议控制的需要。VoiceXML[11]通过HTTP传输的请求和响应来满足IVR的需求。这使开发人员能够使用最适合他们需要的任何模型。
In general, a media server offers services to SIP UACs, such as Application Servers, Feature Servers, and Media Gateway Controllers. See the IPCC Reference Architecture [12] for definitions of these terms. It is unlikely, but not prohibited, for end-user SIP UACs to have a direct signaling relationship with a media server. The term "client" is used in this document to refer generically to an entity that interacts with the media server using SIP and MSCML.
通常，媒体服务器向SIP UAC提供服务，如应用服务器、功能服务器和媒体网关控制器。有关这些术语的定义，请参见IPCC参考架构[12]。终端用户SIP UAC不太可能（但不禁止）与媒体服务器建立直接信令关系。本文档中的术语“客户机”泛指使用SIP和MSCML与媒体服务器交互的实体。
The media server fulfills the role of the Media Resource Function (MRF) in the IP Multimedia Subsystem (IMS) [13] as described by 3GPP. MSCML and RFC 4240 [2], upon which MSCML builds, are specifically focused on the Media resource (Mr) interface which supports interactions between application logic and the MRF.
如3GPP所述，媒体服务器在IP多媒体子系统（IMS）[13]中履行媒体资源功能（MRF）的角色。MSCML和RFC 4240[2]是MSCML构建的基础，它们特别关注支持应用程序逻辑和MRF之间交互的媒体资源（Mr）接口。
This document describes a working framework and protocol with which there is considerable implementation experience. Application developers and service providers have created several MSCML-based services since the availability of the initial version in 2001. This experience is highly relevant to the ongoing work of the IETF, particularly the SIP [26], SIPPING [27], MMUSIC [28], and XCON [29] work groups, the IMS [30] work in 3GPP, and the CCXML work in the Voice Browser Work Group of the W3C.
本文件描述了一个具有丰富实施经验的工作框架和协议。自2001年推出初始版本以来，应用程序开发人员和服务提供商已经创建了多个基于MSCML的服务。这一经验与IETF正在进行的工作密切相关，特别是SIP[26]、SIP[27]、MMUSIC[28]和XCON[29]工作组、3GPP中的IMS[30]工作以及W3C语音浏览器工作组中的CCXML工作。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
It is critically important to emphasize that the goal of MSCML is to provide an application interface that follows the SIP, HTTP, and XML development paradigm to foster easier and more rapid application deployment. This goal is reflected in MSCML in two ways.
必须强调的是，MSCML的目标是提供一个遵循SIP、HTTP和XML开发范式的应用程序接口，以促进更简单、更快速的应用程序部署。这一目标在MSCML中有两种体现。
First, the programming model is that of peer to peer rather than master-slave. Importantly, this allows the media server to be used simultaneously for multiple applications rather than be tied to a single point of control. It also enables standard SIP mechanisms to be used for media server location and load balancing.
首先，编程模型是对等的，而不是主从的。重要的是，这允许媒体服务器同时用于多个应用程序，而不是绑定到单个控制点。它还支持将标准SIP机制用于媒体服务器位置和负载平衡。
Second, MSCML defines constructs and primitives that are meaningful at the application level to ensure that programmers are not distracted by unnecessary complexity. For example, the mixing resource operates on constructs such as conferences and call participants rather than directly on individual media streams.
其次，MSCML定义了在应用程序级别有意义的结构和原语，以确保程序员不会因不必要的复杂性而分心。例如，混合资源在会议和呼叫参与者等结构上运行，而不是直接在单个媒体流上运行。
The MSCML paradigm is important to the developer community, in that developers and operators conceptually write applications about calls, conferences, and call legs. For the majority of developers and applications this approach significantly simplifies and speeds development.
MSCML范式对开发人员社区很重要，因为开发人员和操作员在概念上编写了关于调用、会议和调用分支的应用程序。对于大多数开发人员和应用程序来说，这种方法大大简化和加快了开发。
As mentioned above, MSCML payloads may be carried in either SIP INVITE or INFO requests. The initial INVITE, which creates an enhanced conference, MAY include an MSCML payload. A subsequent INVITE to the same Request-URI joins a participant leg to the conference. This INVITE MAY include an MSCML payload. The initial INVITE that establishes an IVR session MUST NOT include an MSCML payload. The client sends all mid-call MSCML payloads for conferencing and IVR via SIP INFO requests.
如上所述，MSCML有效负载可以在SIP INVITE或INFO请求中携带。创建增强会议的初始INVITE可能包括MSCML负载。对同一请求URI的后续邀请将参与者分支加入会议。此INVITE可能包括MSCML负载。建立IVR会话的初始INVITE不能包含MSCML负载。客户端通过SIP INFO请求为会议和IVR发送所有呼叫中MSCML有效负载。
SIP INVITE requests that contain both MSCML and Session Description Protocol (SDP) body parts are used frequently in conferencing scenarios. Therefore, the media server MUST support message bodies with the MIME type "multipart/mixed" in SIP INVITE requests.
包含MSCML和会话描述协议（SDP）主体部分的SIP INVITE请求在会议场景中经常使用。因此，媒体服务器必须支持SIP INVITE请求中MIME类型为“multipart/mixed”的消息体。
The media server transports MSCML responses in the final response to the SIP INVITE containing the matching MSCML request or in a SIP INFO message. The only allowable final response to a SIP INFO containing a message body is a 200 OK, per RFC 2976 [3]. Therefore, if the client sends the MSCML request via SIP INFO, the media server responds with the MSCML response in a separate INFO request. In general, these responses are asynchronous in nature and require a separate transaction due to timing considerations.
媒体服务器在包含匹配MSCML请求的SIP INVITE的最终响应中或在SIP INFO消息中传输MSCML响应。根据RFC 2976[3]，对包含消息正文的SIP信息的唯一允许的最终响应是200 OK。因此，如果客户端通过SIP INFO发送MSCML请求，则媒体服务器将在单独的INFO请求中使用MSCML响应进行响应。通常，这些响应本质上是异步的，并且出于时间考虑，需要单独的事务。
There has been considerable debate on the use of the SIP INFO method for any purpose. Our experience is that MSCML would not have been possible without it. At the time the first MSCML specification was published, the first SIP Event Notification draft had just been submitted as an individual submission. At that time, there was no mechanism to link SUBSCRIBE/NOTIFY to an existing dialog. This prevented its use in MSCML, since all events occurred in an INVITE-established dialog. And while SUBSCRIBE/NOTIFY was well suited for reporting conference events, its semantics seemed inappropriate for modifying a participant leg or conference setting where the only "event" was the success or failure of the request. Lastly, since SIP INFO was an established RFC, most SIP stack implementations supported it at that time. We had few, if any, interoperability issues as a result.
关于SIP INFO方法在任何用途上的使用一直存在相当大的争议。我们的经验是，如果没有它，MSCML是不可能的。在第一个MSCML规范发布时，第一个SIP事件通知草案刚刚作为单独提交提交。当时，没有将订阅/通知链接到现有对话框的机制。这阻止了它在MSCML中的使用，因为所有事件都发生在一个INVITE建立的对话框中。“修改会议的成功/失败”和“仅通知与会者会议的成功/失败”的语义设置。最后，由于SIP INFO是一个已建立的RFC，所以当时大多数SIP堆栈实现都支持它。因此，我们几乎没有（如果有的话）互操作性问题。
More recent developments have provided additional reasons why SUBSCRIBE/NOTIFY is not appropriate for use in MSCML. Use of SUBSCRIBE presents two problems. The first is semantic. The purpose of SUBSCRIBE is to register interest in User Agent state. However, using SUBSCRIBE for MSCML results in the SUBSCRIBE modifying the User Agent state. The second reason SUBSCRIBE is not appropriate is because MSCML is inherently call based. The association of a SIP dialog with a call leg means MSCML can be incredibly straightforward.
最近的发展提供了订阅/通知不适合在MSCML中使用的其他原因。使用SUBSCRIBE存在两个问题。第一个是语义。SUBSCRIBE的目的是注册用户代理状态中的兴趣。但是，使用SUBSCRIBE for MSCML会导致SUBSCRIBE修改用户代理状态。SUBSCRIBE不合适的第二个原因是，MSCML本质上是基于调用的。SIP对话与呼叫分支的关联意味着MSCML可以非常简单。
For example, if one used SUBSCRIBE or other SIP method to send commands about some context, one must identify that context somehow. Relating commands to the SIP dialog they arrive on defines the context for free. Moreover, it is conceptually easy for the developer. Using NOTIFY to transport MSCML responses is also not appropriate, as the NOTIFY would be in response to an implicit subscription. The SIP and SIPPING lists have discussed the dangers of implicit subscription.
例如，如果使用SUBSCRIBE或其他SIP方法发送有关某个上下文的命令，则必须以某种方式标识该上下文。将命令关联到它们到达的SIP对话框可以免费定义上下文。此外，对于开发人员来说，这在概念上很容易。使用NOTIFY传输MSCML响应也不合适，因为NOTIFY将响应隐式订阅。SIP和SIP列表讨论了隐式订阅的危险。
In order to guarantee interoperability with this specification, as well as with SIP User Agents that are unaware of MSCML, SIP UACs that wish to use MSCML services MUST specify a service indicator that supports MSCML in the initial INVITE. RFC 4240 [2] defines the service indicator "conf", which MUST be used for MSCML conferencing applications. The service indicator "ivr" MUST be used for MSCML interactive voice response applications. In this specification, only "conf" and "ivr" are described.
为了保证与本规范以及不知道MSCML的SIP用户代理的互操作性，希望使用MSCML服务的SIP UAC必须在初始INVITE中指定支持MSCML的服务指示符。RFC 4240[2]定义了服务指示符“conf”，它必须用于MSCML会议应用程序。服务指示器“ivr”必须用于MSCML交互式语音响应应用程序。在本规范中，仅描述了“conf”和“ivr”。
The media server MUST support moving the call between services through sending the media server a BYE on the existing dialog and establishing a new dialog with an INVITE to the desired service. Media servers SHOULD support moving between services without requiring modification of the previously established SDP parameters. This is achieved by sending a re-INVITE on the existing dialog in which the Request-URI is modified to specify the new service desired by the client. This eliminates the need for the client to send an INVITE to the caller or gateway to establish new SDP parameters.
媒体服务器必须支持在现有对话框上向媒体服务器发送BYE，并通过邀请所需服务建立新对话框，从而在服务之间移动呼叫。媒体服务器应支持在服务之间移动，而无需修改先前建立的SDP参数。这是通过在现有对话框上发送重新邀请来实现的，在该对话框中修改请求URI以指定客户端所需的新服务。这消除了客户端向调用方或网关发送邀请以建立新SDP参数的需要。
The media server, as a SIP UAS, MUST respond appropriately to an INVITE that contains an MSCML body. If MSCML is not supported, the media server MUST generate a 415 final response and include a list of the supported content types in the response per RFC 3261 [4]. The media server MUST also advertise its support of MSCML in responses to OPTIONS requests, by including "application/mediaservercontrol+xml" as a supported content type in an Accept header. This alleviates the major issues with using INFO for the transport of application data; namely, the User Agent's proper interpretation of what is, by design, an opaque message request.
作为SIP UAS的媒体服务器必须适当响应包含MSCML主体的邀请。如果不支持MSCML，则媒体服务器必须根据RFC 3261生成415最终响应，并在响应中包括支持的内容类型列表[4]。媒体服务器还必须通过在Accept标头中包含“application/mediaservercontrol+xml”作为受支持的内容类型，在响应选项请求时公布其对MSCML的支持。这缓解了使用信息传输应用程序数据的主要问题；也就是说，用户代理对设计上不透明的消息请求的正确解释。
To avoid undue complexity, MSCML establishes two rules regarding its usage. The first is that only one MSCML body may be present in a SIP request. The second is that each MSCML body may contain only one request or response. This greatly simplifies transaction management. MSCML syntax does provide for the unique identification of multiple requests in a single body part. However, this is not supported in this specification.
为了避免不必要的复杂性，MSCML建立了两个关于其使用的规则。第一个是SIP请求中只能存在一个MSCML主体。第二，每个MSCML主体可能只包含一个请求或响应。这大大简化了事务管理。MSCML语法确实为单个主体部分中的多个请求提供了唯一标识。但是，本规范不支持这一点。
Per the guidelines of RFC 3470 [14], MSCML bodies MUST be well formed and valid.
根据RFC 3470[14]的指南，MSCML实体必须结构良好且有效。
MSCML is a direct request-response protocol. There are no provisional responses, only final responses. A request may, however, result in multiple notifications. For example, a request for active talker reports will result in a notification for each speaker set. This maps to the three major element trees for MSCML: <request>, <response>, and <notification>.
MSCML是一种直接请求-响应协议。没有临时回复，只有最终回复。但是，一个请求可能会导致多个通知。例如，请求活动说话者报告将导致每个说话者集的通知。这映射到MSCML的三个主要元素树：<request>、<response>和<notification>。
Figure 1 shows a request body. Depending on the command, one can send the request in an INVITE or an INFO. Figure 2 shows a response body. The SIP INFO method transports response bodies. Figure 3 shows a notification body. The SIP INFO method transports notifications.
图1显示了一个请求主体。根据命令的不同，可以通过邀请或信息发送请求。图2显示了一个响应主体。SIP INFO方法传输响应体。图3显示了一个通知主体。SIP INFO方法传输通知。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
... request body ...
</request>
</MediaServerControl>
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
... request body ...
</request>
</MediaServerControl>
Figure 1: MSCML Request Format
图1:MSCML请求格式
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<response>
... response body ...
</response>
</MediaServerControl>
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<response>
... response body ...
</response>
</MediaServerControl>
Figure 2: MSCML Response Format
图2:MSCML响应格式
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<notification>
... notification body ...
</notification>
</MediaServerControl>
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<notification>
... notification body ...
</notification>
</MediaServerControl>
Figure 3: MSCML Notification Format
图3:MSCML通知格式
MSCML requests MAY include a client-defined ID attribute for the purposes of matching requests and responses. The values used for these IDs need only be unique within the scope of the dialog in which the requests are issued.
为了匹配请求和响应，MSCML请求可能包括客户端定义的ID属性。用于这些ID的值只需要在发出请求的对话框的范围内是唯一的。
In the philosophy of XML as a text-based description language, and not as a programming language, MSCML makes the choice of many attribute values for readability by a human. Thus, many attributes that would often be "boolean" instead take "yes" or "no" values. For example, what does 'report="false"' or 'report="1"' mean? However, 'report="yes"' is clearer: I want a report. Some programmers prefer the precision of a boolean. To satisfy both styles, MSCML defines an XML type, "yesnoType", that takes on the values "yes" and "no" as well as "true", "false", "1", and "0".
在XML作为基于文本的描述语言而不是编程语言的理念中，MSCML选择了许多属性值以供用户阅读。因此，许多通常为“布尔”的属性采用“是”或“否”值。例如，“report=“false”或“report=“1”是什么意思？然而，“report=“yes”更清楚：我想要一份报告。一些程序员更喜欢布尔运算的精度。为了满足这两种样式，MSCML定义了一个XML类型“yesnoType”，它接受值“yes”和“no”以及“true”、“false”、“1”和“0”。
Many attributes in the MSCML schema have default values. In order to limit demands on the XML parser, MSCML applies these values at the protocol, not XML, level. The MSCML schema documents these defaults as XML annotations to the appropriate attribute.
MSCML模式中的许多属性都有默认值。为了限制对XML解析器的需求，MSCML在协议级别而不是XML级别应用这些值。MSCML模式将这些默认值记录为相应属性的XML注释。
For clarity, time values in MSCML are based on the time designations described in the Cascading Style Sheets level 2 (CSS2) Specification [15]. Their format consists of a number immediately followed by an optional time unit identifier of the following form:
为清楚起见，MSCML中的时间值基于级联样式表2级（CSS2）规范中描述的时间指定[15]。其格式包括一个数字，后面紧跟一个可选的时间单位标识符，格式如下：
ms: milliseconds (default) s: seconds
毫秒：毫秒（默认值）秒：秒
If no time unit identifier is present, the value MUST be interpreted as being in milliseconds. As extensions to [15] MSCML allows the string values "immediate" and "infinite", which have special meaning for certain timers.
如果不存在时间单位标识符，则必须将该值解释为以毫秒为单位。作为[15]MSCML的扩展，允许字符串值“立即”和“无限”，这对某些计时器具有特殊意义。
The advanced conferencing model is a star controller model, with both signaling and media directed to a central location. Figure 4 depicts a typical signaling relationship between end users' UACs, a conference application server, and a media server.
高级会议模型是星型控制器模型，信号和媒体都指向中心位置。图4描述了最终用户的UAC、会议应用服务器和媒体服务器之间的典型信令关系。
RFC 4353 [10] describes this model. The application server is an instantiation of the conference focus. The media server is an instantiation of the media mixer. Note that user-level constructs, such as event notifications, are in the purview of the application server. This is why, for example, the media server sends active talker reports using MSCML notifications, while the application server would instead use the conference package [16] for individual notifications to SIP user agents. Note that we do not recommend the use of the conference package for media server to application server notifications because none of the filtering and membership information is available at the media server.
RFC 4353[10]描述了该模型。应用服务器是会议焦点的一个实例。媒体服务器是媒体混合器的一个实例。请注意，用户级构造（如事件通知）属于应用程序服务器的权限。这就是为什么，例如，媒体服务器使用MSCML通知发送活动通话器报告，而应用服务器将使用会议包[16]向SIP用户代理发送单个通知。请注意，我们不建议将会议包用于媒体服务器到应用程序服务器的通知，因为媒体服务器上没有可用的筛选和成员信息。
+-------+
| UAC 1 |---\ Public URI +-------------+
+-------+ \ _____________| Application |
/ / | Server | Not shown:
+-------+ / / +-------------+ RTP flows directly
| UAC 2 |---/ / | Private between UACs and
+-------+ / | URI media server
. / +--------------+
: / | |
+-------+ / | Media Server |
| UAC n |---/ | |
+-------+ +--------------+
+-------+
| UAC 1 |---\ Public URI +-------------+
+-------+ \ _____________| Application |
/ / | Server | Not shown:
+-------+ / / +-------------+ RTP flows directly
| UAC 2 |---/ / | Private between UACs and
+-------+ / | URI media server
. / +--------------+
: / | |
+-------+ / | Media Server |
| UAC n |---/ | |
+-------+ +--------------+
Figure 4: Conference Model
图4：会议模型
Each UAC sends an INVITE to a Public Conference URI. Presumably, the client publishes this URI, or it is an ad hoc URI. In any event, the client generates a Private URI, following the rules specified by RFC 4240 [2]. That is, the URI is of the following form:
每个UAC向公共会议URI发送一个邀请。客户机可能会发布此URI，或者它是一个临时URI。在任何情况下，客户机都会按照RFC 4240[2]指定的规则生成一个私有URI。也就是说，URI的形式如下：
sip:conf=UniqueID@ms.example.net
sip:conf=UniqueID@ms.example.net
where UniqueID is a unique conference identifier and ms.example.net is the host name or IP address of the media server. There is nothing to prevent the UACs from contacting the media
其中UniqueID是唯一的会议标识符，ms.example.net是媒体服务器的主机名或IP地址。没有任何东西可以阻止UAC联系媒体
server directly. However, one would expect the owner of the media server to restrict who can use its resources.
直接使用服务器。但是，我们希望媒体服务器的所有者限制谁可以使用它的资源。
As for basic conferencing, described by RFC 4240 [2], the first INVITE to the media server with a UniqueID creates a conference. However, in advanced conferencing, the first INVITE MAY include a MSCML <configure_conference> payload rather than the SDP of a conference participant. The <configure_conference> payload conveys extended session parameters (e.g., number of participants) that SDP does not readily express, but the media server must know to allocate the appropriate resources.
对于RFC 4240[2]所述的基本会议，第一次使用唯一ID邀请媒体服务器创建会议。然而，在高级会议中，第一个邀请可能包括MSCML<configure_conference>负载，而不是会议参与者的SDP。<configure_conference>有效负载传递SDP不容易表示的扩展会话参数（例如，参与者数量），但媒体服务器必须知道如何分配适当的资源。
When the conference is created by sending an INVITE containing a MSCML <configure_conference> payload, the resulting SIP dialog is termed the "Conference Control Leg." This leg has several useful properties. The lifetime of the conference is the same as that of its control leg. This ensures that the conference remains in existence even if all participant legs leave or have not yet arrived. In addition, when the client terminates the Conference Control Leg, the media server automatically terminates all participant legs. The Conference Control Leg is also used for play or record operations to/from the entire conference and for active talker notifications. Full conference media operations and active talker report subscriptions MUST be executed on the Conference Control Leg.
当通过发送包含MSCML<configure\u conference>有效负载的INVITE创建会议时，生成的SIP对话框被称为“会议控制分支”。该分支具有几个有用的属性。会议的生命周期与其控制站的生命周期相同。这确保了即使所有与会者离开或尚未到达，会议仍然存在。此外，当客户端终止会议控制分支时，媒体服务器自动终止所有参与者分支。会议控制段还用于整个会议的播放或录制操作，以及主动通话者通知。必须在会议控制分支上执行完整的会议媒体操作和主动通话者报告订阅。
Creation of a Conference Control Leg is RECOMMENDED because full advanced conferencing capabilities are not available without it. Clients MUST establish the Conference Control Leg in the initial INVITE that creates the conference; it cannot be created later.
建议创建会议控制分支，因为如果没有它，则无法提供完整的高级会议功能。客户必须在创建会议的初始邀请中建立会议控制分支；以后无法创建它。
Once the client has created the conference with or without the Conference Control Leg, participants can be joined to the conference. This is achieved by the client's directing an INVITE to the Private Conference URI for each participant. Using the example conference URI given above, this would be sip:conf=UniqueID@ms.example.net.
一旦客户端创建了带有或不带有会议控制分支的会议，参与者就可以加入会议。这是通过客户机为每个参与者向私有会议URI发出邀请来实现的。使用上面给出的示例会议URI，这将是sip:conf=UniqueID@ms.example.net.
The <configure_conference> request has two attributes that control the resources the media server sets aside for the conference. These are described in the list below.
<configure_conference>请求有两个属性，用于控制媒体服务器为会议预留的资源。下面的列表中描述了这些问题。
Attributes of <configure_conference>:
<configure\u conference>的属性：
o reservedtalkers - optional (see note), no default value: The maximum number of talker legs allocated for the conference. Note:
o reservedtalkers-可选（请参见注释），无默认值：为会议分配的说话者分支的最大数量。注:
required when establishing the Conference Control Leg but optional in subsequent <configure_conference> requests.
建立会议控制分支时需要，但在后续的<configure\u Conference>请求中可选。
o reserveconfmedia - optional, default value "yes": Controls allocation of resources to enable playing or recording to or from the entire conference
o reserveconfmedia-可选，默认值“yes”：控制资源分配，以便能够播放或录制整个会议
When the reservedtalkers+1st INVITE arrives at the media server, the media server SHOULD generate a 486 Busy Here response. Failure to send a 486 response to this condition can cause the media server to oversubscribe its resources.
当reservedtalkers+1st INVITE到达媒体服务器时，媒体服务器应生成486 Busy Here响应。未能对此情况发送486响应可能会导致媒体服务器过度订阅其资源。
NOTE: It would be symmetric to have a reservedlisteners parameter. However, the practical limitation on the media server is the number of talkers for a mixer to monitor. In either case, the client regulates who gets into the conference by either proxying the INVITEs from the user agent clients or metering to whom it gives the conference URI.
注意：使用reservedlisteners参数是对称的。然而，媒体服务器的实际限制是混音器要监控的对讲机数量。在这两种情况下，客户机通过代理来自用户代理客户机的邀请或计量它向谁提供会议URI来控制谁进入会议。
For example, to create a conference with up to 120 active talkers and the ability to play audio into the conference or record portions or all of the conference full mix, the client specifies both attributes, as shown in Figure 6.
例如，要创建一个最多有120名活动说话者的会议，并能够在会议中播放音频或录制部分或全部会议全混音，客户端将指定这两个属性，如图6所示。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_conference reservedtalkers="120"
reserveconfmedia="yes"/>
</request>
</MediaServerControl>
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_conference reservedtalkers="120"
reserveconfmedia="yes"/>
</request>
</MediaServerControl>
Figure 6: 120 Speaker MSCML Example
图6:120扬声器MSCML示例
In addition to these attributes, a <configure_conference> request MAY contain a child <subscribe> element. The <subscribe> element is used to request notifications for conference-wide active talker events. Detailed information regarding active talker events is contained in Section 5.7.
除了这些属性外，<configure\u conference>请求还可能包含子<subscribe>元素。<subscribe>元素用于请求会议范围内活动说话者事件的通知。第5.7节中包含了有关活动说话者事件的详细信息。
The client MUST include a <configure_conference> request in the initial INVITE which establishes the conference when creating the Conference Control Leg. The client server MUST issue asynchronous commands, such as <play>, separately (i.e., in INFO messages) to avoid ambiguous responses.
客户端必须在初始邀请中包含<configure_conference>请求，该请求在创建会议控制分支时建立会议。客户端服务器必须单独（即在信息消息中）发出异步命令，如<play>，以避免不明确的响应。
Media operations on the Conference Control leg are performed internally, no external RTP streams are involved. Accordingly, the
会议控制分支上的媒体操作在内部执行，不涉及外部RTP流。因此
media server does not expect RTP on the Conference Control Leg. Therefore, the client MUST send either no SDP or hold SDP in the INVITE request containing a <configure_conference> payload. The media server MUST treat SDP with all media lines set to "inactive" or with connection addresses set to 0.0.0.0 (for backwards compatibility) as hold SDP.
媒体服务器不希望在会议控制分支上使用RTP。因此，客户端必须在包含<configure\u conference>负载的INVITE请求中不发送SDP或保持SDP。媒体服务器必须将所有媒体线路设置为“非活动”或连接地址设置为0.0.0.0（用于向后兼容）的SDP视为保持SDP。
The media server sends a response when it has finished processing the <configure_conference> request. The format of the <configure_conference> response is detailed in Section 10.2.
媒体服务器在处理完<configure\u conference>请求后发送响应。第10.2节详细介绍了<configure_conference>响应的格式。
Conference legs have a number of properties the client can modify. These are set using the <configure_leg> request. This request has the attributes described in the list below.
会议分支具有许多属性，客户端可以修改这些属性。这些是使用<configure\u leg>请求设置的。此请求具有以下列表中描述的属性。
Attributes of <configure_leg>:
<configure\u leg>的属性：
o type - optional, default value "talker": Consider this leg's audio for inclusion in the output mix. Alternative is "listener".
o 类型-可选，默认值“说话者”：考虑这条腿的音频包含在输出组合中。另一种选择是“聆听者”。
o dtmfclamp - optional, default value "yes": Remove detected DTMF digits from the input audio.
o dtmfclamp-可选，默认值“是”：从输入音频中删除检测到的DTMF数字。
o toneclamp - optional, default value "yes": Remove tones from the input audio. Tones include call progress tones and the like.
o ToneCamp-可选，默认值“是”：从输入音频中删除音调。铃声包括通话进度铃声等。
o mixmode - optional, default value "full": Be a candidate for the full mix. Alternatives are "mute", to disallow media in the mix, "parked", to disconnect the leg's media streams from the conference for IVR operations, "preferred", to give this stream preferential selection in the mix (i.e., even if not loudest talker, include media, if present, from this leg in the mix), and "private", which enables personalized mixes.
o mixmode-可选，默认值“full”：作为完整混合的候选。备选方案是“静音”，不允许混音中的媒体，“停放”，断开分支媒体流与会议的连接以进行IVR操作，“首选”，在混音中优先选择该流（即，即使不是最大声的说话者，也包括混音中该分支的媒体（如果存在），以及“私有”，从而实现个性化混音。
In addition to these attributes, there are four child elements defined for <configure_leg>. These are <inputgain>, <outputgain>, <configure_team>, and <subscribe>.
除了这些属性之外，还有为<configure\u leg>定义的四个子元素。它们是<inputgain>、<outputgain>、<configure\u team>和<subscribe>。
The first two, <inputgain> and <outputgain>, modify the gain applied
to the input and output audio streams, respectively. These may
contain <auto>, to use automatic gain control (AGC) or <fixed>. The
<auto> element has the attributes "startlevel", "targetlevel", and
"silencethreshold". All the parameters are in dB. The <fixed>
element has the attribute "level", which is in dB. The default for
both <inputgain> and <outputgain> is <fixed>. The media server MAY
The first two, <inputgain> and <outputgain>, modify the gain applied
to the input and output audio streams, respectively. These may
contain <auto>, to use automatic gain control (AGC) or <fixed>. The
<auto> element has the attributes "startlevel", "targetlevel", and
"silencethreshold". All the parameters are in dB. The <fixed>
element has the attribute "level", which is in dB. The default for
both <inputgain> and <outputgain> is <fixed>. The media server MAY
silently cap <inputgain> or <outputgain> requests that exceed the gain limits imposed by the platform.
静默地限制超过平台规定的增益限制的<inputgain>或<outputgain>请求。
Clients most commonly manipulate only the input gain for a conference leg and rely on the mixer to set an optimum output gain based on the inputs currently in the mix. However, as described above, MSCML does allow for manipulation of the output gain as well. Some of the IVR commands, such as <play>, enable control of the output gain for content playback operations. The interaction of conference output gain and IVR playback gain controls is described in Section 6.1.1. Note that <inputgain> and <outputgain> settings apply only to conference legs and do not apply to IVR sessions.
客户机通常只操纵会议段的输入增益，并依靠混音器根据当前混音中的输入设置最佳输出增益。然而，如上所述，MSCML也允许操纵输出增益。一些IVR命令（如<play>）可以控制内容播放操作的输出增益。第6.1.1节描述了会议输出增益和IVR回放增益控制的交互作用。请注意，<inputgain>和<outputgain>设置仅适用于会议段，不适用于IVR会话。
The <configure_team> element is used to create and manipulate groups for personalized mixes. Details of personalized mixes are discussed in Section 5.8.
<configure\u team>元素用于创建和操作个性化混合的组。第5.8节讨论了个性化混音的细节。
The <subscribe> element is used to request notifications for call leg related events, such as asynchronous DTMF digit reports. Detailed information regarding call leg events is discussed in Section 7.
<subscribe>元素用于请求呼叫分支相关事件的通知，例如异步DTMF数字报告。第7节讨论了有关呼叫分支事件的详细信息。
If the default parameters are acceptable for the leg the client wishes to enter into the conference, then a normal SIP INVITE, with no MSCML body, is sufficient. However, if the client wishes to modify one or more of the parameters, the client can include a MSCML body in addition to the SDP body.
如果客户端希望进入会议的分支可以接受默认参数，那么没有MSCML主体的正常SIP INVITE就足够了。但是，如果客户端希望修改一个或多个参数，则除了SDP主体之外，客户端还可以包括MSCML主体。
The client can modify the conference leg parameters during the conference by issuing a SIP INFO on the dialog representing the conference leg. Of course, the client cannot modify SDP in an INFO message.
客户端可以在会议期间通过在代表会议分支的对话框上发出SIP信息来修改会议分支参数。当然，客户端不能在信息消息中修改SDP。
The media server sends a response when it has finished processing the <configure_leg> request. The format of the <configure_leg> response is detailed in Section 10.3.
媒体服务器在处理完<configure\u leg>请求后发送响应。第10.3节详细介绍了<configure_leg>响应的格式。
To remove a leg from the conference, the client issues a SIP BYE request on the selected dialog representing the conference leg.
要从会议中删除分支，客户端将在代表会议分支的选定对话框上发出SIP BYE请求。
The client can terminate all legs in a conference by issuing a SIP BYE request on the Conference Control Leg. If one or more participants are still in the conference when the media server receives a SIP BYE request on the Conference Control Leg, the media server issues SIP BYE requests on all remaining conference legs to ensure cleanup of the legs.
客户端可以通过在会议控制分支上发出SIP BYE请求来终止会议中的所有分支。当媒体服务器在会议控制分支上收到SIP BYE请求时，如果一个或多个参与者仍在会议中，则媒体服务器在所有剩余会议分支上发出SIP BYE请求，以确保清理分支。
The media server returns a 200 OK to the SIP BYE request as it sends BYE requests to the other legs. This is because we cannot issue a provisional response to a non-INVITE request, yet the teardown of the other legs may exceed the retransmission timer limits of the original request. While the conference is being cleaned up, the media server MUST reject any new INVITEs to the terminated conference with a 486 Busy Here response. This response indicates that the specified conference cannot accept any new members, pending deletion.
媒体服务器向其他分支发送BYE请求时，向SIP BYE请求返回200 OK。这是因为我们无法对非INVITE请求发出临时响应，但其他分支的拆卸可能会超过原始请求的重传计时器限制。清理会议时，媒体服务器必须以486 Busy Here响应拒绝对已终止会议的任何新邀请。此响应表示指定的会议无法接受任何新成员，等待删除。
Once the conference has begun, the client can manipulate the conference as a whole or a particular participant leg by issuing commands on the associated SIP dialog. For example, by sending MSCML requests on the Conference Control Leg the client can request that the media server record the conference, play a prompt to the conference, or request reports on active talker events. Similarly, the client may mute a participant leg, configure a personalized mix or request reports for call leg events, such as DTMF keypresses.
一旦会议开始，客户机就可以通过在相关的SIP对话框上发出命令来操纵整个会议或特定的参与者分支。例如，通过在会议控制分支上发送MSCML请求，客户端可以请求媒体服务器录制会议、播放会议提示或请求关于活动通话者事件的报告。类似地，客户端可以使参与者分支静音、配置个性化混合或请求呼叫分支事件的报告，例如DTMF按键。
Figure 7 shows an example of an MSCML command that plays a prompt to all conference participants.
图7显示了MSCML命令的示例，该命令向所有会议参与者播放提示。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<play>
<prompt>
<audio url="http://prompts.example.net/en_US/welcome.au"/>
</prompt>
</play>
</request>
</MediaServerControl>
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<play>
<prompt>
<audio url="http://prompts.example.net/en_US/welcome.au"/>
</prompt>
</play>
</request>
</MediaServerControl>
Figure 7: Full Conference Audio Command - Play
图7：完整会议音频命令-播放
A client can modify a leg by issuing an INFO on the dialog associated with the participant leg. For example, Figure 8 mutes a conference leg.
客户端可以通过在与参与者腿相关联的对话框上发布信息来修改腿。例如，图8禁用了一个会议分支。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_leg mixmode="mute"/>
</request>
</MediaServerControl>
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_leg mixmode="mute"/>
</request>
</MediaServerControl>
Figure 8: Sample Change Leg Command
图8：示例ChangeLeg命令
In Figure 7, we saw a request to play a prompt to the entire conference. The client can also request to play a prompt to an individual call leg. In that case, the MSCML request is issued within the SIP dialog of the desired conference participant.
在图7中，我们看到了向整个会议播放提示符的请求。客户端还可以请求对单个通话段播放提示。在这种情况下，MSCML请求在所需会议参与者的SIP对话框中发出。
Section 6 describes the interactive voice response (IVR) services offered by MSCML. If an IVR command arrives on the control channel, it takes effect on the whole conference. This is a mechanism for playing prompts to the entire conference (e.g., announcing new participants). If an IVR command arrives on an individual leg, it only affects that leg. This is a mechanism for interacting with users, such as the creation of "waiting rooms", allowing a user to mute themselves using key presses, allowing a moderator to out-dial, etc.
第6节描述了MSCML提供的交互式语音应答（IVR）服务。如果IVR命令到达控制通道，它将对整个会议生效。这是一种向整个会议播放提示的机制（例如，宣布新与会者）。如果IVR命令到达单个分支，则它仅影响该分支。这是一种与用户交互的机制，例如创建“等候室”，允许用户使用按键使自己静音，允许主持人拨出电话等等。
A participant leg MUST be configured with mixmode="parked" prior to the issuance of any IVR commands with prompt content ('prompturl' attribute or <prompt> element). Parking the leg isolates the participant's input and output media from the conference and allows use of those streams for playing and recording purposes. However, the mixmode has no effect if just digit collection or recording is desired. <playcollect> and <playrecord> requests without prompt content MAY be sent on participant legs without setting mixmode="parked".
在发出任何包含提示内容的IVR命令（“prompturl”属性或<prompt>元素）之前，必须使用mixmode=“parked”配置参与者分支。将支腿停放在会议上可将与会者的输入和输出媒体与会议隔离开来，并允许将这些流用于播放和录制目的。但是，如果只需要数字采集或记录，则混音模式不起作用<无提示内容的playcollect>和<playrecord>请求可以在参与者腿上发送，而无需设置mixmode=“parked”。
MSCML-controlled advanced conferences, as well as RFC 4240 [2] controlled basic conferences, implicitly support video conferencing in the form of video switching. In video switching, the video stream of the loudest talker (with some hysteresis) is sent to all participants other than that talker. The loudest talker receives the video stream from the immediately prior loudest talker.
MSCML控制的高级会议，以及RFC 4240[2]控制的基本会议，隐式支持视频交换形式的视频会议。在视频切换中，声音最大的说话者（有一些滞后）的视频流被发送到该说话者以外的所有参与者。最大声的说话者从前一个最大声的说话者接收视频流。
Media servers MUST ensure that participants receive video media compatible with their session. For example, a participant who has established an H.263 video stream will not receive video from another participant employing H.264 media. Media servers SHOULD implement video transcoding to minimize media incompatibilities between participants.
媒体服务器必须确保参与者接收与其会话兼容的视频媒体。例如，已建立H.263视频流的参与者将不会从使用H.264媒体的另一参与者接收视频。媒体服务器应实现视频转码，以尽量减少参与者之间的媒体不兼容。
The media server MUST switch video streams only when it receives a refresh video frame. A refresh frame contains all the video information required to decode that frame (i.e., there is no dependency on data from previous video frames).
媒体服务器只有在接收到刷新视频帧时才能切换视频流。刷新帧包含解码该帧所需的所有视频信息（即，不依赖于来自先前视频帧的数据）。
Refresh frames are large and generally sent infrequently to conserve network bandwidth. The media server MUST implement standard mechanisms to request that the new loudest talker's video encoder transmits a refresh frame to ensure that video can be switched quickly.
刷新帧很大，通常不经常发送，以节省网络带宽。媒体服务器必须实现标准机制，以请求新的最大声说话者的视频编码器传输刷新帧，以确保视频可以快速切换。
A client can subscribe for periodic active talker event reports that indicate which participants are included in the conference mix. As these are conference-level events, the subscription and notifications are sent on the Conference Control Leg.
客户机可以订阅定期的活动说话者事件报告，这些报告指示会议组合中包括哪些参与者。由于这些是会议级别的事件，订阅和通知在会议控制分支上发送。
Media servers MAY impose limits on the minimum interval for active talker reports for performance reasons. If the client request is below the imposed minimum, the media server SHOULD set the interval to the minimum value supported. To limit unnecessary notification traffic, the media server SHOULD NOT send a report if the active talker information for the conference has not changed during the reporting interval.
出于性能原因，媒体服务器可能会对活动说话者报告的最小间隔施加限制。如果客户端请求低于规定的最小值，媒体服务器应将间隔设置为支持的最小值。为了限制不必要的通知流量，如果在报告间隔期间会议的活动说话者信息没有更改，则媒体服务器不应发送报告。
A request for an active talker report is in Figure 9. The active talker report enumerates the current call legs in the mix.
图9中显示了一个主动对话者报告的请求。active talker报告枚举混合中的当前呼叫分支。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_conference>
<subscribe>
<events>
<activetalkers report="yes" interval="60s"/>
</events>
</subscribe>
</configure_conference>
</request>
</MediaServerControl>
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_conference>
<subscribe>
<events>
<activetalkers report="yes" interval="60s"/>
</events>
</subscribe>
</configure_conference>
</request>
</MediaServerControl>
Figure 9: Active Talker Request
图9：主动对讲机请求
Event notifications are sent in SIP INFO messages. Figure 10 shows an example of a report.
事件通知在SIP信息消息中发送。图10显示了一个报告示例。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<notification>
<conference uniqueid="ab34h76z" numtalkers="47">
<activetalkers>
<talker callid="myhost4sn123"/>
<talker callid="myhost2sn456"/>
<talker callid="myhost12sn78"/>
</activetalkers>
</conference>
</notification>
</MediaServerControl>
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<notification>
<conference uniqueid="ab34h76z" numtalkers="47">
<activetalkers>
<talker callid="myhost4sn123"/>
<talker callid="myhost2sn456"/>
<talker callid="myhost12sn78"/>
</activetalkers>
</conference>
</notification>
</MediaServerControl>
Figure 10: Active Talker Event Example
图10：活动说话者事件示例
The value of the "callid" attribute in the <talker> element corresponds to the value of the SIP Call-ID header of the associated dialog. This enables the client to associate the active talker with a specific participant leg.
<talker>元素中“callid”属性的值对应于相关对话框的SIP Call ID头的值。这使得客户机能够将活跃的说话者与特定的参与者腿相关联。
MSCML enables clients to create personalized mixes through the <configure_team> element for scenarios where the standard mixmode settings do not provide sufficient control. The <configure_team> element is a child of <configure_leg>.
MSCML使客户端能够通过<configure_team>元素为标准混合模式设置无法提供足够控制的场景创建个性化混合。<configure\u team>元素是<configure\u leg>的子元素。
To create personalized mixes, the client has to identify the relationships among the participants. This is accomplished by manipulating two MSCML objects. These objects are:
要创建个性化的混合，客户必须确定参与者之间的关系。这是通过操纵两个MSCML对象来实现的。这些对象是：
1. The list of team members (<teammate> elements), set using <configure_team>
1. 使用<configure\u team>
2. The mixmode attribute set through <configure_leg>
2. 通过<configure\u leg>
The media server uses the values of these objects to determine which audio inputs to combine for output to the participant. In a normal conference, each participant hears the conference mix minus their own input if they are part of the mixed output. The team list enables the client to specify other participants that the leg can hear in addition to the normal mixed output. Note that personalized mix settings apply only to audio media and do not affect video switching.
媒体服务器使用这些对象的值来确定要组合哪些音频输入以输出给参与者。在正常的会议中，每个参与者都会听到会议组合减去他们自己的输入（如果他们是混合输出的一部分）。团队列表使客户能够指定腿除了正常混合输出之外还可以听到的其他参与者。请注意，个性化混音设置仅适用于音频媒体，不影响视频切换。
Team relationships are implicitly symmetric. If the client sets participant A as a team member of participant B, then the media server automatically sets participant B as a team member for A.
团队关系是隐式对称的。如果客户端将参与者A设置为参与者B的团队成员，则媒体服务器会自动将参与者B设置为A的团队成员。
The id attribute set through <configure_leg> is used to identify the various participants. A unique ID MUST be assigned to each participant included in a personalized mix. The IDs used MUST be unique within the scope of the conference in which they appear.
通过<configure_leg>设置的id属性用于标识各种参与者。必须为个性化组合中的每个参与者分配一个唯一的ID。所使用的ID在其出现的会议范围内必须是唯一的。
By itself, the team list only defines those participants that the leg can hear. The mixmode attribute of each team member determines whether to include their audio input in the personalized mix. If the client sets the teammate's mixmode to private, then it is part of the mix. If the mixmode is set to any other value, it is not.
团队列表本身只定义腿能听到的参与者。每个团队成员的mixmode属性确定是否将其音频输入包括在个性化混音中。如果客户机将队友的mixmode设置为private，则它是混合的一部分。如果mixmode被设置为任何其他值，则不会。
Control of personalized mixes rely on two major MSCML elements:
个性化混音的控制依赖于两个主要的MSCML元素：
1. <configure_leg>, using the mixmode attribute setting mixmode="private"
1. <configure_leg>，使用mixmode属性设置mixmode=“private”
2. <configure_team>
2. <configure\u团队>
The <configure_team> element allows the user to make the participants members of a team within a specific conference. It is a child of the <configure_leg> parent element.
<configure_team>元素允许用户使参与者成为特定会议中团队的成员。它是<configure\u leg>父元素的子元素。
The client sends the <configure_team> element in a <configure_leg> request in either a SIP INVITE or SIP INFO.
客户端在SIP INVITE或SIP INFO中的<configure\u leg>请求中发送<configure\u team>元素。
o In an INVITE, to join a participant whose properties differ from the properties established for the conference as a whole.
o 在邀请中，加入一个参与者，该参与者的属性与为整个会议确定的属性不同。
o In an INFO, to change the properties for an existing leg.
o 在信息中，更改现有支腿的属性。
The two attributes of the configure_team element are "id" and "action". The id attribute MUST contain the unique ID of the leg being modified, as set in the original <configure_leg> request. The action attribute can take on the values "add", "delete", "query", and "set". The default value is "query". This attribute allows the user to modify the team list. Table 1 describes the actions that can be performed on the team list.
configure_团队元素的两个属性是“id”和“action”。id属性必须包含被修改分支的唯一id，如原始<configure\u leg>请求中所设置的。action属性的值可以是“添加”、“删除”、“查询”和“设置”。默认值为“查询”。此属性允许用户修改团队列表。表1描述了可在团队列表上执行的操作。
+--------+----------------------------------------------------------+
| Action | Description |
+--------+----------------------------------------------------------+
| add | Adds a teammate to the mix. |
| delete | Deletes a teammate from the mix. |
| query | Returns the teammate list to the requestor. This is the |
| | default value. |
| set | Creates a team list when followed by <teammate id="n"> |
| | and also removes all the teammates from the team list |
| | for example, when the creator (originator) of the team |
| | list on that specific conference leg wants to remove all |
| | of the teammates from the team. If the set operation |
| | removes all teammates from a participant, that |
| | participant hears the full conference mix. |
+--------+----------------------------------------------------------+
+--------+----------------------------------------------------------+
| Action | Description |
+--------+----------------------------------------------------------+
| add | Adds a teammate to the mix. |
| delete | Deletes a teammate from the mix. |
| query | Returns the teammate list to the requestor. This is the |
| | default value. |
| set | Creates a team list when followed by <teammate id="n"> |
| | and also removes all the teammates from the team list |
| | for example, when the creator (originator) of the team |
| | list on that specific conference leg wants to remove all |
| | of the teammates from the team. If the set operation |
| | removes all teammates from a participant, that |
| | participant hears the full conference mix. |
+--------+----------------------------------------------------------+
Table 1: Configure Team Actions
表1：配置团队操作
A common use of personalized mixing is to support coaching of one participant by another. The coaching scenario includes three participants: 1. The Supervisor, who coaches the agent. 2. The Agent, who interacts with the customer. 3. The Customer, who interacts with the agent.
个性化混合的一个常见用途是支持一个参与者对另一个参与者的指导。指导场景包括三个参与者：1。指导经纪人的主管。2.与客户互动的代理。3.与代理互动的客户。
Table 2 illustrates the details of the coached conference topology.
表2显示了指导会议拓扑的详细信息。
+-------------+------------+------------+---------+-----------------+
| Participant | ID | Team | Mixmode | Hears |
| | | Members | | |
+-------------+------------+------------+---------+-----------------+
| Supervisor | supervisor | Agent | Private | customer + |
| | | | | agent |
| Agent | agent | Supervisor | Full | customer + |
| | | | | supervisor |
| Customer | customer | none | Full | agent |
+-------------+------------+------------+---------+-----------------+
+-------------+------------+------------+---------+-----------------+
| Participant | ID | Team | Mixmode | Hears |
| | | Members | | |
+-------------+------------+------------+---------+-----------------+
| Supervisor | supervisor | Agent | Private | customer + |
| | | | | agent |
| Agent | agent | Supervisor | Full | customer + |
| | | | | supervisor |
| Customer | customer | none | Full | agent |
+-------------+------------+------------+---------+-----------------+
Table 2: Coached Conference Example
表2：辅导会议示例
To create this topology, the client performs the following actions:
要创建此拓扑，客户端将执行以下操作：
1. The client joins each leg to the conference, being certain to include a unique ID in the <configure_leg> request. The leg ID needs to be unique only within the scope of the conference to which it belongs.
1. 客户端将每个分支加入会议，确保在<configure\u leg>请求中包含唯一的ID。腿ID只需在其所属会议的范围内是唯一的。
2. The client configures the teammate list and mixmode of each participant, as required.
2. 客户端根据需要配置每个参与者的队友列表和混合模式。
Both actions (steps 1 and 2) may be combined in a single MSCML request. The following sections detail these actions and their corresponding MSCML payloads.
这两个操作（步骤1和步骤2）可以组合在一个MSCML请求中。以下各节详细介绍了这些操作及其相应的MSCML有效负载。
Before joining any participants, the client must create the conference by sending a SIP INVITE that contains an MSCML <configure_conference> request with a unique conference identifier.
在加入任何参与者之前，客户端必须通过发送SIP INVITE来创建会议，该SIP INVITE包含具有唯一会议标识符的MSCML<configure_conference>请求。
Join the coach leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to supervisor and its mixmode to private.
通过发送包含<configure\u leg>请求的SIP INVITE，将coach leg加入会议并配置其所需的属性。<configure\u leg>元素将leg的唯一ID设置为supervisor，将其mixmode设置为private。
The corresponding MSCML request is as follows.
相应的MSCML请求如下所示。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="supervisor" mixmode="private"/>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="supervisor" mixmode="private"/>
</request>
</MediaServerControl>
Figure 11: Join Coach Request
图11：加入Coach请求
Note that the client cannot configure the teammate list for the coach yet, as there are no other participants in the conference. One must join a participant to the conference before one can add it as a teammate for another leg.
注意，客户机还不能为教练配置队友列表，因为会议中没有其他参与者。一个人必须加入一名与会者，然后才能将其作为另一站的队友加入会议。
Join the agent leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to "agent" and sets the supervisor as a team member of the agent. Because team member relationships are symmetric, this action also adds the agent as a team member for the coach.
将代理分支加入会议，并通过发送包含<configure\u leg>请求的SIP INVITE来配置其所需属性。<configure\u leg>元素将leg的唯一ID设置为“agent”，并将主管设置为agent的团队成员。由于团队成员关系是对称的，因此此操作还将代理添加为教练的团队成员。
The corresponding MSCML request is as follows.
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="agent">
<configure_team action="set">
<teammate id="supervisor"/>
</configure_team>
</configure_leg>
</request>
</MediaServerControl>
The corresponding MSCML request is as follows.
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="agent">
<configure_team action="set">
<teammate id="supervisor"/>
</configure_team>
</configure_leg>
</request>
</MediaServerControl>
Figure 12: Join Agent Request
图12：加入代理请求
Because the desired mixmode for this leg is full, which is the default value, there is no need to set it explicitly.
由于此分支所需的mixmode是full，这是默认值，因此无需显式设置它。
Join the client leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element simply sets the leg's unique ID to "customer". The media server does not need further configuration because the desired mixmode, full, is the default and the customer has no team members.
通过发送包含<configure\u leg>请求的SIP INVITE，将客户端连接到会议并配置其所需的属性。<configure\u leg>元素只是将leg的唯一ID设置为“customer”。媒体服务器不需要进一步配置，因为所需的混合模式full是默认模式，并且客户没有团队成员。
The corresponding MSCML request is as follows.
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="customer"/>
</request>
</MediaServerControl>
The corresponding MSCML request is as follows.
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="customer"/>
</request>
</MediaServerControl>
Figure 13: Join Client Request
图13：加入客户端请求
Strictly speaking, it is not a requirement that the client give the customer leg a unique ID because it will not be a team member. However, when using coached conferencing, we RECOMMEND that one assign a unique ID to each leg in the initial INVITE request. Assigning a unique ID eliminates the need to set it later by sending a SIP INFO if one later desires personalized mixing for the customer leg.
严格地说，客户不需要给客户腿提供唯一的ID，因为它不是团队成员。但是，当使用辅导会议时，我们建议在初始邀请请求中为每个分支分配一个唯一的ID。如果以后需要为客户分支进行个性化混合，则分配唯一ID无需稍后通过发送SIP信息进行设置。
The conference is now in the desired configuration, shown previously in Table 2.
会议现在处于所需的配置中，如表2所示。
In the IVR model, the media server acts as a media-processing proxy for the UAC. This is particularly useful when the UAC is a media gateway or other device with limited media processing capability.
在IVR模型中，媒体服务器充当UAC的媒体处理代理。当UAC是媒体网关或具有有限媒体处理能力的其他设备时，这尤其有用。
The typical use case for MSCML is when there is an application server that is the MSCML client. The client can use the SIP Service URI concept (RFC 3087) to initiate a service. The client then uses RFC 4240 [2] to initiate a MSCML session on a media server. These relationships are shown in Figure 14.
MSCML的典型用例是当存在作为MSCML客户端的应用程序服务器时。客户端可以使用SIP服务URI概念（rfc3087）来启动服务。然后，客户端使用RFC 4240[2]在媒体服务器上启动MSCML会话。这些关系如图14所示。
SIP +--------------+
Service URI | Application |
/----------------| Server |
/(e.g., RFC 3087) +--------------+
/ | MSCML
/ SIP | Session
/ +--------------+
+-----+/ RTP | |
| UAC |======================| Media Server |
+-----+ | |
+--------------+
SIP +--------------+
Service URI | Application |
/----------------| Server |
/(e.g., RFC 3087) +--------------+
/ | MSCML
/ SIP | Session
/ +--------------+
+-----+/ RTP | |
| UAC |======================| Media Server |
+-----+ | |
+--------------+
Figure 14: IVR Model
图14:IVR模型
The IVR service supports basic Interactive Voice Response functions, playing announcements, collecting DTMF digits, and recording, based on Media Server Control Markup Language (MSCML) directives added to the message body of a SIP request. The major MSCML IVR requests are <play>, <playcollect>, and <playrecord>.
IVR服务支持基于添加到SIP请求消息体的媒体服务器控制标记语言（MSCML）指令的基本交互式语音响应功能、播放公告、收集DTMF数字和录制。主要的MSCML IVR请求是<play>、<playcollect>和<playcrecord>。
Multifunction media servers MUST use the URI conventions described in RFC 4240 [2]. The service indicator for MSCML IVR MUST be set to "ivr", as shown in the following example:
多功能媒体服务器必须使用RFC 4240[2]中描述的URI约定。MSCML IVR的服务指示器必须设置为“IVR”，如下例所示：
sip:ivr@ms.example.net
抿：ivr@ms.example.net
The VoiceXML IVR service indicator is "dialog". This service indicator MUST NOT be used for any other interactive voice response control mechanism.
VoiceXML IVR服务指示器为“dialog”。此服务指示器不得用于任何其他交互式语音响应控制机制。
The media server MUST accept MSCML IVR payloads in INFO requests and MUST NOT accept MSCML IVR payloads in the initial or subsequent INVITEs. The INFO method reduces certain timing issues that occur with INVITEs and requires less processing on both the client and media server.
媒体服务器必须在信息请求中接受MSCML IVR有效负载，并且不得在初始或后续邀请中接受MSCML IVR有效负载。INFO方法减少了邀请中出现的某些计时问题，并且在客户端和媒体服务器上都需要较少的处理。
The media server notifies the client that the command has completed through a <response> message containing final status information and associated data such as collected DTMF digits.
媒体服务器通过包含最终状态信息和相关数据（如采集的DTMF数字）的<response>消息通知客户端命令已完成。
The media server does not queue IVR requests. If the media server receives a new IVR request while another is in progress, the media server stops the first operation and it carries out the new request. The media server generates a <response> message for the first request and returns any data collected up to that point. If a client wishes to stop a request in progress but does not wish to initiate another operation, it issues a <stop> request. This also causes the media server to generate a <response> message.
媒体服务器不对IVR请求排队。如果媒体服务器在另一个IVR请求进行中收到新的IVR请求，则媒体服务器将停止第一个操作并执行新请求。媒体服务器为第一个请求生成<response>消息，并返回在此之前收集的所有数据。如果客户端希望停止正在进行的请求，但不希望启动另一个操作，则会发出<stop>请求。这也会导致媒体服务器生成<response>消息。
The media server treats a SIP re-INVITE that modifies the established SDP parameters as an implicit <stop> request. Examples of such SDP modifications include receiving hold SDP or removing an audio or video stream. When this occurs, the media server immediately terminates the running <play>, <playcollect>, or <playrecord> request and sends a <response> indicating "reason=stopped".
媒体服务器将修改已建立SDP参数的SIP重新邀请视为隐式<stop>请求。此类SDP修改的示例包括接收保持SDP或移除音频或视频流。出现这种情况时，媒体服务器会立即终止正在运行的<play>、<playcollect>或<playcrecord>请求，并发送一个<response>，指示“原因=已停止”。
The MSCML IVR requests support two methods of specifying content to be delivered to the user. These are the <prompt> element and the prompturl attribute. Clients MUST NOT utilize both methods in a single IVR request. Clients SHOULD use the more flexible <prompt> mechanism. Use of the prompturl attribute is deprecated and may not be supported in future MSCML versions.
MSCML IVR请求支持两种指定要交付给用户的内容的方法。这些是<prompt>元素和prompturl属性。客户端不能在单个IVR请求中同时使用这两种方法。客户端应该使用更灵活的<prompt>机制。prompturl属性的使用已被弃用，在将来的MSCML版本中可能不受支持。
The <prompt> element MAY be included in the body of a <play>, <playcollect>, or <playrecord> request to specify a prompt sequence to be delivered to the caller. The prompt sequence consists of one or more references to physical content files, spoken variables, or dynamic URLs that return a sub-sequence of files or variables. In addition, the <prompt> element has several attributes that control playback of the included content. These are described in the list below.
<prompt>元素可以包含在<play>、<playcollect>或<playcrecord>请求的主体中，以指定要传递给调用者的提示序列。提示序列包括对物理内容文件、语音变量或返回文件或变量子序列的动态URL的一个或多个引用。另外，<prompt>元素有几个属性控制所包含内容的播放。下面的列表中描述了这些问题。
Attributes of <prompt>:
<prompt>的属性：
o baseurl - optional, no default value: For notational convenience, as well as reducing the MSCML payload size, the "baseurl" attribute is used to specify a base URL that is prepended to any other URLs in the sequence that are not fully qualified.
o baseurl-可选，无默认值：为了便于记法，以及减少MSCML负载大小，“baseurl”属性用于指定一个基本URL，该URL位于序列中未完全限定的任何其他URL之前。
o delay - optional, default value "0": The "delay" attribute to the prompt element specifies the time to pause between repetitions of the <prompt> sequence. It has no effect on the first iteration of the sequence. Expressed as a time value (Section 4.2.1) from 0 onwards.
o 延迟-可选，默认值“0”：prompt元素的“delay”属性指定重复<prompt>序列之间的暂停时间。它对序列的第一次迭代没有影响。表示为从0开始的时间值（第4.2.1节）。
o duration - optional, default value "infinite": The "duration" attribute to the prompt element controls the maximum amount of time that may elapse while the media server repeats the sequence. This allows the client to set an upper bound on the length of play. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite". "Immediate" directs the media server to end play immediately, whereas "infinite" indicates that the media server imposes no limit.
o 持续时间-可选，默认值“无限”：提示元素的“持续时间”属性控制媒体服务器重复序列时可能经过的最大时间。这允许客户端设置播放长度的上限。表示为从1ms开始的时间值（第4.2.1节）或字符串“立即”和“无限”。“立即”指示媒体服务器立即结束播放，而“无限”指示媒体服务器不施加限制。
o gain - optional, default value "0": Sets the absolute gain to be applied to the content contained in <prompt>. The value of this attribute is specified in units of dB. The media server MAY silently cap values that exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content contained in <prompt> has been completed.
o 增益-可选，默认值“0”：设置应用于<prompt>中包含的内容的绝对增益。此属性的值以dB为单位指定。媒体服务器可以静默地限制超过平台施加的增益限制的值。播放<prompt>中包含的内容完成后，级别将恢复为其原始值。
o gaindelta - optional, default value "0": Sets the relative gain to be applied to the content contained in <prompt>. The value of this attribute is specified in units of dB. The media server MAY silently cap values which exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content contained in <prompt> has been completed.
o gaindelta-可选，默认值“0”：设置应用于<prompt>中包含的内容的相对增益。此属性的值以dB为单位指定。媒体服务器可以静默地限制超过平台施加的增益限制的值。播放<prompt>中包含的内容完成后，级别将恢复为其原始值。
o rate - optional, default value "0": Specifies the absolute playback rate of the content relative to normal as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content contained in <prompt> has been completed.
o 速率-可选，默认值“0”：将内容相对于正常的绝对播放速率指定为正百分比（更快）或负百分比（更慢）。任何试图将速率设置为高于允许的最大值或低于允许的最小值的值都会自动将速率设置为最大值或最小值。播放<prompt>中包含的内容完成后，速率将恢复为其原始值。
o ratedelta - optional, default value "0": Specifies the playback rate of the content relative to it's current rate as either a positive percentage (faster) or negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content contained in <prompt> has completed.
o ratedelta-可选，默认值“0”：将内容相对于其当前速率的播放速率指定为正百分比（较快）或负百分比（较慢）。任何试图将速率设置为高于允许的最大值或低于允许的最小值的值都会自动将速率设置为最大值或最小值。播放<prompt>中包含的内容完成后，速率将恢复为其原始值。
o locale - optional, no default value: Specifies the language and country variant used for resolving spoken variables. The language is defined as a two-letter code per ISO 639. The country variant is also defined as a two-letter code per ISO 3166. These codes are concatenated with a single underscore (%x5F) character.
o locale-可选，无默认值：指定用于解析语音变量的语言和国家变量。根据ISO 639，该语言定义为两个字母的代码。根据ISO 3166，国家变量也定义为两个字母的代码。这些代码由一个下划线（%x5F）字符连接。
o offset - optional, default value "0": A time value (Section 4.2.1) which specifies the time from the beginning of the sequence at which play is to begin. Offset only applies to the first repetition; subsequent repetitions begin play at offset 0. Allowable values are positive time values from 0 onwards. When the sequence consists of multiple content files, the offset may select any point in the sequence. If the offset value is greater than the total time of the sequence, it will "wrap" to the beginning and continue from there until the media server reaches the specified offset.
o 偏移-可选，默认值“0”：一个时间值（第4.2.1节），指定从开始播放的序列开始的时间。偏移仅适用于第一次重复；后续重复从偏移量0开始播放。允许值是从0开始的正时间值。当序列由多个内容文件组成时，偏移可以选择序列中的任何点。如果偏移量值大于序列的总时间，它将“换行”到开头，并从那里继续，直到媒体服务器达到指定的偏移量。
o repeat - optional, default value "1": The "repeat" attribute to the prompt element controls the number of times the media server plays the sequence in the <prompt> element. Allowable values are integers from 0 on and the string "infinite", which indicates that repetition should occur indefinitely. For example, "repeat=2" means that the sequence will be played twice, and "repeat=0", which is allowed, means that the sequence is not played.
o repeat-可选，默认值“1”：prompt元素的“repeat”属性控制媒体服务器在<prompt>元素中播放序列的次数。允许的值是从0开始的整数和字符串“infinite”，这表示重复应该无限期地发生。例如，“repeat=2”表示该序列将被播放两次，“repeat=0”表示该序列不被播放，这是允许的。
o stoponerror - optional, default value "no": Controls media server handling and reporting of errors encountered when retrieving remote content. If set to "yes", content play will end if a fetch error occurs, and the response will contain details regarding the failure. If set to "no", the media server will silently move on to the next URL in the sequence if a fetch failure occurs.
o stoponerror-可选，默认值“否”：控制媒体服务器处理和报告检索远程内容时遇到的错误。如果设置为“是”，内容播放将在出现获取错误时结束，响应将包含有关失败的详细信息。如果设置为“否”，则媒体服务器将在获取失败时以静默方式移动到序列中的下一个URL。
Clients MUST NOT include both 'gain' and 'gaindelta' attributes within a single <prompt> element.
客户端不能在单个<prompt>元素中同时包含“gain”和“gaindelta”属性。
When the client explicitly controls the output gain on a conference leg, as described in Section 5.3, the 'gain' and 'gaindelta' attributes SHOULD interact with the conference leg output gain settings in the following manner.
如第5.3节所述，当客户端明确控制会议段上的输出增益时，“增益”和“增益增量”属性应以以下方式与会议段输出增益设置交互。
o Conference leg output gain set to <fixed>: The operation of the 'gain' and 'gaindelta' attributes are unchanged. However, the baseline gain value before any playback changes are applied is the value specified for the conference leg.
o 会议段输出增益设置为<固定>：“增益”和“增益增量”属性的操作不变。但是，应用任何播放更改之前的基线增益值是为会议段指定的值。
o Conference leg output gain set to <auto>: When playback gain controls are used, the automatic gain control settings for the leg are suspended for the duration of the playback operation. The
o 会议支腿输出增益设置为<自动>：使用播放增益控制时，支腿的自动增益控制设置在播放操作期间暂停。这个
operation of the 'gain' and 'gaindelta' attributes are unchanged. The automatic gain control settings are reinstated when playback has finished.
“gain”和“gaindelta”属性的操作保持不变。播放完成后，自动增益控制设置将恢复。
Media servers SHOULD support rate controls for content. However, media servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <prompt> element.
媒体服务器应支持内容的速率控制。但是，如果内容限制不允许满足速率更改请求，则媒体服务器可能会自动忽略该请求。客户端不能在单个<prompt>元素中同时包含“rate”和“ratedta”属性。
Figure 16 shows a sample prompt block.
图16显示了一个示例提示块。
<prompt stoponerror="yes"
baseurl="file:////var/mediaserver/prompts/"
locale="en_US" offset="0" gain="0" rate="0"
delay="0" duration="infinite" repeat="1">
<audio url="num_dialed.raw" encoding="ulaw"/>
<variable type="dig" subtype="ndn" value="3014170700"/>
<audio url="num_invalid.wav"/>
<audio url="please_check.wav"/>
</prompt>
<prompt stoponerror="yes"
baseurl="file:////var/mediaserver/prompts/"
locale="en_US" offset="0" gain="0" rate="0"
delay="0" duration="infinite" repeat="1">
<audio url="num_dialed.raw" encoding="ulaw"/>
<variable type="dig" subtype="ndn" value="3014170700"/>
<audio url="num_invalid.wav"/>
<audio url="please_check.wav"/>
</prompt>
Figure 16: Prompt Block Example
图16：提示块示例
Clients compose prompt sequences using the <audio> and <variable> elements. An <audio> element MAY refer to content that contains audio, video, or both; the generic name is preserved for backwards compatibility. The <audio> element has the attributes described in the list below.
客户端使用<audio>和<variable>元素组成提示序列。<audio>元素可以指包含音频、视频或两者的内容；保留泛型名称是为了向后兼容。<audio>元素具有下面列表中描述的属性。
Attributes of <audio>:
<audio>的属性：
o url - required, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. If the URL is not fully qualified and a "baseurl" attribute was set, the value of the "baseurl" attribute will be prepended to this value to generate the target URL.
o url-必需，无默认值：要检索和播放的内容的url。目标可以是本地或远程（NFS）“文件：//”方案URL或“http://”或“https://”方案URL。如果URL不是完全限定的，并且设置了“baseurl”属性，“baseurl”属性的值将前置到此值以生成目标URL。
o encoding - optional, default value "ulaw": Specifies the content encoding for file formats that are not self-describing (e.g., .WAV). Allowable values are "ulaw", "alaw", and "msgsm". This attribute only affects "file://" scheme URLs.
o 编码-可选，默认值“ulaw”：指定非自描述文件格式（例如.WAV）的内容编码。允许值为“ulaw”、“alaw”和“msgsm”。此属性仅影响“file://”方案URL。
o gain - optional, default value "0": Sets the absolute gain to be applied to the content URL. The value of this attribute is
o 增益-可选，默认值“0”：设置应用于内容URL的绝对增益。此属性的值为
specified in units of dB. The media server MAY silently cap values that exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content URL has been completed.
以dB为单位指定。媒体服务器可以静默地限制超过平台施加的增益限制的值。完成内容URL的播放后，级别将恢复为其原始值。
o gaindelta - optional, default value "0": Sets the relative gain to be applied to the content URL. The value of this attribute is specified in units of dB. The media server MAY silently cap values that exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content URL has been completed.
o gaindelta-可选，默认值“0”：设置应用于内容URL的相对增益。此属性的值以dB为单位指定。媒体服务器可以静默地限制超过平台施加的增益限制的值。完成内容URL的播放后，级别将恢复为其原始值。
o rate - optional, default value "0": Specifies the absolute playback rate of the content relative to normal as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content URL has been completed.
o 速率-可选，默认值“0”：将内容相对于正常的绝对播放速率指定为正百分比（更快）或负百分比（更慢）。任何试图将速率设置为高于允许的最大值或低于允许的最小值的值都会自动将速率设置为最大值或最小值。内容URL播放完成后，速率将恢复为其原始值。
o ratedelta - optional, default value "0": Specifies the playback rate of the content relative to it's current rate as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content URL has been completed.
o ratedelta-可选，默认值“0”：将内容相对于其当前速率的播放速率指定为正百分比（较快）或负百分比（较慢）。任何试图将速率设置为高于允许的最大值或低于允许的最小值的值都会自动将速率设置为最大值或最小值。内容URL播放完成后，速率将恢复为其原始值。
Clients MUST NOT include both 'gain' and 'gaindelta' attributes within a single <audio> element.
客户端不能在单个<audio>元素中同时包含“gain”和“gaindelta”属性。
When the client explicitly controls the output gain on a conference leg, as described in Section 5.3, the 'gain' and 'gaindelta' attributes SHOULD interact with the conference leg output gain settings in the following manner.
如第5.3节所述，当客户端明确控制会议段上的输出增益时，“增益”和“增益增量”属性应以以下方式与会议段输出增益设置交互。
o Conference leg output gain set to <fixed>: The operation of the 'gain' and 'gaindelta' attributes are unchanged. However, the baseline gain value before any playback changes are applied is the value specified for the conference leg.
o 会议段输出增益设置为<固定>：“增益”和“增益增量”属性的操作不变。但是，应用任何播放更改之前的基线增益值是为会议段指定的值。
o Conference leg output gain set to <auto>: When playback gain controls are used, the automatic gain control settings for the leg are suspended for the duration of the playback operation. The operation of the 'gain' and 'gaindelta' attributes are unchanged. The automatic gain control settings are reinstated when playback has finished.
o 会议支腿输出增益设置为<自动>：使用播放增益控制时，支腿的自动增益控制设置在播放操作期间暂停。“gain”和“gaindelta”属性的操作保持不变。播放完成后，自动增益控制设置将恢复。
Media servers SHOULD support rate controls for content. However, media servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <audio> element.
媒体服务器应支持内容的速率控制。但是，如果内容限制不允许满足速率更改请求，则媒体服务器可能会自动忽略该请求。客户端不能在单个<audio>元素中同时包含“rate”和“ratedelta”属性。
Media servers MUST support local and remote (NFS) "file://" scheme URLs and "http://" and "https://" scheme URLs for content retrieval.
媒体服务器必须支持本地和远程（NFS）“文件：//”方案URL以及用于内容检索的“http://”和“https://”方案URL。
NOTE: The provisioning of NFS mount points and their mapping to the "file://" schema is purely a local matter at the media server.
注意：NFS装载点的设置及其到“file://”架构的映射纯粹是媒体服务器的本地事务。
MSCML also supports "http://" and "https://" scheme URLS that return a list of physical URLs using the "text/uri-list" MIME type. This facility provides flexibility for applications to dynamically generate prompt sequences at execution time and enables separation of this function from the client and media server.
MSCML还支持“http://”和“https://”方案URL，它们使用“text/uri list”MIME类型返回物理URL列表。此功能为应用程序在执行时动态生成提示序列提供了灵活性，并允许将此功能与客户端和媒体服务器分离。
Spoken variables are specified using the <variable> element. This element has the attributes described in the list below. MSCML's spoken variables are based on those described in Audio Server Protocol [17].
使用<variable>元素指定语音变量。此元素具有以下列表中描述的属性。MSCML的语音变量基于音频服务器协议[17]中描述的变量。
Attributes of <variable>:
<variable>的属性：
o type - required, no default value: Specifies the major type format of the spoken variable to be played. Allowable values are "dat" (date), "dig" (digit), "dur" (duration), "mth" (month), "mny" (money), "num" (number), "sil" (silence), "str" (string), "tme" (time), and "wkd" (weekday).
o type-必需，无默认值：指定要播放的语音变量的主要类型格式。允许的值有“dat”（日期）、“dig”（数字）、“dur”（持续时间）、“mth”（月份）、“mny”（货币）、“num”（数字）、“sil”（静音）、“str”（字符串）、“tme”（时间）和“wkd”（工作日）。
o subtype - optional, no default value: Specifies the minor type format of the spoken variable to be played. Allowable values depend on the value of the corresponding "type" attribute. Possible values are "mdy", "ymd", and "dmy" for dates, "t12" and "t24" for times, "gen", "ndn", "crd", and "ord" for digits, and "USD" for money.
o subtype-可选，无默认值：指定要播放的语音变量的次要类型格式。允许值取决于相应“类型”属性的值。可能的值为日期的“mdy”、“ymd”和“dmy”，时间的“t12”和“t24”，数字的“gen”、“ndn”、“crd”和“ord”，货币的“USD”。
o value - required, no default value: A string that will be interpreted based on the formatting information specified in the "type" and "subtype" attributes and the "locale" attribute of the parent <prompt> element to render the spoken variable.
o value-必需，无默认值：一个字符串，将根据父<prompt>元素的“type”和“subtype”属性以及“locale”属性中指定的格式信息来解释，以呈现口语变量。
If the "locale" attribute was not specified in <prompt>, the media server SHOULD make a selection based on platform configuration. If the precise "locale" requested cannot be honored, the media server SHOULD select the closest match based on the available content.
如果在<prompt>中未指定“locale”属性，则媒体服务器应根据平台配置进行选择。如果无法遵守请求的精确“区域设置”，则媒体服务器应根据可用内容选择最接近的匹配项。
IVR applications normally require specialized prompt content that is authored by the application provider. To deliver a quality user interaction, the specialized prompts and spoken variables must be generated by the same speaker. Since the media server inherently supports multiple simultaneous applications, it is extremely difficult to provision all the necessary application prompts and matching spoken variable content locally on the media server. Therefore, we STRONGLY RECOMMEND that clients employ the dynamic URL mechanism described earlier to generate spoken variables using an external web server that returns "text/uri-list" content.
IVR应用程序通常需要由应用程序提供商编写的专门提示内容。为了提供高质量的用户交互，必须由同一发言者生成专门的提示和语音变量。由于媒体服务器本身就支持多个同时运行的应用程序，因此很难在媒体服务器上本地提供所有必要的应用程序提示和匹配语音变量内容。因此，我们强烈建议客户端使用前面描述的动态URL机制，使用返回“文本/uri列表”内容的外部web服务器生成语音变量。
MSCML IVR requests implicitly support multimedia content. Multimedia capabilities are controlled by the audio and video media negotiated for the dialog and the content specified by the client for play and record operations. If the content specified for delivery contains both audio and video tracks and the dialog has audio and video streams, both tracks are streamed to the caller. Likewise, if the dialog has both audio and video streams and the content format specified supports both (e.g., .3gp files) the media server records both streams to the file.
MSCML IVR请求隐式支持多媒体内容。多媒体功能由对话协商的音频和视频媒体以及客户端为播放和录制操作指定的内容控制。如果指定要传送的内容同时包含音频和视频曲目，并且对话框中包含音频和视频流，则这两个曲目都会流式传送给调用者。同样，如果该对话框同时具有音频和视频流，并且指定的内容格式同时支持这两个流（例如，3gp文件），则媒体服务器会将这两个流记录到该文件中。
If there is a mismatch between the real time media and specified content, the media server MUST play or record the appropriate content tracks rather than failing the request. For example, if the client has requested playback of content with audio and video tracks but only audio media has been established for the dialog, the media server should play the audio track. If the dialog has both audio and video media but the content is audio-only, the media server MAY stream a pre-provisioned video track to the caller. Media servers SHOULD implement video transcoding functions to minimize incompatibilities between real time media and content.
如果实时媒体与指定内容不匹配，媒体服务器必须播放或录制适当的内容曲目，而不是请求失败。例如，如果客户端请求播放带有音频和视频曲目的内容，但仅为对话框建立了音频媒体，则媒体服务器应播放音频曲目。如果该对话框同时具有音频和视频媒体，但内容仅为音频，则媒体服务器可以将预先设置的视频曲目流式传输给调用者。媒体服务器应实现视频转码功能，以尽量减少实时媒体和内容之间的不兼容性。
The media server MUST begin recording video media only when it receives a refresh video frame. A refresh frame contains all the video information required to decode that frame (i.e., there is no dependency on data from previous video frames). Refresh frames are large and generally sent infrequently to conserve network bandwidth. The media server MUST implement standard mechanisms to request that the caller (video encoder) transmit a refresh frame to ensure video recording begins quickly. The media server MUST begin recording the audio track immediately while waiting to receive the video refresh frame.
媒体服务器必须仅在收到刷新视频帧时才开始录制视频媒体。刷新帧包含解码该帧所需的所有视频信息（即，不依赖于来自先前视频帧的数据）。刷新帧很大，通常不经常发送，以节省网络带宽。媒体服务器必须实现标准机制，请求调用者（视频编码器）发送刷新帧，以确保视频录制快速开始。在等待接收视频刷新帧时，媒体服务器必须立即开始录制音频曲目。
The client issues a <play> request to play an announcement without interruption and with no digit collection. One use, for example, is to announce the name of a new participant to the entire conference. The <play> request has the attributes described in the list below.
客户端发出<play>请求，在不中断和不收集数字的情况下播放公告。例如，一个用途是向整个会议宣布新参与者的姓名。<play>请求具有以下列表中描述的属性。
Attributes of <play>:
<play>的属性：
o id - optional, no default value: Specifies a client-defined ID for purposes of matching requests and responses.
o id-可选，无默认值：指定客户端定义的id，用于匹配请求和响应。
o offset - optional, default value "0": Specifies the time from the beginning of the URL specified in the 'prompturl' attribute at which play will begin. Expressed as a time value (Section 4.2.1) from 0 onwards. If the offset value is greater than the total time of the content, it will "wrap" to the beginning and continue from there until the media server reaches the specified offset. NOTE: Use of this attribute is deprecated.
o 偏移量-可选，默认值“0”：指定从“prompturl”属性中指定的URL开始播放的时间。表示为从0开始的时间值（第4.2.1节）。如果偏移量值大于内容的总时间，它将“换行”到开头并从那里继续，直到媒体服务器达到指定的偏移量。注意：不推荐使用此属性。
o promptencoding - optional, no default value: Specifies the content encoding for file formats that are not self-describing (e.g., .WAV). Allowable values are "ulaw", "alaw", and "msgsm". This attribute only affects "file://" scheme URLs. NOTE: Use of this attribute is deprecated.
o Promptencode-可选，无默认值：指定非自描述文件格式（例如.WAV）的内容编码。允许值为“ulaw”、“alaw”和“msgsm”。此属性仅影响“file://”方案URL。注意：不推荐使用此属性。
o prompturl - optional, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
o prompturl-可选，无默认值：要检索和播放的内容的URL。目标可以是本地或远程（NFS）“文件：//”方案URL或“http://”或“https://”方案URL。注意：不推荐使用此属性。
The <play> request has one child element defined, <prompt>. Use of <prompt> is described in Section 6.1.1.
<play>请求定义了一个子元素<prompt>。第6.1.1节描述了<prompt>的使用。
The client MUST NOT use both the <prompt> element and "prompturl" attribute in a single request. As previously discussed, the "prompturl" attribute is supported for backwards compatibility with older MSCML applications, but its use is deprecated. The more flexible <prompt> element SHOULD be used instead.
客户端不能在单个请求中同时使用<prompt>元素和“prompturl”属性。如前所述，支持“prompturl”属性以向后兼容较旧的MSCML应用程序，但不推荐使用它。应该使用更灵活的<prompt>元素。
The following play request (Figure 17) example shows the delivery of a complex prompt sequence consisting of content accessed via NFS and spoken variables.
下面的播放请求（图17）示例显示了复杂提示序列的交付，该序列由通过NFS访问的内容和语音变量组成。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<play id="332985001">
<prompt stoponerror="yes"
baseurl="file:////var/mediaserver/prompts/"
locale="en_US" offset="0" gain="0" rate="0"
delay="0" duration="infinite" repeat="1">
<audio url="num_dialed.raw" encoding="ulaw"/>
<variable type="dig" subtype="ndn" value="3014170700"/>
<audio url="num_invalid.wav"/>
<audio url="please_check.wav"/>
</prompt>
</play>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<play id="332985001">
<prompt stoponerror="yes"
baseurl="file:////var/mediaserver/prompts/"
locale="en_US" offset="0" gain="0" rate="0"
delay="0" duration="infinite" repeat="1">
<audio url="num_dialed.raw" encoding="ulaw"/>
<variable type="dig" subtype="ndn" value="3014170700"/>
<audio url="num_invalid.wav"/>
<audio url="please_check.wav"/>
</prompt>
</play>
</request>
</MediaServerControl>
Figure 17: <Play> Request Example
Figure 17: <Play> Request Example
When the announcement has finished playing, the media server sends a <response> payload to the client in a SIP INFO message. Details regarding the format of <play> responses are provided in Section 10.4.
当公告播放完毕后，媒体服务器将以SIP INFO消息的形式向客户端发送<response>负载。第10.4节提供了有关<play>响应格式的详细信息。
The client issues a <playcollect> request to play an announcement (optional) and collect digits. The <playcollect> request is executed in two phases, prompt and collect. If the client specifies prompt content to be played, using the <prompt> element or prompturl attribute, the media server plays the content before starting the collection phase. If no prompt content is specified, the collect phase begins immediately.
客户端发出<playcollect>请求以播放公告（可选）并收集数字。<playcollect>请求分两个阶段执行，提示和收集。如果客户端使用<prompt>元素或prompturl属性指定要播放的提示内容，则媒体服务器将在开始收集阶段之前播放内容。如果未指定提示内容，则收集阶段立即开始。
The basic attributes of <playcollect> are the same as those of <play>, which were described in Section 6.3. In addition to these basic attributes, <playcollect> defines others which control digit buffering and barge-in behavior, collection timers, special purpose DTMF key functions, and logging of user DTMF input. Each functional category and its attributes are described below.
<playcollect>的基本属性与第6.3节中描述的<play>的基本属性相同。除了这些基本属性外，<playcollect>还定义了控制数字缓冲和插入行为、采集计时器、专用DTMF键功能以及用户DTMF输入记录的其他属性。每个功能类别及其属性如下所述。
Whenever the media server is processing a call that specifies an MSCML service (i.e., "conf" and "ivr"), the media server continuously looks for DTMF digits and places them in a quarantine buffer. The quarantine buffer is examined when a <playcollect> request is received. The media server compares any previously buffered digits for barge-in, and to look for matches with DTMF grammars or special purpose keys. This provides the type-ahead behavior for menu traversal and other types of IVR interactions.
每当媒体服务器处理指定MSCML服务（即“conf”和“ivr”）的调用时，媒体服务器都会持续查找DTMF数字并将其放入隔离缓冲区。当收到<playcollect>请求时，将检查隔离缓冲区。媒体服务器将比较任何先前缓冲的数字，以便插入，并查找与DTMF语法或专用密钥的匹配。这为菜单遍历和其他类型的IVR交互提供了类型先行行为。
Attributes for Control of Digit Buffering and Barge-In:
数字缓冲和驳入控制的属性：
o cleardigits - optional, default value "no": Specifies whether previous user input should be considered or ignored for barge-in purposes and DTMF matching. When it is set to "yes", any previously buffered digits are removed, so prior user input is ignored. If it is set to "no", previously buffered digits will be considered. If "cleardigits" is set to "no" and barge-in is enabled, previously buffered digits will immediately terminate the prompt phase. In this case, the prompt is not played, and digit collection begins immediately.
o cleardigits-可选，默认值“否”：指定是否应考虑或忽略以前的用户输入，以便进行驳接和DTMF匹配。当设置为“是”时，所有先前缓冲的数字都将被删除，因此先前的用户输入将被忽略。如果设置为“否”，则将考虑先前缓冲的数字。如果“cleardigits”设置为“no”，并且启用了驳入，则先前缓冲的数字将立即终止提示阶段。在这种情况下，不会播放提示，并立即开始数字采集。
o barge - optional, default value "yes": Specifies whether user input will barge the prompt and force transition to the collect phase. When it is set to "yes", a DTMF input will barge the prompt. When it is set to "no", the prompt phase cannot be barged, and any user input during the prompt is placed in the quarantine buffer for inspection during the collect phase. Note that if the "barge" attribute is set to "no", the "cleardigits" attribute implicitly has a value of "yes". This ensures that the media server does not leave DTMF input that occurred prior to the current collection in the quarantine buffer after the request is completed.
o 驳船-可选，默认值“是”：指定用户输入是否会驳船提示并强制转换到收集阶段。当设置为“是”时，DTMF输入将触发提示。当设置为“否”时，提示阶段不能进行驳接，提示期间的任何用户输入都会被放入检疫缓冲区，以便在采集阶段进行检查。请注意，如果“驳船”属性设置为“否”，则“cleardigits”属性隐式具有值“是”。这可确保在请求完成后，媒体服务器不会将当前采集之前发生的DTMF输入保留在隔离缓冲区中。
The client can define mappings between DTMF digits and special functions. The media server invokes the special function if the associated DTMF digit is detected. MSCML has two attributes that define mappings that affect termination of the collect phase. These attributes are described in the list below.
客户端可以定义DTMF数字和特殊函数之间的映射。如果检测到相关的DTMF数字，媒体服务器将调用特殊功能。MSCML有两个属性定义影响收集阶段终止的映射。下面的列表中描述了这些属性。
DTMF Key Mappings for <playcollect>:
<playcollect>的DTMF键映射：
o escapekey - optional, default value "*": Specifies a DTMF key that indicates that the user wishes to terminate the current operation without saving any input collected to that point. Detection of the mapped DTMF key terminates the request immediately and generates a response.
o escapekey-可选，默认值“*”：指定DTMF键，该键指示用户希望终止当前操作，而不保存收集到该点的任何输入。检测到映射的DTMF密钥会立即终止请求并生成响应。
o returnkey - optional, default value "#": Specifies a DTMF key that indicates that the user has completed input and wants to return all collected digits to the client. When the media server detects the returnkey, it immediately terminates collection and returns the collected digits to the client in the <response> message.
o returnkey-可选，默认值“#”：指定一个DTMF键，指示用户已完成输入并希望将所有收集的数字返回给客户端。当媒体服务器检测到returnkey时，它会立即终止采集，并在<response>消息中将采集的数字返回给客户端。
MSCML defines three additional mappings to enable video cassette recorder (VCR) type controls while playing a prompt sequence. Media servers SHOULD support VCR controls. However, if the media server does not support VCR controls, it MUST silently ignore DTMF inputs mapped to VCR functions and complete the <playcollect> request. The VCR control attributes are described in the list below.
MSCML定义了三个额外的映射，以在播放提示序列时启用盒式录像机（VCR）类型控件。媒体服务器应支持VCR控制。但是，如果媒体服务器不支持VCR控件，它必须以静默方式忽略映射到VCR功能的DTMF输入，并完成<playcollect>请求。VCR控制属性如下表所示。
Attributes for VCR Controls:
VCR控件的属性：
o skipinterval - optional, default value "6s": The "skipinterval" attribute indicates how far the media server should skip backwards or forwards when the rewind key (rwkey) or fast forward key (ffkey) is pressed, specified as a time value (Section 4.2.1).
o skipinterval-可选，默认值“6s”：skipinterval属性表示当按回放键（rwkey）或快进键（ffkey）时，媒体服务器应向后或向前跳过的距离，指定为时间值（第4.2.1节）。
o ffkey - optional, no default value: The "ffkey" attribute maps a DTMF key to a fast forward operation equal to the value of the "skipinterval" attribute.
o ffkey-可选，无默认值：“ffkey”属性将DTMF键映射到等于“skipinterval”属性值的快进操作。
o rwkey - optional, no default value: The "rwkey" attribute maps a DTMF key to a rewind action equal to the value of the "skipinterval" attribute.
o rwkey-可选，无默认值：“rwkey”属性将DTMF键映射到等于“skipinterval”属性值的回放操作。
Clients MUST NOT map the same DTMF digit to both the "rwkey" and "ffkey" attributes in a single <playcollect> request.
客户端不得在单个<playcollect>请求中将同一DTMF数字映射到“rwkey”和“ffkey”属性。
VCR control operations are bounded by the beginning and end of the prompt sequence. A rewind action that moves the offset before the beginning of the sequence results in playback starting at the beginning of the sequence (i.e., offset=0). A fast forward action that moves the offset past the end of the sequence results in the media server's treating the sequence as complete.
VCR控制操作以提示序列的开始和结束为界限。在序列开始之前移动偏移量的倒带动作会导致从序列开始处开始播放（即偏移量=0）。将偏移量移过序列末尾的快进操作将导致媒体服务器将序列视为完整。
MSCML defines several timer attributes that control how long the media server waits for digits in the input sequence. All timer settings are time values (Section 4.2.1). The list below describes these attributes and their use.
MSCML定义了几个计时器属性，用于控制媒体服务器在输入序列中等待数字的时间。所有定时器设置均为时间值（第4.2.1节）。下面的列表描述了这些属性及其使用。
Collection Timer Attributes:
收集计时器属性：
o firstdigittimer - optional, default value "5000ms": Specifies how long the media server waits for the initial DTMF input before terminating the collection. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately whereas "infinite" indicates that the timer will never fire.
o firstdigittimer-可选，默认值“5000ms”：指定媒体服务器在终止采集之前等待初始DTMF输入的时间。表示为从1ms开始的时间值（第4.2.1节）或字符串“立即”和“无限”。值“立即”表示计时器应立即启动，而“无限”表示计时器永远不会启动。
o interdigittimer - optional, default value "2000ms": Specifies how long the media server waits between DTMF inputs. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately, whereas "infinite" indicates that the timer will never fire.
o interdigittimer-可选，默认值“2000ms”：指定媒体服务器在DTMF输入之间等待的时间。表示为从1ms开始的时间值（第4.2.1节）或字符串“立即”和“无限”。值“立即”表示计时器应立即启动，而“无限”表示计时器永远不会启动。
o extradigittimer - optional, default value "1000ms": Specifies how long the media server waits for additional user input after the specified number of digits has been collected. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately, whereas "infinite" indicates that the timer will never fire.
o extradigittimer-可选，默认值“1000ms”：指定媒体服务器在收集指定位数后等待其他用户输入的时间。表示为从1ms开始的时间值（第4.2.1节）或字符串“立即”和“无限”。值“立即”表示计时器应立即启动，而“无限”表示计时器永远不会启动。
o interdigitcriticaltimer - optional, defaults to the value of the interdigittimer attribute: Specifies how long the media server waits after a grammar has been matched for a subsequent digit that may cause a longer match. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" results in "shortest match first" behavior, whereas "infinite" means to wait indefinitely for additional input. If not explicitly specified otherwise, this attribute is set to the value of the 'interdigittimer' attribute.
o interdigitcriticaltimer-可选，默认为interdigittimer属性的值：指定语法匹配可能导致更长匹配的后续数字后，媒体服务器等待的时间。表示为从1ms开始的时间值（第4.2.1节）或字符串“立即”和“无限”。值“立即”导致“最短匹配优先”行为，而“无限”表示无限期等待其他输入。如果未明确指定，则此属性将设置为“interdigittimer”属性的值。
The extradigittimer setting enables the "returnkey" input to be associated with the current collection. For example, if maxdigits is set to 3 and returnkey is set to #, the user may enter either "x#", "xx#", or "xxx#", where x represents a DTMF digit.
extradigittimer设置使“returnkey”输入与当前集合相关联。例如，如果maxdigits设置为3，returnkey设置为#，则用户可以输入“x”、“xx”或“xxx”，其中x表示DTMF数字。
If the media server detects the "returnkey" pattern during the "extradigit" interval, the media server returns the collected digits to the client and removes the "returnkey" from the digit buffer.
如果媒体服务器在“extradigit”间隔期间检测到“returnkey”模式，则媒体服务器会将收集到的数字返回给客户端，并从数字缓冲区中删除“returnkey”。
If this were not the case, the example would return "xxx" to the client and leave the terminating "#" in the digit buffer. At the next <playcollect> request, the media server would process the '#'. This might result in the termination of the following prompt, which is clearly not what the user intended.
如果不是这样，示例将向客户端返回“xxx”，并在数字缓冲区中保留终止“#”。在下一个<playcollect>请求中，媒体服务器将处理“#”。这可能会导致以下提示终止，这显然不是用户想要的。
The extradigittimer has no effect unless returnkey has been set.
除非设置了returnkey，否则extradigittimer无效。
Standard SIP mechanisms, such as those discussed in Security Considerations (Section 14), protect MSCML protocol exchanges and the information they contain. These protections do not apply to data captured in media server log files. In general, media server logging is platform specific and therefore is not covered by this specification. However, one aspect of logging, the capture of sensitive information (such as personal identification numbers or credit card numbers), is relevant. The media server has no means to determine whether the DTMF input it receives may be sensitive, as that is in the purview of the client. Recognizing this, MSCML includes a per- request mechanism to suppress logging of captured DTMF to be enabled by clients as needed.
标准SIP机制（如安全注意事项（第14节）中讨论的机制）保护MSCML协议交换及其包含的信息。这些保护不适用于媒体服务器日志文件中捕获的数据。一般来说，媒体服务器日志记录是特定于平台的，因此不在本规范的范围内。然而，日志记录的一个方面，即敏感信息（如个人身份号码或信用卡号码）的捕获是相关的。媒体服务器无法确定其接收的DTMF输入是否敏感，因为这属于客户端的权限。认识到这一点，MSCML包括一个按请求机制，用于抑制客户端根据需要启用捕获的DTMF的日志记录。
The "maskdigits" attribute controls whether detected DTMF digits appear in the log output. Clients use this attribute when the media server collects sensitive information that should not be accessible through the log files.
“maskdigits”属性控制检测到的DTMF数字是否出现在日志输出中。当媒体服务器收集不应通过日志文件访问的敏感信息时，客户端使用此属性。
Maskdigits Attribute:
Maskdigits属性：
o maskdigits - optional, default value "no": Controls whether user DTMF inputs are captured in media server log files. The possible values for this attribute are "yes" and "no".
o maskdigits-可选，默认值“否”：控制是否在媒体服务器日志文件中捕获用户DTMF输入。此属性的可能值为“是”和“否”。
MSCML supports four methods for specifying DTMF grammars: the "maxdigits" attribute, which provides a simple mechanism for collecting any number of digits up to the maximum, regular expressions, MGCP [5] digit maps, and H.248.1 [6] digit maps. A media server MUST support the maxdigits and regular expression methods for specifying DTMF grammars and SHOULD support MGCP and H.248.1 methods. A client MUST NOT mix DTMF grammar types in a single <playcollect> request.
MSCML支持四种指定DTMF语法的方法：“maxdigits”属性，它提供了一种简单的机制，用于收集最大数量的数字、正则表达式、MGCP[5]数字映射和H.248.1[6]数字映射。媒体服务器必须支持指定DTMF语法的maxdigits和正则表达式方法，并应支持MGCP和H.248.1方法。客户端不能在单个<playcollect>请求中混合DTMF语法类型。
Following is a description of the "maxdigits" attribute.
以下是“maxdigits”属性的说明。
Maxdigits Attribute:
Maxdigits属性：
o maxdigits - optional, no default value: Specifies the maximum number of DTMF digits to be collected.
o maxdigits-可选，无默认值：指定要收集的最大DTMF位数。
The <pattern> element specifies a digit pattern or patterns for the media server to look for. This element may contain three different child elements that specify the type of DTMF grammar used in the expression. The <pattern> element has no attributes.
元素指定媒体服务器要查找的一个或多个数字模式。此元素可能包含三个不同的子元素，它们指定表达式中使用的DTMF语法类型。<pattern>元素没有属性。
<regex> Use regular expressions to define DTMF patterns to match. The complete regular expression syntax used in MSCML is described in Appendix A.
<regex>使用正则表达式定义要匹配的DTMF模式。MSCML中使用的完整正则表达式语法如附录A所述。
<mgcpdigitmap> Use digit maps as specified in MGCP [5].
<mgcpdigitmap>使用MGCP[5]中指定的数字映射。
<megacodigitmap> Use digit maps as specified in H.248.1 [6].
<megacodigitmap>使用H.248.1[6]中规定的数字映射。
At least one <regex> element MUST be present in <pattern> when regex grammars are used. Multiple <regex> elements MAY be present. When <mgcpdigitmap> or <megacodigitmap> grammars are used, <pattern> MUST contain only one grammar element.
使用正则表达式语法时，<pattern>中必须至少存在一个<regex>元素。可能存在多个<regex>元素。当使用<mgcpdigitmap>或<megacodigitmap>语法时，<pattern>必须只包含一个语法元素。
The DTMF grammar elements <regex>, <mgcpdigitmap>, and <megacodigitmap> have the attributes described in the list below.
DTMF语法元素<regex>、<mgcpdigitmap>和<megacodigitmap>具有下面列表中描述的属性。
Attributes of DTMF Grammar Elements:
DTMF语法元素的属性：
o value - required, no default value: Specifies a string representing a DTMF grammar matching the parent element type (e.g., regex). Regex values represent a single DTMF grammar. MGCP and MEGACO digit maps allow multiple grammars to be described in a single string.
o value-必需，无默认值：指定表示与父元素类型（例如regex）匹配的DTMF语法的字符串。正则表达式值表示单个DTMF语法。MGCP和MEGACO数字映射允许在单个字符串中描述多个语法。
o name - optional, no default value: Associates a client defined name for the grammar that is sent back in the <playcollect> response. This attribute is most useful with regex type grammars as each grammar element can have a unique name.
o name-可选，无默认值：为<playcollect>响应中返回的语法关联客户端定义的名称。该属性对于正则表达式类型的语法非常有用，因为每个语法元素都可以有一个唯一的名称。
When the <playcollect> has finished, the media server sends a <response> payload to the client in a SIP INFO message.
当<playcollect>完成时，媒体服务器将在SIP INFO消息中向客户端发送<response>负载。
Details of the <playcollect> response are described in Section 10.5.
第10.5节描述了<playcollect>响应的详细信息。
The following <playcollect> request (Figure 18) example depicts use of the "maxdigits" attribute to control digit collection.
下面的<playcollect>请求（图18）示例描述了使用“maxdigits”属性来控制数字收集。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<playcollect id="332986004" maxdigits="6" firstdigittimer="10000"
interdigittimer="5000" extradigittimer="1000"
interdigitcriticaltimer="1000" returnkey="#" escapekey="*"
cleardigits="no" barge="yes" maskdigits="no">
<prompt baseurl="http://www.example.com/prompts/">
<audio url="generic/en_US/enter_pin.wav"/>
</prompt>
</playcollect>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<playcollect id="332986004" maxdigits="6" firstdigittimer="10000"
interdigittimer="5000" extradigittimer="1000"
interdigitcriticaltimer="1000" returnkey="#" escapekey="*"
cleardigits="no" barge="yes" maskdigits="no">
<prompt baseurl="http://www.example.com/prompts/">
<audio url="generic/en_US/enter_pin.wav"/>
</prompt>
</playcollect>
</request>
</MediaServerControl>
Figure 18: <Playcollect> Request Example Using the Maxdigits Attribute
图18:<Playcollect>使用Maxdigits属性的请求示例
The <playrecord> request directs the media server to convert and possibly to transcode the RTP payloads it receives and store them to the specified URL using the requested content codec(s) and file format. This request proceeds in two phases; prompt and record.
<playrecord>请求指示媒体服务器转换它接收的RTP有效负载，并可能对其进行转码，然后使用请求的内容编解码器和文件格式将其存储到指定的URL。这项请求分两个阶段进行；提示并记录。
The <playrecord> request shares the basic attributes of <play> and <playcollect> as described in Section 6.3. MSCML also defines other attributes that control the behavior of the prompt and recording phases. These phases and the attributes that control them are described in the text and tables below.
<playrecord>请求共享第6.3节所述的<play>和<playcollect>的基本属性。MSCML还定义了控制提示和录制阶段行为的其他属性。这些阶段以及控制这些阶段的属性在下面的文本和表格中进行了描述。
The presence or absence of a "prompturl" attribute or child <prompt> element controls whether a prompt is played before recording begins. As previously noted, use of the "prompturl" attribute is deprecated, and clients SHOULD use <prompt> instead.
“prompturl”属性或子<prompt>元素的存在与否控制录制开始前是否播放提示。如前所述，不推荐使用“prompturl”属性，客户机应该使用<prompt>。
When the client requests that the media server prompt the caller before recording audio, <playrecord> has two stages. The first is equivalent to a <playcollect> operation. The client may set the prompt phase to be interruptible by DTMF input (barge) and may specify an escape key that will terminate the <playrecord> request before the recording phase begins.
当客户端请求媒体服务器在录制音频之前提示调用者时，<playrecord>有两个阶段。第一个相当于<playcollect>操作。客户端可将提示阶段设置为可由DTMF输入（驳船）中断，并可指定一个退出键，该键将在录制阶段开始之前终止<playrecord>请求。
The list below describes the attributes of <playrecord> that specify the behavior of the prompt phase of the request.
下面的列表描述了<playrecord>的属性，这些属性指定了请求的提示阶段的行为。
Playrecord Attributes for the Prompt Phase:
提示阶段的播放记录属性：
o barge - optional, default value "yes": Specifies whether user input will barge the prompt and force transition to the record phase. When it is set to "yes", a DTMF input will barge the prompt. When it is set to "no", the prompt phase cannot be barged, and any user input during the prompt is placed in the quarantine buffer for inspection during the collect phase. Note that if the "barge" attribute is set to "no", the "cleardigits" attribute implicitly has a value of "yes". This ensures that the media server does not leave DTMF input that occurred prior to the current collection in the quarantine buffer after the request completes.
o 驳接-可选，默认值“是”：指定用户输入是否将驳接提示并强制转换到记录阶段。当设置为“是”时，DTMF输入将触发提示。当设置为“否”时，提示阶段不能进行驳接，提示期间的任何用户输入都会被放入检疫缓冲区，以便在采集阶段进行检查。请注意，如果“驳船”属性设置为“否”，则“cleardigits”属性隐式具有值“是”。这可确保在请求完成后，媒体服务器不会将当前采集之前发生的DTMF输入保留在隔离缓冲区中。
o cleardigits - optional, default value "no": Specifies whether previous user input should be considered or ignored for barge-in purposes. When it is set to "yes", any previously buffered digits are removed, so prior user input is ignored. If it is set to "no", previously buffered digits will be considered. If "cleardigits" is set to "no" and barge-in is enabled, previously buffered digits will terminate the prompt phase immediately. In this case, the prompt is not played, and recording begins immediately.
o cleardigits-可选，默认值“否”：指定是否应考虑或忽略以前的用户输入以进行驳接。当设置为“是”时，所有先前缓冲的数字都将被删除，因此先前的用户输入将被忽略。如果设置为“否”，则将考虑先前缓冲的数字。如果“cleardigits”设置为“no”，并且启用了驳入，则先前缓冲的数字将立即终止提示阶段。在这种情况下，不会播放提示，并立即开始录制。
o escapekey - optional, default value "*": Specifies a DTMF key that indicates the user wishes to terminate the current operation without saving any input recorded to that point. Detection of the mapped DTMF key terminates the request immediately and generates a response.
o escapekey-可选，默认值“*”：指定DTMF键，表示用户希望终止当前操作，而不保存记录到该点的任何输入。检测到映射的DTMF密钥会立即终止请求并生成响应。
Detection of the escape key generates a response message, and the operation returns immediately. If the user presses any other keys and if the prompt is interruptible (barge="yes"), then the play stops immediately, and the recording phase begins.
检测到转义键会生成一条响应消息，操作会立即返回。如果用户按下任何其他键并且提示可中断（barge=“yes”），则播放立即停止，录制阶段开始。
If the request proceeds to the recording phase, the media server discards any digits from the collect phase from the quarantine buffer to eliminate unintended termination of the recording. The following attributes control recording behavior.
如果请求进入录制阶段，媒体服务器将从隔离缓冲区丢弃收集阶段的任何数字，以消除录制的意外终止。以下属性控制录制行为。
Playrecord Attributes for the Record Phase:
录制阶段的播放录制属性：
o recurl - required, no default value: Specifies the target URL for the recorded content.
o recurl-必需，无默认值：指定录制内容的目标URL。
o recencoding - optional, default value "ulaw": Specifies the encoding of the recorded content if it cannot be inferred from the recurl. Possible values are "ulaw", "alaw", and "msgsm."
o recencoding-可选，默认值“ulaw”：如果无法从recurl推断出录制内容，则指定录制内容的编码。可能的值为“ulaw”、“alaw”和“msgsm”
o mode - optional, default value "overwrite": Specifies whether the recording should overwrite or be appended to the target URL. Allowable values are "overwrite" and "append."
o 模式-可选，默认值“覆盖”：指定录制是应覆盖还是附加到目标URL。允许的值为“覆盖”和“附加”
o duration - optional, default value "infinite": Specifies the maximum allowable duration for the recording. Expressed as a time value (Section 4.2.1) from 1 onwards or the strings "immediate" and "infinite." The value "immediate" indicates that recording will end immediately, whereas "infinite" indicates recording should continue indefinitely. If the maximum duration is reached, the <playrecord> request will terminate and generate a response.
o 持续时间-可选，默认值“无限”：指定录制允许的最大持续时间。表示为从1开始的时间值（第4.2.1节）或字符串“立即”和“无限”。值“立即”表示记录将立即结束，而“无限”表示记录应无限期继续。如果达到最大持续时间，<playrecord>请求将终止并生成响应。
o beep - optional, default value "yes": Specifies whether a beep should be played to the caller immediately prior to the start of the recording phase. Allowable values are "yes" and "no."
o 蜂鸣音-可选，默认值“是”：指定是否应在录音阶段开始前立即向呼叫者播放蜂鸣音。允许值为“是”和“否”
o initsilence - optional, default value "3000ms": Specifies how long to wait for initial speech input before terminating (canceling) the recording. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately, whereas "infinite" directs the media server to wait indefinitely.
o initsilence-可选，默认值“3000ms”：指定在终止（取消）录制之前等待初始语音输入的时间。表示为从1ms开始的时间值（第4.2.1节）或字符串“立即”和“无限”。值“立即”表示计时器应立即启动，而“无限”指示媒体服务器无限期等待。
o endsilence - optional, default value "4000ms": Specifies how long the media server waits after speech has ended to stop the recording. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." When set to "infinite", the recording will continue indefinitely after speech has ended and will only terminate due to a DTMF keypress or because the input has reached the maximum desired duration.
o endsilence-可选，默认值“4000ms”：指定语音结束后媒体服务器等待多长时间停止录制。以1ms后的时间值（第4.2.1节）或字符串“立即”和“无限”表示。当设置为“无限”时，录音将在语音结束后无限期继续，并且仅因DTMF按键或输入达到最大期望持续时间而终止。
o recstopmask - optional, default value "0123456789ABCD#*": Specifies a list of individual DTMF characters that, if detected, will cause the recording to be terminated. To ensure that the input of a specific key does not cause the recording to stop, remove the DTMF key from the list.
o recstopmask-可选，默认值“0123456789ABCD#*”：指定单个DTMF字符的列表，如果检测到这些字符，将导致终止录制。为确保特定键的输入不会导致录制停止，请从列表中删除DTMF键。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
媒体服务器必须在“recurl”属性中支持本地和远程（NFS）“file://”方案URL。MSCML通过<managecontent>（第8节）请求间接支持“http://”和“https://”方案URL。
The media server buffers and returns any digits collected in the prompt phase, with the exception of those contained in the "recstopmask" attribute, in the response.
媒体服务器缓冲并返回响应中提示阶段收集的所有数字，但“recstopmask”属性中包含的数字除外。
The media server compares digits detected during the recording phase to the digits specified in the "recstopmask" to determine whether they indicate a recording termination request.
媒体服务器将在录制阶段检测到的数字与“recstopmask”中指定的数字进行比较，以确定它们是否表示录制终止请求。
The media server ignores digits not present in the recstopmask and passes them into the recording. If DTMF input terminates the recording, the media server returns the collected digit to the client in the <response>.
媒体服务器忽略recstopmask中不存在的数字，并将其传递到录制中。如果DTMF输入终止录制，媒体服务器将在<response>中将采集的数字返回给客户端。
Once recording has begun, the media server writes the received media to the specified recurl URL no matter what DTMF events the media server detects. It is the responsibility of the client to examine the DTMF input returned in the <response> message to determine whether the audio file should be saved or deleted and, potentially, re-recorded.
录制开始后，无论媒体服务器检测到何种DTMF事件，媒体服务器都会将接收到的媒体写入指定的recurl URL。客户端负责检查<response>消息中返回的DTMF输入，以确定是否应保存或删除音频文件，并可能重新录制。
If the endsilence timer expires, the media server trims the end of the recorded audio by an amount equal to the value of the "endsilence" attribute.
如果endsilence计时器过期，媒体服务器将按等于“endsilence”属性值的量修剪录制音频的结尾。
When the recording is finished, the media server generates a <response> message and sends it to the client in a SIP INFO message. Details of the <playrecord> response are described in Section 10.6.
录制完成后，媒体服务器将生成一条<response>消息，并以SIP INFO消息的形式发送给客户端。<playrecord>响应的详细信息见第10.6节。
The recording example (Figure 19) plays a prompt and records it to the destination specified in the "recurl" attribute encoded as MS-GSM in wave format.
记录示例（图19）播放一个提示，并将其记录到“recurl”属性中指定的目的地，该属性以wave格式编码为MS-GSM。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<playrecord id="5556123"
recurl="file:////nfs.example.com/rec/name.wav"
recencoding="msgsm"
initsilence="5000" endsilence="3000" duration="30000"
barge="yes"
beep="yes"
mode="overwrite"
cleardigits="no"
escapekey="*"
recstopmask="0123456789#*">
<prompt>
<audio url="http://www.example.com/prompts/recordname.wav"/>
</prompt>
</playrecord>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<playrecord id="5556123"
recurl="file:////nfs.example.com/rec/name.wav"
recencoding="msgsm"
initsilence="5000" endsilence="3000" duration="30000"
barge="yes"
beep="yes"
mode="overwrite"
cleardigits="no"
escapekey="*"
recstopmask="0123456789#*">
<prompt>
<audio url="http://www.example.com/prompts/recordname.wav"/>
</prompt>
</playrecord>
</request>
</MediaServerControl>
Figure 19: Recording Example
图19：记录示例
The client issues a <stop> request when the objective is to stop a request in progress and not to initiate another operation. This request generates a <response> message from the media server.
当目标是停止正在进行的请求而不是启动另一个操作时，客户端发出<stop>请求。此请求从媒体服务器生成<response>消息。
The only attribute is id, which is optional.
唯一的属性是id，这是可选的。
The client-defined request id correlates the asynchronous response with its original request and echoes back to the client in the media server's response.
客户端定义的请求id将异步响应与其原始请求相关联，并在媒体服务器的响应中回显到客户端。
The following MSCML payload (Figure 20) depicts an example <stop> request.
下面的MSCML有效负载（图20）描述了一个示例<stop>请求。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<stop id="4578903"/>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<stop id="4578903"/>
</request>
</MediaServerControl>
Figure 20: Stop Example
图20：停止示例
The format of a response to a <stop> request is detailed in Section 10.2.
第10.2节详细说明了对<stop>请求的响应格式。
As discussed previously, the media server treats a SIP re-INVITE that modifies the established SDP parameters as an implicit <stop> request. Examples of such SDP modifications include receiving hold SDP or removing an audio or video stream. When this occurs, the media server immediately terminates the running <play>, <playcollect>, or <playrecord> request and sends a <response> indicating "reason=stopped".
如前所述，媒体服务器将修改已建立SDP参数的SIP重新邀请视为隐式<stop>请求。此类SDP修改的示例包括接收保持SDP或移除音频或视频流。出现这种情况时，媒体服务器会立即终止正在运行的<play>、<playcollect>或<playcrecord>请求，并发送一个<response>，指示“原因=已停止”。
MSCML defines event notifications that are scoped to a specific SIP dialog or call leg. These events allow a client to be notified of individual, asynchronous DTMF keypresses, as well as of various call progress signals. The subscription, event detection, and notifications for call leg events occur in the same SIP dialog. This is different from the conference level active talker events described earlier. The subscription and notifications for active talker events occur on the conference control leg, but the actual event detection occurs on one or more participant legs.
MSCML定义事件通知，其作用域为特定SIP对话或呼叫分支。这些事件允许向客户端通知单个异步DTMF按键以及各种呼叫进度信号。呼叫分支事件的订阅、事件检测和通知发生在同一个SIP对话框中。这与前面描述的会议级主动对话者事件不同。活动说话者事件的订阅和通知发生在会议控制分支上，但实际事件检测发生在一个或多个参与者分支上。
Subscriptions for call leg events are made by sending an MSCML <configure_leg> request on the desired SIP dialog. Call leg events may be used with the MSCML conferencing or IVR services. When used with the IVR service, the <configure_leg> request SHOULD NOT include any conference-related attributes. The media server MUST ignore these if present. Call leg event subscriptions MUST NOT be made on the conference control leg, since it has no actual RTP media to process for event detection. The media server MUST reject a <configure_leg> request sent on the conference control leg.
通过在所需的SIP对话框上发送MSCML<configure\u leg>请求来订阅呼叫分支事件。呼叫分支事件可与MSCML会议或IVR服务一起使用。与IVR服务一起使用时，<configure\u leg>请求不应包括任何与会议相关的属性。媒体服务器必须忽略这些（如果存在）。呼叫分支事件订阅不得在会议控制分支上进行，因为它没有用于事件检测的实际RTP介质。媒体服务器必须拒绝在会议控制分支上发送的<configure\u leg>请求。
The <configure_leg> request contains the child elements <subscribe> and <events>. The <events> element may contain two child elements that control subscriptions to call leg events. These are <keypress> and <signal>. A <configure_leg> request MUST contain at most one <keypress> element but MAY contain multiple <signal> elements that request notification of different call progress events.
<configure\u leg>请求包含子元素<subscribe>和<events>。<events>元素可能包含两个子元素，它们控制对调用段事件的订阅。它们是<keypress>和<signal>。一个<configure_leg>请求最多必须包含一个<keypress>元素，但可以包含多个<signal>元素，请求通知不同的呼叫进度事件。
Keypress events are used when the client wishes to receive notifications of individual DTMF events that are not tied to a specific <playcollect> request. One use of this facility is to monitor conference legs for DTMF inputs that require application intervention; for example, to notify the moderator that the caller wishes to speak. Keypress events are also used when the application desires complete control of grammars and timing constraints.
当客户端希望接收未绑定到特定<playcollect>请求的单个DTMF事件通知时，可使用按键事件。该设备的一个用途是监控需要应用程序干预的DTMF输入的会议分支；例如，通知主持人来电者希望发言。当应用程序希望完全控制语法和时序约束时，也会使用按键事件。
When used in a subscription context, the <keypress> element has two attributes, 'report' and 'maskdigits', which are detailed in the list below.
在订阅上下文中使用时，<keypress>元素有两个属性，“report”和“maskdigits”，详细信息如下所示。
Keypress Subscription Attributes:
按键订阅属性：
o report - required, no default value: Possible values are 'standard', 'long', 'both', and 'none'. 'Standard' means that detected digits should be reported. 'Long' means that long digits should be reported. 'Long' digits are defined as a single key press held down for more than one second, or two distinct key presses (a "double") of the same digit that occur within two seconds of each other with no other intervening digits. 'Both' means that both 'standard' and 'long' digit events should be reported. As a 'long' digit consists of one or more "normal" digits, a single long duration key press will generate one standard event and one 'long' event. A "double" will produce two standard events and one 'long' event. 'None' means that no keypress events should be reported; it disables keypress event reporting if enabled.
o 报告-必需，无默认值：可能的值为“标准”、“长”、“两者”和“无”“标准”表示应报告检测到的数字“长”表示应报告长数字“长”数字定义为一次按住一秒钟以上的按键，或两次不同的同一数字按键（一个“双”）在两秒钟内发生，没有其他中间数字“两者”表示应报告“标准”和“长”数字事件。由于“长”数字由一个或多个“正常”数字组成，单次长时间按键将生成一个标准事件和一个“长”事件。“双人”将产生两个标准项目和一个“长”项目“无”表示不应报告按键事件；如果启用，则禁用按键事件报告。
o maskdigits - optional, default value "no": Controls whether user DTMF inputs are captured in media server log files. The possible values for this attribute are "yes" and "no".
o maskdigits-可选，默认值“否”：控制是否在媒体服务器日志文件中捕获用户DTMF输入。此属性的可能值为“是”和“否”。
The media server sends an MSCML response to the subscription immediately upon receiving the request. Notifications are sent to the client when the specified events are detected.
媒体服务器在收到请求后立即向订阅发送MSCML响应。当检测到指定的事件时，会向客户端发送通知。
When used in a notification context, the <keypress> element has several attributes that are used to convey details of the event that was detected. It also contains a child element, <status>, that provides information on any MSCML request that was in progress when the event occurred. The details of these notification attributes are described in the list below.
在通知上下文中使用时，<keypress>元素具有多个属性，用于传递检测到的事件的详细信息。它还包含一个子元素<status>，该元素提供事件发生时正在进行的任何MSCML请求的信息。下面的列表中描述了这些通知属性的详细信息。
Keypress Notification Attributes:
按键通知属性：
o digit - required, no default value: Specifies the DTMF digit detected. Possible values are [0-9], [A-D], '#', or '*'.
o 数字-必需，无默认值：指定检测到的DTMF数字。可能的值为[0-9]、[A-D]、“#”或“*”。
o length - required, no default value: Specifies the duration class of the DTMF input. Possible values are 'standard' or 'long'.
o 长度-必需，无默认值：指定DTMF输入的持续时间类别。可能的值为“标准”或“长”。
o method - required, no default value: Specifies the keypress detection method that generated the notification. Possible values are 'standard', 'long', and 'double'.
o 方法-必需，无默认值：指定生成通知的按键检测方法。可能的值为“标准”、“长”和“双精度”。
o interdigittime - required, no default value: Specifies the elapsed time, as a time value (Section 4.2.1), between the current event detection and the previous one.
o interdigittime-必需，无默认值：指定当前事件检测和上一个事件检测之间经过的时间，作为时间值（第4.2.1节）。
The following examples of MSCML payloads depict a subscription for standard keypress events and disabling keypress reporting.
以下MSCML有效负载示例描述了标准按键事件的订阅和禁用按键报告。
Figure 21 shows a subscription for standard keypress events.
图21显示了标准按键事件的订阅。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<keypress report="standard"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<keypress report="standard"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
Figure 21: Standard Digit Events Subscription
图21：标准数字事件订阅
Figure 22 shows a client disabling keypress event notifications.
图22显示了一个禁用按键事件通知的客户端。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<keypress report="none"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<keypress report="none"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
Figure 22: Disabling Keypress Event Reporting
图22：禁用按键事件报告
The following MSCML payloads depict keypress event notifications caused by various types of DTMF input.
以下MSCML有效负载描述了由各种类型的DTMF输入引起的按键事件通知。
Figure 23 shows a notification generated by the detection of a standard "4" DTMF digit. In this example, this is the first digit detected. Thus, the 'interdigittime' attribute has a value of '0'.
图23显示了通过检测标准“4”DTMF数字生成的通知。在本例中，这是检测到的第一个数字。因此，“interdigittime”属性的值为“0”。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<keypress digit="4" length="standard" method="standard"
interdigittime="0">
<status command="play" duration="10"/>
</keypress>
</notification>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<keypress digit="4" length="standard" method="standard"
interdigittime="0">
<status command="play" duration="10"/>
</keypress>
</notification>
</MediaServerControl>
Figure 23: Standard Keypress Notification
图23：标准按键通知
Figure 24 shows a notification generated by detection of a long pound (#).
图24显示了通过检测长磅（#）生成的通知。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<keypress digit="#" length="long" method="long"
interdigittime="200">
<status command="idle" duration="4"/>
</keypress>
</notification>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<keypress digit="#" length="long" method="long"
interdigittime="200">
<status command="idle" duration="4"/>
</keypress>
</notification>
</MediaServerControl>
Figure 24: Long Keypress Notification
图24：长按键通知
MSCML supports notification of certain call progress tones through the <signal> element. When used in a subscription context, the <signal> element has two attributes, 'type' and 'report', and no child elements. These attributes are detailed in the list below.
MSCML支持通过<signal>元素通知某些通话进度音。在订阅上下文中使用时，<signal>元素有两个属性，“type”和“report”，并且没有子元素。下面的列表中详细介绍了这些属性。
Signal Subscription Attributes:
信号订阅属性：
o report - required, no default value: Controls whether the specified signal is reported. Possible values are 'yes' and 'no'. When set to 'yes', the media server invokes the required signal detection code and reports detected events. When it is set to 'no', the media server disables the associated signal detection code and does not report events.
o 报告-必需，无默认值：控制是否报告指定的信号。可能的值为“是”和“否”。当设置为“是”时，媒体服务器将调用所需的信号检测代码并报告检测到的事件。当设置为“否”时，媒体服务器将禁用相关的信号检测代码，并且不报告事件。
o type - required, no default value: Specifies the type of call progress signal to detect. Possible values are 'busy', 'ring', 'CED', 'CNG', and '400', which correspond to busy tone, ring tone, fax CED, fax CNG, and 400 Hz tone, respectively.
o type-必需，无默认值：指定要检测的呼叫进度信号的类型。可能的值为“忙音”、“铃声”、“CED”、“CNG”和“400”，分别对应于忙音、铃声、传真CED、传真CNG和400 Hz音调。
NOTE: The details of media server provisioning required to support country-specific variants of 'busy' and 'ring' is not covered by this specification.
注意：本规范不包括支持特定国家/地区的“忙”和“环”变体所需的媒体服务器配置的详细信息。
As stated previously, a single <configure_leg> request MAY contain multiple <signal> elements that request notification of different call progress tones. A single <configure_leg> request SHOULD NOT contain multiple <signal> elements that have the same 'type' attribute value. If the media server receives such a request, it SHOULD honor the last element specifying that type that appears in the request.
如前所述，单个<configure\u leg>请求可能包含多个<signal>元素，这些元素请求不同呼叫进度音的通知。单个<configure\u leg>请求不应包含具有相同“type”属性值的多个<signal>元素。如果媒体服务器收到这样的请求，它应该接受最后一个指定请求中出现的类型的元素。
The media server generates an immediate response to the <configure_leg> subscription request and sends notifications when the specified signals are detected. A single notification is sent as soon as the specified signal has been reliably detected. If the signal persists continuously, additional notifications will not be sent. If the signal is interrupted and then resumes, additional notifications will be sent.
媒体服务器立即响应<configure_leg>订阅请求，并在检测到指定信号时发送通知。一旦可靠地检测到指定的信号，就会发送单个通知。如果信号持续存在，则不会发送其他通知。如果信号中断，然后恢复，将发送其他通知。
Signal notifications have a single attribute, "type", as described in the list below.
信号通知只有一个属性“type”，如下表所述。
Signal Notification Attribute:
信号通知属性：
o type - required, no default value: Specifies the type of call progress signal that was detected. Possible values are 'busy', 'ring', 'CED', 'CNG', and '400', which correspond to busy tone, ring tone, fax CED, fax CNG, and 400 Hz tone, respectively.
o 类型-必需，无默认值：指定检测到的呼叫进度信号的类型。可能的值为“忙音”、“铃声”、“CED”、“CNG”和“400”，分别对应于忙音、铃声、传真CED、传真CNG和400 Hz音调。
The following MSCML payloads show a signal event subscription (Figure 25) and notification (Figure 26).
以下MSCML有效负载显示了信号事件订阅（图25）和通知（图26）。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<signal type="busy" report="yes"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<signal type="busy" report="yes"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
Figure 25: Signal Event Subscription
图25：信号事件订阅
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<signal type="busy"/>
</notification>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<signal type="busy"/>
</notification>
</MediaServerControl>
Figure 26: Signal Event Notification
图26：信号事件通知
MSCML uses the <managecontent> request to move recorded content from the media server to remote locations using the HTTP protocol. This is a store-and-forward model, which requires the completion of local temporary recording before the media server can send it to the web server. This facility is useful in applications such as voice messaging, where a message may be reviewed by the caller prior to being committed to persistent storage.
MSCML使用<managecontent>请求使用HTTP协议将录制的内容从媒体服务器移动到远程位置。这是一种存储转发模式，需要先完成本地临时录制，然后媒体服务器才能将其发送到web服务器。在将语音消息传递设施提交到诸如持久性消息传递设施中之前，语音消息传递设施可能是有用的。
The <managecontent> request contains no child elements and has the attributes described in the list below.
<managecontent>请求不包含子元素，并且具有下面列表中描述的属性。
Managecontent Attributes:
Managecontent属性：
o src - required, no default value: Specifies the local source URL of the content. The URL scheme MUST be "file://".
o src-必需，无默认值：指定内容的本地源URL。URL方案必须为“file://”。
o dest - required (see note), no default value: Specifies the destination URL. The URL scheme MUST be "http://". Note: If the selected action is 'delete', this attribute is optional; otherwise it is required.
o dest-必需（请参见注释），无默认值：指定目标URL。URL方案必须为“http://”。注意：如果所选操作为“删除”，则此属性是可选的；否则，它是必需的。
o action - optional, default value "move": Specifies the operation for the media server to execute. Values can be either 'move' or 'delete'. The 'delete' action operates on the local source file. After a successful move or delete, the media server deletes the source file from its local storage. If the request is unsuccessful, the source file is not deleted, which gives the client complete control of the retry strategy.
o 操作-可选，默认值“移动”：指定媒体服务器要执行的操作。值可以是“移动”或“删除”。“删除”操作对本地源文件进行操作。成功移动或删除后，媒体服务器将从其本地存储中删除源文件。如果请求不成功，则不会删除源文件，从而使客户端完全控制重试策略。
o httpmethod - optional, default value "post": HTTP protocol method for the media server to use in the HTTP request. The only values are 'post' or 'put'.
o httpmethod-可选，默认值“post”：媒体服务器在HTTP请求中使用的HTTP协议方法。唯一的值是“post”或“put”。
o name - required (see note), no default value: Specifies the field name for the content in the form when using the 'post' method. This is not to be confused with the "src" or "dest" attributes. Note: This attribute is required when the "htttpmethod" has the value "post" and is optional otherwise.
o 名称-必需（请参见注释），无默认值：使用“post”方法时，指定表单中内容的字段名称。这不能与“src”或“dest”属性混淆。注意：当“htttpmethod”的值为“post”时，该属性是必需的，否则该属性是可选的。
o fetchtimeout - optional, default value "10000ms": Specifies the maximum time allowed for the transfer to complete. Expressed as a time value (Section 4.2.1) from 1ms onwards.
o fetchtimeout-可选，默认值“10000ms”：指定完成传输所允许的最长时间。表示为从1ms开始的时间值（第4.2.1节）。
o mimetype - required (see note), no default value: Specifies the MIME type that the media server will use for the content transfer. If it is not provided, the media server MUST try to infer it from the content file extension based on a platform specific mapping table. A non-normative, example mapping table is shown in Table 3. To avoid ambiguity, we RECOMMEND that clients explicitly set this attribute. Note: If the MIME type of the content cannot be inferred from the file extension, this attribute is required.
o mimetype-必需（请参见注释），无默认值：指定媒体服务器将用于内容传输的MIME类型。如果未提供，则媒体服务器必须尝试根据特定于平台的映射表从内容文件扩展名推断出它。表3显示了一个非规范性的映射表示例。为了避免歧义，我们建议客户端显式设置此属性。注意：如果无法从文件扩展名推断内容的MIME类型，则需要此属性。
Table 3 shows common audio and video MIME types and possible file extension mappings.
表3显示了常见的音频和视频MIME类型以及可能的文件扩展名映射。
+-----------+--------------------+
| Extension | MIME Type |
+-----------+--------------------+
| alaw | audio/x-alaw-basic |
| ulaw | audio/basic |
| msgsm | audio/ms-gsm |
| wav | audio/x-wav |
| tif | image/tiff |
| tiff | image/tiff |
| mov | video/quicktime |
| qt | video/quicktime |
| 3gp | video/3gpp |
| 3gpp | video/3gpp |
+-----------+--------------------+
+-----------+--------------------+
| Extension | MIME Type |
+-----------+--------------------+
| alaw | audio/x-alaw-basic |
| ulaw | audio/basic |
| msgsm | audio/ms-gsm |
| wav | audio/x-wav |
| tif | image/tiff |
| tiff | image/tiff |
| mov | video/quicktime |
| qt | video/quicktime |
| 3gp | video/3gpp |
| 3gpp | video/3gpp |
+-----------+--------------------+
Table 3: Example File Extension to MIME Type Mappings
表3：MIME类型映射的文件扩展名示例
<Managecontent> is purely a transport operation; the underlying content is not changed by it. Therefore clients MUST ensure that the source and destination file name extensions and MIME types are the same. Failure to do so could result in content that is unreadable.
<Managecontent>纯粹是一种传输操作；它不会更改基础内容。因此，客户端必须确保源和目标文件扩展名以及MIME类型相同。否则可能会导致内容无法阅读。
The ability to move or delete any local file presents a potential risk to the security of the media server system. For this reason, we STRONGLY RECOMMEND that implementers limit local file system access when using <managecontent>. For example, we encourage limiting access as based on file ownership and/or specific directories.
移动或删除任何本地文件的能力会对媒体服务器系统的安全造成潜在风险。因此，我们强烈建议实施者在使用<managecontent>时限制本地文件系统访问。例如，我们鼓励根据文件所有权和/或特定目录限制访问。
The following is an example (Figure 27) showing a local file on the media server being transferred to an HTTP URL using the "put" method. The client sends the following request.
下面是一个示例（图27），显示了使用“put”方法将媒体服务器上的本地文件传输到HTTP URL。客户端发送以下请求。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<managecontent id="102"
src="file:////var/mediaserver/rec/6A5GH49B.ulaw"
dest="http://www.example.com/recordings/myrecording.ulaw"
mimetype="audio/basic" action="move" httpmethod="put"
fetchtimeout="5000"/>
</request>
</MediaServerControl>
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<managecontent id="102"
src="file:////var/mediaserver/rec/6A5GH49B.ulaw"
dest="http://www.example.com/recordings/myrecording.ulaw"
mimetype="audio/basic" action="move" httpmethod="put"
fetchtimeout="5000"/>
</request>
</MediaServerControl>
Figure 27: Managecontent Example
图27:Managecontent示例
Note that the client can change the temporary file name assigned by the media server as part of this operation as shown.
请注意，作为此操作的一部分，客户端可以更改媒体服务器分配的临时文件名，如图所示。
If the request is ambiguous, the media server MUST return a status code of "400" and text "Bad Request." If the media server is unable to execute a syntactically correct and unambiguous request, it MUST return a "500" status code with the text "Server Error." For example, the local file system access restrictions may prevent deletion of the specified file. In this case, the "reason" attribute in the response conveys additional details on the server error that occurred. If there is a network or remote server error, the media server provides detailed error information in the <error_info> element contained in the media server response. Additional information regarding <managecontent> responses is provided in Section 10.7.
如果请求不明确，媒体服务器必须返回状态代码“400”和文本“Bad request”。如果媒体服务器无法执行语法正确且无歧义的请求，则必须返回带有文本“server Error”的“500”状态代码。例如，本地文件系统访问限制可能会阻止删除指定的文件。在这种情况下，响应中的“reason”属性会传递有关发生的服务器错误的其他详细信息。如果存在网络或远程服务器错误，媒体服务器将在媒体服务器响应中包含的<error\u info>元素中提供详细的错误信息。第10.7节提供了有关<managecontent>响应的其他信息。
The <faxrecord> request directs the media server to process a fax in answer mode. The reason for a request separate from <playrecord> is that the media server needs to know to process the T.30 [18] or T.38 [19] fax protocols.
<faxrecord>请求指示媒体服务器以应答模式处理传真。请求与<playrecord>分开的原因是媒体服务器需要知道如何处理T.30[18]或T.38[19]传真协议。
The <faxrecord> request has multiple attributes and one child element, <prompt>. Its attributes are described in the list below.
<faxrecord>请求具有多个属性和一个子元素<prompt>。其属性如下表所示。
Attributes of <faxrecord>:
<faxrecord>的属性：
o lclid - optional, default value "" (the empty string): A string that identifies the called station.
o lclid-可选，默认值“”（空字符串）：标识被叫电台的字符串。
o prompturl - optional, no default value: The URL of the fax content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
o prompturl-可选，无默认值：要检索和播放的传真内容的URL。目标可以是本地或远程（NFS）“文件：//”方案URL或“http://”或“https://”方案URL。注意：不推荐使用此属性。
o promptencoding - optional, no default value: Specifies the content encoding for files that do not have a 'tif' or 'tiff' extension. The only allowable value is 'tiff'. This attribute only affects "file://" scheme URLs. NOTE: Use of this attribute is deprecated.
o Promptencode-可选，无默认值：为没有“tif”或“tiff”扩展名的文件指定内容编码。唯一允许的值是“tiff”。此属性仅影响“file://”方案URL。注意：不推荐使用此属性。
o recurl - optional, no default value: Specifies the target URL for the recorded content.
o recurl-可选，无默认值：指定录制内容的目标URL。
o rmtid - optional, no default value: Specifies the calling station identifier of the remote terminal. If present, the media server
o rmtid-可选，无默认值：指定远程终端的呼叫站标识符。如果存在，请选择媒体服务器
MUST reject transactions with the remote terminal if the remote terminal's identifier does not match the value of 'rmtid'.
如果远程终端的标识符与“rmtid”的值不匹配，则必须拒绝与远程终端的交易。
Clients SHOULD use the more flexible <prompt> mechanism for specifying fax content. Use of the 'prompturl' attribute is deprecated and may not be supported in future MSCML versions. The <prompt> element is described in Section 6.1.1. A <prompt> element sent in a <faxrecord> request MUST NOT contain <variable> elements.
客户端应该使用更灵活的<prompt>机制来指定传真内容。不推荐使用“prompturl”属性，将来的MSCML版本可能不支持使用该属性。第6.1.1节描述了<prompt>元素。在<faxrecord>请求中发送的<prompt>元素不得包含<variable>元素。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
媒体服务器必须在“recurl”属性中支持本地和远程（NFS）“file://”方案URL。MSCML通过<managecontent>（第8节）请求间接支持“http://”和“https://”方案URL。
The <faxrecord> request operates in one of three modes: receive, poll, and turnaround poll. The combination of <prompt> or 'prompturl' attribute and 'recurl' attribute define the mode. Table 4 describes these modes in detail. The 'prompt' column in the table has the value 'yes' if the request has either a <prompt> element or a 'prompturl' attribute.
<faxrecord>请求以三种模式之一运行：接收、轮询和周转轮询。<prompt>或'prompturl'属性和'recurl'属性的组合定义了模式。表4详细描述了这些模式。如果请求具有<prompt>元素或'prompturl'属性，则表中的'prompt'列的值为'yes'。
+--------+--------+---------+---------------------------------------+
| prompt | recurl | Mode | Operation |
+--------+--------+---------+---------------------------------------+
| no | no | Invalid | Request fails. |
| no | yes | Receive | Record the fax to the target URL |
| | | | specified in 'recurl'. |
| yes | no | Poll | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute. If there is a 'rmtid', it |
| | | | MUST match the remote terminal's |
| | | | identifier, or the request will fail. |
| yes | yes | TP | Turnaround Poll (TP) mode. If the |
| | | | remote terminal wishes to transmit, |
| | | | the media server records the fax to |
| | | | the target URL specified in 'recurl'. |
| | | | If the remote terminal wishes to |
| | | | receive, the media server sends the |
| | | | fax from the source URL contained in |
| | | | <prompt> or 'prompturl'. If there is |
| | | | a 'rmtid', it MUST match remote |
| | | | terminal's identifier, or the send |
| | | | request will fail. A receive |
| | | | operation will still succeed, |
| | | | however. |
+--------+--------+---------+---------------------------------------+
+--------+--------+---------+---------------------------------------+
| prompt | recurl | Mode | Operation |
+--------+--------+---------+---------------------------------------+
| no | no | Invalid | Request fails. |
| no | yes | Receive | Record the fax to the target URL |
| | | | specified in 'recurl'. |
| yes | no | Poll | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute. If there is a 'rmtid', it |
| | | | MUST match the remote terminal's |
| | | | identifier, or the request will fail. |
| yes | yes | TP | Turnaround Poll (TP) mode. If the |
| | | | remote terminal wishes to transmit, |
| | | | the media server records the fax to |
| | | | the target URL specified in 'recurl'. |
| | | | If the remote terminal wishes to |
| | | | receive, the media server sends the |
| | | | fax from the source URL contained in |
| | | | <prompt> or 'prompturl'. If there is |
| | | | a 'rmtid', it MUST match remote |
| | | | terminal's identifier, or the send |
| | | | request will fail. A receive |
| | | | operation will still succeed, |
| | | | however. |
+--------+--------+---------+---------------------------------------+
Table 4: Fax Receive Modes
表4：传真接收模式
In receive mode, the media server receives the fax and writes the fax data to the target URL specified by the 'recurl' attribute.
在接收模式下，媒体服务器接收传真并将传真数据写入“recurl”属性指定的目标URL。
In poll mode, the media server sends a fax, but as a polled (called) device.
在轮询模式下，媒体服务器发送传真，但作为轮询（调用）设备。
In turnaround poll mode, the media server will record a fax that the remote machine sends. If the remote machine requests a transmission, then the media server will send the fax.
在周转轮询模式下，媒体服务器将记录远程机器发送的传真。如果远程计算机请求传输，则媒体服务器将发送传真。
When transmitting a fax, the media server will advertise that it can receive faxes in the DIS message. Likewise, when receiving a fax, the media server will advertise that it can send faxes in the DIS message.
发送传真时，媒体服务器将在DIS消息中通告它可以接收传真。同样，当接收传真时，媒体服务器将在DIS消息中通告它可以发送传真。
The media server MUST flush any quarantined digits when it receives a <faxrecord> request.
媒体服务器收到<faxrecord>请求时，必须刷新任何隔离的数字。
The <faxplay> request directs the media server to process a fax in originate mode. The reason for a request separate from <play> is that the media server needs to know to process the T.30 [18] or T.38 [19] fax protocols.
<faxplay>请求指示媒体服务器以发起模式处理传真。请求与<play>分开的原因是媒体服务器需要知道如何处理T.30[18]或T.38[19]传真协议。
The <faxplay> request has multiple attributes and one child element, <prompt>. Its attributes are described in the list below.
<faxplay>请求具有多个属性和一个子元素<prompt>。其属性如下表所示。
Attributes of <faxplay>:
<faxplay>的属性：
o lclid - optional, default value "" (the empty string): A string that identifies the called station.
o lclid-可选，默认值“”（空字符串）：标识被叫电台的字符串。
o prompturl - optional, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
o prompturl-可选，无默认值：要检索和播放的内容的URL。目标可以是本地或远程（NFS）“文件：//”方案URL或“http://”或“https://”方案URL。注意：不推荐使用此属性。
o promptencoding - optional, no default value: Specifies the content encoding for files that do not have a 'tif' or 'tiff' extension. The only allowable value is 'tiff'. This attribute only affects "file://" scheme URLs. NOTE: Use of this attribute is deprecated.
o Promptencode-可选，无默认值：为没有“tif”或“tiff”扩展名的文件指定内容编码。唯一允许的值是“tiff”。此属性仅影响“file://”方案URL。注意：不推荐使用此属性。
o recurl - optional, no default value: Specifies the target URL for the recorded content.
o recurl-可选，无默认值：指定录制内容的目标URL。
o rmtid - optional, no default value: Specifies the calling station identifier of the remote terminal. If present, the media server
o rmtid-可选，无默认值：指定远程终端的呼叫站标识符。如果存在，请选择媒体服务器
MUST reject transactions with the remote terminal if the remote terminal's identifier does not match the value of 'rmtid'.
如果远程终端的标识符与“rmtid”的值不匹配，则必须拒绝与远程终端的交易。
Clients SHOULD use the more flexible <prompt> mechanism for specifying fax content. Use of the 'prompturl' attribute is deprecated and may not be supported in future MSCML versions. The <prompt> element is described in Section 6.1.1. A <prompt> element sent in a <faxrecord> request MUST NOT contain <variable> elements.
客户端应该使用更灵活的<prompt>机制来指定传真内容。不推荐使用“prompturl”属性，将来的MSCML版本可能不支持使用该属性。第6.1.1节描述了<prompt>元素。在<faxrecord>请求中发送的<prompt>元素不得包含<variable>元素。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
媒体服务器必须在“recurl”属性中支持本地和远程（NFS）“file://”方案URL。MSCML通过<managecontent>（第8节）请求间接支持“http://”和“https://”方案URL。
The <faxplay> request operates in one of three modes: send, remote poll, and turnaround poll. The combination of <prompt> or 'prompturl' attribute and 'recurl' attribute define the mode. Table 5 describes these modes in detail. The 'prompt' column in the table has the value 'yes' if the request has either a <prompt> element or a 'prompturl' attribute.
<faxplay>请求以三种模式之一运行：发送、远程轮询和周转轮询。<prompt>或'prompturl'属性和'recurl'属性的组合定义了模式。表5详细描述了这些模式。如果请求具有<prompt>元素或'prompturl'属性，则表中的'prompt'列的值为'yes'。
+--------+--------+---------+---------------------------------------+
| prompt | recurl | Mode | Operation |
+--------+--------+---------+---------------------------------------+
| no | no | Invalid | Request fails. |
| yes | no | Send | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute. If there is a 'rmtid', it |
| | | | MUST match the remote terminal's |
| | | | identifier, or the request will fail. |
| no | yes | Poll | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute, assuming the remote |
| | | | terminal specifies it can receive a |
| | | | fax in its DIS message. If the remote |
| | | | terminal does not support reverse |
| | | | polling, the request will fail. If |
| | | | 'rmtid' is specified, it MUST match |
| | | | remote terminal's identifier, or the |
| | | | request will fail. |
| yes | yes | TP | Turnaround Poll (TP) mode. If the |
| | | | remote terminal wishes to transmit, |
| | | | the media server records the fax to |
| | | | the target URL specified in 'recurl'. |
| | | | If the remote terminal wishes to |
| | | | receive, the media server sends the |
| | | | fax from the source URL contained in |
| | | | <prompt> or 'prompturl'. If there is |
| | | | a 'rmtid', it MUST match remote |
| | | | terminal's identifier, or the send |
| | | | request will fail. A receive |
| | | | operation will still succeed, |
| | | | however. |
+--------+--------+---------+---------------------------------------+
+--------+--------+---------+---------------------------------------+
| prompt | recurl | Mode | Operation |
+--------+--------+---------+---------------------------------------+
| no | no | Invalid | Request fails. |
| yes | no | Send | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute. If there is a 'rmtid', it |
| | | | MUST match the remote terminal's |
| | | | identifier, or the request will fail. |
| no | yes | Poll | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute, assuming the remote |
| | | | terminal specifies it can receive a |
| | | | fax in its DIS message. If the remote |
| | | | terminal does not support reverse |
| | | | polling, the request will fail. If |
| | | | 'rmtid' is specified, it MUST match |
| | | | remote terminal's identifier, or the |
| | | | request will fail. |
| yes | yes | TP | Turnaround Poll (TP) mode. If the |
| | | | remote terminal wishes to transmit, |
| | | | the media server records the fax to |
| | | | the target URL specified in 'recurl'. |
| | | | If the remote terminal wishes to |
| | | | receive, the media server sends the |
| | | | fax from the source URL contained in |
| | | | <prompt> or 'prompturl'. If there is |
| | | | a 'rmtid', it MUST match remote |
| | | | terminal's identifier, or the send |
| | | | request will fail. A receive |
| | | | operation will still succeed, |
| | | | however. |
+--------+--------+---------+---------------------------------------+
Table 5: Fax Send Modes
表5：传真发送模式
In send mode, the media server sends the fax.
在发送模式下，媒体服务器发送传真。
In remote poll mode, the client places a call on behalf of the media server. The media server requests a fax transmission from the remote fax terminal.
在远程轮询模式下，客户端代表媒体服务器进行调用。媒体服务器从远程传真终端请求传真传输。
In turnaround poll mode, the media server will record a fax that the remote machine sends. If the remote machine requests a transmission, then the media server will send the fax.
在周转轮询模式下，媒体服务器将记录远程机器发送的传真。如果远程计算机请求传输，则媒体服务器将发送传真。
When transmitting a fax, the media server will advertise that it can receive faxes in the DIS message. Likewise, when receiving a fax,
发送传真时，媒体服务器将在DIS消息中通告它可以接收传真。同样地，当收到传真时，
the media server will advertise that it can send faxes in the DIS message.
媒体服务器将公布它可以在DIS消息中发送传真。
The media server MUST flush any quarantined digits when it receives a <faxplay> request.
媒体服务器收到<faxplay>请求时，必须刷新任何隔离的数字。
The media server acknowledges receipt of a client MSCML request sent in a SIP INVITE by sending a response of either 200 OK or 415 Bad Media Type. The media server responds with 415 when the SIP request contains a content type other than "application/sdp" or "application/ mediaservercontrol+xml".
媒体服务器通过发送200 OK或415 Bad媒体类型的响应来确认接收到SIP INVITE中发送的客户端MSCML请求。当SIP请求包含除“应用/sdp”或“应用/mediaservercontrol+xml”之外的内容类型时，媒体服务器以415响应。
The media server acknowledges receipt of a client MSCML request sent in a SIP INFO with a 200 OK or 415 Bad Media Type. The media server responds with 415 if the INFO request contains a content type other than "application/mediaservercontrol+xml".
媒体服务器确认接收到以200 OK或415 Bad媒体类型的SIP INFO发送的客户端MSCML请求。如果INFO请求包含除“application/mediaservercontrol+xml”之外的内容类型，则媒体服务器以415响应。
The media server transports the MSCML <response> message in a SIP INFO request.
媒体服务器在SIP INFO请求中传输MSCML<response>消息。
If there is an error in the request or the media server cannot complete the request, the media server sends the <response> message very shortly after receiving the request. If the request is able to proceed, the <response> contains final status information as described below.
如果请求中有错误或媒体服务器无法完成请求，媒体服务器将在收到请求后很快发送<response>消息。如果请求能够继续，则<response>包含如下所述的最终状态信息。
All MSCML responses have the basic attributes defined in the list below.
所有MSCML响应都具有以下列表中定义的基本属性。
Basic MSCML Response Attributes:
基本MSCML响应属性：
o id - optional, no default value: Echoes the client-defined ID contained in the request.
o id-可选，无默认值：回显请求中包含的客户端定义的id。
o request - required, no default value: Specifies the MSCML request type that generated the response. Allowable values are "configure_conference", "configure_leg", "play", "playcollect", "playrecord", "stop", "faxplay", "faxrecord", and "managecontent".
o request-required，无默认值：指定生成响应的MSCML请求类型。允许的值为“配置会议”、“配置会议”、“播放”、“播放收藏”、“播放录制”、“停止”、“传真播放”、“传真录制”和“管理内容”。
o code - required, no default value: The final status code for the request. MSCML uses a subset of the status classes defined in RFC 3261 [4]. In MSCML, 2XX responses indicate success, 4XX responses indicate client error, and 5XX responses indicate an error on the media server. There are no 1XX, 3XX, or 6XX status codes in MSCML.
o 代码-必需，无默认值：请求的最终状态代码。MSCML使用RFC 3261[4]中定义的状态类的子集。在MSCML中，2XX响应表示成功，4XX响应表示客户端错误，5XX响应表示媒体服务器上的错误。MSCML中没有1XX、3XX或6XX状态代码。
o text - required, no default value: The human readable reason phrase associated with the status code.
o text-必需，无默认值：与状态代码关联的人类可读的原因短语。
Responses to <configure_conference> and <stop> requests contain only the attributes above. MSCML responses to other requests MAY contain additional request-specific attributes and elements. These are described in the following sections.
Responses to <configure_conference> and <stop> requests contain only the attributes above. MSCML responses to other requests MAY contain additional request-specific attributes and elements. These are described in the following sections.translate error, please retry
Responses to <configure_leg> requests have only the base response attributes defined in Section 10.2. However, when the request contains a <configure_team> element, the response includes a <team> element describing the teammate configuration for that leg. The attributes of the <team> element are shown in the list below.
对<configure_leg>请求的响应只有第10.2节中定义的基本响应属性。但是，当请求包含<configure\u team>元素时，响应包含一个<team>元素，描述该腿的队友配置。<team>元素的属性显示在下面的列表中。
Attributes of <team>:
<team>的属性：
o id - required, no default value: The client-defined unique identifier for the conference leg.
o id-必需，无默认值：客户端为会议段定义的唯一标识符。
o numteam - required, no default value: The number of team members for the leg.
o numteam-必需，无默认值：分支的团队成员数。
Additional information on each team member is conveyed by child <teammate> elements contained within <team>. Each teammate is represented by a single element in the list. The <teammate> element has a single attribute, as described below.
每个团队成员的附加信息由<team>中包含的child<队友>元素传达。每个队友都由列表中的单个元素表示。元素有一个单独的属性，如下所述。
Attributes of <teammate>:
<队友>的属性：
o id - required, no default value: The client-defined unique identifier for the teammate leg.
o id-必需，无默认值：客户端为队友腿定义的唯一标识符。
In addition to the base response attributes defined in Section 10.2, responses to <play> requests have the additional attributes described in the list below.
除了第10.2节中定义的基本响应属性外，<play>请求的响应还具有以下列表中描述的其他属性。
MSCML Response Attributes for <play>:
<play>的MSCML响应属性：
o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received, and "EOF", indicating that the end of the specified sequence of URLs was reached.
o reason-可选，无默认值：对于未立即完成的请求，“reason”属性传递有关命令完成原因的其他信息。可能的值为“stopped”，表示接收到显式或隐式的<stop>请求，“EOF”，表示到达指定URL序列的末尾。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout.
o 播放持续时间-必需，无默认值：返回相关内容播放持续时间的时间值（第4.2.1节）。
o playoffset - required, no default value: A time value (Section 4.2.1) that returns the time offset into the specified content sequence where play was terminated. If the initial "offset" value in the sequence was "0", then "playduration" and "playoffset" are equal. However, if the initial offset had some other value, "playoffset" serves as a bookmark for the client to resume play in a subsequent request.
o playoffset-必需，无默认值：时间值（第4.2.1节），用于将时间偏移返回到终止播放的指定内容序列中。如果序列中的初始“偏移”值为“0”，则“播放持续时间”和“播放偏移”相等。但是，如果某个playoffset客户端的初始值为“resume to other bookmark”，则“offset to resume”在后续的playoffset客户端中用作“resume”。
If the associated request set "stoponerror=yes" in <prompt> and an error occurred while retrieving the specified content the response will include an <error_info> element detailing the problem. This element contains the response information received from the remote content server. The <error_info> element has the attributes described in the list below.
如果相关请求在<prompt>中设置了“stoponerror=yes”，并且在检索指定内容时发生错误，则响应将包含一个<error\u info>元素，详细说明问题。此元素包含从远程content server接收的响应信息。<error\u info>元素具有下面列表中描述的属性。
Attributes of <error_info>:
<error\u info>的属性：
o code - required, no default value: The status code returned by the remote content server. For example, a web server might return 404 to indicate that the requested content was not found.
o 代码-必需，无默认值：远程content server返回的状态代码。例如，web服务器可能返回404以指示未找到请求的内容。
o text - required, no default value: The human-readable reason phrase returned by the remote content server. For example, the reason phrase "Not Found" would be returned if the requested content was not found.
o text-必需，无默认值：远程content server返回的可读原因短语。例如，如果未找到请求的内容，将返回原因短语“未找到”。
o context - required, no default value: Contains the content URL that was being fetched when the retrieval error occurred. This enables the client to know precisely which URL in a sequence caused the problem.
o 上下文-必需，无默认值：包含发生检索错误时正在获取的内容URL。这使客户机能够准确地知道序列中的哪个URL导致了问题。
An <error_info> element MAY be present in the response to any request that contains a child <prompt> element.
对包含子<prompt>元素的任何请求的响应中可能存在<error\u info>元素。
In addition to the base response attributes defined in Section 10.2, responses to <playcollect> requests have the additional attributes described in the list below.
除了第10.2节中定义的基本响应属性外，<playcollect>请求的响应还具有以下列表中描述的其他属性。
MSCML Response Attributes for <playcollect>:
<playcollect>的MSCML响应属性：
o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "match", meaning that a DTMF grammar was matched; "timeout", indicating that no DTMF input was received before one of the collection timers expired; and "returnkey" or "escapekey", meaning the DTMF digit mapped to that key was detected and the return key or escape key terminated the operation, respectively.
o reason-可选，无默认值：对于未立即完成的请求，“reason”属性传递有关命令完成原因的其他信息。可能的值为“stopped”，表示接收到显式或隐式的<stop>请求；“匹配”，表示DTMF语法匹配；“超时”，表示在其中一个采集计时器过期之前未收到DTMF输入；和“returnkey”或“escapekey”，表示检测到映射到该键的DTMF数字，返回键或escape键分别终止操作。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout. If the caller barged the prompt, this value will reflect the play duration up to that event.
o 播放持续时间-必需，无默认值：返回相关内容播放持续时间的时间值（第4.2.1节）。如果呼叫者闯过提示，该值将反映该事件之前的播放持续时间。
o playoffset - required, no default value: A time value (Section 4.2.1) that returns the time offset into the specified content sequence where play was terminated. If the initial "offset" value in the sequence was "0", then "playduration" and "playoffset" are equal. However, if the initial offset had some other value, "playoffset" serves as a bookmark for the client to resume play in a subsequent request. If the caller barged the prompt this value will reflect the time offset at which barge-in occurred.
o playoffset-必需，无默认值：时间值（第4.2.1节），用于将时间偏移返回到终止播放的指定内容序列中。如果序列中的初始“偏移”值为“0”，则“播放持续时间”和“播放偏移”相等。但是，如果初始偏移量有其他值，“playoffset”将作为书签供客户端在后续请求中继续播放。如果呼叫者闯入提示，该值将反映闯入发生的时间偏移。
o digits - required, no default value: Contains the collected DTMF input characters. If no DTMF input was collected, this attribute is set to the empty string ("").
o 数字-必需，无默认值：包含收集的DTMF输入字符。如果未收集DTMF输入，则此属性设置为空字符串（“”）。
o name - required (see note), no default value: The client-defined name of the DTMF grammar that was matched. Note: This attribute is required if the "name" attribute was set in the matching DTMF grammar.
o name-必需（请参见注释），无默认值：匹配的DTMF语法的客户端定义名称。注意：如果在匹配的DTMF语法中设置了“name”属性，则此属性是必需的。
Responses to <playcollect> requests MAY include an <error_info> element, as described in Section 10.4.1.
对<playcollect>请求的响应可能包括<error\u info>元素，如第10.4.1节所述。
In addition to the base response attributes defined in Section 10.2, responses to <playrecord> requests have the additional attributes described in the list below.
除了第10.2节中定义的基本响应属性外，<playrecord>请求的响应还具有以下列表中描述的其他属性。
o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "digit", meaning that a DTMF digit was detected and that the prompt phase was barged; "init_silence", meaning the recording terminated because of no input; "end_silence", meaning that the recording was terminated because the "endsilence" timer elapsed; "max_duration", indicating that the maximum time for the recording was reached; "escapekey", indicating that the DTMF input mapped to "escapekey" was detected, thus terminating the recording; and "error", indicating a general operation failure.
o reason-可选，无默认值：对于未立即完成的请求，“reason”属性传递有关命令完成原因的其他信息。可能的值为“stopped”，表示接收到显式或隐式的<stop>请求；“数字”，表示检测到双音多频数字，提示相位被中断；“init_silence”，表示由于没有输入而终止录制；“end_silence”，表示由于“endsilence”计时器已过而终止录制；“最大持续时间”，表示已达到录制的最大时间；“escapekey”，表示检测到映射到“escapekey”的DTMF输入，从而终止记录；和“错误”，表示一般操作失败。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout. If the caller barged the prompt, this value will reflect the play duration up to that event.
o 播放持续时间-必需，无默认值：返回相关内容播放持续时间的时间值（第4.2.1节）。如果呼叫者闯过提示，该值将反映该事件之前的播放持续时间。
o playoffset - required, no default value: A time value (Section 4.2.1) that returns the time offset into the specified content sequence where play was terminated. If the initial "offset" value in the sequence was "0", then "playduration" and "playoffset" are equal. However, if the initial offset had some other value, "playoffset" serves as a bookmark for the client to resume play in a subsequent request. If the caller barged the prompt this value will reflect the time offset at which barge-in occurred.
o playoffset-必需，无默认值：时间值（第4.2.1节），用于将时间偏移返回到终止播放的指定内容序列中。如果序列中的初始“偏移”值为“0”，则“播放持续时间”和“播放偏移”相等。但是，如果初始偏移量有其他值，“playoffset”将作为书签供客户端在后续请求中继续播放。如果呼叫者闯入提示，该值将反映闯入发生的时间偏移。
o digits - required, no default value: Contains the DTMF digit that terminated the recording. If no DTMF input was detected, this attribute is set to the empty string ("").
o 数字-必需，无默认值：包含终止录制的DTMF数字。如果未检测到DTMF输入，则此属性设置为空字符串（“”）。
o reclength - required, no default value: The length of the recorded content, in bytes.
o reclength-必需，无默认值：记录内容的长度，以字节为单位。
o recduration - required, no default value: A time value (Section 4.2.1) indicating the elapsed duration of the recording.
o recduration-必需，无默认值：一个时间值（第4.2.1节），指示记录的持续时间。
Responses to <playrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
对<playrecord>请求的响应可能包括<error\u info>元素，如第10.4.1节所述。
Responses to <managecontent> requests have only the base response attributes defined in Section 10.2. If a content transfer error occurs while executing the request the response will also contain an <error_info> element as described in Section 10.4.1.
对<managecontent>请求的响应只有第10.2节中定义的基本响应属性。如果在执行请求时发生内容传输错误，响应还将包含第10.4.1节所述的<error\u info>元素。
In addition to the base response attributes defined in Section 10.2, responses to <faxplay> and <faxrecord> requests have the additional attributes described in the list below.
除了第10.2节中定义的基本响应属性外，对<faxplay>和<faxrecord>请求的响应还具有以下列表中描述的其他属性。
o reason - required, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "complete", indicating successful completion, even if there were bad lines or minor negotiation problems (e.g., a DCN was received); "disconnect", meaning that the session was disconnected; and "notfax", indicating that no DIS or DCS was received on the connection.
o reason-required，无默认值：对于未立即完成的请求，“reason”属性传递有关命令完成原因的其他信息。可能的值为“stopped”，表示接收到显式或隐式的<stop>请求；“完成”，表示成功完成，即使存在错误线路或轻微协商问题（例如，收到DCN）；“断开连接”，表示会话已断开连接；和“notfax”，表示连接上未收到DIS或DCS。
o pages_received - required (see note), no default value: Indicates the number of fax pages received. Note: This attribute is required if any pages were received.
o pages_received-required（请参见注释），无默认值：表示收到的传真页数。注意：如果收到任何页面，则此属性是必需的。
o pages_sent - required (see note), no default value: Indicates the number of fax pages sent. Note: This attribute is required if any pages were sent.
o pages_sent-required（请参见注释），无默认值：表示发送的传真页数。注意：如果发送了任何页面，则此属性是必需的。
o faxcode - required, no default value: The value of the "faxcode" attribute is the binary-or of the bit patterns defined in Table 6.
o faxcode-必需，无默认值：“faxcode”属性的值为二进制或表6中定义的位模式。
+------+--------------------------------------+
| Mask | description |
+------+--------------------------------------+
| 0 | Operation Failed |
| 1 | Operation Succeeded |
| 2 | Partial Success |
| 4 | Image received and placed in recurl |
| 8 | Image sent from specified source URL |
| 16 | rmtid did not match |
| 32 | Error reading source URL |
| 64 | Error writing recurl |
| 128 | Negotiation failure on send phase |
| 256 | Negotiation failure on receive phase |
| 512 | Reserved |
| 1024 | Irrecoverable IP packet loss |
| 2048 | Line errors in received image |
+------+--------------------------------------+
+------+--------------------------------------+
| Mask | description |
+------+--------------------------------------+
| 0 | Operation Failed |
| 1 | Operation Succeeded |
| 2 | Partial Success |
| 4 | Image received and placed in recurl |
| 8 | Image sent from specified source URL |
| 16 | rmtid did not match |
| 32 | Error reading source URL |
| 64 | Error writing recurl |
| 128 | Negotiation failure on send phase |
| 256 | Negotiation failure on receive phase |
| 512 | Reserved |
| 1024 | Irrecoverable IP packet loss |
| 2048 | Line errors in received image |
+------+--------------------------------------+
Table 6: Faxcode Mask
表6：传真代码掩码
Responses to <faxplay> and <faxrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
对<faxplay>和<faxrecord>请求的响应可能包括<error\u info>元素，如第10.4.1节所述。
The following syntax specification uses XML Schema as described in XML [7].
以下语法规范使用XML[7]中描述的XML模式。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="MediaServerControl">
<xs:complexType>
<xs:choice>
<xs:element name="request">
<xs:complexType>
<xs:choice>
<xs:element name="configure_conference"
type="configure_conferenceRequestType"/>
<xs:element name="configure_leg"
type="configure_legRequestType"/>
<xs:element name="play" type="playRequestType"/>
<xs:element name="playcollect"
type="playcollectRequestType"/>
<xs:element name="playrecord"
type="playrecordRequestType"/>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="MediaServerControl">
<xs:complexType>
<xs:choice>
<xs:element name="request">
<xs:complexType>
<xs:choice>
<xs:element name="configure_conference"
type="configure_conferenceRequestType"/>
<xs:element name="configure_leg"
type="configure_legRequestType"/>
<xs:element name="play" type="playRequestType"/>
<xs:element name="playcollect"
type="playcollectRequestType"/>
<xs:element name="playrecord"
type="playrecordRequestType"/>
<xs:element name="managecontent"
type="managecontentRequestType"/>
<xs:element name="faxplay"
type="faxRequestType"/>
<xs:element name="faxrecord"
type="faxRequestType"/>
<xs:element name="stop" type="stopRequestType"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="response" type="responseType"/>
<xs:element name="notification">
<xs:complexType>
<xs:choice>
<xs:element name="conference"
type="conferenceNotificationType"/>
<xs:element name="keypress"
type="keypressNotificationType"/>
<xs:element name="signal"
type="signalNotificationType"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:choice>
<xs:attribute name="version" use="required"/>
</xs:complexType>
</xs:element>
<!-- Definitions for base and concrete MSCML requests -->
<!-- and embedded types. -->
<xs:complexType name="base_requestType" abstract="true">
<xs:attribute name="id" type="xs:string"/>
</xs:complexType>
<xs:complexType name="playRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="offset" type="xs:string"/>
<xs:attribute name="promptencoding" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="configure_conferenceRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:element name="managecontent"
type="managecontentRequestType"/>
<xs:element name="faxplay"
type="faxRequestType"/>
<xs:element name="faxrecord"
type="faxRequestType"/>
<xs:element name="stop" type="stopRequestType"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="response" type="responseType"/>
<xs:element name="notification">
<xs:complexType>
<xs:choice>
<xs:element name="conference"
type="conferenceNotificationType"/>
<xs:element name="keypress"
type="keypressNotificationType"/>
<xs:element name="signal"
type="signalNotificationType"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:choice>
<xs:attribute name="version" use="required"/>
</xs:complexType>
</xs:element>
<!-- Definitions for base and concrete MSCML requests -->
<!-- and embedded types. -->
<xs:complexType name="base_requestType" abstract="true">
<xs:attribute name="id" type="xs:string"/>
</xs:complexType>
<xs:complexType name="playRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="offset" type="xs:string"/>
<xs:attribute name="promptencoding" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="configure_conferenceRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="subscribe"
type="conference_eventsubscriptionType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="reservedtalkers"
type="xs:positiveInteger"/>
<xs:attribute name="reserveconfmedia" type="yesnoType"
default="yes"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="configure_legRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="inputgain" type="gainType"
minOccurs="0"/>
<xs:element name="outputgain" type="gainType"
minOccurs="0"/>
<xs:element name="configure_team"
type="configure_teamType" minOccurs="0"/>
<xs:element name="subscribe"
type="leg_eventsubscriptionType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="type">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="talker"/>
<xs:enumeration value="listener"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="mixmode">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="full"/>
<xs:enumeration value="mute"/>
<xs:enumeration value="preferred"/>
<xs:enumeration value="parked"/>
<xs:enumeration value="private"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="dtmfclamp" type="yesnoType"/>
<xs:attribute name="toneclamp" type="yesnoType"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:sequence>
<xs:element name="subscribe"
type="conference_eventsubscriptionType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="reservedtalkers"
type="xs:positiveInteger"/>
<xs:attribute name="reserveconfmedia" type="yesnoType"
default="yes"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="configure_legRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="inputgain" type="gainType"
minOccurs="0"/>
<xs:element name="outputgain" type="gainType"
minOccurs="0"/>
<xs:element name="configure_team"
type="configure_teamType" minOccurs="0"/>
<xs:element name="subscribe"
type="leg_eventsubscriptionType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="type">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="talker"/>
<xs:enumeration value="listener"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="mixmode">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="full"/>
<xs:enumeration value="mute"/>
<xs:enumeration value="preferred"/>
<xs:enumeration value="parked"/>
<xs:enumeration value="private"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="dtmfclamp" type="yesnoType"/>
<xs:attribute name="toneclamp" type="yesnoType"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="configure_teamType">
<xs:sequence>
<xs:element name="teammate" type="teammateType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string"/>
<xs:attribute name="action" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="add"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="query"/>
<xs:enumeration value="set"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="teammateType">
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="playcollectRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
<xs:element name="pattern" type="dtmfGrammarType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="offset" type="xs:string"/>
<xs:attribute name="barge" type="yesnoType" default="yes"/>
<xs:attribute name="promptencoding" type="xs:string"/>
<xs:attribute name="cleardigits" type="yesnoType"
default="no"/>
<xs:attribute name="maxdigits" type="xs:string"/>
<xs:attribute name="firstdigittimer" type="xs:string"
default="5000ms"/>
<xs:attribute name="interdigittimer" type="xs:string"
default="2000ms"/>
<xs:attribute name="extradigittimer" type="xs:string"
default="1000ms"/>
<xs:attribute name="interdigitcriticaltimer"
type="xs:string"/>
<xs:attribute name="skipinterval" type="xs:string"
default="6s"/>
<xs:attribute name="ffkey" type="DTMFkeyType"/>
<xs:attribute name="rwkey" type="DTMFkeyType"/>
<xs:complexType name="configure_teamType">
<xs:sequence>
<xs:element name="teammate" type="teammateType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string"/>
<xs:attribute name="action" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="add"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="query"/>
<xs:enumeration value="set"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="teammateType">
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="playcollectRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
<xs:element name="pattern" type="dtmfGrammarType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="offset" type="xs:string"/>
<xs:attribute name="barge" type="yesnoType" default="yes"/>
<xs:attribute name="promptencoding" type="xs:string"/>
<xs:attribute name="cleardigits" type="yesnoType"
default="no"/>
<xs:attribute name="maxdigits" type="xs:string"/>
<xs:attribute name="firstdigittimer" type="xs:string"
default="5000ms"/>
<xs:attribute name="interdigittimer" type="xs:string"
default="2000ms"/>
<xs:attribute name="extradigittimer" type="xs:string"
default="1000ms"/>
<xs:attribute name="interdigitcriticaltimer"
type="xs:string"/>
<xs:attribute name="skipinterval" type="xs:string"
default="6s"/>
<xs:attribute name="ffkey" type="DTMFkeyType"/>
<xs:attribute name="rwkey" type="DTMFkeyType"/>
<xs:attribute name="returnkey" type="DTMFkeyType"
default="#"/>
<xs:attribute name="escapekey" type="DTMFkeyType"
default="*"/>
<xs:attribute name="maskdigits" type="yesnoType"
default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="playrecordRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="promptencoding" type="xs:string"/>
<xs:attribute name="offset" type="xs:string" default="0"/>
<xs:attribute name="barge" type="yesnoType" default="yes"/>
<xs:attribute name="cleardigits" type="yesnoType"
default="no"/>
<xs:attribute name="escapekey" type="xs:string" default="*"/>
<xs:attribute name="recurl" type="xs:string" use="required"/>
<xs:attribute name="mode" default="overwrite">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="append"/>
<xs:enumeration value="overwrite"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="recencoding" type="xs:string"/>
<xs:attribute name="initsilence" type="xs:string"/>
<xs:attribute name="endsilence" type="xs:string"/>
<xs:attribute name="duration" type="xs:string"/>
<xs:attribute name="beep" type="yesnoType" default="yes"/>
<xs:attribute name="recstopmask" type="xs:string"
default="01234567890*#"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="managecontentRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:attribute name="fetchtimeout" type="xs:string"
default="10000"/>
<xs:attribute name="mimetype" type="xs:string"/>
<xs:attribute name="returnkey" type="DTMFkeyType"
default="#"/>
<xs:attribute name="escapekey" type="DTMFkeyType"
default="*"/>
<xs:attribute name="maskdigits" type="yesnoType"
default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="playrecordRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="promptencoding" type="xs:string"/>
<xs:attribute name="offset" type="xs:string" default="0"/>
<xs:attribute name="barge" type="yesnoType" default="yes"/>
<xs:attribute name="cleardigits" type="yesnoType"
default="no"/>
<xs:attribute name="escapekey" type="xs:string" default="*"/>
<xs:attribute name="recurl" type="xs:string" use="required"/>
<xs:attribute name="mode" default="overwrite">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="append"/>
<xs:enumeration value="overwrite"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="recencoding" type="xs:string"/>
<xs:attribute name="initsilence" type="xs:string"/>
<xs:attribute name="endsilence" type="xs:string"/>
<xs:attribute name="duration" type="xs:string"/>
<xs:attribute name="beep" type="yesnoType" default="yes"/>
<xs:attribute name="recstopmask" type="xs:string"
default="01234567890*#"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="managecontentRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:attribute name="fetchtimeout" type="xs:string"
default="10000"/>
<xs:attribute name="mimetype" type="xs:string"/>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="httpmethod">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="put"/>
<xs:enumeration value="post"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="action">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="move"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="dest" type="xs:string"/>
<xs:attribute name="src" type="xs:string" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="stopRequestType">
<xs:complexContent>
<xs:extension base="base_requestType"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="faxRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="lclid" type="xs:string"/>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="recurl" type="xs:string"/>
<xs:attribute name="rmtid" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="dtmfGrammarType">
<xs:choice>
<xs:element name="regex" type="dtmfPatternType"
maxOccurs="unbounded"/>
<xs:element name="mgcpdigitmap" type="dtmfPatternType"/>
<xs:element name="megacodigitmap" type="dtmfPatternType"/>
</xs:choice>
</xs:complexType>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="httpmethod">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="put"/>
<xs:enumeration value="post"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="action">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="move"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="dest" type="xs:string"/>
<xs:attribute name="src" type="xs:string" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="stopRequestType">
<xs:complexContent>
<xs:extension base="base_requestType"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="faxRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="lclid" type="xs:string"/>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="recurl" type="xs:string"/>
<xs:attribute name="rmtid" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="dtmfGrammarType">
<xs:choice>
<xs:element name="regex" type="dtmfPatternType"
maxOccurs="unbounded"/>
<xs:element name="mgcpdigitmap" type="dtmfPatternType"/>
<xs:element name="megacodigitmap" type="dtmfPatternType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="dtmfPatternType">
<xs:attribute name="value" type="xs:string" use="required"/>
<xs:attribute name="name" type="xs:string"/>
</xs:complexType>
<!-- Definitions for base and concrete MSCML responses -->
<!-- and embedded types. -->
<xs:complexType name="base_responseType" abstract="true">
<xs:attribute name="request" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="configure_conference"/>
<xs:enumeration value="configure_leg"/>
<xs:enumeration value="play"/>
<xs:enumeration value="playcollect"/>
<xs:enumeration value="playrecord"/>
<xs:enumeration value="managecontent"/>
<xs:enumeration value="faxplay"/>
<xs:enumeration value="faxrecord"/>
<xs:enumeration value="stop"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="id" type="xs:string"/>
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attribute name="text" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="responseType">
<xs:complexContent>
<xs:extension base="base_responseType">
<xs:sequence>
<xs:element name="error_info"
type="stoponerrorResponseType" minOccurs="0"/>
<xs:element name="team" type="configure_teamResponseType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="reason" type="xs:string"/>
<xs:attribute name="reclength" type="xs:string"/>
<xs:attribute name="recduration" type="xs:string"/>
<xs:attribute name="digits" type="xs:string"/>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="playduration" type="xs:string"/>
<xs:attribute name="playoffset" type="xs:string"/>
<xs:attribute name="faxcode" type="xs:string"/>
<xs:attribute name="pages_sent" type="xs:string"/>
<xs:attribute name="pages_recv" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="dtmfPatternType">
<xs:attribute name="value" type="xs:string" use="required"/>
<xs:attribute name="name" type="xs:string"/>
</xs:complexType>
<!-- Definitions for base and concrete MSCML responses -->
<!-- and embedded types. -->
<xs:complexType name="base_responseType" abstract="true">
<xs:attribute name="request" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="configure_conference"/>
<xs:enumeration value="configure_leg"/>
<xs:enumeration value="play"/>
<xs:enumeration value="playcollect"/>
<xs:enumeration value="playrecord"/>
<xs:enumeration value="managecontent"/>
<xs:enumeration value="faxplay"/>
<xs:enumeration value="faxrecord"/>
<xs:enumeration value="stop"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="id" type="xs:string"/>
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attribute name="text" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="responseType">
<xs:complexContent>
<xs:extension base="base_responseType">
<xs:sequence>
<xs:element name="error_info"
type="stoponerrorResponseType" minOccurs="0"/>
<xs:element name="team" type="configure_teamResponseType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="reason" type="xs:string"/>
<xs:attribute name="reclength" type="xs:string"/>
<xs:attribute name="recduration" type="xs:string"/>
<xs:attribute name="digits" type="xs:string"/>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="playduration" type="xs:string"/>
<xs:attribute name="playoffset" type="xs:string"/>
<xs:attribute name="faxcode" type="xs:string"/>
<xs:attribute name="pages_sent" type="xs:string"/>
<xs:attribute name="pages_recv" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="stoponerrorResponseType">
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attribute name="text" type="xs:string" use="required"/>
<xs:attribute name="context" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="configure_teamResponseType">
<xs:sequence>
<xs:element name="teammate" type="teammateType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="numteam" type="xs:integer" use="required"/>
</xs:complexType>
<!-- Definitions for MSCML event subscriptions and -->
<!-- embedded types -->
<xs:complexType name="conference_eventsubscriptionType">
<xs:sequence>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="activetalkers"
type="activetalkersSubscriptionType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="activetalkersSubscriptionType">
<xs:attribute name="report" type="yesnoType" use="required"/>
<xs:attribute name="interval" type="xs:string" default="60s"/>
</xs:complexType>
<xs:complexType name="leg_eventsubscriptionType">
<xs:sequence>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="keypress"
type="keypressSubscriptionType" minOccurs="0"
maxOccurs="1"/>
<xs:element name="signal" type="signalSubscriptionType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="keypressSubscriptionType">
<xs:attribute name="report" use="required">
<xs:complexType name="stoponerrorResponseType">
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attribute name="text" type="xs:string" use="required"/>
<xs:attribute name="context" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="configure_teamResponseType">
<xs:sequence>
<xs:element name="teammate" type="teammateType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="numteam" type="xs:integer" use="required"/>
</xs:complexType>
<!-- Definitions for MSCML event subscriptions and -->
<!-- embedded types -->
<xs:complexType name="conference_eventsubscriptionType">
<xs:sequence>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="activetalkers"
type="activetalkersSubscriptionType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="activetalkersSubscriptionType">
<xs:attribute name="report" type="yesnoType" use="required"/>
<xs:attribute name="interval" type="xs:string" default="60s"/>
</xs:complexType>
<xs:complexType name="leg_eventsubscriptionType">
<xs:sequence>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="keypress"
type="keypressSubscriptionType" minOccurs="0"
maxOccurs="1"/>
<xs:element name="signal" type="signalSubscriptionType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="keypressSubscriptionType">
<xs:attribute name="report" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
<xs:enumeration value="both"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="maskdigits" type="yesnoType" default="no"/>
</xs:complexType>
<xs:complexType name="signalSubscriptionType">
<xs:attribute name="type" type="xs:NMTOKEN" use="required"/>
<xs:attribute name="report" type="yesnoType" use="required"/>
</xs:complexType>
<!-- Definitions for MSCML event notifications and -->
<!-- embedded types. -->
<xs:complexType name="conferenceNotificationType">
<xs:sequence>
<xs:element name="activetalkers"
type="activetalkersNotificationType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="uniqueid" type="xs:string" use="required"/>
<xs:attribute name="numtalkers" type="xs:string"
use="required"/>
</xs:complexType>
<xs:complexType name="activetalkersNotificationType">
<xs:sequence minOccurs="0">
<xs:element name="talker" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="callid" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="keypressNotificationType">
<xs:sequence>
<xs:element name="status" type="statusType"/>
</xs:sequence>
<xs:attribute name="digit" type="DTMFkeyType" use="required"/>
<xs:attribute name="length" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
<xs:enumeration value="both"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="maskdigits" type="yesnoType" default="no"/>
</xs:complexType>
<xs:complexType name="signalSubscriptionType">
<xs:attribute name="type" type="xs:NMTOKEN" use="required"/>
<xs:attribute name="report" type="yesnoType" use="required"/>
</xs:complexType>
<!-- Definitions for MSCML event notifications and -->
<!-- embedded types. -->
<xs:complexType name="conferenceNotificationType">
<xs:sequence>
<xs:element name="activetalkers"
type="activetalkersNotificationType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="uniqueid" type="xs:string" use="required"/>
<xs:attribute name="numtalkers" type="xs:string"
use="required"/>
</xs:complexType>
<xs:complexType name="activetalkersNotificationType">
<xs:sequence minOccurs="0">
<xs:element name="talker" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="callid" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="keypressNotificationType">
<xs:sequence>
<xs:element name="status" type="statusType"/>
</xs:sequence>
<xs:attribute name="digit" type="DTMFkeyType" use="required"/>
<xs:attribute name="length" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="method" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
<xs:enumeration value="double"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="interdigittime" type="xs:string"
use="required"/>
</xs:complexType>
<xs:complexType name="statusType">
<xs:attribute name="command" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="idle"/>
<xs:enumeration value="play"/>
<xs:enumeration value="collect"/>
<xs:enumeration value="record"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="duration" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="signalNotificationType">
<xs:attribute name="type" use="required" fixed="busy"/>
</xs:complexType>
<!-- Definitions for miscellaneous embedded, helper data types -->
<xs:complexType name="promptType">
<xs:choice maxOccurs="unbounded">
<xs:element name="audio" type="promptcontentType"/>
<xs:element name="variable" type="spokenvariableType"/>
</xs:choice>
<xs:attribute name="locale" type="xs:string"/>
<xs:attribute name="baseurl" type="xs:string"/>
<xs:attribute name="stoponerror" type="yesnoType" default="no"/>
<xs:attribute name="gain" type="xs:string" default="0"/>
<xs:attribute name="gaindelta" type="xs:string" default="0"/>
<xs:attribute name="rate" type="xs:string" default="0"/>
<xs:attribute name="ratedelta" type="xs:string" default="0"/>
<xs:attribute name="repeat" type="xs:string" default="1"/>
<xs:attribute name="duration" type="xs:string"
default="infinite"/>
<xs:attribute name="offset" type="xs:string" default="0"/>
<xs:attribute name="delay" type="xs:string" default="0"/>
</xs:complexType>
</xs:attribute>
<xs:attribute name="method" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
<xs:enumeration value="double"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="interdigittime" type="xs:string"
use="required"/>
</xs:complexType>
<xs:complexType name="statusType">
<xs:attribute name="command" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="idle"/>
<xs:enumeration value="play"/>
<xs:enumeration value="collect"/>
<xs:enumeration value="record"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="duration" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="signalNotificationType">
<xs:attribute name="type" use="required" fixed="busy"/>
</xs:complexType>
<!-- Definitions for miscellaneous embedded, helper data types -->
<xs:complexType name="promptType">
<xs:choice maxOccurs="unbounded">
<xs:element name="audio" type="promptcontentType"/>
<xs:element name="variable" type="spokenvariableType"/>
</xs:choice>
<xs:attribute name="locale" type="xs:string"/>
<xs:attribute name="baseurl" type="xs:string"/>
<xs:attribute name="stoponerror" type="yesnoType" default="no"/>
<xs:attribute name="gain" type="xs:string" default="0"/>
<xs:attribute name="gaindelta" type="xs:string" default="0"/>
<xs:attribute name="rate" type="xs:string" default="0"/>
<xs:attribute name="ratedelta" type="xs:string" default="0"/>
<xs:attribute name="repeat" type="xs:string" default="1"/>
<xs:attribute name="duration" type="xs:string"
default="infinite"/>
<xs:attribute name="offset" type="xs:string" default="0"/>
<xs:attribute name="delay" type="xs:string" default="0"/>
</xs:complexType>
<xs:complexType name="promptcontentType">
<xs:attribute name="url" type="xs:string" use="required"/>
<xs:attribute name="encoding" type="xs:string"/>
<xs:attribute name="gain" type="xs:string" default="0"/>
<xs:attribute name="gaindelta" type="xs:string" default="0"/>
<xs:attribute name="rate" type="xs:string" default="0"/>
<xs:attribute name="ratedelta" type="xs:string" default="0"/>
</xs:complexType>
<xs:complexType name="spokenvariableType">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="dat"/>
<xs:enumeration value="dig"/>
<xs:enumeration value="dur"/>
<xs:enumeration value="mth"/>
<xs:enumeration value="mny"/>
<xs:enumeration value="num"/>
<xs:enumeration value="sil"/>
<xs:enumeration value="str"/>
<xs:enumeration value="tme"/>
<xs:enumeration value="wkd"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="subtype">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="mdy"/>
<xs:enumeration value="dmy"/>
<xs:enumeration value="ymd"/>
<xs:enumeration value="ndn"/>
<xs:enumeration value="t12"/>
<xs:enumeration value="t24"/>
<xs:enumeration value="USD"/>
<xs:enumeration value="gen"/>
<xs:enumeration value="ndn"/>
<xs:enumeration value="crd"/>
<xs:enumeration value="ord"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
<xs:simpleType name="yesnoType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
<xs:complexType name="promptcontentType">
<xs:attribute name="url" type="xs:string" use="required"/>
<xs:attribute name="encoding" type="xs:string"/>
<xs:attribute name="gain" type="xs:string" default="0"/>
<xs:attribute name="gaindelta" type="xs:string" default="0"/>
<xs:attribute name="rate" type="xs:string" default="0"/>
<xs:attribute name="ratedelta" type="xs:string" default="0"/>
</xs:complexType>
<xs:complexType name="spokenvariableType">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="dat"/>
<xs:enumeration value="dig"/>
<xs:enumeration value="dur"/>
<xs:enumeration value="mth"/>
<xs:enumeration value="mny"/>
<xs:enumeration value="num"/>
<xs:enumeration value="sil"/>
<xs:enumeration value="str"/>
<xs:enumeration value="tme"/>
<xs:enumeration value="wkd"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="subtype">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="mdy"/>
<xs:enumeration value="dmy"/>
<xs:enumeration value="ymd"/>
<xs:enumeration value="ndn"/>
<xs:enumeration value="t12"/>
<xs:enumeration value="t24"/>
<xs:enumeration value="USD"/>
<xs:enumeration value="gen"/>
<xs:enumeration value="ndn"/>
<xs:enumeration value="crd"/>
<xs:enumeration value="ord"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
<xs:simpleType name="yesnoType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
<xs:enumeration value="1"/>
<xs:enumeration value="0"/>
<xs:enumeration value="true"/>
<xs:enumeration value="false"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="DTMFkeyType">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]"/>
<xs:pattern value="[A-D]"/>
<xs:pattern value="[a-d]"/>
<xs:pattern value="#"/>
<xs:pattern value="\*"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="gainType">
<xs:choice>
<xs:element name="auto" type="autogainType"/>
<xs:element name="fixed" type="fixedgainType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="autogainType">
<xs:attribute name="startlevel" type="xs:string"/>
<xs:attribute name="targetlevel" type="xs:string"/>
<xs:attribute name="silencethreshold" type="xs:string"/>
</xs:complexType>
<xs:complexType name="fixedgainType">
<xs:attribute name="level" type="xs:string"/>
</xs:complexType>
</xs:schema>
<xs:enumeration value="1"/>
<xs:enumeration value="0"/>
<xs:enumeration value="true"/>
<xs:enumeration value="false"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="DTMFkeyType">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]"/>
<xs:pattern value="[A-D]"/>
<xs:pattern value="[a-d]"/>
<xs:pattern value="#"/>
<xs:pattern value="\*"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="gainType">
<xs:choice>
<xs:element name="auto" type="autogainType"/>
<xs:element name="fixed" type="fixedgainType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="autogainType">
<xs:attribute name="startlevel" type="xs:string"/>
<xs:attribute name="targetlevel" type="xs:string"/>
<xs:attribute name="silencethreshold" type="xs:string"/>
</xs:complexType>
<xs:complexType name="fixedgainType">
<xs:attribute name="level" type="xs:string"/>
</xs:complexType>
</xs:schema>
12.1. IANA Registration of MIME Media Type application/ mediaservercontrol+xml
12.1. MIME媒体类型应用程序/mediaservercontrol+xml的IANA注册
MIME media type name: application MIME subtype name: mediaservercontrol+xml Required parameters: none Optional parameters: charset
MIME媒体类型名称：应用程序MIME子类型名称：mediaservercontrol+xml必需参数：无可选参数：字符集
charset This parameter has identical semantics to the charset parameter of the "application/xml" media type, as specified in XML Media Types [8].
charset此参数与“application/xml”媒体类型的charset参数具有相同的语义，如xml媒体类型[8]中所述。
Encoding considerations: See RFC 3023 [8]. Interoperability considerations: See RFC 2023 [8] and RFC 4722. Published specification: RFC 4722
编码注意事项：参见RFC 3023[8]。互操作性注意事项：参见RFC 2023[8]和RFC 4722。已发布规范：RFC 4722
Applications that use this media type: Multimedia, enhanced conferencing and interactive applications. Personal and email address for further information: eburger@cantata.com [31] Intended usage: COMMON
使用此媒体类型的应用程序：多媒体、增强型会议和交互式应用程序。个人和电子邮件地址以获取更多信息：eburger@cantata.com[31]预期用途：普通
Because media flows through a media server in a conference, the media server itself MUST protect the integrity, confidentiality, and security of the sessions. It should not be possible for a conference participant, on her own behalf, to be able to "tap in" to another conference without proper authorization.
由于媒体在会议中流经媒体服务器，因此媒体服务器本身必须保护会话的完整性、机密性和安全性。会议参与者在未经适当授权的情况下，不应以自己的名义“介入”另一次会议。
Because conferencing is a high-value application, the media server SHOULD implement appropriate security measures. This includes, but is not limited to, access lists for application servers. That is, the media server only allows a select list of application or proxy servers to create conferences, to invite participants to sessions, etc. Note that the mechanisms for such security, like private networks, shared certificates, MAC white/black lists, are beyond the scope of this document.
由于会议是一种高价值的应用程序，因此媒体服务器应实施适当的安全措施。这包括但不限于应用服务器的访问列表。也就是说，媒体服务器只允许选择应用程序或代理服务器列表来创建会议、邀请参与者参加会议等。请注意，此类安全机制，如专用网络、共享证书、MAC白/黑列表，不在本文档的范围内。
Security concerns are one important reason MSCML limits requests with conference scope to a separate control leg per conference. MSCML uses the simple, proven, Internet-scale security model of SIP to determine if a client is who they say they are (authentication) and if they are allowed to create and manipulate a conference. However, the security model to enable a control leg to manipulate arbitrary conferences on the media server is extremely difficult. Not only would one need to authenticate and authorize the basic conference primitives, but privacy considerations require policies for one client to access another client's conferences, even if the two clients are on the same host. For example, if the media server allowed any control leg to control any conference, an authorized but unrelated client could maliciously attach itself to an existing session and record or tap the conversation without the participant's knowledge or consent.
安全问题是MSCML将具有会议范围的请求限制为每次会议的单独控制分支的一个重要原因。MSCML使用简单、经验证的SIP Internet级安全模型来确定客户机是否是他们所说的人（身份验证），以及是否允许他们创建和操纵会议。但是，使控制分支能够在媒体服务器上操纵任意会议的安全模型非常困难。不仅需要对基本会议原语进行身份验证和授权，而且出于隐私考虑，需要为一个客户端访问另一个客户端的会议制定策略，即使两个客户端位于同一主机上。例如，如果媒体服务器允许任何控制分支控制任何会议，则授权但无关的客户端可能会恶意连接到现有会话，并在参与者不知情或不同意的情况下录制或点击对话。
Participants give implicit authorization to their applications by virtue of the INVITE to the application. However, there is no trust, explicit or implicit, between the users of one service and a distinct client of another service.
通过对参与者的申请进行隐性授权，邀请其申请。但是，在一个服务的用户和另一个服务的不同客户机之间不存在显式或隐式信任。
All MSCML messages are sent within an INVITE-created SIP dialog. As a result, it would be difficult for an entity other than the original requestor to interfere with an established MSCML session, as this would require detailed information on the dialog state. This allows
所有MSCML消息都在INVITE创建的SIP对话框中发送。因此，原始请求者以外的实体很难干扰已建立的MSCML会话，因为这需要有关对话框状态的详细信息。这允许
multiple applications to utilize the resources of a single media server simultaneously without interfering with one another.
多个应用程序可以同时利用单个媒体服务器的资源，而不会相互干扰。
Because of the sensitive nature of collected data, such as credit card numbers or other identifying information, the media server MUST support sips: and TLS. Clients, who presumably know the value of the information they collect, as well as the privacy expectations of their users, are free to use clear text signaling or encrypted secure signaling, depending on the application's needs. Likewise, the media server SHOULD support Secure Realtime Transport Protocol (SRTP) [9]. Again, the clients are free to negotiate the appropriate level of media security.
由于收集的数据（如信用卡号或其他识别信息）的敏感性，媒体服务器必须支持sips:和TLS。客户可能知道他们收集的信息的价值，以及他们用户的隐私期望，可以根据应用程序的需要自由使用明文信号或加密安全信号。同样，媒体服务器应支持安全实时传输协议（SRTP）[9]。同样，客户可以自由协商适当级别的媒体安全。
The media management facilities of MSCML, such as the <managecontent> (Section 8) request, assume a trust relationship between the media server and file server. This scenario is similar to the one addressed by URLAUTH [20]. Namely, the media server is acting on behalf of a given user, yet the media server does not have credentials for that user. One might be tempted to use the user:pass facility of the HTTP URI to offer per-user security, but that also requires that the media server be secure, as the media server would need to know the user credentials in a form that is easily compromised (clear text passwords).
MSCML的媒体管理功能，如<managecontent>（第8节）请求，在媒体服务器和文件服务器之间具有信任关系。此场景类似于URLAUTH[20]所述的场景。也就是说，该用户尚未为服务器提供代理媒体的凭据。有人可能会尝试使用HTTP URI的user:pass功能来提供每个用户的安全性，但这也要求媒体服务器是安全的，因为媒体服务器需要以一种容易被泄露的形式（明文密码）知道用户凭据。
The IETF is investigating methods for providing per-user or per-instance authorization of third-party http writing, as is needed for other protocols as well, such as WEBDAV [21]. However, until that work is completed, media server implementations MUST be prepared to authenticate themselves to file and web servers using appropriate authentication means. At a minimum, the media server MUST support HTTPS basic authentication. Implementers should note that the media server will need to respond appropriately to whatever authentication mechanism the file server requires.
IETF正在研究为第三方http写入提供每用户或每实例授权的方法，其他协议（如WEBDAV）[21]也需要这种方法。但是，在这项工作完成之前，媒体服务器实现必须准备好使用适当的身份验证手段向文件和web服务器进行身份验证。媒体服务器至少必须支持HTTPS基本身份验证。实现者应该注意，媒体服务器将需要适当地响应文件服务器所需的任何身份验证机制。
As this is an XML markup, all the security considerations of RFC 3023 [8] apply.
由于这是一个XML标记，因此RFC 3023[8]的所有安全注意事项都适用。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[2] Burger，E.，Van Dyke，J.，和A.Spitzer，“具有SIP的基本网络媒体服务”，RFC 42402005年12月。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[5] "Network call signalling protocol for the delivery of time-critical services over cable television networks using cable modems", ITU-T J.162, March 2001.
[5] “使用电缆调制解调器在有线电视网络上提供时间关键型服务的网络呼叫信令协议”，ITU-T J.162，2001年3月。
[6] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[6] Groves，C.，Pantaleo，M.，Anderson，T.，和T.Taylor，“网关控制协议版本1”，RFC 35252003年6月。
[7] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.
[7] Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第1部分：结构”，W3C REC-xmlschema-1-20010502，2001年5月。
[8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[8] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[9] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[10] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[10] Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[11] Carter, J., Danielsen, P., Hunt, A., Ferrans, J., Lucas, B., Porter, B., Rehor, K., Tryphonas, S., McGlashan, S., and D. Burnett, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C REC REC-voicexml20-20040316, March 2004.
[11] Carter，J.，Danielsen，P.，Hunt，A.，Ferrans，J.，Lucas，B.，Porter，B.，Rehor，K.，Tryphonas，S.，McGrashan，S.，和D.Burnett，“语音可扩展标记语言（VoiceXML）2.0版”，W3C REC REC-voicexml20-20040316，2004年3月。
[12] International Packet Communications Consortium, "IPCC Reference Architecture V2", June 2002.
[12] 国际分组通信联合会，“IPCC参考体系结构V2”，2002年6月。
[13] European Telecommunications Standards Institute, "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 23.228 version 7.2.0 Release 7)", December 2005.
[13] 欧洲电信标准协会，“数字蜂窝通信系统（第2+阶段）；通用移动通信系统（UMTS）；IP多媒体子系统（IMS）；第2阶段（3GPP TS 23.228版本7.2.0版本7）”，2005年12月。
[14] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[14] Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[15] Jacobs, I., Lie, H., Bos, B., and C. Lilley, "Cascading Style Sheets, level 2 (CSS2) Specification", W3C REC REC-CSS2- 19980512, May 1998.
[15] Jacobs，I.，Lie，H.，Bos，B.，和C.Lilley，“级联样式表，2级（CSS2）规范”，W3C REC REC-CSS2-19980512，1998年5月。
[16] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[16] Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[17] Cable Television Laboratories, Inc., "Audio Server Protocol", January 2005.
[17] 有线电视实验室有限公司，“音频服务器协议”，2005年1月。
[18] "Procedures for document facsimile transmission in the general switched telephone network", Recommendation T.30, April 1999.
[18] “通用交换电话网中文件传真传输程序”，建议T.30，1999年4月。
[19] "Procedures for real-time Group 3 facsimile communication over IP networks", Recommendation T.38, March 2002.
[19] “通过IP网络进行实时第3组传真通信的程序”，建议T.38，2002年3月。
[20] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[20] Crispin，M.，“互联网消息访问协议（IMAP）-URLAUTH扩展”，RFC 4467，2006年5月。
[21] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[21] Goland，Y.，Whitehead，E.，Faizi，A.，Carter，S.，和D.Jensen，“分布式创作的HTTP扩展——WEBDAV”，RFC25181999年2月。
[22] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: Base Definitions, Chapter 9", IEEE Standard 1003.1, June 2001.
[22] 电气和电子工程师协会，“信息技术-便携式操作系统接口（POSIX）-第1部分：基本定义，第9章”，IEEE标准1003.12001年6月。
[23] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[23] Burger，E.和M.Dolly，“按键刺激（KPML）的会话启动协议（SIP）事件包”，RFC 4730，2006年11月。
[24] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[24] 《简单邮件传输协议》，RFC 28212001年4月。
[25] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol", Work in Progress, June 2006.
[25] Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议”，正在进行的工作，2006年6月。
URIs
URI
[26] <http://www.ietf.org/html.charters/sip-charter.html>
[26] <http://www.ietf.org/html.charters/sip-charter.html>
[27] <http://www.ietf.org/html.charters/sipping-charter.html>
[27] <http://www.ietf.org/html.charters/sipping-charter.html>
[28] <http://www.ietf.org/html.charters/mmusic.html>
[28] <http://www.ietf.org/html.charters/mmusic.html>
[29] <http://www.ietf.org/html.charters/xcon-charter.html>
[29] <http://www.ietf.org/html.charters/xcon-charter.html>
[30] <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>
[30] <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>
[31] <mailto:eburger@cantata.com>
[31] <mailto:eburger@cantata.com>
The regular expression syntax used in MSCML is a telephony-oriented subset of POSIX Extended Regular Expressions (ERE) [22] termed Digit REGular EXpression (DRegex). This syntax was first described in KPML [23].
MSCML中使用的正则表达式语法是POSIX扩展正则表达式（ERE）[22]的面向电话的子集，称为数字正则表达式（DRegex）。这种语法首先在KPML[23]中描述。
DRegex includes ordinary characters, special characters, bracket expressions, and interval expressions. These entities are defined in the list below.
DRegex包括普通字符、特殊字符、括号表达式和区间表达式。以下列表中定义了这些实体。
character matches digits 0-9, *, #, and A-D (case insensitive) * matches the * character # matches the # character [character selector] matches any character in selector [range1-range2] matches any character in range from range1 to range2, inclusive x matches any digit 0-9 {m} matches m repetitions of the previous pattern {m,} matches m or more repetitions of the previous pattern {,n} matches at most n (including zero) repetitions of the previous pattern {m,n} at least m and at most n repetitions of the previous pattern L the presence of 'L' in any regex expression causes the media server to enable "long" digit detection mode. See Section 7.1 for the definition of "long" digits.
字符匹配数字0-9、*、#和A-D（不区分大小写）*匹配*字符#匹配#字符[character selector]匹配选择器中的任何字符[range1-range2]匹配范围从range1到range2的任何字符，包括x匹配任何数字0-9{m}匹配上一模式的m个重复{m，}匹配上一个模式{，n}的m个或多个重复匹配上一个模式{m，n}的至多n个（包括零个）重复匹配上一个模式{m，n}的至少m个和上一个模式L的至多n个重复任何正则表达式中出现“L”都会导致媒体服务器启用“长”数字检测模式。有关“长”数字的定义，请参见第7.1节。
Table 7 illustrates DRegex usage through examples.
表7通过示例说明了DRegex的用法。
+--------------+--------------------------------------------+
| Example | Description |
+--------------+--------------------------------------------+
| 1 | Matches the digit 1 |
| [179] | Matches 1, 7, or 9 |
| [2-9] | Matches 2, 3, 4, 5, 6, 7, 8, 9 |
| [02-46-9A-D] | Matches 0, 2, 3, 4, 6, 7, 8, 9, A, B, C, D |
| x | Matches 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 |
| *6[179#] | Matches *61, *67, *69, or *6# |
| x{10} | Ten digits (0-9) |
| 011x{7,15} | 011 followed by seven to fifteen digits |
| L* | Long star |
+--------------+--------------------------------------------+
+--------------+--------------------------------------------+
| Example | Description |
+--------------+--------------------------------------------+
| 1 | Matches the digit 1 |
| [179] | Matches 1, 7, or 9 |
| [2-9] | Matches 2, 3, 4, 5, 6, 7, 8, 9 |
| [02-46-9A-D] | Matches 0, 2, 3, 4, 6, 7, 8, 9, A, B, C, D |
| x | Matches 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 |
| *6[179#] | Matches *61, *67, *69, or *6# |
| x{10} | Ten digits (0-9) |
| 011x{7,15} | 011 followed by seven to fifteen digits |
| L* | Long star |
+--------------+--------------------------------------------+
Table 7: DRegex Examples
表7:DRegex示例
Jeff Van Dyke and Andy Spitzer did the concept, development, documentation, and execution for MSCML at SnowShore Networks, Inc., which is now part of Cantata Technology, Inc. Andy Spitzer's original work at The Telephone Connection, Inc., influenced the IVR implementation. Mary Ann Leekley implemented the personalized mix feature and several other enhancements.
杰夫·范·戴克（Jeff Van Dyke）和安迪·斯皮策（Andy Spitzer）在斯诺肖尔网络公司（SnowShore Networks，Inc.）完成了MSCML的概念、开发、文档编制和执行工作，该公司现在是Cantata Technology，Inc.的一部分。安迪·斯皮策（Andy Spitzer）在电话连接公司的原始工作影响了IVR的实施。Mary Ann Leekley实现了个性化混音功能和其他一些增强功能。
Cliff Schornak of Commetrex and Jeff Van Dyke developed the facsimile service.
Commetrex的Cliff Schornak和Jeff Van Dyke开发了传真服务。
Jai Cauvet, Rolando Herrero, Srinivas Motamarri, and Ashish Patel contributed greatly by testing MSCML.
Jai Cauvet、Rolando Herrero、Srinivas Motamarri和Ashish Patel通过测试MSCML做出了巨大贡献。
The following individuals provided valuable assistance in the direction, development, or debugging of MSCML:
以下人员在指导、开发或调试MSCML方面提供了宝贵的帮助：
o Brian Badger and Phil Crable from Verizon Business o Stephane Bastien from BroadSoft o Peter Danielsen of Lucent Technologies o Kevin Flemming, formerly of SnowShore Networks, Inc. o Wesley Hicks and Ravindra Kabre, formerly from Sonus Networks o Jon Hinckley from SkyWave/Sestro o Terence Lobo, formerly of SnowShore Networks, Inc. o Kunal Nawale, formerly of SnowShore Networks, Inc. o Edwina Nowicki, formerly of SnowShore Networks, Inc. o Diana Rawlins and Sharadha Vijay, formerly of WorldCom o Gaurav Srivastva and Subhash Verma from BayPackets o Kevin Summers from Sonus Networks o Tim Wong from at&t
o Verizon Business的Brian Badger和Phil Crable，BroadSoft的Stephane Bastien，朗讯科技的Peter Danielsen，SnowShore Networks，Inc.的前任Kevin Fleming，Sonus Networks的前任Wesley Hicks和Ravindra Kabre，Sonus Networks的前任Jon Hinckley，SkyWave/Sestro Terence Lobo的前任SnowShore Networks，Inc.o Kunal Nawale的前任Jon Hinckley，曾任职于斯诺肖尔网络公司o Edwina Nowicki，曾任职于斯诺肖尔网络公司o Diana Rawlins和Sharadha Vijay，曾任职于世界通讯公司o Gaurav Srivastva和Subhash Verma，来自BayPackets，来自Sonus Networks的Kevin Summers，来自at&t的Tim Wong
The authors would like to thank Cullen Jennings and Dan Wing from Cisco Systems for their helpful review comments.
作者要感谢思科系统公司的Cullen Jennings和Dan Wing提供了有益的评论。
The authors would also like to thank Scotty Farber for applying her technical writing expertise to the documentation of MSCML.
作者还要感谢Scotty Farber将她的技术写作专业知识应用于MSCML文档。
Authors' Addresses
作者地址
Jeff Van Dyke Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
Jeff Van Dyke Cantata Technology，Inc.18 Keewaydin Dr.Salem，NH 03079美国
EMail: jvandyke@cantata.com
EMail: jvandyke@cantata.com
Eric Burger (editor) Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
Eric Burger（编辑）Cantata Technology，Inc.18 Keewaydin Dr.Salem，NH 03079美国
EMail: eburger@cantata.com
EMail: eburger@cantata.com
Andy Spitzer Pingtel Corporation 400 West Cummings Park Woburn, MA 01801 USA
Andy Spitzer Pingtel Corporation美国马萨诸塞州沃本市西卡明斯公园400号邮编：01801
EMail: woof@pingtel.com
EMail: woof@pingtel.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。