Internet Engineering Task Force (IETF) A. Amirante
Request for Comments: 7058 University of Napoli
Category: Informational T. Castaldi
ISSN: 2070-1721 L. Miniero
Meetecho
S P. Romano
University of Napoli
November 2013
Internet Engineering Task Force (IETF) A. Amirante
Request for Comments: 7058 University of Napoli
Category: Informational T. Castaldi
ISSN: 2070-1721 L. Miniero
Meetecho
S P. Romano
University of Napoli
November 2013
Media Control Channel Framework (CFW) Call Flow Examples
媒体控制通道框架（CFW）调用流示例
Abstract
摘要
This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference document for both implementors and protocol researchers.
本文档提供了典型媒体控制通道框架调用流的列表。它旨在成为应用程序服务器和基于MEDIACTRL的媒体服务器之间接口使用的简单指南，同时也是实现人员和协议研究人员的基本参考文档。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7058.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7058.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions .....................................................5
3. Terminology .....................................................5
4. A Practical Approach ............................................6
4.1. State Diagrams .............................................6
5. Control Channel Establishment ..................................10
5.1. COMEDIA Negotiation .......................................11
5.2. SYNC ......................................................14
5.3. K-ALIVE ...................................................15
5.4. Wrong Behavior ............................................17
6. Use-Case Scenarios and Examples ................................20
6.1. Echo Test .................................................27
6.1.1. Direct Echo Test ...................................28
6.1.2. Echo Test Based on Recording .......................30
6.2. Phone Call ................................................39
6.2.1. Direct Connection ..................................42
6.2.2. Conference-Based Approach ..........................44
6.2.3. Recording a Conversation ...........................51
6.3. Conferencing ..............................................57
6.3.1. Simple Bridging ....................................62
6.3.2. Rich Conference Scenario ...........................66
6.3.3. Coaching Scenario ..................................75
6.3.4. Sidebars ...........................................83
6.3.5. Floor Control ......................................93
6.4. Additional Scenarios ......................................99
6.4.1. Voice Mail ........................................100
6.4.2. Current Time ......................................107
6.4.3. DTMF-Driven Conference Manipulation ...............112
7. Media Resource Brokering ......................................126
7.1. Publishing Interface .....................................127
7.2. Consumer Interface .......................................136
7.2.1. Query Mode ........................................137
7.2.2. Inline-Aware Mode .................................140
7.2.3. Inline-Unaware Mode ...............................155
7.3. Handling Media Dialogs ...................................157
7.3.1. Query and Inline-Aware Mode .......................157
7.3.2. Inline-Unaware Mode ...............................160
7.3.3. CFW Protocol Behavior .............................167
8. Security Considerations .......................................170
9. Acknowledgments ...............................................180
10. References ...................................................180
10.1. Normative References ....................................180
10.2. Informative References ..................................181
1. Introduction ....................................................4
2. Conventions .....................................................5
3. Terminology .....................................................5
4. A Practical Approach ............................................6
4.1. State Diagrams .............................................6
5. Control Channel Establishment ..................................10
5.1. COMEDIA Negotiation .......................................11
5.2. SYNC ......................................................14
5.3. K-ALIVE ...................................................15
5.4. Wrong Behavior ............................................17
6. Use-Case Scenarios and Examples ................................20
6.1. Echo Test .................................................27
6.1.1. Direct Echo Test ...................................28
6.1.2. Echo Test Based on Recording .......................30
6.2. Phone Call ................................................39
6.2.1. Direct Connection ..................................42
6.2.2. Conference-Based Approach ..........................44
6.2.3. Recording a Conversation ...........................51
6.3. Conferencing ..............................................57
6.3.1. Simple Bridging ....................................62
6.3.2. Rich Conference Scenario ...........................66
6.3.3. Coaching Scenario ..................................75
6.3.4. Sidebars ...........................................83
6.3.5. Floor Control ......................................93
6.4. Additional Scenarios ......................................99
6.4.1. Voice Mail ........................................100
6.4.2. Current Time ......................................107
6.4.3. DTMF-Driven Conference Manipulation ...............112
7. Media Resource Brokering ......................................126
7.1. Publishing Interface .....................................127
7.2. Consumer Interface .......................................136
7.2.1. Query Mode ........................................137
7.2.2. Inline-Aware Mode .................................140
7.2.3. Inline-Unaware Mode ...............................155
7.3. Handling Media Dialogs ...................................157
7.3.1. Query and Inline-Aware Mode .......................157
7.3.2. Inline-Unaware Mode ...............................160
7.3.3. CFW Protocol Behavior .............................167
8. Security Considerations .......................................170
9. Acknowledgments ...............................................180
10. References ...................................................180
10.1. Normative References ....................................180
10.2. Informative References ..................................181
This document provides a list of typical MEDIACTRL Media Control Channel Framework [RFC6230] call flows. The motivation for this comes from our implementation experience with the framework and its protocol. This drove us to write a simple guide to the use of the several interfaces between Application Servers and MEDIACTRL-based Media Servers, and a base reference document for other implementors and protocol researchers.
本文档提供了典型的MEDIACTRL媒体控制通道框架[RFC6230]调用流的列表。这样做的动机来自于我们对框架及其协议的实现经验。这促使我们编写了一份简单的指南，介绍应用程序服务器和基于MEDIACTRL的媒体服务器之间几个接口的使用，并为其他实现人员和协议研究人员编写了一份基础参考文档。
Following this spirit, this document covers several aspects of the interaction between Application Servers and Media Servers. However, in the context of this document, the call flows almost always depict the interaction between a single Application Server (which, for the sake of conciseness, is called the AS from now on) and a single Media Server (MS). In Section 7, some flows involving more entities by means of a Media Resource Broker compliant with [RFC6917] are presented. To help readers understand all the flows (as related to both SIP dialogs and Media Control Channel Framework (CFW) transactions), the domains hosting the AS and the MS in all the scenarios are called 'as.example.com' and 'ms.example.net', respectively, per [RFC2606]. The flows will often focus more on the CFW [RFC6230] interaction, rather than on the other involved protocols, e.g., SIP [RFC3261], the Session Description Protocol (SDP) [RFC3264], or RTP [RFC3550].
本着这一精神，本文档涵盖了应用程序服务器和媒体服务器之间交互的几个方面。然而，在本文的上下文中，调用流几乎总是描述单个应用服务器（为了简洁起见，从现在起称为AS）和单个媒体服务器（MS）之间的交互。在第7节中，介绍了通过符合[RFC6917]的媒体资源代理涉及更多实体的一些流。为了帮助读者理解所有流（与SIP对话框和媒体控制通道框架（CFW）事务相关），根据[RFC2606]，在所有场景中承载as和MS的域分别称为“as.example.com”和“MS.example.net”。这些流通常更关注CFW[RFC6230]交互，而不是其他涉及的协议，例如SIP[RFC3261]、会话描述协议（SDP）[RFC3264]或RTP[RFC3550]。
In the next paragraphs, a brief overview of our implementation approach is described, with particular focus on protocol-related aspects. This involves state diagrams that depict both the client side (the AS) and the server side (the MS). Of course, this section is not at all to be considered a mandatory approach to the implementation of the framework. It is only meant to help readers understand how the framework works from a practical point of view.
在接下来的段落中，将简要概述我们的实现方法，特别关注与协议相关的方面。这涉及描述客户端（AS）和服务器端（MS）的状态图。当然，这一节根本不应被视为执行框架的强制性办法。它只是为了帮助读者从实用的角度理解框架是如何工作的。
Once done with these preliminary considerations, in the subsequent sections real-life scenarios are addressed. In this context, first of all, the establishment of the Control Channel is dealt with. After that, some use-case scenarios involving the most typical multimedia applications are depicted and described.
完成这些初步考虑后，将在后续章节中讨论真实场景。在此背景下，首先讨论控制通道的建立。然后，描述了一些涉及最典型多媒体应用的用例场景。
It is worth pointing out that this document is not meant in any way to be a self-contained guide to implementing a MEDIACTRL-compliant framework. The specifications are a mandatory read for all implementors, especially because this document follows their guidelines but does not delve into the details of every aspect of the protocol.
值得指出的是，本文档并不打算以任何方式作为实现MEDIACTRL兼容框架的自包含指南。规范是所有实现者必须阅读的，特别是因为本文档遵循他们的指导原则，但没有深入研究协议的每个方面的细节。
Note that due to RFC formatting conventions, SIP/SDP and CFW lines whose content exceeds 72 characters are split across lines. This line folding is marked by a backslash at the end of the first line. This backslash, the preceding whitespace, the following CRLF, and the whitespace beginning the next line would not appear in the actual protocol contents. Note also that the indentation of the XML content is only provided for readability. Actual messages will follow strict XML syntax, which allows, but does not require, indentation. Due to the same limit of 72 characters per line, this document also sometimes splits the content of XML elements across lines. Please be aware that when this happens, no whitespace is actually meant to be at either the beginning or the end of the element content.
请注意，由于RFC格式约定，内容超过72个字符的SIP/SDP和CFW行会跨行拆分。此折线在第一行末尾用反斜杠标记。此反斜杠、前面的空格、后面的CRLF以及下一行开头的空格不会出现在实际的协议内容中。还请注意，XML内容的缩进仅用于可读性。实际消息将遵循严格的XML语法，该语法允许但不要求缩进。由于每行72个字符的相同限制，本文档有时还会跨行拆分XML元素的内容。请注意，当发生这种情况时，实际上元素内容的开头或结尾都没有空格。
Note also that a few diagrams show arrows that go from a network entity to itself. It's worth pointing out that such arrows do not represent any transaction message but are rather meant as an indication to the reader that the involved network entity made a decision, within its application logic, according to the input it previously received.
还请注意，一些图表显示了从网络实体到自身的箭头。值得指出的是，这样的箭头并不代表任何事务消息，而是向读者表明，所涉及的网络实体根据其先前接收到的输入，在其应用程序逻辑中做出了决定。
This document uses the same terminology as [RFC6230], [RFC6231], [RFC6505], and [RFC6917]. The following terms are only a summarization of the terms most commonly used in this context and are mostly derived from the terminology used in the related documents:
本文件使用与[RFC6230]、[RFC6231]、[RFC6505]和[RFC6917]相同的术语。以下术语仅为本上下文中最常用术语的总结，主要来源于相关文件中使用的术语：
COMEDIA: connection-oriented media (i.e., TCP and Transport Layer Security (TLS)). Also used to signify the support in SDP for connection-oriented media and the RFCs that define that support ([RFC4145] and [RFC4572]).
喜剧：面向连接的媒体（即TCP和传输层安全（TLS））。还用于表示SDP中对面向连接的媒体和定义该支持的RFC的支持（[RFC4145]和[RFC4572]）。
Application Server: an entity that requests media processing and manipulation from a Media Server; typical examples are Back-to-Back User Agents (B2BUAs) and endpoints requesting manipulation of a third party's media stream.
应用服务器：从媒体服务器请求媒体处理和操作的实体；典型的例子是背靠背用户代理（B2BUA）和请求操纵第三方媒体流的端点。
Media Server: an entity that performs a service, such as media processing, on behalf of an Application Server; typical provided functions are mixing, announcement, tone detection and generation, and play and record services.
媒体服务器：代表应用服务器执行服务（如媒体处理）的实体；提供的典型功能包括混音、广播、音调检测和生成以及播放和录制服务。
Control Channel: a reliable connection between an Application Server and a Media Server that is used to exchange framework messages.
控制通道：用于交换框架消息的应用程序服务器和媒体服务器之间的可靠连接。
VCR controls: runtime control of aspects of an audio playback like speed and volume, via dual-tone multi-frequency (DTMF) signals sent by the user, in a manner that resembles the functions of a VCR (video cassette recorder) controller.
VCR控制：通过用户发送的双音多频（DTMF）信号，以类似于VCR（盒式磁带录像机）控制器功能的方式，运行时控制音频播放的各个方面，如速度和音量。
In this document, we embrace an engineering approach to the description of a number of interesting scenarios that can be realized through the careful orchestration of the Media Control Channel Framework entities, namely the Application Server and the Media Server. We will demonstrate, through detailed call flows, how a variegated bouquet of services (ranging from very simple scenarios to much more complicated examples) can be implemented with the functionality currently offered, within the main MEDIACTRL framework, by the Control Packages that have been made available to date. The document aims at being a useful guide for those interested in investigating the inter-operation among MEDIACTRL components, as well as being a base reference document for application developers willing to build advanced services on top of the base infrastructure made available by the framework.
在本文档中，我们采用工程方法来描述许多有趣的场景，这些场景可以通过精心编排媒体控制通道框架实体（即应用程序服务器和媒体服务器）来实现。我们将通过详细的调用流，演示如何使用主MEDIACTRL框架中当前提供的功能，通过迄今为止提供的控制包，实现各种各样的服务（从非常简单的场景到更复杂的示例）。本文档旨在为那些有兴趣研究MEDIACTRL组件之间的交互操作的人提供有用的指南，同时也为那些愿意在框架提供的基础基础设施之上构建高级服务的应用程序开发人员提供基础参考文档。
In this section, we present an "informal" view of the main MEDIACTRL protocol interactions, in the form of state diagrams. Each diagram is indeed a classical representation of a Mealy automaton, comprising a number of possible protocol states, indicated with rectangular boxes. Transitions between states are indicated through edges, with each edge labeled with a slash-separated pair representing a specific input together with the associated output (a dash in the output position means that, for that particular input, no output is generated from the automaton). Some of the inputs are associated with MEDIACTRL protocol messages arriving at a MEDIACTRL component while it is in a certain state. This is the case for 'CONTROL', 'REPORT' (in its various "flavors" -- pending, terminate, etc.), '200', '202', and 'Error' (error messages correspond to specific numeric codes). Further inputs represent triggers arriving at the MEDIACTRL automaton from the upper layer, namely the Application Programming Interface used by programmers while implementing MEDIACTRL-enabled services. Such inputs have been indicated with the term 'API' followed by the message that the API itself is triggering (as an example, 'API terminate' is a request to send a 'REPORT' message with a status of 'terminate' to the peering component).
在本节中，我们以状态图的形式展示了主要MEDIACTRL协议交互的“非正式”视图。每个图实际上都是Mealy自动机的经典表示，由许多可能的协议状态组成，用矩形框表示。状态之间的转换通过边表示，每条边用斜线分隔的对标记，表示特定输入和相关输出（输出位置的破折号表示，对于该特定输入，自动机不会生成任何输出）。某些输入与MEDIACTRL组件处于特定状态时到达该组件的MEDIACTRL协议消息相关联。“CONTROL”、“REPORT”（各种“风格”——挂起、终止等）、“200”、“202”和“Error”（错误消息对应于特定的数字代码）就是这种情况。进一步的输入表示从上层到达MEDIACTRL自动机的触发器，即程序员在实现支持MEDIACTRL的服务时使用的应用程序编程接口。此类输入用术语“API”表示，后跟API本身触发的消息（例如，“API终止”是向对等组件发送状态为“终止”的“报告”消息的请求）。
Four diagrams are provided. Two of them (Figures 1 and 2) describe normal operation of the framework. Figure 3 contains two diagrams describing asynchronous event notifications. Figure 1 embraces the MS perspective, whereas Figure 2 shows the AS side. The upper part of Figure 3 shows how events are generated, on the MS side, by issuing a CONTROL message addressed to the AS; events are acknowledged by the AS through standard 200 responses. Hence, the behavior of the AS, which mirrors that of the MS, is depicted in the lower part of the figure.
提供了四个图表。其中两个（图1和图2）描述了框架的正常操作。图3包含两个描述异步事件通知的图。图1包含MS透视图，而图2显示AS侧。图3的上半部分显示了如何在MS端通过向AS发出控制消息来生成事件；AS通过标准200响应确认事件。因此，AS的行为反映了MS的行为，如图下部所示。
Coming back to Figure 1, the diagram shows that the MS activates upon reception of CONTROL messages coming from the AS. The CONTROL messages instruct the MS regarding the execution of a specific command that belongs to one of the available Control Packages. The execution of the received command can either be quick or require some time. In the former case, right after completing its operation, the MS sends back to the AS a 200 message, which basically acknowledges correct termination of the invoked task. In the latter case, the MS first sends back an interlocutory 202 message containing a 'Timeout' value, which lets it enter a different state ('202' sent). While in the new state, the MS keeps on performing the invoked task. If the task does not complete in the provided timeout, the server will update the AS on the other side of the Control Channel by periodically issuing 'REPORT update' messages; each such message has to be acknowledged by the AS (through a '200' response). Eventually, when the MS is done with the required service, it sends to the AS a 'REPORT terminate' message. The transaction is concluded when the AS acknowledges receipt of the message. It is worth pointing out that the MS may send a 202 response after it determines that the request does not contain any errors that cannot be reported in a later REPORT terminate request instead. After the MS sends a 202 response, any error that it (or the API) finds in the request is reported in the final REPORT terminate request. Again, the behavior of the AS, as depicted in Figure 2, mirrors the above-described actions undertaken at the MS side. The figures also show the cases in which transactions cannot be successfully completed due to abnormal conditions; such conditions always trigger the creation and transmission of a specific 'Error' message that, as mentioned previously, is reported as a numeric error code.
回到图1，该图显示MS在接收到来自AS的控制消息时激活。控制消息指示MS执行属于一个可用控制包的特定命令。所接收命令的执行可能很快，也可能需要一些时间。在前一种情况下，在完成其操作之后，MS立即将AS 200消息发送回，该消息基本上确认所调用任务的正确终止。在后一种情况下，MS首先发回包含“超时”值的中间202消息，该消息使其进入不同的状态（“202”已发送）。在新状态下，MS继续执行被调用的任务。如果任务未在提供的超时时间内完成，服务器将通过定期发出“报告更新”消息来更新控制通道另一侧的AS；AS必须确认每个此类消息（通过“200”响应）。最终，当MS完成所需的服务时，它会将“报告终止”消息发送到。当AS确认收到消息时，交易结束。值得指出的是，MS可以在确定请求不包含任何不能在稍后的报告终止请求中报告的错误之后发送202响应。MS发送202响应后，它（或API）在请求中发现的任何错误都将在最终报告终止请求中报告。同样，如图2所示，AS的行为反映了在MS端执行的上述操作。这些数字还显示了由于异常情况而无法成功完成交易的情况；这种情况总是会触发特定“错误”消息的创建和传输，如前所述，该消息将作为数字错误代码报告。
+------------------+ CONTROL/- +------------------+ API 202/202
| Idle/'terminate' |------------>| CONTROL received |---------+
+------------------+ +------------------+ |
^ ^ ^ API 200/200 | | |
| | | | | |
| | +------------------+ | |
| 200/- | API Error/Error | |
| +----------------------------+ |
| |
+-------------+ |
| Waiting for | v
| last 200 |<------------------------+ +------------+
+-------------+ | | '202' sent |
^ | +------------+
| | | |
| +---------------+ |
| API terminate/ API terminate/ |
| REPORT terminate REPORT terminate |
| |
+--------------------+ |
| 'update' confirmed |------+ API update/ |
+--------------------+ | REPORT update |
^ | API update/ |
| | REPORT update |
| v |
| 200/- +---------------+ |
+--------------| 'update' sent |<----------------+
+---------------+
+------------------+ CONTROL/- +------------------+ API 202/202
| Idle/'terminate' |------------>| CONTROL received |---------+
+------------------+ +------------------+ |
^ ^ ^ API 200/200 | | |
| | | | | |
| | +------------------+ | |
| 200/- | API Error/Error | |
| +----------------------------+ |
| |
+-------------+ |
| Waiting for | v
| last 200 |<------------------------+ +------------+
+-------------+ | | '202' sent |
^ | +------------+
| | | |
| +---------------+ |
| API terminate/ API terminate/ |
| REPORT terminate REPORT terminate |
| |
+--------------------+ |
| 'update' confirmed |------+ API update/ |
+--------------------+ | REPORT update |
^ | API update/ |
| | REPORT update |
| v |
| 200/- +---------------+ |
+--------------| 'update' sent |<----------------+
+---------------+
Figure 1: Media Server CFW State Diagram
图1：媒体服务器CFW状态图
+--------------+ 202/- +--------------+
+-->| CONTROL sent |---------->| 202 received |
| +--------------+ +--------------+
| | | | |
| | | | |
API CONTROL/ | | 200/- | | |
send CONTROL | | | | |
| | | Error/ | |
+------------------+ | | Error | |
| Idle/'terminate' |<-+ | | |
+------------------+<---------+ | |
^ ^ | |
| | REPORT 'terminate'/ | |
| | send 200 | |
| +--------------------------------+ | REPORT 'update'/
| | send 200
| REPORT 'terminate'/ |
| send 200 |
| +-----------+ |
+---------------------| 'update ' |<--------------+
+-----------+
^ |
| | REPORT 'update'/
+------+ send 200
+--------------+ 202/- +--------------+
+-->| CONTROL sent |---------->| 202 received |
| +--------------+ +--------------+
| | | | |
| | | | |
API CONTROL/ | | 200/- | | |
send CONTROL | | | | |
| | | Error/ | |
+------------------+ | | Error | |
| Idle/'terminate' |<-+ | | |
+------------------+<---------+ | |
^ ^ | |
| | REPORT 'terminate'/ | |
| | send 200 | |
| +--------------------------------+ | REPORT 'update'/
| | send 200
| REPORT 'terminate'/ |
| send 200 |
| +-----------+ |
+---------------------| 'update ' |<--------------+
+-----------+
^ |
| | REPORT 'update'/
+------+ send 200
Figure 2: Application Server CFW State Diagram
图2：应用服务器CFW状态图
+--------------+
+-->| CONTROL sent |
| +--------------+
| |
| |
API CONTROL/ | | 200/-
send CONTROL | |
| |
+------------------+ |
| Idle/'terminate' |<----+
+------------------+
+--------------+
+-->| CONTROL sent |
| +--------------+
| |
| |
API CONTROL/ | | 200/-
send CONTROL | |
| |
+------------------+ |
| Idle/'terminate' |<----+
+------------------+
(Media Server perspective)
（媒体服务器透视图）
+------------------+ CONTROL/- +------------------+
| Idle/'terminate' |------------>| CONTROL received |
+------------------+ +------------------+
^ API 200/200 |
| |
+----------------------------+
+------------------+ CONTROL/- +------------------+
| Idle/'terminate' |------------>| CONTROL received |
+------------------+ +------------------+
^ API 200/200 |
| |
+----------------------------+
(Application Server perspective)
（应用服务器透视图）
Figure 3: Event Notifications
图3：事件通知
As specified in [RFC6230], the preliminary step to any interaction between an AS and an MS is the establishment of a Control Channel between the two. As explained in the next subsection, this is accomplished by means of a connection-oriented media (COMEDIA) [RFC4145] [RFC4572] negotiation. This negotiation allows a reliable connection to be created between the AS and the MS. It is here that the AS and the MS agree on the transport-level protocol to use (TCP / Stream Control Transmission Protocol (SCTP)) and whether any application-level security is needed or not (e.g., TLS). For the sake of simplicity, we assume that an unencrypted TCP connection is negotiated between the two involved entities. Once they have connected, a SYNC message sent by the AS to the MS consolidates the Control Channel. An example of how a keep-alive message is triggered is also presented in the following paragraphs. For the sake of completeness, this section also includes a couple of common mistakes that can occur when dealing with the Control Channel establishment.
如[RFC6230]所述，As和MS之间任何交互的初步步骤是在两者之间建立控制通道。如下一小节所述，这是通过面向连接的媒体（喜剧）[RFC4145][RFC4572]协商实现的。此协商允许在AS和MS之间创建可靠连接。在此，AS和MS就要使用的传输级协议（TCP/流控制传输协议（SCTP））以及是否需要任何应用级安全性（例如TLS）达成一致。为了简单起见，我们假设在两个相关实体之间协商未加密的TCP连接。连接后，AS向MS发送的同步消息将整合控制通道。以下段落还提供了如何触发保持活动消息的示例。为完整起见，本节还包括处理控制通道建立时可能出现的两个常见错误。
AS MS
| |
| INVITE (COMEDIA) |
|------------------------------>|
| 100 (Trying) |
|<------------------------------|
| 200 OK (COMEDIA) |
|<------------------------------|
| ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
| SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
AS MS
| |
| INVITE (COMEDIA) |
|------------------------------>|
| 100 (Trying) |
|<------------------------------|
| 200 OK (COMEDIA) |
|<------------------------------|
| ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
| SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
Figure 4: Control Channel Establishment
图4：控制通道建立
As a first step, the AS and the MS establish a Control SIP dialog. This is usually originated by the AS itself. The AS generates a SIP INVITE message containing in its SDP body information about the TCP connection it wants to establish with the MS. In the provided example (see Figure 5 and the attached call flow), the AS wants to actively open a new TCP connection, which on its side will be bound to port 5757. If the request is fine, the MS answers by communicating to the AS the transport address to connect to in order to establish the TCP connection. In the provided example, the MS will listen on port 7575. Once this negotiation is over, the AS can effectively connect to the MS.
作为第一步，As和MS建立控制SIP对话。这通常是由AS本身发起的。AS生成一条SIP INVITE消息，该消息在其SDP正文中包含有关其希望与MS建立的TCP连接的信息。在提供的示例中（参见图5和附带的调用流），AS希望主动打开一个新的TCP连接，该连接将绑定到端口5757。如果请求正常，则MS将通过与作为要连接的传输地址的进行通信来应答，以便建立TCP连接。在提供的示例中，MS将侦听端口7575。一旦协商结束，AS可以有效地连接到MS。
The negotiation includes additional attributes. The 'cfw-id' attribute is the most important, since it specifies the Dialog-ID, which in turn will be subsequently referred to by both the AS and the MS as specified in [RFC6230].
协商包括附加属性。“cfw id”属性是最重要的，因为它指定了对话框id，随后AS和MS将按照[RFC6230]中的规定引用对话框id。
AS MS
| |
| 1. INVITE (COMEDIA) |
|------------------------------>|
| 2. 100 (Trying) |
|<------------------------------|
| 3. 200 OK (COMEDIA) |
|<------------------------------|
| 4. ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
. .
. .
AS MS
| |
| 1. INVITE (COMEDIA) |
|------------------------------>|
| 2. 100 (Trying) |
|<------------------------------|
| 3. 200 OK (COMEDIA) |
|<------------------------------|
| 4. ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
. .
. .
Figure 5: COMEDIA Negotiation: Sequence Diagram
图5：喜剧谈判：序列图
1. AS -> MS (SIP INVITE) ------------------------ INVITE sip:MediaServer@ms.example.net:5060 SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060;\ branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060> From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 203
1. AS->MS（SIP邀请）---------------------------邀请SIP：MediaServer@ms.example.net：5060 SIP/2.0通过：SIP/2.0/UDP 203.0.113.1:5060；\分支=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-；rport=5060最大转发：70个联系人：<sip:ApplicationServer@203.0.113.1：5060>至：<sip:MediaServer@ms.example.net：5060>发件人：<sip:ApplicationServer@as.example.com:5060>;tag=4354ec63调用ID:MDK2YTK1MDU3YMVKZJGZYTQYMJLNJE5NTA4ZDQ1OGY。CSeq:1邀请允许：邀请、确认、取消、选项、再见、更新、注册内容类型：应用程序/sdp内容长度：203
v=0
o=lminiero 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 5757 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:5feb6486792a
v=0
o=lminiero 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 5757 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:5feb6486792a
2. AS <- MS (SIP 100 Trying) ---------------------------- SIP/2.0 100 Trying Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74 From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 INVITE Content-Length: 0
2. AS<-MS（SIP 100尝试）-------------SIP/2.0 100尝试通过：SIP/2.0/UDP 203.0.113.1:5060；\分支=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-；rport=5060至：<sip:MediaServer@ms.example.net:5060>;标签=499a5b74来自：<sip:ApplicationServer@as.example.com:5060>;tag=4354ec63调用ID:MDK2YTK1MDU3YMVKZJGZYTQYMJLNJE5NTA4ZDQ1OGY。CSeq:1邀请内容长度：0
3. AS <- MS (SIP 200 OK) ------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 Contact: <sip:MediaServer@ms.example.net:5060> To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74 From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 199
3. AS<-MS（SIP 200正常）---------------------------SIP/2.0 200正常通过：SIP/2.0/UDP 203.0.113.1:5060；\分支=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-；rport=5060联系人：<sip:MediaServer@ms.example.net：5060>至：<sip:MediaServer@ms.example.net:5060>;标签=499a5b74来自：<sip:ApplicationServer@as.example.com:5060>;tag=4354ec63调用ID:MDK2YTK1MDU3YMVKZJGZYTQYMJLNJE5NTA4ZDQ1OGY。CSeq:1邀请允许：邀请、确认、取消、选项、再见、更新、注册内容类型：应用程序/sdp内容长度：199
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:5feb6486792a
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:5feb6486792a
4. AS -> MS (SIP ACK) --------------------- ACK sip:MediaServer@ms.example.net:5060 SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74 From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 ACK Content-Length: 0
4. AS->MS（SIP确认）--------确认SIP:MediaServer@ms.example.net：5060 SIP/2.0通过：SIP/2.0/UDP 203.0.113.1:5060；\分支=z9hG4bK-d8754z-22940F5F458901B-1---d8754z-；rport最大转发：70个联系人：<sip:ApplicationServer@203.0.113.1：5060>至：<sip:MediaServer@ms.example.net:5060>;标签=499a5b74来自：<sip:ApplicationServer@as.example.com:5060>;tag=4354ec63调用ID:MDK2YTK1MDU3YMVKZJGZYTQYMJLNJE5NTA4ZDQ1OGY。CSeq:1确认内容长度：0
Once the AS and the MS have successfully established a TCP connection, an additional step is needed before the Control Channel can be used. In fact, as seen in the previous subsection, the first interaction between the AS and the MS happens by means of a SIP dialog, which in turn allows the creation of the TCP connection. This introduces the need for a proper correlation between the above-mentioned entities (SIP dialog and TCP connection), so that the MS can be sure that the connection came from the AS that requested it. This is accomplished by means of a dedicated framework message called a SYNC message. This SYNC message uses a unique identifier called the Dialog-ID to validate the Control Channel. This identifier, as introduced previously, is meant to be globally unique and as such is properly generated by the caller (the AS in the call flow) and added as an SDP media attribute (cfw-id) to the COMEDIA negotiation in order to make both entities aware of its value:
一旦AS和MS成功地建立了TCP连接，就需要在使用控制通道之前执行额外的步骤。事实上，如前一小节所示，as和MS之间的第一次交互是通过SIP对话框进行的，而SIP对话框又允许创建TCP连接。这就需要在上述实体（SIP对话和TCP连接）之间建立适当的关联，以便MS能够确保连接来自请求它的实体。这是通过称为同步消息的专用框架消息实现的。此同步消息使用称为对话框ID的唯一标识符来验证控制通道。如前所述，该标识符是全局唯一的，因此由呼叫方（呼叫流中的as）正确生成，并作为SDP媒体属性（cfw id）添加到喜剧协商中，以使两个实体都意识到其价值：
a=cfw-id:5feb6486792a ^^^^^^^^^^^^ It also offers an additional negotiation mechanism. In fact, the AS uses the SYNC to not only properly correlate, as explained before, but also negotiate with the MS the Control Packages in which it is interested, as well as agree on a 'Keep-Alive' timer needed by both the AS and the MS so that they will know if problems on the connection occur. In the provided example (see Figure 6 and the related call flow), the AS sends a SYNC with a Dialog-ID constructed as needed (using the 'cfw-id' attribute from the SIP dialog) and requests access to two Control Packages: specifically, the Interactive Voice Response (IVR) package and the Mixer package. The AS also instructs the MS that a 100-second timeout is to be used for keep-alive messages. The MS validates the request by matching the received Dialog-ID with the SIP dialog values, and, assuming that it supports the Control Packages the AS requested access to (and for the sake of this document we assume that it does), it answers with a
a=cfw id:5feb6486792a^^^^^^^^^^^^^它还提供了一种额外的协商机制。事实上，AS使用同步不仅可以正确关联（如前所述），还可以与MS协商其感兴趣的控制包，以及商定AS和MS都需要的“保持活动”计时器，以便他们知道连接是否出现问题。在提供的示例中（参见图6和相关的调用流），AS发送一个带有根据需要构造的对话框ID的同步（使用SIP对话框中的“cfw ID”属性），并请求访问两个控制包：具体地说，交互式语音响应（IVR）包和混音器包。AS还指示MS将100秒超时用于保持活动消息。MS通过将接收到的对话ID与SIP对话值相匹配来验证请求，并且假设它支持按请求访问的控制包（为了本文档的目的，我们假设它支持），它会以
200 message. Additionally, the MS provides the AS with a list of other unrequested packages it supports (in this case just a dummy package providing testing functionality).
200条留言。此外，MS向AS提供其支持的其他未请求的包的列表（在本例中，只是提供测试功能的虚拟包）。
AS MS
. .
. .
| |
| 1. SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
AS MS
. .
. .
| |
| 1. SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
Figure 6: SYNC: Sequence Diagram
图6：同步：序列图
1. AS -> MS (CFW SYNC) ---------------------- CFW 6e5e86f95609 SYNC Dialog-ID: 5feb6486792a Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0
1. AS->MS（CFW同步）-------------------------CFW 6e5e86f95609同步对话框ID:5feb6486792a保持活动状态：100个包：msc ivr/1.0，msc mixer/1.0
2. AS <- MS (CFW 200) --------------------- CFW 6e5e86f95609 200 Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0 Supported: msc-example-pkg/1.0
2. AS<-MS（CFW 200）--------CFW 6e5e86f95609 200保持活动状态：100个包：msc ivr/1.0，支持msc混音器/1.0：msc示例pkg/1.0
The framework-level transaction identifier is obviously the same in both the request and the response (6e5e86f95609), since the AS needs to be able to match the response to the original request. At this point, the Control Channel is finally established, and it can be used by the AS to request services from the MS.
框架级事务标识符在请求和响应（6e5e86f95609）中显然是相同的，因为AS需要能够将响应与原始请求相匹配。在这一点上，控制信道最终被建立，并且它可以被AS用于从MS请求服务。
[RFC6230] provides a mechanism for implementing a keep-alive functionality. Such a mechanism is especially useful whenever any NAT or firewall sits in the path between an AS and an MS. In fact, NATs and firewalls may have timeout values for the TCP connections
[RFC6230]提供了实现保持活动功能的机制。当任何NAT或防火墙位于AS和MS之间的路径时，这种机制特别有用。事实上，NAT和防火墙可能具有TCP连接的超时值
they handle, which means that if no traffic is detected on these connections within a specific time they could be shut down. This could be the case for a Control Channel established between an AS and an MS but not used for some time. For this reason, [RFC6230] specifies a dedicated framework message (K-ALIVE) that the AS and MS can use in order to generate traffic on the TCP connection and keep it alive.
它们可以处理，这意味着如果在特定时间内这些连接上没有检测到流量，它们可能会被关闭。对于在AS和MS之间建立但在一段时间内未使用的控制信道，可能是这种情况。因此，[RFC6230]指定了一个专用的框架消息（K-ALIVE），AS和MS可以使用该消息在TCP连接上生成流量并使其保持活动状态。
As discussed in Section 5.2, the timeout value for the keep-alive mechanism is set by the SYNC request. Specifically, in the example, the AS specified a value of 100 seconds. In fact, the timeout value is not actually negotiated between the AS and MS, as it is simply specified by whichever endpoint takes the active role. The 100-second value is compliant with how NATs and firewalls are usually implemented, since in most cases the timeout value they use before shutting TCP connections down is around 2 minutes. Such a value has a strong meaning within the context of this mechanism. In fact, it means that the active role (the AS, in this case) has to send a K-ALIVE message before those 100 seconds pass; otherwise, the passive role (the MS) will tear down the connection, treating it like a timeout. [RFC6230] suggests a more conservative approach towards handling this timeout value, suggesting that the K-ALIVE message be triggered before 80% of the negotiated time passes (80 seconds, in this case). This is exactly the case presented in Figure 7.
如第5.2节所述，保持活动机制的超时值由同步请求设置。具体而言，在该示例中，指定的值为100秒。事实上，超时值实际上并不是在AS和MS之间协商的，因为它只是由担任活动角色的端点指定的。100秒的值符合NAT和防火墙通常的实现方式，因为在大多数情况下，它们在关闭TCP连接之前使用的超时值大约为2分钟。这种价值观在这一机制的背景下具有很强的意义。事实上，这意味着活动角色（在本例中为AS）必须在这100秒过去之前发送一条K-ALIVE消息；否则，被动角色（MS）将断开连接，将其视为超时。[RFC6230]建议采用更保守的方法来处理此超时值，建议在协商时间的80%之前（本例中为80秒）触发K-ALIVE消息。这正是图7所示的情况。
AS MS
. .
. .
| |
~80 s have +--| |
passed since | | |
last K-ALIVE +->| |
| 1. K-ALIVE |
|+++++++++++++++++++++++++++++>>|
| |--+ Reset the local
| | | 'Keep-Alive'
| |<-+ timer
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
Reset the +--| |
local | | |
'Keep-Alive' +->| |
timer | |
. .
. .
AS MS
. .
. .
| |
~80 s have +--| |
passed since | | |
last K-ALIVE +->| |
| 1. K-ALIVE |
|+++++++++++++++++++++++++++++>>|
| |--+ Reset the local
| | | 'Keep-Alive'
| |<-+ timer
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
Reset the +--| |
local | | |
'Keep-Alive' +->| |
timer | |
. .
. .
Figure 7: K-ALIVE: Sequence Diagram
图7:K-ALIVE：序列图
After the Control Channel has been established (COMEDIA+SYNC), both the AS and the MS start local 'Keep-Alive' timers mapped to the negotiated keep-alive timeout value (100 seconds). When about 80 seconds have passed since the start of the timer (80% of 100 seconds), the AS sends a framework-level K-ALIVE message to the MS. The message as seen in the protocol message dump is very lightweight, since it only includes a single line with no additional header. When the MS receives the K-ALIVE message, it resets its local 'Keep-Alive' timer and sends a 200 message back as confirmation. As soon as the AS receives the 200 message, it resets its local 'Keep-Alive' timer as well, and the mechanism starts over again.
建立控制通道（COMEDIA+SYNC）后，AS和MS启动本地“保持活动”计时器，并映射到协商的保持活动超时值（100秒）。当计时器启动后大约过了80秒（100秒的80%）时，AS向MS发送框架级别的K-ALIVE消息。协议消息转储中看到的消息非常轻量级，因为它只包含一行，没有额外的头。当MS接收到K-ALIVE消息时，它重置其本地“保持活动”计时器，并发送一条200消息作为确认。一旦As收到200消息，它也会重置其本地“保持活动”计时器，机制将重新启动。
The actual transaction steps are presented below.
实际的交易步骤如下所示。
1. AS -> MS (K-ALIVE) --------------------- CFW 518ba6047880 K-ALIVE
1. AS->MS（K-ALIVE）--------CFW 518ba6047880 K-ALIVE
2. AS <- MS (CFW 200) --------------------- CFW 518ba6047880 200
2. AS<-MS（CFW 200）--------CFW 518ba6047880 200
If the timer expired in either the AS or the MS (i.e., the K-ALIVE or the 200 arrived after the 100 seconds), the connection and the associated SIP control dialog would be torn down by the entity detecting the timeout, thus ending the interaction between the AS and the MS.
如果AS或MS中的计时器过期（即，K-ALIVE或200在100秒后到达），则检测超时的实体将中断连接和相关SIP控制对话框，从而结束AS和MS之间的交互。
This section will briefly address some types of behavior that could represent the most common mistakes when dealing with the establishment of a Control Channel between an AS and an MS. These scenarios are obviously of interest, since they result in the AS and the MS being unable to interact with each other. Specifically, these simple scenarios will be described:
本节将简要介绍在AS和MS之间建立控制通道时可能代表最常见错误的一些行为类型。这些场景显然很有趣，因为它们导致AS和MS无法相互交互。具体来说，将描述这些简单场景：
1. an AS providing the MS with a wrong Dialog-ID in the initial SYNC.
1. 在初始同步过程中，向MS提供错误的对话框ID。
2. an AS sending a generic CONTROL message instead of SYNC as a first transaction.
2. 作为第一个事务发送通用控制消息而不是同步消息。
The first scenario is depicted in Figure 8.
第一个场景如图8所示。
AS MS
. .
. .
| |
| 1. SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC (wrong!)
| |<-+
| 2. 481 |
|<<+++++++++++++++++++++++++++++|
| |
|<-XX- CLOSE TCP CONNECTION -XX-|
| |
| SIP BYE |
|------------------------------>|
| |
. .
. .
AS MS
. .
. .
| |
| 1. SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC (wrong!)
| |<-+
| 2. 481 |
|<<+++++++++++++++++++++++++++++|
| |
|<-XX- CLOSE TCP CONNECTION -XX-|
| |
| SIP BYE |
|------------------------------>|
| |
. .
. .
Figure 8: SYNC with Wrong Dialog-ID: Sequence Diagram
图8：与错误对话框ID同步：序列图
This scenario is similar to the scenario presented in Section 5.2, but with a difference: instead of using the correct, expected Dialog-ID in the SYNC message (5feb6486792a, the one negotiated via COMEDIA), the AS uses a wrong value (4hrn7490012c). This causes the SYNC transaction to fail. First of all, the MS sends a framework-level 481 message. This response, when given in reply to a SYNC message, means that the SIP dialog associated with the provided Dialog-ID (the wrong identifier) does not exist. The Control Channel must be torn down as a consequence, and so the MS also closes the TCP connection it received the SYNC message from. The AS at this point is supposed to tear down its SIP control dialog as well, and so it sends a SIP BYE to the MS.
该场景与第5.2节中的场景类似，但有一点不同：AS使用了错误的值（4hrn7490012c），而不是在同步消息中使用正确的预期对话框ID（5feb6486792a，通过COMEDIA协商的对话框ID）。这会导致同步事务失败。首先，MS发送框架级别481消息。当响应同步消息时，此响应表示与提供的对话框ID（错误标识符）关联的SIP对话框不存在。因此，必须断开控制通道，因此MS也会关闭从中接收同步消息的TCP连接。此时AS应该也会中断其SIP控制对话框，因此它会向MS发送SIP BYE。
The actual transaction is presented below.
实际交易如下所示。
1. AS -> MS (CFW SYNC with wrong Dialog-ID) ------------------------------------------- CFW 2b4dd8724f27 SYNC Dialog-ID: 4hrn7490012c Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0
1. AS->MS（带有错误对话框ID的CFW同步）--------------------------------------CFW 2b4dd8724f27同步对话框ID:4hrn7490012c保持活动状态：100个包：msc ivr/1.0，msc mixer/1.0
2. AS <- MS (CFW 481) --------------------- CFW 2b4dd8724f27 481
2. AS<-MS（CFW 481）----------------CFW 2b4dd8724f27 481
The second scenario is depicted in Figure 9.
第二个场景如图9所示。
AS MS
. .
. .
| |
| 1. CONTROL |
|+++++++++++++++++++++++++++++>>|
| |--+ First transaction
| | | is not a SYNC
| |<-+
| 2. 403 |
|<<+++++++++++++++++++++++++++++|
| |
|<-XX- CLOSE TCP CONNECTION -XX-|
| |
| SIP BYE |
|------------------------------>|
| |
. .
. .
AS MS
. .
. .
| |
| 1. CONTROL |
|+++++++++++++++++++++++++++++>>|
| |--+ First transaction
| | | is not a SYNC
| |<-+
| 2. 403 |
|<<+++++++++++++++++++++++++++++|
| |
|<-XX- CLOSE TCP CONNECTION -XX-|
| |
| SIP BYE |
|------------------------------>|
| |
. .
. .
Figure 9: Incorrect First Transaction: Sequence Diagram
图9：不正确的第一个事务：序列图
This scenario demonstrates another common mistake that could occur when trying to set up a Control Channel. In fact, [RFC6230] mandates that the first transaction after the COMEDIA negotiation be a SYNC to conclude the setup. If the AS, instead of triggering a SYNC message as expected, sends a different message to the MS (in the example below, it tries to send an <audit> message addressed to the IVR Control Package), the MS treats it like an error. As a consequence, the MS replies with a framework-level 403 message (Forbidden) and, just as before, closes the TCP connection and waits for the related SIP control dialog to be torn down.
此场景演示了在尝试设置控制通道时可能发生的另一个常见错误。事实上，[RFC6230]要求喜剧谈判后的第一笔交易是完成设置的同步。如果AS没有按预期触发同步消息，而是向MS发送了另一条消息（在下面的示例中，它尝试发送一条发往IVR控制包的<audit>消息），MS将其视为错误。因此，MS以框架级别403消息（禁止）进行回复，并与之前一样关闭TCP连接，等待相关SIP控制对话框被拆除。
The actual transaction is presented below.
实际交易如下所示。
1. AS -> MS (CFW CONTROL instead of SYNC) ----------------------------------------- CFW 101fbbd62c35 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 78
1. AS->MS（CFW控制代替同步）----------------------------------------CFW 101fbbd62c35控制包：msc ivr/1.0内容类型：应用程序/msc ivr+xml内容长度：78
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
2. AS <- MS (CFW 403 Forbidden) ------------------------------- CFW 101fbbd62c35 403
2. AS<-MS（禁止使用CFW 403）------------------------------------CFW 101fbbd62c35 403
The following scenarios have been chosen for their common presence in many rich real-time multimedia applications. Each scenario is depicted as a set of call flows involving both the SIP/SDP signaling (UACs<->AS<->MS) and the Control Channel communication (AS<->MS).
选择以下场景是因为它们在许多富实时多媒体应用程序中普遍存在。每个场景被描述为一组呼叫流，涉及SIP/SDP信令（UACs<->as<->MS）和控制信道通信（as<->MS）。
All the examples assume that a Control Channel has already been correctly established and SYNCed between the reference AS and MS. Also, unless stated otherwise, the same User Agent Client (UAC) session is referenced in all the examples that will be presented in this document. The UAC session is assumed to have been created as described in Figure 10:
所有示例均假定已在参考AS和MS之间正确建立并同步了控制通道。此外，除非另有说明，否则在本文档中提供的所有示例中均引用了相同的用户代理客户端（UAC）会话。假设UAC会话已创建，如图10所示：
UAC AS MS
| | |
| INVITE (X) | |
|------------------>| |
| 180 (Ringing) | |
|<------------------| |
| |--+ |
| | | Handle app(X) |
| |<-+ |
| | INVITE (Y) as 3PCC |
| |-------------------------->|
| | 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate media
| | | | with UAC; map
| | |<-+ tags and labels
| | 200 OK |
| |<--------------------------|
| 200 OK | |
|<------------------| |
| ACK | |
|------------------>| |
| | ACK |
| |-------------------------->|
| | |
|<<###########################################>>|
| RTP Media Stream(s) flowing |
|<<###########################################>>|
| | |
. . .
. . .
UAC AS MS
| | |
| INVITE (X) | |
|------------------>| |
| 180 (Ringing) | |
|<------------------| |
| |--+ |
| | | Handle app(X) |
| |<-+ |
| | INVITE (Y) as 3PCC |
| |-------------------------->|
| | 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate media
| | | | with UAC; map
| | |<-+ tags and labels
| | 200 OK |
| |<--------------------------|
| 200 OK | |
|<------------------| |
| ACK | |
|------------------>| |
| | ACK |
| |-------------------------->|
| | |
|<<###########################################>>|
| RTP Media Stream(s) flowing |
|<<###########################################>>|
| | |
. . .
. . .
Figure 10: 3PCC Sequence Diagram
图10:3PCC序列图
Note well: This is only an example of a possible approach involving a Third-Party Call Control (3PCC) negotiation among the UAC, the AS, and the MS, and as such is not at all to be considered the mandatory way, nor best common practice, in the presented scenario. [RFC3725] provides several different solutions and many details about how 3PCC
请注意：这只是涉及UAC、AS和MS之间的第三方呼叫控制（3PCC）协商的可能方法的一个示例，因此在所述场景中根本不被视为强制方式，也不被视为最佳通用做法。[RFC3725]提供了几种不同的解决方案以及有关3PCC如何
can be realized, with pros and cons. It is also worth pointing out that the two INVITEs displayed in the figure are different SIP dialogs.
可以实现，有利有弊。还值得指出的是，图中显示的两个邀请是不同的SIP对话框。
The UAC first places a call to a SIP URI for which the AS is responsible. The specific URI is not relevant to the examples, since the application logic behind the mapping between a URI and the service it provides is a matter that is important only to the AS. So, a generic 'sip:mediactrlDemo@as.example.com' is used in all the examples, whereas the service this URI is associated with in the AS logic is mapped scenario by scenario to the case under examination. The UAC INVITE is treated as envisaged in [RFC5567]. The INVITE is forwarded by the AS to the MS via a third party (e.g., the 3PCC approach), without the SDP provided by the UAC being touched, in order to have the session fully negotiated by the MS according to its description. The MS matches the UAC's offer with its own capabilities and provides its answer in a 200 OK. This answer is then forwarded, again without the SDP contents being touched, by the AS to the target UAC. This way, while the SIP signaling from the UAC is terminated in the AS, all the media would start flowing directly between the UAC and the MS.
UAC首先调用AS负责的SIPURI。特定URI与示例无关，因为URI与其提供的服务之间的映射背后的应用程序逻辑只对AS重要。因此，一般的“sip：mediactrlDemo@as.example.com'在所有示例中都使用，而AS逻辑中与此URI相关联的服务在一个场景一个场景地映射到正在检查的案例。UAC邀请按[RFC5567]中的设想处理。AS通过第三方（例如，3PCC方法）将邀请转发给MS，而不涉及UAC提供的SDP，以便MS根据其描述完全协商会话。MS将UAC的报价与其自身的能力相匹配，并以200 OK的形式给出答案。然后，AS再次将该答案转发给目标UAC，而不涉及SDP内容。这样，当来自UAC的SIP信令在AS中终止时，所有媒体将开始直接在UAC和MS之间流动。
As a consequence of this negotiation, one or more media connections are created between the MS and the UAC. They are then addressed, when needed, by the AS and the MS by means of the concatenation of tags, as specified in [RFC6230]. How the identifiers are created and addressed is explained by using the sample signaling provided in the following lines.
作为该协商的结果，在MS和UAC之间创建了一个或多个媒体连接。然后，如[RFC6230]所述，AS和MS在需要时通过标签串联的方式对其进行寻址。标识符是如何创建和寻址的，将通过使用下面几行中提供的示例信令来解释。
1. UAC -> AS (SIP INVITE) ------------------------- INVITE sip:mediactrlDemo@as.example.com SIP/2.0 Via: SIP/2.0/UDP 203.0.113.2:5063;rport;branch=z9hG4bK1396873708 From: <sip:lminiero@users.example.com>;tag=1153573888 To: <sip:mediactrlDemo@as.example.com> Call-ID: 1355333098 CSeq: 20 INVITE Contact: <sip:lminiero@203.0.113.2:5063> Content-Type: application/sdp Max-Forwards: 70 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) Subject: Phone call Expires: 120 Content-Length: 330
1. UAC->AS（SIP邀请）-----邀请SIP：mediactrlDemo@as.example.comSIP/2.0 Via:SIP/2.0/UDP 203.0.113.2:5063；rport；branch=z9hG4bK1396873708发件人：<sip:lminiero@users.example.com>;标签=1153573888至：<sip:mediactrlDemo@as.example.com>呼叫ID:1355333098 CSeq:20邀请联系人：<sip:lminiero@203.0.113.2：5063>内容类型：应用程序/sdp最大转发：70用户代理：Linphone/2.1.1（eXosip2/3.0.3）主题：电话呼叫过期：120内容长度：330
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=1;QCIF=1
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=1;QCIF=1
2. UAC <- AS (SIP 180 Ringing) ------------------------------ SIP/2.0 180 Ringing Via: SIP/2.0/UDP 203.0.113.2:5063;rport=5063; \ branch=z9hG4bK1396873708 Contact: <sip:mediactrlDemo@as.example.com> To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 From: <sip:lminiero@users.example.com>;tag=1153573888 Call-ID: 1355333098 CSeq: 20 INVITE Content-Length: 0
2. UAC<-AS（SIP 180振铃）------------------------------------SIP/2.0 180振铃通过：SIP/2.0/UDP 203.0.113.2:5063；rport=5063；\分支机构=z9hG4bK1396873708联系人：<sip:mediactrlDemo@as.example.com>致：<sip:mediactrlDemo@as.example.com>;标签=bcd47c32发件人：<sip:lminiero@users.example.com>;tag=1153573888呼叫ID:1355333098 CSeq:20邀请内容长度：0
3. AS -> MS (SIP INVITE) ------------------------ INVITE sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060> From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 330
3. AS->MS（SIP邀请）---------------------------邀请SIP：MediaServer@ms.example.net:5060;传输=UDP SIP/2.0通过：SIP/2.0/UDP 203.0.113.1:5060；\分支=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-；rport最大转发：70个联系人：<sip:ApplicationServer@203.0.113.1：5060>至：<sip:MediaServer@ms.example.net：5060>发件人：<sip:ApplicationServer@as.example.com:5060>;tag=10514b7f呼叫ID:NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ。CSeq:1邀请允许：邀请、确认、取消、选项、再见、更新、注册内容类型：应用程序/sdp内容长度：330
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=1;QCIF=1
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=1;QCIF=1
4. AS <- MS (SIP 100 Trying) ---------------------------- SIP/2.0 100 Trying Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179 From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. CSeq: 1 INVITE Content-Length: 0
4. AS<-MS（SIP 100尝试）-------------SIP/2.0 100尝试通过：SIP/2.0/UDP 203.0.113.1:5060；\分支=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-；rport=5060至：<sip:MediaServer@ms.example.net:5060>;标签=6a900179发件人：<sip:ApplicationServer@as.example.com:5060>;tag=10514b7f呼叫ID:NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ。CSeq:1邀请内容长度：0
5. AS <- MS (SIP 200 OK) ------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-;rport=5060 Contact: <sip:MediaServer@ms.example.net:5060> To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179 From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 374
5. AS<-MS（SIP 200正常）---------------------------SIP/2.0 200正常通过：SIP/2.0/UDP 203.0.113.1:5060；\分支=z9hG4bK-d8754z-8723e421ebc45f6b-1---d8754z-；rport=5060联系人：<sip:MediaServer@ms.example.net：5060>至：<sip:MediaServer@ms.example.net:5060>;标签=6a900179发件人：<sip:ApplicationServer@as.example.com:5060>;tag=10514b7f呼叫ID:NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ。CSeq:1邀请允许：邀请、确认、取消、选项、再见、更新、注册内容类型：应用程序/sdp内容长度：374
v=0 o=lminiero 123456 654322 IN IP4 ms.example.net s=MediaCtrl c=IN IP4 ms.example.net t=0 0 m=audio 63442 RTP/AVP 0 3 8 101
v=0 o=lminiero 123456 654322在IP4 ms中。example.net s=MediaCtrl c=在IP4 ms中。example.net t=0 0 m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
6. UAC <- AS (SIP 200 OK) ------------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 203.0.113.2:5063;rport=5063; \ branch=z9hG4bK1396873708 Contact: <sip:mediactrlDemo@as.example.com> To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 From: <sip:lminiero@users.example.com>;tag=1153573888 Call-ID: 1355333098 CSeq: 20 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 374
6. UAC<-AS（SIP 200正常）—SIP/2.0 200正常通过：SIP/2.0/UDP 203.0.113.2:5063；rport=5063；\分支机构=z9hG4bK1396873708联系人：<sip:mediactrlDemo@as.example.com>致：<sip:mediactrlDemo@as.example.com>;标签=bcd47c32发件人：<sip:lminiero@users.example.com>;tag=1153573888呼叫ID:1355333098 CSeq:20邀请允许：邀请、确认、取消、选项、再见、更新、注册内容类型：应用程序/sdp内容长度：374
v=0
o=lminiero 123456 654322 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
v=0
o=lminiero 123456 654322 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
7. UAC -> AS (SIP ACK) ---------------------- ACK sip:mediactrlDemo@as.example.com SIP/2.0 Via: SIP/2.0/UDP 203.0.113.2:5063;rport;branch=z9hG4bK1113338059 From: <sip:lminiero@users.example.com>;tag=1153573888 To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 Call-ID: 1355333098 CSeq: 20 ACK Contact: <sip:lminiero@203.0.113.2:5063> Max-Forwards: 70 User-Agent: Linphone/2.1.1 (eXosip2/3.0.3) Content-Length: 0
7. UAC->AS（SIP确认）-------------------------确认SIP：mediactrlDemo@as.example.comSIP/2.0 Via:SIP/2.0/UDP 203.0.113.2:5063；rport；分支=Z9HG4BK11113338059来自：lminiero@users.example.com>;标签=1153573888至：<sip:mediactrlDemo@as.example.com>;tag=bcd47c32呼叫ID:1355333098 CSeq:20确认联系人：<sip:lminiero@203.0.113.2：5063>最大转发：70用户代理：Linphone/2.1.1（eXosip2/3.0.3）内容长度：0
8. AS -> MS (SIP ACK) --------------------- ACK sip:MediaServer@ms.example.net:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060; \ branch=z9hG4bK-d8754z-5246003419ccd662-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060;tag=6a900179 From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f Call-ID: NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ. CSeq: 1 ACK Content-Length: 0
8. AS->MS（SIP确认）--------确认SIP:MediaServer@ms.example.net:5060;传输=UDP SIP/2.0通过：SIP/2.0/UDP 203.0.113.1:5060；\分支机构=z9hG4bK-d8754z-5246003419ccd662-1---d8754z-；rport最大转发：70个联系人：<sip:ApplicationServer@203.0.113.1：5060>至：<sip:MediaServer@ms.example.net:5060;标签=6a900179发件人：<sip:ApplicationServer@as.example.com:5060>;tag=10514b7f呼叫ID:NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ。CSeq:1确认内容长度：0
As a result of the 3PCC negotiation just presented, the following relevant information is retrieved:
根据刚刚介绍的3PCC谈判结果，检索到以下相关信息：
1. The 'From' and 'To' tags (10514b7f and 6a900179, respectively) of the AS<->MS session:
1. AS<->MS会话的“From”和“To”标签（分别为10514b7f和6a900179）：
From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f
^^^^^^^^
To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179
^^^^^^^^
From: <sip:ApplicationServer@as.example.com:5060>;tag=10514b7f
^^^^^^^^
To: <sip:MediaServer@ms.example.net:5060>;tag=6a900179
^^^^^^^^
2. The labels [RFC4574] associated with the negotiated media connections, in this case an audio stream (7eda834) and a video stream (0132ca2):
2. 与协商的媒体连接相关联的标签[RFC4574]，在这种情况下是音频流（7eda834）和视频流（0132ca2）：
m=audio 63442 RTP/AVP 0 3 8 101
[..]
a=label:7eda834
^^^^^^^
m=audio 63442 RTP/AVP 0 3 8 101
[..]
a=label:7eda834
^^^^^^^
m=video 33468 RTP/AVP 98 [..] a=label:0132ca2 ^^^^^^^ These four identifiers allow the AS and MS to univocally and unambiguously address to each other the connections associated with the related UAC. Specifically:
m=video 33468 RTP/AVP 98[…]a=label:0132ca2^^^^^^^^^这四个标识符允许AS和MS以单音和明确的方式相互寻址与相关UAC相关联的连接。明确地：
1. 10514b7f:6a900179, the concatenation of the 'From' and 'To' tags through a colon (':') token, addresses all the media connections between the MS and the UAC.
1. 10514b7f:6a900179，通过冒号（“：”）标记将“From”和“To”标记串联在一起，用于处理MS和UAC之间的所有媒体连接。
2. 10514b7f:6a900179 <-> 7eda834, the association of the previous value with the label attribute, addresses only one of the media connections of the UAC session (in this case, the audio stream). Since, as will be made clearer in the example scenarios, the explicit identifiers in requests can only address 'from:tag' connections, an additional mechanism will be required to have a finer control of individual media streams (i.e., by means of the <stream> element in package-level requests).
2. 10514b7f:6a900179<->7eda834，前一个值与标签属性的关联，只处理UAC会话的一个媒体连接（在本例中为音频流）。由于在示例场景中将更清楚地说明，请求中的显式标识符只能寻址“from:tag”连接，因此需要额外的机制来更好地控制各个媒体流（即，通过包级请求中的<stream>元素）。
The mapping that the AS makes between the UACs<->AS and the AS<->MS SIP dialogs is out of scope for this document. We just assume that the AS knows how to address the right connection according to the related session it has with a UAC (e.g., to play an announcement to a specific UAC). This is obviously very important, since the AS is responsible for all the business logic of the multimedia application it provides.
AS在UACs<->AS和AS<->MS SIP对话框之间进行的映射超出了本文档的范围。我们只是假设AS知道如何根据与UAC的相关会话处理正确的连接（例如，向特定UAC播放公告）。这显然非常重要，因为AS负责其提供的多媒体应用程序的所有业务逻辑。
The echo test is the simplest example scenario that can be achieved by means of an MS. It basically consists of a UAC directly or indirectly "talking" to itself. A media perspective of such a scenario is depicted in Figure 11.
回声测试是可以通过MS实现的最简单的示例场景。它基本上由UAC直接或间接地与自身“对话”组成。图11描述了这种场景的媒体透视图。
+-------+ A (RTP) +--------+
| UAC |=========================>| Media |
| A |<=========================| Server |
+-------+ A (RTP) +--------+
+-------+ A (RTP) +--------+
| UAC |=========================>| Media |
| A |<=========================| Server |
+-------+ A (RTP) +--------+
Figure 11: Echo Test: Media Perspective
图11：回声测试：媒体透视图
From the framework point of view, when the UAC's leg is not attached to anything yet, what appears is shown in Figure 12: since there's no connection involving the UAC yet, the frames it might be sending are discarded, and nothing is sent to it (except for silence, if its transmission is requested).
从框架的角度来看，当UAC的分支还没有连接到任何东西时，出现的情况如图12所示：由于还没有涉及UAC的连接，它可能发送的帧将被丢弃，并且不会向它发送任何内容（如果请求其传输，则沉默除外）。
MS
+------+
UAC | |
o----->>-------x |
o.....<<.......x |
| |
+------+
MS
+------+
UAC | |
o----->>-------x |
o.....<<.......x |
| |
+------+
Figure 12: Echo Test: UAC Media Leg Not Attached
图12：回声测试：未连接UAC媒体支架
Starting from these considerations, two different approaches to the Echo Test scenario are explored in this document:
从这些考虑出发，本文档探讨了回声测试场景的两种不同方法：
1. a Direct Echo Test approach, where the UAC directly talks to itself.
1. 直接回声测试方法，UAC直接与自身对话。
2. a Recording-based Echo Test approach, where the UAC indirectly talks to itself.
2. 一种基于记录的回声测试方法，其中UAC间接与自身对话。
In the Direct Echo Test approach, the UAC is directly connected to itself. This means that, as depicted in Figure 13, each frame the MS receives from the UAC is sent back to it in real time.
在直接回波测试方法中，UAC直接连接到自身。这意味着，如图13所示，MS从UAC接收到的每个帧都会实时发送回UAC。
MS
+------+
UAC | |
o----->>-------@ |
o-----<<-------@ |
| |
+------+
MS
+------+
UAC | |
o----->>-------@ |
o-----<<-------@ |
| |
+------+
Figure 13: Echo Test: Direct Echo (Self-Connection)
图13：回波测试：直接回波（自连接）
In the framework, this can be achieved by means of the Mixer Control Package [RFC6505], which is in charge of joining connections and conferences.
在该框架中，这可以通过混音器控制包[RFC6505]实现，该包负责连接和会议。
A sequence diagram of a potential transaction is depicted in Figure 14:
潜在交易的序列图如图14所示：
UAC AS MS
| | |
| | 1. CONTROL (join UAC to itself) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ self-
| | | | join
| | 2. 200 OK |<-+ UAC
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| Everything is now echoed back to the UAC |
|<<######################################################>>|
| | |
. . .
. . .
UAC AS MS
| | |
| | 1. CONTROL (join UAC to itself) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ self-
| | | | join
| | 2. 200 OK |<-+ UAC
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| Everything is now echoed back to the UAC |
|<<######################################################>>|
| | |
. . .
. . .
Figure 14: Self-Connection: Framework Transaction
图14：自连接：框架事务
The transaction steps have been numbered and are explained below:
交易步骤已编号，说明如下：
o The AS requests the joining of the connection to itself by sending to the MS a CONTROL request (1) that is specifically meant for the conferencing Control Package (msc-mixer/1.0). A <join> request is used for this purpose, and since the connection must be attached to itself, both id1 and id2 attributes are set to the same value, i.e., the connectionid.
o AS通过向MS发送专门针对会议控制包（msc mixer/1.0）的控制请求（1），请求连接到自身。<join>请求用于此目的，并且由于连接必须附加到自身，因此id1和id2属性都设置为相同的值，即connectionid。
o The MS, having checked the validity of the request, enforces the joining of the connection to itself. This means that all the frames sent by the UAC are sent back to it. To report the result of the operation, the MS sends a 200 OK (2) in reply to the AS, thus ending the transaction. The transaction ended successfully, as indicated by the body of the message (the 200 status code in the <response> tag).
o MS在检查了请求的有效性后，强制将连接连接到自身。这意味着UAC发送的所有帧都会发送回UAC。为了报告操作结果，MS向AS发送200 OK（2）应答，从而结束事务。事务成功结束，如消息正文所示（标签<response>中的200状态代码）。
The complete transaction -- that is, the full bodies of the exchanged messages -- is provided in the following lines:
下面几行提供了完整的事务（即交换消息的完整主体）：
1. AS -> MS (CFW CONTROL) ------------------------- CFW 4fed9bf147e2 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 130
1. AS->MS（CFW控制）-------------CFW 4fed9bf147e2控制包：msc mixer/1.0内容类型：application/msc mixer+xml内容长度：130
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="10514b7f:6a900179"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="10514b7f:6a900179"/>
</mscmixer>
2. AS <- MS (CFW 200 OK) ------------------------ CFW 4fed9bf147e2 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125
2. AS<-MS（CFW 200正常）---------------------------CFW 4fed9bf147e2 200超时：10内容类型：应用程序/msc混合器+xml内容长度：125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
In the Recording-based Echo Test approach, the UAC is NOT directly connected to itself, but rather indirectly. This means that, as depicted in Figure 15, each frame the MS receives from the UAC is first recorded; then, when the recording process is ended, the whole recorded frames are played back to the UAC as an announcement.
在基于记录的回声测试方法中，UAC不直接与其自身连接，而是间接连接。这意味着，如图15所示，首先记录MS从UAC接收的每个帧；然后，当录制过程结束时，整个录制的帧作为通告回放给UAC。
MS
+------+
UAC | |
o----->>-------+~~~~~> (recording.wav) ~~+
o-----<<-------+ | |
| ^ | v
+--|---+ |
+~~~~~~~~~~~<<~~~~~~~~~~~~+
MS
+------+
UAC | |
o----->>-------+~~~~~> (recording.wav) ~~+
o-----<<-------+ | |
| ^ | v
+--|---+ |
+~~~~~~~~~~~<<~~~~~~~~~~~~+
Figure 15: Echo Test: Recording Involved
图15：回声测试：涉及记录
In the framework, this can be achieved by means of the IVR Control Package [RFC6231], which is in charge of both the recording and the playout phases. However, the whole scenario cannot be accomplished in a single transaction; at least two steps, in fact, need to be performed:
在该框架中，这可以通过IVR控制包[RFC6231]实现，该控制包负责录制和播放阶段。但是，整个场景不可能在单个事务中完成；事实上，至少需要执行两个步骤：
1. First, a recording (preceded by an announcement, if requested) must take place.
1. 首先，必须进行录音（如有要求，可在录音前进行公告）。
2. Then, a playout of the previously recorded media must occur.
2. 然后，必须播放以前录制的媒体。
This means that two separate transactions need to be invoked. A sequence diagram of a potential multiple transaction is depicted in Figure 16:
这意味着需要调用两个单独的事务。图16中描述了潜在多重事务的序列图：
UAC AS MS
| | |
| | A1. CONTROL (record for 10s) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | |--+ start
| | | | the
| | A3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "This is an echo test: say something" |
|<<########################################################|
| | |
|########################################################>>|
| 10 s of audio from the UAC are recorded |--+ save
|########################################################>>| | in a
| | |<-+ file
| | B1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Use recorded +--| B2. 200 OK |
| file to play | |++++++++++++++++++++++++++++++++>>|
| announcement +->| |
| | C1. CONTROL (play recorded) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | |--+ start
| | | | the
| | C3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Can you hear me? It's me, UAC, talking" |
|<<########################################################|
| | |
| | D1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
UAC AS MS
| | |
| | A1. CONTROL (record for 10s) |
| |++++++++++++++++++++++++++++++++>>|
| | A2. 202 |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | |--+ start
| | | | the
| | A3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | A4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "This is an echo test: say something" |
|<<########################################################|
| | |
|########################################################>>|
| 10 s of audio from the UAC are recorded |--+ save
|########################################################>>| | in a
| | |<-+ file
| | B1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Use recorded +--| B2. 200 OK |
| file to play | |++++++++++++++++++++++++++++++++>>|
| announcement +->| |
| | C1. CONTROL (play recorded) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 202 |
| |<<++++++++++++++++++++++++++++++++| prepare &
| | |--+ start
| | | | the
| | C3. REPORT (terminate) |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | C4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "Can you hear me? It's me, UAC, talking" |
|<<########################################################|
| | |
| | D1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 16: Recording-Based Echo: Two Framework Transactions
图16：基于记录的Echo：两个框架事务
The first obvious difference that stands out when looking at the diagram is that, unlike the Direct Echo scenario, the MS does not reply with a 200 message to the CONTROL request originated by the AS. Instead, a 202 provisional message is sent first, followed by a REPORT message. The 202+REPORT(s) mechanism is used whenever the MS wants to tell the AS that the requested operation might take more time than the limit specified in the definition of the Control Package. So, while the <join> operation in the Direct Echo scenario was expected to be fulfilled in a very short time, the IVR request was assumed to last longer. A 202 message provides a timeout value and tells the AS to wait a bit, since the preparation of the dialog might not happen immediately. In this example, the preparation ends before the timeout, and so the transaction is concluded with a 'REPORT terminate', which reports the end of the transaction (as did the 200 message in the previous example). If the preparation took longer than the timeout, an additional 'REPORT update' would have been sent with a new timeout value, and so on, until completion by means of a 'REPORT terminate'.
当查看图表时，第一个明显的区别是，与直接回送场景不同，MS不对AS发起的控制请求回复200消息。相反，首先发送202临时消息，然后发送报告消息。每当MS想要告诉AS请求的操作可能需要比控制包定义中指定的限制更多的时间时，就会使用202+报告机制。因此，虽然直接Echo场景中的<join>操作预计将在很短的时间内完成，但假设IVR请求的持续时间更长。202消息提供了一个超时值，并告诉AS等待一点，因为对话框的准备可能不会立即进行。在本例中，准备在超时之前结束，因此事务以“REPORT terminate”结束，它报告事务的结束（如前一示例中的200消息）。如果准备时间长于超时时间，则会发送一个附加的“报告更新”以及一个新的超时值，依此类推，直到通过“报告终止”完成。
Note that the REPORT mechanism depicted is only shown to clarify its behavior. In fact, the 202+REPORT mechanism is assumed to be involved only when the requested transaction is expected to take a long time (e.g., retrieving a large media file for a prompt from an external server). In this scenario, the transaction would be prepared in much less time and as a consequence would very likely be completed within the context of a simple CONTROL+200 request/ response. The following scenarios will only involve 202+REPORTs when they are strictly necessary.
请注意，所描述的报告机制仅用于阐明其行为。事实上，假设202+报告机制仅在请求的事务预计需要很长时间（例如，从外部服务器检索大型媒体文件以获得提示）时才涉及。在这种情况下，事务将在更短的时间内准备好，因此很可能在一个简单的控件+200请求/响应的上下文中完成。以下场景仅在严格必要时涉及202多个报告。
Regarding the dialog itself, note how the AS-originated CONTROL transactions are terminated as soon as the requested dialogs start. As specified in [RFC6231], the MS uses a framework CONTROL message to report the result of the dialog and how it has proceeded. The two transactions (the AS-generated CONTROL request and the MS-generated CONTROL event) are correlated by means of the associated dialog identifier, as explained below. As before, the transaction steps have been numbered. The two transactions are distinguished by the preceding letter (A,B=recording, C,D=playout).
关于对话框本身，请注意，当请求的对话框启动时，原始控制事务是如何终止的。如[RFC6231]中所述，MS使用框架控制消息来报告对话框的结果及其进行方式。这两个事务（AS生成的控制请求和MS生成的控制事件）通过关联的对话框标识符进行关联，如下所述。如前所述，事务步骤已编号。这两个事务通过前面的字母（A，B=录制，C，D=播放）进行区分。
o The AS, as a first transaction, invokes a recording on the UAC connection by means of a CONTROL request (A1). The body is for the IVR package (msc-ivr/1.0) and requests the start (<dialogstart>) of a new recording context (<record>). The recording must be preceded by an announcement (<prompt>), must not last longer than 10 s (maxtime), and cannot be interrupted by a DTMF tone (dtmfterm=false). This is only done once (the missing
o AS作为第一个事务，通过控制请求（A1）调用UAC连接上的记录。正文用于IVR包（msc IVR/1.0），并请求启动新录制上下文（<record>）。录制之前必须有公告（<prompt>），持续时间不得超过10秒（maxtime），并且不能被DTMF音中断（dtmfterm=false）。此操作仅执行一次（缺少
repeatCount attribute is 1 by default for a <dialog>), which means that if the recording does not succeed the first time, the transaction must fail. A video recording is requested (considering that the associated connection includes both audio and video and no restriction is enforced on streams to record), which is to be fed by both of the negotiated media streams. A beep has to be played (beep=true) right before the recording starts, to notify the UAC.
默认情况下，<dialog>的repeatCount属性为1），这意味着如果第一次录制不成功，则事务必须失败。请求视频记录（考虑到相关连接包括音频和视频，并且对要记录的流没有强制限制），该视频记录将由两个协商的媒体流馈送。必须在录音开始前播放一声蜂鸣音（蜂鸣音=真），以通知UAC。
o As seen before, the MS sends a provisional 202 response to let the AS know that the operation might need some time.
o 如前所述，MS发送临时202响应以让As知道操作可能需要一些时间。
o In the meantime, the MS prepares the dialog (e.g., by retrieving the announcement file, for which an HTTP URL is provided, and by checking that the request is well formed) and if all is fine it starts it, notifying the AS with a new REPORT (A3) with a terminated status. As explained previously, interlocutory REPORT messages with an update status would have been sent if the preparation took longer than the timeout provided in the 202 message (e.g., if retrieving the resource via HTTP took longer than expected). Once the dialog has been prepared and started, the UAC connection is then passed to the IVR package, which first plays the announcement on the connection, followed by a beep, and then records all the incoming frames to a buffer. The MS also provides the AS with a unique dialog identifier (dialogid) that will be used in all subsequent event notifications concerning the dialog it refers to.
o 同时，MS准备对话（例如，通过检索提供HTTP URL的公告文件，并通过检查请求的格式是否正确），如果一切正常，则启动该对话框，并使用具有终止状态的新报告（A3）通知AS。如前所述，如果准备时间长于202消息中提供的超时时间（例如，如果通过HTTP检索资源的时间长于预期时间），则将发送具有更新状态的中间报告消息。对话框准备好并启动后，UAC连接将传递给IVR包，IVR包首先在连接上播放公告，然后发出嘟嘟声，然后将所有传入帧记录到缓冲区。MS还为AS提供了一个唯一的对话框标识符（dialogid），该标识符将用于与所引用对话框相关的所有后续事件通知中。
o The AS acks the latest REPORT (A4), thus terminating this transaction, and waits for the results.
o AS确认最新报告（A4），从而终止此事务，并等待结果。
o Once the recording is over, the MS prepares a notification CONTROL (B1). The <event> body is prepared with an explicit reference to the previously provided dialog identifier, in order to make the AS aware of the fact that the notification is related to that specific dialog. The event body is then completed with the recording-related information (<recordinfo>), in this case the path to the recorded file (here, an HTTP URL) that can be used by the AS for anything it needs. The payload also contains information about the prompt (<promptinfo>), which is, however, not relevant to the scenario.
o 记录结束后，MS准备通知控件（B1）。<event>主体使用前面提供的对话框标识符的显式引用来准备，以便让AS知道通知与该特定对话框相关。然后，事件主体使用记录相关信息（<recordinfo>）完成，在本例中，记录文件的路径（此处为HTTP URL），AS可以使用该路径进行任何需要的操作。有效负载还包含有关提示符（<promptinfo>）的信息，但这与场景无关。
o The AS concludes this first recording transaction by acking the CONTROL event (B2).
o AS通过确认控制事件（B2）来结束第一个记录事务。
Now that the first transaction has ended, the AS has the 10-s recording of the UAC talking and can let the UAC hear it by having the MS play it for the UAC as an announcement:
现在，第一笔交易已经结束，AS拥有UAC对话的10秒录音，并可以让MS将其作为公告播放给UAC听：
o In the second transaction, the AS invokes a playout on the UAC connection by means of a new CONTROL request (C1). The body is once again for the IVR package (msc-ivr/1.0), but this time it requests the start (<dialogstart>) of a new announcement context (<prompt>). The file to be played is the file that was recorded before (<media>).
o 在第二个事务中，AS通过新的控制请求（C1）调用UAC连接上的播放。正文再次用于IVR包（msc IVR/1.0），但这次它请求启动（<dialogstart>）新的公告上下文（<prompt>）。要播放的文件是以前录制的文件（<media>）。
o Again, the usual provisional 202 (C2) takes place.
o 同样，通常的临时202（C2）发生。
o In the meantime, the MS prepares and starts the new dialog, and notifies the AS with a new REPORT (C3) with a terminated status. The connection is then passed to the IVR package, which plays the file on it.
o 同时，MS准备并启动新对话框，并向AS通知一份状态为终止的新报告（C3）。然后将连接传递到IVR包，该包在其上播放文件。
o The AS acks the terminating REPORT (C4), now waiting for the announcement to end.
o AS确认正在等待公告结束的终止报告（C4）。
o Once the playout is over, the MS sends a CONTROL event (D1) that contains in its body (<promptinfo>) information about the just-concluded announcement. As before, the proper dialogid is used as a reference to the correct dialog.
o 播放结束后，MS将发送一个控制事件（D1），该事件在其正文（<PrompInfo>）中包含有关刚刚结束的公告的信息。与前面一样，正确的对话框ID用作对正确对话框的引用。
o The AS concludes this second and last transaction by acking the CONTROL event (D2).
o AS通过确认控制事件（D2）结束第二个也是最后一个事务。
As in the previous paragraph, the whole CFW interaction is provided for a more in-depth evaluation of the protocol interaction.
如前一段所述，提供整个CFW交互是为了对协议交互进行更深入的评估。
A1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 796d83aa1ce4 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 265
A1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 796d83aa1ce4 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 265
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.com/demo/echorecord.mpg"/>
</prompt>
<record beep="true" maxtime="10s"/>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.com/demo/echorecord.mpg"/>
</prompt>
<record beep="true" maxtime="10s"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 796d83aa1ce4 202
Timeout: 5
A2. AS <- MS (CFW 202)
----------------------
CFW 796d83aa1ce4 202
Timeout: 5
A3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 796d83aa1ce4 REPORT
Seq: 1
Status: terminate
Timeout: 25
Content-Type: application/msc-ivr+xml
Content-Length: 137
A3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 796d83aa1ce4 REPORT
Seq: 1
Status: terminate
Timeout: 25
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started"
dialogid="68d6569"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started"
dialogid="68d6569"/>
</mscivr>
A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 796d83aa1ce4 200
Seq: 1
A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 796d83aa1ce4 200
Seq: 1
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 0eb1678c0bfc CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 403
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 0eb1678c0bfc CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 403
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="68d6569">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="9987" termmode="completed"/>
<recordinfo duration="10017" termmode="maxtime">
<mediainfo
loc="http://www.example.net/recordings/recording-68d6569.mpg"
type="video/mpeg" size="591872"/>
</recordinfo>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="68d6569">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="9987" termmode="completed"/>
<recordinfo duration="10017" termmode="maxtime">
<mediainfo
loc="http://www.example.net/recordings/recording-68d6569.mpg"
type="video/mpeg" size="591872"/>
</recordinfo>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 0eb1678c0bfc 200
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 0eb1678c0bfc 200
C1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 1632eead7e3b CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 241
C1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 1632eead7e3b CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 241
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-68d6569.mpg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-68d6569.mpg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 202)
----------------------
CFW 1632eead7e3b 202
Timeout: 5
C2. AS <- MS (CFW 202)
----------------------
CFW 1632eead7e3b 202
Timeout: 5
C3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 1632eead7e3b REPORT
Seq: 1
Status: terminate
Timeout: 25
Content-Type: application/msc-ivr+xml
Content-Length: 137
C3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 1632eead7e3b REPORT
Seq: 1
Status: terminate
Timeout: 25
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started"
dialogid="5f5cb45"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started"
dialogid="5f5cb45"/>
</mscivr>
C4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 1632eead7e3b 200
Seq: 1
C4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 1632eead7e3b 200
Seq: 1
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 502a5fd83db8 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 230
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 502a5fd83db8 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 230
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5f5cb45">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10366" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5f5cb45">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10366" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 502a5fd83db8 200
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 502a5fd83db8 200
Another scenario that might involve the interaction between an AS and an MS is the classic phone call between two UACs. In fact, even though the most straightforward way to achieve this would be to let the UACs negotiate the session and the media to be used between them, there are cases when the services provided by an MS might also prove useful for such phone calls.
另一个可能涉及AS和MS之间交互的场景是两个UAC之间的经典电话呼叫。事实上，即使实现这一点最直接的方法是让UAC协商会话和它们之间要使用的媒体，但在某些情况下，MS提供的服务也可能对此类电话有用。
One of these cases is when the two UACs have no common supported codecs: having the two UACs directly negotiate the session would result in a session with no available media. Involving the MS as a transcoder would in this case still allow the two UACs to communicate. Another interesting case is when the AS (or any other entity on whose behalf the AS is working) is interested in manipulating or monitoring the media session between the UACs, e.g., to record the conversation. A similar scenario will be dealt with in Section 6.2.2.
其中一种情况是两个UAC没有共同支持的编解码器：让两个UAC直接协商会话将导致会话没有可用的媒体。在这种情况下，将MS作为转码器将仍然允许两个UAC通信。另一个有趣的情况是，当AS（或AS代表其工作的任何其他实体）有兴趣操纵或监控UAC之间的媒体会话时，例如，记录对话。第6.2.2节将讨论类似情况。
Before looking at how such a scenario might be accomplished by means of the Media Control Channel Framework, it is worth mentioning what the SIP signaling involving all the interested parties might look like. In fact, in such a scenario, a 3PCC approach is absolutely needed. An example is provided in Figure 17. Again, the presented example is not at all to be considered best common practice when 3PCC is needed in a MEDIACTRL-based framework. It is only described in order to help the reader more easily understand what the requirements are on the MS side, and as a consequence what information might be required. [RFC3725] provides a much more detailed overview on 3PCC patterns in several use cases. Only an explanatory sequence diagram is provided, without delving into the details of the exchanged SIP messages.
在研究如何通过媒体控制信道框架实现这种场景之前，值得一提的是涉及所有相关方的SIP信令可能是什么样子。事实上，在这种情况下，绝对需要3PCC方法。图17中提供了一个示例。同样，在基于MEDIACTRL的框架中需要3PCC时，本示例根本不被视为最佳常见做法。描述它只是为了帮助读者更容易地理解MS端的需求，以及可能需要的信息。[RFC3725]提供了几个用例中3PCC模式的更详细概述。只提供了一个解释性的序列图，没有深入研究交换的SIP消息的细节。
UAC(1) UAC(2) AS MS
| | | |
| INVITE (offer A) | |
| Call-Id: A | | |
|---------------------------------->| |
| | 100 Trying | |
| | Call-Id: A | |
|<----------------------------------| |
| | INVITE (no offer) | |
| | Call-Id: B | |
| |<--------------------| |
| | 180 Ringing | |
| | Call-Id: B | |
| |-------------------->| |
| | 180 Ringing | |
| | Call-Id: A | |
|<----------------------------------| |
| | | INVITE (offer A) |
| | | Call-Id: C |
| | |-------------------------->|
| | | 200 OK (offer A') |
| | | Call-Id: C |
| | |<--------------------------|
| | | ACK |
| | | Call-Id: C |
| | |-------------------------->|
| | 200 OK (offer B) | |
| | Call-Id: B | |
| |-------------------->| |
| | | INVITE (offer B) |
| | | Call-Id: D |
| | |-------------------------->|
| | | 200 OK (offer B') |
| | | Call-Id: D |
| | |<--------------------------|
| | | ACK |
| | | Call-Id: D |
| | |-------------------------->|
| | ACK (offer B') | |
| | Call-Id: B | |
UAC(1) UAC(2) AS MS
| | | |
| INVITE (offer A) | |
| Call-Id: A | | |
|---------------------------------->| |
| | 100 Trying | |
| | Call-Id: A | |
|<----------------------------------| |
| | INVITE (no offer) | |
| | Call-Id: B | |
| |<--------------------| |
| | 180 Ringing | |
| | Call-Id: B | |
| |-------------------->| |
| | 180 Ringing | |
| | Call-Id: A | |
|<----------------------------------| |
| | | INVITE (offer A) |
| | | Call-Id: C |
| | |-------------------------->|
| | | 200 OK (offer A') |
| | | Call-Id: C |
| | |<--------------------------|
| | | ACK |
| | | Call-Id: C |
| | |-------------------------->|
| | 200 OK (offer B) | |
| | Call-Id: B | |
| |-------------------->| |
| | | INVITE (offer B) |
| | | Call-Id: D |
| | |-------------------------->|
| | | 200 OK (offer B') |
| | | Call-Id: D |
| | |<--------------------------|
| | | ACK |
| | | Call-Id: D |
| | |-------------------------->|
| | ACK (offer B') | |
| | Call-Id: B | |
| |<--------------------| |
| | 200 OK (offer A') | |
| | Call-Id: A | |
|<----------------------------------| |
| ACK | | |
| Call-Id: A | | |
|---------------------------------->| |
| | | |
. . . .
. . . .
| |<--------------------| |
| | 200 OK (offer A') | |
| | Call-Id: A | |
|<----------------------------------| |
| ACK | | |
| Call-Id: A | | |
|---------------------------------->| |
| | | |
. . . .
. . . .
Figure 17: Phone Call: Example of 3PCC
图17：电话呼叫：3PCC示例
In this example, UAC1 wants to place a phone call to UAC2. To do so, it sends an INVITE to the AS with its offer A. The AS sends an offerless INVITE to UAC2. When UAC2 responds with a 180, the same message is forwarded by the AS to UAC1 to notify it that the callee is ringing. In the meantime, the AS also adds a leg to the MS for UAC1, as explained at the beginning of Section 6. To do so, it of course uses the offer A that UAC1 made. Once UAC2 accepts the call by providing its own offer B in the 200, the AS also adds a leg for offer B to the MS. At this point, the negotiation can be completed by providing the two UACs with the SDP answer negotiated by the MS with them (A' and B', respectively).
在本例中，UAC1希望向UAC2拨打电话。为此，它向AS发送邀请和报价A。AS向UAC2发送无报价邀请。当UAC2以180应答时，AS会将相同的消息转发给UAC1，通知其被叫方正在振铃。同时，AS还为UAC1的MS添加了一个分支，如第6节开头所述。为了做到这一点，它当然使用了UAC1提供的报价。一旦UAC2通过在200中提供其自己的报价B来接受呼叫，AS也会向MS添加报价B的一段。此时，可以通过向两个UAC提供由MS与其协商的SDP应答（分别为a'和B'来完成协商。
Of course, this is only one way to deal with the signaling and shall not be considered an absolutely mandatory approach.
当然，这只是处理信号的一种方法，不应被视为绝对强制性的方法。
Once the negotiation is over, the two UACs are not in communication yet. In fact, it's up to the AS now to actively trigger the MS to somehow attach their media streams to each other, by referring to the connection identifiers associated with the UACs as explained previously. This document presents two different approaches that might be followed, according to what needs to be accomplished. A generic media perspective of the phone call scenario is depicted in Figure 18. The MS is basically in the media path between the two UACs.
一旦谈判结束，两个UAC还没有进行沟通。事实上，现在由AS主动触发MS以某种方式将其媒体流连接到彼此，方法是参考与UAC关联的连接标识符，如前面所述。本文件根据需要完成的工作，提出了可能遵循的两种不同方法。电话通话场景的一般媒体透视图如图18所示。MS基本上位于两个UAC之间的媒体路径中。
+-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| 1 |<===================| Server |<===================| 2 |
+-------+ UAC2 (RTP) +--------+ UAC2 (RTP) +-------+
+-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| 1 |<===================| Server |<===================| 2 |
+-------+ UAC2 (RTP) +--------+ UAC2 (RTP) +-------+
Figure 18: Phone Call: Media Perspective
图18：电话：媒体视角
From the framework point of view, when the UACs' legs are not attached to anything yet, what appears is shown in Figure 19: since there are no connections involving the UACs yet, the frames they might be sending are discarded, and nothing is sent to them (except for silence, if its transmission is requested).
从框架的角度来看，当UAC的支腿还没有连接到任何东西时，出现的情况如图19所示：因为还没有涉及UAC的连接，所以它们可能发送的帧被丢弃，并且不会向它们发送任何内容（如果请求传输，则静默除外）。
MS
+--------------+
UAC 1 | | UAC 2
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
+--------------+
MS
+--------------+
UAC 1 | | UAC 2
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
+--------------+
Figure 19: Phone Call: UAC Media Leg Not Attached
图19：电话：未连接UAC媒体分支
The Direct Connection approach is the easiest, and a more straightforward, approach to get the phone call between the two UACs to work. The idea is basically the same as that of the Direct Echo approach. A <join> directive is used to directly attach one UAC to the other, by exploiting the MS to only deal with the transcoding/ adaption of the flowing frames, if needed.
直接连接方法是使两个UAC之间的电话正常工作的最简单、更直接的方法。这个想法与直接回声法基本相同。<join>指令用于直接将一个UAC连接到另一个UAC，通过利用MS仅处理流帧的转码/自适应（如果需要）。
This approach is depicted in Figure 20.
该方法如图20所示。
MS
+--------------+
UAC 1 | | UAC 2
o----->>-------+~~~>>~~~+------->>-----o
o-----<<-------+~~~<<~~~+-------<<-----o
| |
+--------------+
MS
+--------------+
UAC 1 | | UAC 2
o----->>-------+~~~>>~~~+------->>-----o
o-----<<-------+~~~<<~~~+-------<<-----o
| |
+--------------+
Figure 20: Phone Call: Direct Connection
图20：电话：直接连接
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (join UAC1 to UAC2) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1
| | | 2. 200 OK |<-+ UAC2
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
|<<#######################################################>>|
| UAC1 can hear UAC2 talking |
|<<#######################################################>>|
| | | |
| |<<###########################################>>|
| | UAC2 can hear UAC1 talking |
| |<<###########################################>>|
| | | |
|<*talking*>| | |
. . . .
. . . .
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (join UAC1 to UAC2) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1
| | | 2. 200 OK |<-+ UAC2
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
|<<#######################################################>>|
| UAC1 can hear UAC2 talking |
|<<#######################################################>>|
| | | |
| |<<###########################################>>|
| | UAC2 can hear UAC1 talking |
| |<<###########################################>>|
| | | |
|<*talking*>| | |
. . . .
. . . .
Figure 21: Direct Connection: Framework Transactions
图21：直接连接：框架事务
The framework transactions needed to accomplish this scenario are very trivial and easy to understand. They are basically the same as those presented in the Direct Echo Test scenario; the only difference is in the provided identifiers. In fact, this time the MS is not supposed to attach the UACs' media connections to themselves but has to join the media connections of two different UACs, i.e., UAC1 and UAC2. This means that in this transaction, id1 and i2 will have to address the media connections of UAC1 and UAC2. In the case of a successful transaction, the MS takes care of forwarding all media coming from UAC1 to UAC2 and vice versa, transparently taking care of any required transcoding steps, if necessary.
完成此场景所需的框架事务非常简单且易于理解。它们基本上与直接回波测试场景中呈现的相同；唯一的区别在于提供的标识符。事实上，这次MS不应该将UAC的媒体连接连接连接到自己，而是必须连接两个不同UAC的媒体连接，即UAC1和UAC2。这意味着在该事务中，id1和i2必须处理UAC1和UAC2的媒体连接。在成功事务的情况下，MS负责将所有来自UAC1的媒体转发到UAC2，反之亦然，并在必要时透明地负责任何所需的转码步骤。
1. AS -> MS (CFW CONTROL) ------------------------- CFW 0600855d24c8 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 130
1. AS->MS（CFW控制）-------------CFW 0600855d24c8控制包：msc mixer/1.0内容类型：application/msc mixer+xml内容长度：130
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="e1e1427c:1c998d22"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="e1e1427c:1c998d22"/>
</mscmixer>
2. AS <- MS (CFW 200 OK) ------------------------ CFW 0600855d24c8 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 125
2. AS<-MS（CFW 200正常）---------------------------CFW 0600855d24c8 200超时：10内容类型：应用程序/msc混合器+xml内容长度：125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
Such a simple approach has its drawbacks. For instance, with such an approach, recording a conversation between two users might be tricky to accomplish. In fact, since no mixing would be involved, only the single connections (UAC1<->MS and UAC2<->MS) could be recorded. If the AS wants a conversation-recording service to be provided anyway, it needs additional business logic on its side. An example of such a use case is provided in Section 6.2.3.
这种简单的方法有其缺点。例如，使用这种方法，记录两个用户之间的对话可能很难完成。事实上，由于不涉及混合，因此只能记录单个连接（UAC1<->MS和UAC2<->MS）。如果AS仍然希望提供会话录制服务，那么它需要额外的业务逻辑。第6.2.3节提供了此类用例的示例。
The approach described in Section 6.2.1 surely works for a basic phone call but, as explained previously, might have some drawbacks whenever more advanced features are needed. For instance, one can't record the whole conversation -- only the single connections -- since no mixing is involved. Additionally, even the single task of playing an announcement over the conversation could be complex, especially if the MS does not support implicit mixing over media connections. For this reason, in more advanced cases a different approach might be taken, like the conference-based approach described in this section.
第6.2.1节中描述的方法当然适用于基本电话，但如前所述，当需要更高级的功能时，可能会有一些缺点。例如，一个人不能记录整个对话——只能记录单个连接——因为不涉及混合。此外，即使是在对话中播放公告的单个任务也可能很复杂，特别是当MS不支持通过媒体连接进行隐式混合时。因此，在更高级的情况下，可能会采取不同的方法，如本节所述的基于会议的方法。
The idea is to use a mixing entity in the MS that acts as a bridge between the two UACs. The presence of this entity allows more customization of what needs to be done with the conversation, like the recording of the conversation that has been provided as an example. The approach is depicted in Figure 22. The mixing functionality in the MS will be described in more detail in the following section (which deals with many conference-related scenarios), so only some hints will be provided here for basic comprehension of the approach.
其想法是在MS中使用一个混合实体，作为两个UAC之间的桥梁。该实体的存在允许对会话进行更多的定制，例如作为示例提供的会话录制。该方法如图22所示。下一节将更详细地描述MS中的混合功能（涉及许多与会议相关的场景），因此这里仅提供一些提示，以基本理解该方法。
MS
+---------------+
UAC A | | UAC B
o----->>-------+~~>{#}::>+:::::::>>:::::o
o:::::<<:::::::+<::{#}<~~+-------<<-----o
| : |
| : |
+-------:-------+
:
+::::> (conversation.wav)
MS
+---------------+
UAC A | | UAC B
o----->>-------+~~>{#}::>+:::::::>>:::::o
o:::::<<:::::::+<::{#}<~~+-------<<-----o
| : |
| : |
+-------:-------+
:
+::::> (conversation.wav)
Figure 22: Phone Call: Conference-Based Approach
图22：电话：基于会议的方法
To identify a single sample scenario, let's consider a phone call that the AS wants to record.
为了识别单个样本场景，让我们考虑一个AS想要记录的电话。
Figure 23 shows how this could be accomplished in the Media Control Channel Framework. This example, as usual, hides the previous interaction between the UACs and the AS and instead focuses on the Control Channel operations and what follows.
图23显示了如何在媒体控制通道框架中实现这一点。与往常一样，本例隐藏了UACs和as之间先前的交互，而是将重点放在控制通道操作和后续操作上。
UAC1 UAC2 AS MS
| | | |
| | | A1. CONTROL (create conference) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ create
| | | | | conf and
| | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | B1. CONTROL (record for 10800 s) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ start
| | | | | the
| | | B2. 200 OK |<-+ dialog
| | |<<++++++++++++++++++++++++++++++++|
| Recording +--| |
| of the mix | | |
| has started +->| |
| | | C1. CONTROL (join UAC1<->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1 &
| | | C2. 200 OK |<-+ confY
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<####################################################>>|
| Now UAC1 is mixed in the conference |
|<<####################################################>>|
| | | |
| | | D1. CONTROL (join UAC2<->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | D2. 200 OK |<-+ confY
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| |<<########################################>>|
| | Now UAC2 is mixed too |
| |<#########################################>>|
| | | |
|<*talking*>| | |
| | | |
. . . .
. . . .
UAC1 UAC2 AS MS
| | | |
| | | A1. CONTROL (create conference) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ create
| | | | | conf and
| | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | B1. CONTROL (record for 10800 s) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ start
| | | | | the
| | | B2. 200 OK |<-+ dialog
| | |<<++++++++++++++++++++++++++++++++|
| Recording +--| |
| of the mix | | |
| has started +->| |
| | | C1. CONTROL (join UAC1<->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1 &
| | | C2. 200 OK |<-+ confY
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<####################################################>>|
| Now UAC1 is mixed in the conference |
|<<####################################################>>|
| | | |
| | | D1. CONTROL (join UAC2<->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | D2. 200 OK |<-+ confY
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| |<<########################################>>|
| | Now UAC2 is mixed too |
| |<#########################################>>|
| | | |
|<*talking*>| | |
| | | |
. . . .
. . . .
Figure 23: Conference-Based Approach: Framework Transactions
图23：基于会议的方法：框架事务
The AS uses two different packages to accomplish this scenario: the Mixer package (to create the mixing entity and join the UACs) and the IVR package (to record what happens in the conference). The framework transaction steps can be described as follows:
AS使用两个不同的包来完成此场景：混合器包（创建混合实体并加入UAC）和IVR包（记录会议中发生的事情）。框架事务步骤可以描述如下：
o First of all, the AS creates a new hidden conference by means of a <createconference> request (A1). This conference is properly configured according to the use it is assigned to. In fact, since only two participants will be joined to it, both 'reserved-talkers' and 'reserved-listeners' are set to 2, just as the 'n' value for the N-best audio mixing algorithm. The video layout is also set accordingly (<single-view>/<dual-view>).
o 首先，AS通过<createconference>请求（A1）创建一个新的隐藏会议。此会议已根据分配给它的用途正确配置。事实上，由于只有两名参与者加入，因此“保留的说话者”和“保留的听众”都被设置为2，就像n-best音频混合算法的“n”值一样。视频布局也相应设置（<single view>/<dual view>）。
o The MS sends notification of the successful creation of the new conference in a 200 framework message (A2). The identifier assigned to the conference, which will be used in subsequent requests addressed to it, is 6013f1e.
o MS在200框架消息（A2）中发送成功创建新会议的通知。分配给会议的标识符为6013f1e，将在随后向其发出的请求中使用。
o The AS requests a new recording for the newly created conference. To do so, it places a proper request to the IVR package (B1). The AS is interested in a video recording (type=video/mpeg), which must not last longer than 3 hours (maxtime=10800s), after which the recording must end. Additionally, no beep must be played on the conference (beep=false), and the recording must start immediately whether or not any audio activity has been reported (vadinitial=false is the default value for <record>).
o AS请求为新创建的会议进行新录制。为此，它向IVR包（B1）发出适当的请求。AS对视频录制（类型=视频/mpeg）感兴趣，视频录制的持续时间不得超过3小时（maxtime=10800s），之后必须结束录制。此外，会议上不得播放蜂鸣音（蜂鸣音=假），无论是否报告了任何音频活动，都必须立即开始录制（VadinInitial=假是<record>的默认值）。
o The transaction is handled by the MS, and when the dialog has been successfully started, a 200 OK is issued to the AS (B2). The message contains the dialogid associated with the dialog (00b29fb), which the AS must refer to for later notifications.
o 事务由MS处理，当对话框成功启动时，向AS（B2）发出200 OK。消息包含与对话框（00b29fb）关联的对话框ID，AS在以后的通知中必须参考该对话框ID。
o At this point, the AS attaches both UACs to the conference with two separate <join> directives (C1/D1). When the MS confirms the success of both operations (C2/D2), the two UACs are actually in contact with each other (even though indirectly, since a hidden conference they're unaware of is on their path), and their media contribution is recorded.
o 此时，AS通过两个单独的<join>指令（C1/D1）将两个UAC连接到会议。当MS确认两个行动（C2/D2）都成功时，两个UAC实际上彼此联系（即使是间接的，因为他们不知道的一个隐藏会议正在他们的路上），并且他们的媒体贡献被记录下来。
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 395
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 395
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="2" reserved-listeners="2">
<audio-mixing type="nbest" n="2"/>
<video-layouts>
<video-layout min-participants='1'>
<single-view/>
</video-layout>
<video-layout min-participants='2'>
<dual-view/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
</createconference>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="2" reserved-listeners="2">
<audio-mixing type="nbest" n="2"/>
<video-layouts>
<video-layout min-participants='1'>
<single-view/>
</video-layout>
<video-layout min-participants='2'>
<dual-view/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
</createconference>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 238e1f2946e8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 238e1f2946e8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="6013f1e"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="6013f1e"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-ivr
Content-Type: application/msc-ivr+xml
Content-Length: 226
B1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-ivr
Content-Type: application/msc-ivr+xml
Content-Length: 226
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="6013f1e">
<dialog>
<record beep="false" type="video/mpeg" maxtime="10800s"/>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="6013f1e">
<dialog>
<record beep="false" type="video/mpeg" maxtime="10800s"/>
</dialog>
</dialogstart>
</mscivr>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="00b29fb"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="00b29fb"/>
</mscivr>
C1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 123
C1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="6013f1e"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="6013f1e"/>
</mscmixer>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
D1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 124
D1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 124
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="219782951:0b9d3347" id2="6013f1e"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="219782951:0b9d3347" id2="6013f1e"/>
</mscmixer>
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
The recording of the conversation can subsequently be accessed by the AS by waiting for an event notification from the MS. This event, which will be associated with the previously started recording dialog, will contain the URI of the recorded file. Such an event may be triggered by either a natural completion of the dialog (e.g., the dialog has reached its programmed 3 hours) or any interruption of the dialog itself (e.g., the AS actively requests that the recording be interrupted, since the call between the UACs ended).
AS随后可以通过等待来自MS的事件通知来访问对话的录制。此事件将与先前启动的录制对话框关联，将包含录制文件的URI。此类事件可能由对话的自然完成（例如，对话已达到编程设定的3小时）或对话本身的任何中断（例如，由于UAC之间的通话结束，AS主动请求中断录制）触发。
The previous section described how to take advantage of the conferencing functionality of the Mixer package in order to allow the recording of phone calls in a simple way. However, using a dedicated mixer just for a phone call might be considered overkill. This section shows how recording a conversation and subsequently playing it out can be accomplished without a mixing entity involved in the call, i.e., by using the Direct Connection approach as described in Section 6.2.1.
上一节描述了如何利用Mixer软件包的会议功能，以便以简单的方式录制电话。然而，仅仅在打电话时使用专用混音器可能被认为是过火了。本节说明了如何在通话中不使用混合实体的情况下录制对话并随后播放对话，即使用第6.2.1节所述的直接连接方法。
As explained previously, if the AS wants to record a phone call between two UACs, the use of just the <join> directive without a mixer forces the AS to just rely on separate recording commands. That is, the AS can only instruct the MS to separately record the media flowing on each media leg: a recording for all the data coming from UAC1, and a different recording for all the data coming from UAC2. If someone subsequently wants to access the whole conversation, the AS may take at least two different approaches:
如前所述，如果As想要录制两个UAC之间的电话呼叫，只使用<join>指令而不使用混音器会迫使As仅依赖单独的录制命令。也就是说，AS只能指示MS分别记录每个媒体段上流动的媒体：记录来自UAC1的所有数据，以及记录来自UAC2的所有数据。如果有人随后想要访问整个对话，AS可能会采取至少两种不同的方法：
1. It may mix the two recordings itself (e.g., by delegating it to an offline mixing entity) in order to obtain a single file containing the combination of the two recordings. This way, a simple playout as described in Section 6.1.2 would suffice.
1. 它可以自行混合两个录制（例如，通过将其委托给脱机混合实体），以获得包含两个录制组合的单个文件。这样，第6.1.2节所述的简单播放就足够了。
2. Alternatively, it may take advantage of the mixing functionality provided by the MS itself. One way to do this is to create a hidden conference on the MS, attach the UAC as a passive participant to it, and play the separate recordings on the conference as announcements. This way, the UAC accessing the recording would experience both of the recordings at the same time.
2. 或者，它可以利用MS本身提供的混合功能。一种方法是在MS上创建一个隐藏的会议，将UAC作为被动参与者连接到它，并在会议上播放单独的录音作为公告。这样，UAC访问记录时将同时体验两个记录。
The second approach is considered in this section. The framework transaction as described in Figure 24 assumes that a recording has already been requested for both UAC1 and UAC2, that the phone call has ended, and that the AS has successfully received the URIs to both of the recordings from the MS. Such steps are not described again, since they would be quite similar to the steps described in Section 6.1.2. As mentioned previously, the idea is to use a properly constructed hidden conference to mix the two separate recordings on the fly and present them to the UAC. It is, of course, up to the AS to subsequently unjoin the user from the conference and destroy the conference itself once the playout of the recordings ends for any reason.
本节将考虑第二种方法。如图24所述的框架事务假设已经为UAC1和UAC2请求了记录，电话呼叫已经结束，并且as已经成功地从MS接收到两个记录的URI。这些步骤不再描述，因为它们与第6.1.2节中描述的步骤非常相似。如前所述，我们的想法是使用一个适当构造的隐藏会议来实时混合两个单独的录音，并将它们呈现给UAC。当然，由AS来决定，一旦录音播放出于任何原因结束，随后会取消用户与会议的连接，并销毁会议本身。
UAC3 AS MS
| | |
| (UAC1 and UAC2 have previously been recorded; the AS has |
| the two different recordings available for playout.) |
| | |
| | A1. CONTROL (create conference) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ create
| | | | conf &
| | A2. 200 OK (conferenceid=Y) |<-+ its ID
| |<<++++++++++++++++++++++++++++++++|
| | |
| | B1. CONTROL (join UAC3 & confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ join
| | | | UAC &
| | B2. 200 OK |<-+ confY
| |<+++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| UAC3 is now a passive participant in the conference |
|<<######################################################>>|
| | |
| | C1. CONTROL (play REC1 on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | D1. CONTROL (play REC2 on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ Start
| | | | both
| | | | of the
| | | |dialogs
| | C2. 200 OK |<-+
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| The two recordings are mixed and played together to UAC |
|<<########################################################|
| | |
| | E1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | E2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | F1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
UAC3 AS MS
| | |
| (UAC1 and UAC2 have previously been recorded; the AS has |
| the two different recordings available for playout.) |
| | |
| | A1. CONTROL (create conference) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ create
| | | | conf &
| | A2. 200 OK (conferenceid=Y) |<-+ its ID
| |<<++++++++++++++++++++++++++++++++|
| | |
| | B1. CONTROL (join UAC3 & confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ join
| | | | UAC &
| | B2. 200 OK |<-+ confY
| |<+++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| UAC3 is now a passive participant in the conference |
|<<######################################################>>|
| | |
| | C1. CONTROL (play REC1 on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | D1. CONTROL (play REC2 on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ Start
| | | | both
| | | | of the
| | | |dialogs
| | C2. 200 OK |<-+
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| The two recordings are mixed and played together to UAC |
|<<########################################################|
| | |
| | E1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | E2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | F1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | F2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
| | F2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 24: Phone Call: Playout of a Recorded Conversation
图24：电话：播放录制的对话
The diagram above assumes that a recording of both of the channels (UAC1 and UAC2) has already taken place. Later, when we desire to play the whole conversation to a new user, UAC3, the AS may take care of the presented transactions. The framework transaction steps are only apparently more complicated than those presented so far. The only difference, in fact, is that transactions C and D are concurrent, since the recordings must be played together.
上图假设两个通道（UAC1和UAC2）都已记录。稍后，当我们希望向新用户UAC3播放整个对话时，AS可能会处理呈现的事务。框架事务步骤显然比目前所介绍的更复杂。事实上，唯一的区别是事务C和D是并发的，因为录制必须一起播放。
o First of all, the AS creates a new conference to act as a mixing entity (A1). The settings for the conference are chosen according to the use case, e.g., the video layout, which is fixed to <dual-view>, and the switching type to <controller>. When the conference has been successfully created (A2), the AS takes note of the conference identifier.
o 首先，AS创建了一个新的会议，作为一个混合实体（A1）。会议的设置是根据用例选择的，例如，视频布局固定为<dual view>，切换类型为<controller>。成功创建会议（A2）后，AS会记录会议标识符。
o At this point, UAC3 is attached to the conference as a passive user (B1). There would be no point in letting the user contribute to the conference mix, since he will only need to watch a recording. In order to specify his passive status, both the audio and video streams for the user are set to 'recvonly'. If the transaction succeeds, the MS notifies the AS (B2).
o 此时，UAC3作为被动用户（B1）连接到会议。让用户参与会议组合没有任何意义，因为他只需要观看一段录音。为了指定用户的被动状态，用户的音频和视频流都设置为“recvonly”。如果事务成功，则MS通知AS（B2）。
o Once the conference has been created and UAC3 has been attached to it, the AS can request the playout of the recordings; in order to do so, it requests two concurrent <prompt> directives (C1 and D1), addressing the recording of UAC1 (REC1) and UAC2 (REC2), respectively. Both of the prompts must be played on the previously created conference and not to UAC3 directly, as can be deduced from the 'conferenceid' attribute of the <dialog> element.
o 创建会议并将UAC3连接到会议后，AS可以请求播放录音；为此，它请求两个并发的<prompt>指令（C1和D1），分别处理UAC1（REC1）和UAC2（REC2）的记录。这两个提示必须在先前创建的会议上播放，而不能直接播放到UAC3，这可以从<dialog>元素的“conferenceid”属性推断出来。
o The transactions "live their lives" exactly as explained for previous <prompt> examples. The originating transactions are first prepared and started (C2, D2), and then, as soon as the playout ends, a related CONTROL message is triggered by the MS (E1, F1). This notification may contain a <promptinfo> element with information about how the playout proceeded (e.g., whether the playout completed normally or was interrupted by a DTMF tone, etc.).
o 正如前面的<prompt>示例所述，事务“过着自己的生活”。首先准备并启动原始事务（C2、D2），然后，一旦播放结束，MS（E1、F1）就会触发相关的控制消息。此通知可能包含一个<promptinfo>元素，其中包含有关播放如何进行的信息（例如，播放是正常完成还是被DTMF音中断等）。
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 506e039f65bd CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 312
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 506e039f65bd CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 312
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="0" reserved-listeners="1">
<audio-mixing type="controller"/>
<video-layouts>
<video-layout min-participants='1'>
<dual-view/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
</createconference>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="0" reserved-listeners="1">
<audio-mixing type="controller"/>
<video-layouts>
<video-layout min-participants='1'>
<dual-view/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
</createconference>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 506e039f65bd 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 506e039f65bd 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="2625069"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="2625069"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 09202baf0c81 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 214
B1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 09202baf0c81 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 214
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="aafaf62d:0eac5236" id2="2625069">
<stream media="audio" direction="recvonly"/>
<stream media="video" direction="recvonly"/>
</join>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="aafaf62d:0eac5236" id2="2625069">
<stream media="audio" direction="recvonly"/>
<stream media="video" direction="recvonly"/>
</join>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 09202baf0c81 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 09202baf0c81 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
C1. AS -> MS (CFW CONTROL, play recording from UAC1)
----------------------------------------------------
CFW 3c2a08be4562 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
C1. AS -> MS (CFW CONTROL, play recording from UAC1)
----------------------------------------------------
CFW 3c2a08be4562 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="2625069">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-4ca9fc2.mpg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="2625069">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-4ca9fc2.mpg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
D1. AS -> MS (CFW CONTROL, play recording from UAC2)
----------------------------------------------------
CFW 1c268d810baa CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
D1. AS -> MS (CFW CONTROL, play recording from UAC2)
----------------------------------------------------
CFW 1c268d810baa CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="2625069">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-39dfef4.mpg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="2625069">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-39dfef4.mpg"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 1c268d810baa 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 1c268d810baa 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started"
dialogid="7a457cc"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started"
dialogid="7a457cc"/>
</mscivr>
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3c2a08be4562 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3c2a08be4562 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started"
dialogid="1a0c7cf"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started"
dialogid="1a0c7cf"/>
</mscivr>
E1. AS <- MS (CFW CONTROL event, playout of recorded UAC1 ended)
----------------------------------------------------------------
CFW 77aec0735922 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 230
E1. AS <- MS (CFW CONTROL event, playout of recorded UAC1 ended)
----------------------------------------------------------------
CFW 77aec0735922 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 230
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="7a457cc">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10339" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="7a457cc">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10339" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 77aec0735922 200
E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 77aec0735922 200
F1. AS <- MS (CFW CONTROL event, playout of recorded UAC2 ended)
----------------------------------------------------------------
CFW 62726ace1660 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 230
F1. AS <- MS (CFW CONTROL event, playout of recorded UAC2 ended)
----------------------------------------------------------------
CFW 62726ace1660 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 230
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="1a0c7cf">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10342" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="1a0c7cf">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10342" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
F2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 62726ace1660 200
F2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 62726ace1660 200
One of the most important services the MS must be able to provide is mixing. This involves mixing media streams from different sources and delivering the resulting mix(es) to each interested party, often according to per-user policies, settings, and encoding. A typical scenario involving mixing is, of course, media conferencing. In such a scenario, the media sent by each participant is mixed, and each participant typically receives the overall mix, excluding its own contribution and encoded in the format it negotiated. This example points out in a quite clear way how mixing must take care of the profile of each involved entity.
MS必须能够提供的最重要的服务之一是混合。这涉及到混合来自不同来源的媒体流，并通常根据每个用户的策略、设置和编码向每个感兴趣的方提供最终的混合。当然，涉及混合的典型场景是媒体会议。在这种情况下，每个参与者发送的媒体是混合的，并且每个参与者通常接收整体混合，不包括其自己的贡献，并以其协商的格式进行编码。这个例子非常清楚地指出了混合必须如何处理每个相关实体的轮廓。
A media perspective of such a scenario is depicted in Figure 25.
图25描述了这种场景的媒体透视图。
+-------+
| UAC |
| C |
+-------+
" ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B+C (RTP) +--------+ B (RTP) +-------+
+-------+
| UAC |
| C |
+-------+
" ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B+C (RTP) +--------+ B (RTP) +-------+
Figure 25: Conference: Media Perspective
图25：会议：媒体视角
From the framework point of view, when the UACs' legs are not attached to anything yet, what appears is shown in Figure 26: since there are no connections involving the UACs yet, the frames they might be sending are discarded, and nothing is sent back to them (except for silence, if its transmission is requested).
从框架的角度来看，当UAC的支腿还没有连接到任何东西时，出现的情况如图26所示：因为还没有涉及UAC的连接，所以它们可能发送的帧被丢弃，并且没有任何内容被发送回它们（如果请求传输，除了静默）。
MS
+----------------+
UAC A | | UAC B
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
| |
| xx |
| |. |
+-------|.-------+
|.
^v
^v
|.
oo
UAC C
MS
+----------------+
UAC A | | UAC B
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
| |
| xx |
| |. |
+-------|.-------+
|.
^v
^v
|.
oo
UAC C
Figure 26: Conference: UAC Legs Not Attached
图26：会议：未连接UAC支腿
The next subsections will cover several typical scenarios involving mixing and conferencing as a whole, specifically:
下一小节将介绍几个典型的场景，涉及混合和会议作为一个整体，具体如下：
1. Simple Bridging scenario, which is a very basic (i.e., no "special effects"; just mixing involved) conference involving one or more participants.
1. 简单的桥接场景，这是一个非常基本的会议（即，没有“特效”；只涉及混合），涉及一个或多个参与者。
2. Rich Conference scenario, which enriches the Simple Bridging scenario by adding additional features typically found in conferencing systems (e.g., DTMF collection for PIN-based conference access, private and global announcements, recordings, and so on).
2. 丰富的会议场景，通过添加会议系统中常见的附加功能（例如，基于PIN的会议访问的DTMF收集、私人和全球公告、录音等），丰富了简单的桥接场景。
3. Coaching scenario, which is a more complex scenario that involves per-user mixing (customers, agents, and coaches don't all get the same mixes).
3. 辅导场景，这是一个更复杂的场景，涉及每个用户的混合（客户、代理和教练不都获得相同的混合）。
4. Sidebars scenario, which adds more complexity to the previous conferencing scenarios by involving sidebars (i.e., separate conference instances that only exist within the context of a parent conference instance) and the custom media delivery that follows.
4. 侧栏场景，通过涉及侧栏（即，仅存在于父会议实例上下文中的单独会议实例）和随后的自定义媒体交付，使以前的会议场景更加复杂。
5. Floor Control scenario, which provides some guidance on how floor control could be involved in a MEDIACTRL-based media conference.
5. 楼层控制场景，该场景提供了一些关于如何在基于MEDIACTRL的媒体会议中使用楼层控制的指导。
All of the above-mentioned scenarios depend on the availability of a mixing entity. Such an entity is provided in the Media Control Channel Framework by the conferencing package. Besides allowing for the interconnection of media sources as seen in the Direct Echo Test section, this package enables the creation of abstract connections that can be joined to multiple connections. These abstract connections, called conferences, mix the contribution of each attached connection and feed them accordingly (e.g., a connection with a 'sendrecv' property would be able to contribute to the mix and listen to it, while a connection with a 'recvonly' property would only be able to listen to the overall mix but not actively contribute to it).
上述所有场景都取决于混合实体的可用性。这种实体由会议包在媒体控制通道框架中提供。除了允许直接回波测试部分中所示的媒体源互连外，该软件包还支持创建可连接到多个连接的抽象连接。这些被称为会议的抽象连接混合了每个连接的贡献，并相应地为它们提供信息（例如，与“sendrecv”属性的连接将能够参与混音并收听，而与“recvonly”属性的连接将只能收听整个混音，但不能积极参与）。
That said, each of the above-mentioned scenarios will start more or less in the same way: by the creation of a conference connection (or more than one, as needed in some cases) to be subsequently referred to when it comes to mixing. A typical framework transaction to create a new conference instance in the Media Control Channel Framework is depicted in Figure 27:
也就是说，上述每一种场景都或多或少以相同的方式开始：通过创建会议连接（或在某些情况下根据需要创建多个会议连接），以便在混合时随后参考。在Media Control Channel框架中创建新会议实例的典型框架事务如图27所示：
AS MS
| |
| 1. CONTROL (create conference) |
|++++++++++++++++++++++++++++++++>>|
| |--+ create
| | | conf and
| 2. 200 OK (conferenceid=Y) |<-+ its ID
|<<++++++++++++++++++++++++++++++++|
map URI +--| |
X with | | |
confY +->| |
| |
. .
. .
AS MS
| |
| 1. CONTROL (create conference) |
|++++++++++++++++++++++++++++++++>>|
| |--+ create
| | | conf and
| 2. 200 OK (conferenceid=Y) |<-+ its ID
|<<++++++++++++++++++++++++++++++++|
map URI +--| |
X with | | |
confY +->| |
| |
. .
. .
Figure 27: Conference: Framework Transactions
图27：会议：框架事务
The call flow is quite straightforward and can typically be summarized in the following steps:
调用流程非常简单，通常可以在以下步骤中进行总结：
o The AS invokes the creation of a new conference instance by means of a CONTROL request (1); this request is addressed to the conferencing package (msc-mixer/1.0) and contains in the body the directive (<createconference>) with all the desired settings for the new conference instance. In the example below, the mixing policy is to mix the five ('reserved-talkers') loudest speakers (nbest), while ten listeners at maximum are allowed. Video settings are configured, including the mechanism used to select active video sources (<controller>, meaning the AS will explicitly instruct the MS about it) and details about the video layouts to make available. In this example, the AS is instructing the MS to use a <single-view> layout when only one video source is active, to pass to a <quad-view> layout when at least two video sources are active, and to use a <multiple-5x1> layout whenever the number of sources is at least five. Finally, the AS also subscribes to the "active-talkers" event, which means it wants to be informed (at a rate of 4 seconds) whenever an active participant is speaking.
o AS通过控制请求（1）调用新会议实例的创建；此请求发送到会议包（msc mixer/1.0），并在正文中包含指令（<createconference>），其中包含新会议实例的所有所需设置。在下面的示例中，混音策略是混音五个（保留说话者）最大的扬声器（nbest），而最多允许十个听众。已配置视频设置，包括用于选择活动视频源的机制（<controller>，意味着AS将明确指示MS该设置）以及有关要提供的视频布局的详细信息。在此示例中，AS指示MS在只有一个视频源处于活动状态时使用<single view>布局，在至少两个视频源处于活动状态时传递到<quad view>布局，并且在源数量至少为五个时使用<multiple-5x1>布局。最后，AS还订阅“主动对话者”事件，这意味着它希望在主动参与者发言时得到通知（以4秒的速率）。
o The MS creates the conference instance, assigns a unique identifier to it (6146dd5), and completes the transaction with a 200 response (2).
o MS创建会议实例，为其分配唯一标识符（6146dd5），并使用200响应完成事务（2）。
o At this point, the requested conference instance is active and ready to be used by the AS. It is then up to the AS to integrate the use of this identifier in its application logic.
o 此时，请求的会议实例处于活动状态，可以由AS使用。然后由AS将该标识符的使用集成到其应用程序逻辑中。
1. AS -> MS (CFW CONTROL) ------------------------- CFW 3032e5fb79a1 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 489
1. AS->MS（CFW控制）-------------CFW 3032e5fb79a1控制包：msc mixer/1.0内容类型：application/msc mixer+xml内容长度：489
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="5" reserved-listeners="10">
<audio-mixing type="nbest"/>
<video-layouts>
<video-layout min-participants='1'>
<single-view/>
</video-layout>
<video-layout min-participants='2'>
<quad-view/>
</video-layout>
<video-layout min-participants='5'>
<multiple-5x1/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
<subscribe>
<active-talkers-sub interval="4"/>
</subscribe>
</createconference>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="5" reserved-listeners="10">
<audio-mixing type="nbest"/>
<video-layouts>
<video-layout min-participants='1'>
<single-view/>
</video-layout>
<video-layout min-participants='2'>
<quad-view/>
</video-layout>
<video-layout min-participants='5'>
<multiple-5x1/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
<subscribe>
<active-talkers-sub interval="4"/>
</subscribe>
</createconference>
</mscmixer>
2. AS <- MS (CFW 200) --------------------- CFW 3032e5fb79a1 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 151
2. AS<-MS（CFW 200）--------CFW 3032e5fb79a1 200超时：10内容类型：应用程序/msc混合器+xml内容长度：151
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="6146dd5"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="6146dd5"/>
</mscmixer>
As mentioned previously, the simplest way that an AS can use a conference instance is simple bridging. In this scenario, the conference instance just acts as a bridge for all the participants that are attached to it. The bridge takes care of transcoding, if needed (in general, different participants may use different codecs for their streams), echo cancellation (each participant will receive the overall mix, excluding its own contribution) and per-participant mixing (each participant may receive different mixed streams, according to what it needs/is allowed to send/receive). This assumes, of course, that each interested participant must be somehow joined to the bridge in order to indirectly communicate with the other participants. From the media perspective, the scenario can be seen as depicted in Figure 28.
如前所述，As使用会议实例的最简单方法是简单桥接。在这个场景中，会议实例只是作为连接到它的所有参与者的桥梁。桥接器负责转码（如果需要）（通常情况下，不同的参与者可能对其流使用不同的编解码器）、回声消除（每个参与者将接收整体混合，不包括其自己的贡献）和每个参与者的混合（每个参与者可以根据其需要/允许发送/接收的内容接收不同的混合流）。当然，这假设每个感兴趣的参与者必须以某种方式加入到桥接器中，以便与其他参与者进行间接通信。从媒体的角度看，该场景如图28所示。
MS
+-----------------+
UAC A | | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC C
MS
+-----------------+
UAC A | | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC C
Figure 28: Conference: Simple Bridging
图28：会议：简单桥接
In the framework, the first step is obviously to create a new conference instance as seen in the introductory section (Figure 27). Assuming that a conference instance has already been created, bridging participants to it is quite straightforward and can be accomplished as seen in the Direct Echo Test scenario. The only difference here is that each participant is not directly connected to itself (Direct Echo) or another UAC (Direct Connection) but to the bridge instead. Figure 29 shows the example of two different UACs joining the same conference. The example, as usual, hides the previous interaction between each of the two UACs and the AS, and instead focuses on what the AS does in order to actually join the participants to the bridge so that they can interact in a conference. Please note also that to make the diagram more readable, two different identifiers (UAC1 and UAC2) are used in place of the identifiers previously employed to introduce the scenario (UAC A, B, C).
在该框架中，第一步显然是创建一个新的会议实例，如介绍部分所示（图27）。假设已经创建了一个会议实例，那么将参与者连接到会议实例是非常简单的，并且可以像直接回音测试场景中所看到的那样完成。这里唯一的区别是，每个参与者不是直接连接到自己（直接Echo）或另一个UAC（直接连接），而是连接到网桥。图29显示了两个不同的UAC加入同一会议的示例。与往常一样，该示例隐藏了两个UAC和as之间的先前交互，而是将重点放在as所做的事情上，以便实际将参与者加入到桥接器中，以便他们能够在会议中交互。还请注意，为了使图表更具可读性，使用了两个不同的标识符（UAC1和UAC2）来代替先前用于介绍场景的标识符（UAC A、B、C）。
UAC1 UAC2 AS MS
| | | |
| | | A1. CONTROL (join UAC1 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1 &
| | | A2. 200 OK |<-+ confY
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################>>|
| Now UAC1 is mixed in the conference |
|<<######################################################>>|
| | | |
| | | B1. CONTROL (join UAC2 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | B2. 200 OK |<-+ confY
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
| |<<###########################################>>|
| | Now UAC2 too is mixed in the conference |
| |<<###########################################>>|
| | | |
. . . .
. . . .
UAC1 UAC2 AS MS
| | | |
| | | A1. CONTROL (join UAC1 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC1 &
| | | A2. 200 OK |<-+ confY
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################>>|
| Now UAC1 is mixed in the conference |
|<<######################################################>>|
| | | |
| | | B1. CONTROL (join UAC2 and confY) |
| | |++++++++++++++++++++++++++++++++++>>|
| | | |--+ join
| | | | | UAC2 &
| | | B2. 200 OK |<-+ confY
| | |<<++++++++++++++++++++++++++++++++++|
| | | |
| |<<###########################################>>|
| | Now UAC2 too is mixed in the conference |
| |<<###########################################>>|
| | | |
. . . .
. . . .
Figure 29: Simple Bridging: Framework Transactions (1)
图29：简单桥接：框架事务（1）
The framework transaction steps are actually quite trivial and easy to understand, since they're very similar to some previously described scenarios. The AS joins both UAC1 (id1 in A1) and UAC2 (id1 in B1) to the conference (id2 in both transactions). As a result of these two operations, both UACs are mixed in the conference. Since no <stream> is explicitly provided in any of the transactions, all the media from the UACs (audio/video) are attached to the conference (as long as the conference has been properly configured to support both, of course).
框架事务步骤实际上非常简单且易于理解，因为它们与前面描述的一些场景非常相似。AS将UAC1（A1中的id1）和UAC2（B1中的id1）加入会议（两个事务中的id2）。由于这两项行动，两个UAC在会议中混合使用。由于在任何事务中都没有明确提供<stream>，因此来自UACs的所有媒体（音频/视频）都会连接到会议（当然，只要会议已正确配置为支持这两种媒体）。
A1. AS -> MS (CFW CONTROL)
--------------------------
CFW 434a95786df8 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
A1. AS -> MS (CFW CONTROL)
--------------------------
CFW 434a95786df8 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="e1e1427c:1c998d22" id2="6146dd5"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="e1e1427c:1c998d22" id2="6146dd5"/>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 434a95786df8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 434a95786df8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL)
--------------------------
CFW 5c0cbd372046 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
B1. AS -> MS (CFW CONTROL)
--------------------------
CFW 5c0cbd372046 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="6146dd5"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="6146dd5"/>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 5c0cbd372046 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 5c0cbd372046 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
Once one or more participants have been attached to the bridge, their connections and how their media are handled by the bridge can be dynamically manipulated by means of another directive, called <modifyjoin>. A typical use case for this directive is the change of direction of an existing media (e.g., a previously speaking participant is muted, which means its media direction changes from 'sendrecv' to 'recvonly'). Figure 30 shows how a framework transaction requesting such a directive might appear.
一旦一个或多个参与者连接到网桥，他们的连接以及网桥如何处理他们的媒体可以通过另一个名为<modifyjoin>的指令进行动态操作。本指令的一个典型用例是改变现有媒体的方向（例如，先前发言的参与者被静音，这意味着其媒体方向从“sendrecv”变为“recvonly”）。图30显示了请求这样一个指令的框架事务是如何出现的。
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (modifyjoin UAC1) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modify
| | | | | join
| | | 2. 200 OK |<-+ settings
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################|
| Now UAC1 can receive but not send (recvonly) |
|<<######################################################|
| | | |
. . . .
. . . .
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (modifyjoin UAC1) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modify
| | | | | join
| | | 2. 200 OK |<-+ settings
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################|
| Now UAC1 can receive but not send (recvonly) |
|<<######################################################|
| | | |
. . . .
. . . .
Figure 30: Simple Bridging: Framework Transactions (2)
图30：简单桥接：框架事务（2）
The directive used to modify an existing join configuration is <modifyjoin>, and its syntax is exactly the same as the syntax required in <join> instructions. In fact, the same syntax is used for identifiers (id1/id2). Whenever a <modifyjoin> is requested and id1 and id2 address one or more joined connections, the AS is requesting a change of the join configuration. In this case, the AS instructs the MS to mute (<stream> media=audio, direction=recvonly) UAC1 (id1=UAC1) in the conference (id2) it has been attached to previously. Any other connection existing between them is left untouched.
用于修改现有联接配置的指令是<modifyjoin>，其语法与<join>指令中所需的语法完全相同。事实上，标识符（id1/id2）使用相同的语法。每当请求<modifyjoin>且id1和id2寻址一个或多个连接时，AS都会请求更改连接配置。在这种情况下，AS指示MS在其先前连接到的会议（id2）中静音（<stream>media=audio，direction=recvonly）UAC1（id1=UAC1）。它们之间存在的任何其他连接都保持不变。
It is worth noting that the <stream> settings are enforced according to both the provided direction AND the id1 and id2 identifiers. For instance, in this example id1 refers to UAC1, while id2 refers to the conference in the MS. This means that the required modifications have to be applied to the stream specified in the <stream> element of the message, along the direction that goes from 'id1' to 'id2' (as specified in the <modifyjoin> element of the message). In the provided example, the AS wants to mute UAC1 with respect to the conference. To do so, the direction is set to 'recvonly', meaning that, for what affects id1, the media stream is only to be received. If id1 referred to the conference and id2 to UAC1, to achieve the same result the direction would have to be set to 'sendonly', meaning "id1 (the conference) can only send to id2 (UAC1), and no media stream must be received". Additional settings for a <stream> (e.g., audio volume, region assignments, and so on) follow the same approach, as discussed in subsequent sections.
值得注意的是，<stream>设置是根据提供的方向以及id1和id2标识符来执行的。例如，在此示例中，id1指UAC1，而id2指MS中的会议。这意味着必须沿着从“id1”到“id2”（如消息的<modifyjoin>元素中所指定）的方向，对消息的<stream>元素中指定的流应用所需的修改。在所提供的示例中，AS希望使UAC1相对于会议静音。为此，将方向设置为“RecvoOnly”，这意味着，对于影响id1的内容，仅接收媒体流。如果id1指向会议，id2指向UAC1，为了获得相同的结果，必须将方向设置为“sendonly”，这意味着“id1（会议）只能发送到id2（UAC1），并且不必接收媒体流”。<stream>的附加设置（例如，音频音量、区域分配等）遵循相同的方法，如后续章节所述。
1. AS -> MS (CFW CONTROL) ------------------------- CFW 57f2195875c9 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 182
1. AS->MS（CFW控制）-------------CFW 57f2195875c9控制包：msc混合器/1.0内容类型：应用程序/msc混合器+xml内容长度：182
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="e1e1427c:1c998d22" id2="6146dd5">
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="e1e1427c:1c998d22" id2="6146dd5">
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
2. AS <- MS (CFW 200 OK) ------------------------ CFW 57f2195875c9 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123
2. AS<-MS（CFW 200正常）---------------------------CFW 57f2195875c9 200超时：10内容类型：应用程序/msc混合器+xml内容长度：123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
The previous scenario can be enriched with additional features often found in existing conferencing systems. Typical examples include IVR-based menus (e.g., the DTMF collection for PIN-based conference access), partial and complete recordings in the conference (e.g., for
可以使用现有会议系统中常见的附加功能来丰富前面的场景。典型示例包括基于IVR的菜单（例如，基于PIN的会议访问的DTMF集合）、会议中的部分和完整录制（例如
the "state your name" functionality and recording of the whole conference), private and global announcements, and so on. All of this can be achieved by means of the functionality provided by the MS. In fact, even if the conferencing and IVR features come from different packages, the AS can interact with both of them and achieve complex results by correlating the effects of different transactions in its application logic.
“说出你的名字”功能和整个会议的记录）、私人和全球公告等。所有这些都可以通过MS提供的功能来实现。事实上，即使会议和IVR功能来自不同的软件包，AS也可以与这两者交互，并通过在其应用逻辑中关联不同事务的影响来实现复杂的结果。
From the media and framework perspective, a typical Rich Conference scenario can be seen as depicted in Figure 31.
从媒体和框架的角度来看，典型的富会议场景如图31所示。
MS
+-------- (announcement.wav)
(conference_recording.wav) <:::::+|
:|
+--------:|--------+
UAC A | :v | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: | |
| |v v |
| ++ * (collect DTMF, get name)
| |: |
+--------|:--------+
|:
^v
^v
|:
oo
UAC C
MS
+-------- (announcement.wav)
(conference_recording.wav) <:::::+|
:|
+--------:|--------+
UAC A | :v | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: | |
| |v v |
| ++ * (collect DTMF, get name)
| |: |
+--------|:--------+
|:
^v
^v
|:
oo
UAC C
Figure 31: Conference: Rich Conference Scenario
图31：会议：丰富的会议场景
To identify a single sample scenario, let's consider this sequence for a participant joining a conference (which again we assume has already been created):
为了确定一个样本场景，让我们考虑一个参与者加入会议的顺序（我们假设已经创建）：
1. The UAC as usual INVITEs a URI associated with a conference, and the AS follows the previously explained procedure to have the UAC negotiate a new media session with the MS.
1. UAC一如既往地邀请一个与会议相关联的URI，并按照前面解释的程序让UAC与MS协商一个新的媒体会话。
2. The UAC is presented with an IVR menu, in which it is requested to input a PIN code to access the conference.
2. UAC提供了一个IVR菜单，其中要求其输入PIN码以访问会议。
3. If the PIN is correct, the UAC is asked to state its name so that it can be recorded.
3. 如果PIN码正确，UAC将被要求说明其名称，以便记录。
4. The UAC is attached to the conference, and the previously recorded name is announced globally to the conference to advertise its arrival.
4. UAC附属于会议，先前记录的名称将在全球范围内向会议公布，以宣传其到来。
Figure 32 shows a single UAC joining a conference. The example, as usual, hides the previous interaction between the UAC and the AS, and instead focuses on what the AS does to actually interact with the participant and join it to the conference bridge.
图32显示了一个UAC加入会议。与往常一样，该示例隐藏了UAC和as之间以前的交互，而是关注as如何实际与参与者交互并将其加入会议桥。
UAC AS MS
| | |
| | A1. CONTROL (request DTMF PIN) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | A2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "Please input the PIN number to join the conference" |
|<<########################################################|
| | |
|########################################################>>|
| DTMF digits are collected |--+ get
|########################################################>>| | DTMF
| | |<-+ digits
| | B1. CONTROL (<collectinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Compare DTMF +--| B2. 200 OK |
| digits with | |++++++++++++++++++++++++++++++++>>|
| the PIN number +->| |
| | C1. CONTROL (record name) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | C2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "Please state your name after the beep" |
|<<########################################################|
| | |
|########################################################>>|
| Audio from the UAC is recorded (until timeout or DTMF) |--+ save
|########################################################>>| | in a
| | |<-+ file
| | D1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
UAC AS MS
| | |
| | A1. CONTROL (request DTMF PIN) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | A2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "Please input the PIN number to join the conference" |
|<<########################################################|
| | |
|########################################################>>|
| DTMF digits are collected |--+ get
|########################################################>>| | DTMF
| | |<-+ digits
| | B1. CONTROL (<collectinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Compare DTMF +--| B2. 200 OK |
| digits with | |++++++++++++++++++++++++++++++++>>|
| the PIN number +->| |
| | C1. CONTROL (record name) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | C2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "Please state your name after the beep" |
|<<########################################################|
| | |
|########################################################>>|
| Audio from the UAC is recorded (until timeout or DTMF) |--+ save
|########################################################>>| | in a
| | |<-+ file
| | D1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Store recorded +--| D2. 200 OK |
| file to play | |++++++++++++++++++++++++++++++++>>|
| announcement in +->| |
| conference later | |
| | E1. CONTROL (join UAC & confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ join
| | | | UAC &
| | E2. 200 OK |<-+ confY
| |<+++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| UAC is now included in the mix of the conference |
|<<######################################################>>|
| | |
| | F1. CONTROL (play name on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | F2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| Global announcement: "Simon has joined the conference" |
|<<########################################################|
| | |
| | G1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | G2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
| Store recorded +--| D2. 200 OK |
| file to play | |++++++++++++++++++++++++++++++++>>|
| announcement in +->| |
| conference later | |
| | E1. CONTROL (join UAC & confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ join
| | | | UAC &
| | E2. 200 OK |<-+ confY
| |<+++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| UAC is now included in the mix of the conference |
|<<######################################################>>|
| | |
| | F1. CONTROL (play name on confY) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | F2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| Global announcement: "Simon has joined the conference" |
|<<########################################################|
| | |
| | G1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | G2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 32: Rich Conference Scenario: Framework Transactions
图32：富会议场景：框架事务
As can be deduced from the sequence diagram above, the AS, in its business logic, correlates the results of different transactions, addressed to different packages, to implement a conferencing scenario more complex than the Simple Bridging scenario previously described. The framework transaction steps are as follows:
从上面的序列图可以推断，As在其业务逻辑中，将不同事务的结果关联到不同的包，以实现比前面描述的简单桥接场景更复杂的会议场景。框架事务处理步骤如下所示：
o Since this is a private conference, the UAC is to be presented with a request for a password, in this case a PIN number. To do so, the AS instructs the MS (A1) to collect a series of DTMF digits from the specified UAC (connectionid=UAC). The request includes both a voice message (<prompt>) and the described digit collection context (<collect>). The PIN is assumed to be a
o 由于这是一次私人会议，UAC将收到密码请求，在本例中为PIN码。为此，AS指示MS（A1）从指定的UAC（connectionid=UAC）收集一系列DTMF数字。请求包括语音消息（<prompt>）和所述的数字收集上下文（<collect>）。假设该销是一个销
4-digit number, and so the MS has to collect 4 digits maximum (maxdigits=4). The DTMF digit buffer must be cleared before collecting (cleardigitbuffer=true), and the UAC can use the star key to restart the collection (escapekey=*), e.g., if the UAC is aware that he mistyped any of the digits and wants to start again.
4位数字，因此MS最多必须收集4位数字（maxdigits=4）。在采集之前必须清除DTMF数字缓冲区（cleardigitbuffer=true），UAC可以使用星形键重新启动采集（escapekey=*），例如，如果UAC意识到他输入了任何数字，并希望重新开始。
o The transaction goes on as usual (A2), with the transaction being handled and notification of the dialog start being sent in a 200 OK. After that, the UAC is actually presented with the voice message and is subsequently requested to input the required PIN number.
o 事务照常进行（A2），事务正在处理，对话框开始的通知以200 OK的形式发送。之后，UAC实际上会收到语音消息，并随后被要求输入所需的PIN码。
o We assume that the UAC typed the correct PIN number (1234), which is reported by the MS to the AS by means of the usual MS-generated CONTROL event (B1). The AS correlates this event to the previously started dialog by checking the referenced dialogid (06d1bac) and acks the event (B2). It then extracts the information it needs from the event (in this case, the digits provided by the MS) from the <controlinfo> container (dtmf=1234) and verifies that it is correct.
o 我们假设UAC键入了正确的PIN码（1234），MS通过通常MS生成的控制事件（B1）向AS报告。AS通过检查引用的对话框ID（06d1bac）将此事件与先前启动的对话框关联，并确认事件（B2）。然后，它从<controlinfo>容器（dtmf=1234）中提取事件所需的信息（在本例中，是MS提供的数字），并验证其是否正确。
o Since the PIN is correct, the AS can proceed to the next step, i.e., asking the UAC to state his name, in order to subsequently play the recording on the conference to report the new participant. Again, this is done with a request to the IVR package (C1). The AS instructs the MS to play a voice message ("state your name after the beep"), to be followed by a recording of only the audio from the UAC (in stream, media=audio/sendonly, while media=video/inactive). A beep must be played right before the recording starts (beep=true), and the recording must only last 3 seconds (maxtime=3s), since it is only needed as a brief announcement.
o 由于PIN码是正确的，AS可以进行下一步，即要求UAC说明其姓名，以便随后在会议上播放录音以报告新参与者。同样，这是通过对IVR包（C1）的请求来完成的。AS指示MS播放语音消息（“在嘟嘟声后说明您的姓名”），然后只录制来自UAC的音频（在流中，媒体=音频/仅发送，而媒体=视频/不活动）。必须在录音开始前播放嘟嘟声（嘟嘟声=真），并且录音必须仅持续3秒（maxtime=3s），因为它只需要作为一个简短的通知。
o Without delving again into the details of a recording-related transaction (C2), the AS finally gets the URI of the requested recording (D1, acked in D2).
o 在不再深入研究与录制相关的事务（C2）的细节的情况下，AS最终获得请求录制的URI（D1，在D2中确认）。
o At this point, the AS attaches the UAC (id1) to the conference (id2), just as explained for the Simple Bridging scenario (E1/E2).
o 此时，AS将UAC（id1）连接到会议（id2），正如简单桥接场景（E1/E2）所解释的那样。
o Finally, to notify the other participants that a new participant has arrived, the AS requests a global announcement on the conference. This is a simple <prompt> request to the IVR package (F1), as explained in previous sections (e.g., Section 6.1.2, among others), but with a slight difference: the target of the prompt is not a connectionid (a media connection) but the conference itself (conferenceid=6146dd5). As a result of this transaction, the announcement would be played on all the media
o 最后，为了通知其他参与者新的参与者已经到达，AS请求会议的全球公告。这是对IVR包（F1）的一个简单的<prompt>请求，如前几节所述（如第6.1.2节等），但有一点不同：提示的目标不是连接ID（媒体连接），而是会议本身（conferenceid=6146dd5）。作为交易的结果，该公告将在所有媒体上播放
connections attached to the conference that are allowed to receive media from it. The AS specifically requests that two media files be played:
连接到允许从会议接收媒体的会议。AS特别要求播放两个媒体文件：
1. the media file containing the recorded name of the new user as retrieved in D1 ("Simon...").
1. 包含在D1中检索到的新用户的记录名称的媒体文件（“Simon…”）。
2. a pre-recorded media file explaining what happened ("... has joined the conference").
2. 一个预先录制的媒体文件，解释发生的事情（“…已加入会议”）。
The transaction then follows its usual flow (F2), and the event that sends notification regarding the end of the announcement (G1, acked in G2) concludes the scenario.
然后，事务遵循其通常的流程（F2），发送关于公告结束的通知的事件（G1，在G2中确认）结束场景。
A1. AS -> MS (CFW CONTROL, collect)
-----------------------------------
CFW 50e56b8d65f9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 311
A1. AS -> MS (CFW CONTROL, collect)
-----------------------------------
CFW 50e56b8d65f9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 311
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/prompts/conf-getpin.wav"
type="audio/x-wav"/>
</prompt>
<collect maxdigits="4" escapekey="*" cleardigitbuffer="true"/>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/prompts/conf-getpin.wav"
type="audio/x-wav"/>
</prompt>
<collect maxdigits="4" escapekey="*" cleardigitbuffer="true"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 50e56b8d65f9 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 50e56b8d65f9 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="06d1bac"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="06d1bac"/>
</mscivr>
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 166d68a76659 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 272
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 166d68a76659 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 272
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="06d1bac">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="2312" termmode="completed"/>
<collectinfo dtmf="1234" termmode="match"/>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="06d1bac">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="2312" termmode="completed"/>
<collectinfo dtmf="1234" termmode="match"/>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 166d68a76659 200
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 166d68a76659 200
C1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 61fd484f196e CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 373
C1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 61fd484f196e CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 373
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/prompts/conf-rec-name.wav"
type="audio/x-wav"/>
</prompt>
<record beep="true" maxtime="3s"/>
</dialog>
<stream media="audio" direction="sendonly"/>
<stream media="video" direction="inactive"/>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/prompts/conf-rec-name.wav"
type="audio/x-wav"/>
</prompt>
<record beep="true" maxtime="3s"/>
</dialog>
<stream media="audio" direction="sendonly"/>
<stream media="video" direction="inactive"/>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 61fd484f196e 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 61fd484f196e 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="1cf0549"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="1cf0549"/>
</mscivr>
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 3ec13ab96224 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 402
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 3ec13ab96224 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 402
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="1cf0549">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="4988" termmode="completed"/>
<recordinfo duration="3000" termmode="maxtime">
<mediainfo
loc="http://www.example.net/recordings/recording-1cf0549.wav"
type="audio/x-wav" size="48044"/>
</recordinfo>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="1cf0549">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="4988" termmode="completed"/>
<recordinfo duration="3000" termmode="maxtime">
<mediainfo
loc="http://www.example.net/recordings/recording-1cf0549.wav"
type="audio/x-wav" size="48044"/>
</recordinfo>
</dialogexit>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 3ec13ab96224 200
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 3ec13ab96224 200
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 261d188b63b7 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 261d188b63b7 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="6146dd5"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="6146dd5"/>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 261d188b63b7 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 261d188b63b7 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
F1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 718c30836f38 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 334
F1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 718c30836f38 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 334
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="6146dd5">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-1cf0549.wav"
type="audio/x-wav"/>
<media
loc="http://www.example.net/prompts/conf-hasjoin.wav"
type="audio/x-wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="6146dd5">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-1cf0549.wav"
type="audio/x-wav"/>
<media
loc="http://www.example.net/prompts/conf-hasjoin.wav"
type="audio/x-wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
F2. AS <- MS (CFW 200 OK)
-------------------------
CFW 718c30836f38 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
F2. AS <- MS (CFW 200 OK)
-------------------------
CFW 718c30836f38 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="5f4bc7e"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="5f4bc7e"/>
</mscivr>
G1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 6485194f622f CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
G1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 6485194f622f CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5f4bc7e">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="1838" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5f4bc7e">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="1838" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
G2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 6485194f622f 200
G2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 6485194f622f 200
Another typical conference-based use case is the so-called Coaching scenario. In such a scenario, a customer (called "A" in the following example) places a call to a business call center. An agent (B) is assigned to the customer. A coach (C), who cannot be heard by the customer, provides the agent with whispered suggestions about what to say. This scenario is also described in [RFC4597].
另一个典型的基于会议的用例是所谓的指导场景。在这种情况下，客户（在下面的示例中称为“a”）向业务呼叫中心打电话。为客户分配了一个代理（B）。客户听不见的教练（C）向代理提供关于该说什么的耳语建议。[RFC4597]中也描述了该场景。
As can be deduced from the scenario description, per-user policies for media mixing and delivery, i.e., who can hear what, are very important. The MS must make sure that only the agent can hear the coach's suggestions. Since this is basically a multiparty call (despite what the customer might be thinking), a mixing entity is needed in order to accomplish the scenario requirements. To summarize:
从场景描述可以推断，媒体混合和交付的每个用户策略（即谁能听到什么）非常重要。MS必须确保只有经纪人才能听到教练的建议。由于这基本上是一个多方调用（不管客户可能在想什么），因此需要一个混合实体来完成场景需求。总结如下：
o The customer (A) must only hear what the agent (B) says.
o 客户（A）必须只听到代理（B）所说的话。
o The agent (B) must be able to hear both A and the coach (C).
o 代理人（B）必须能够听到A和教练（C）的声音。
o C must be able to hear both A and B in order to give B the right suggestions and also be aware of the whole conversation.
o C必须能够同时听到A和B的声音，以便给B提供正确的建议，并了解整个对话。
From the media and framework perspective, such a scenario can be seen as depicted in Figure 33.
从媒体和框架的角度来看，这样的场景如图33所示。
************** +-------+
* A=Customer * | UAC |
* B=Agent * | C |
* C=Coach * +-------+
************** " ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B (RTP) +--------+ B (RTP) +-------+
************** +-------+
* A=Customer * | UAC |
* B=Agent * | C |
* C=Coach * +-------+
************** " ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B (RTP) +--------+ B (RTP) +-------+
Figure 33: Coaching Scenario: Media Perspective
图33：辅导场景：媒体视角
From the framework point of view, when the previously mentioned legs are not attached to anything yet, what appears is shown in Figure 34.
从框架的角度来看，当前面提到的支腿还没有连接到任何东西时，显示的内容如图34所示。
MS
+---------------------------+
| |
UAC A | | UAC B
o.....<<.......x x-------<<-----o
o----->>-------x x.......>>.....o
| |
| |
| |
| |
| xx |
| .| +
+------------v^-------------+
v^
.|
.|
oo
UAC C
MS
+---------------------------+
| |
UAC A | | UAC B
o.....<<.......x x-------<<-----o
o----->>-------x x.......>>.....o
| |
| |
| |
| |
| xx |
| .| +
+------------v^-------------+
v^
.|
.|
oo
UAC C
Figure 34: Coaching Scenario: UAC Legs Not Attached
图34：指导场景：未连接UAC支腿
By contrast, what the scenario should look like is depicted in Figure 35. The customer receives media directly from the agent ('recvonly'), while all of the three involved participants contribute to a hidden conference. Of course, the customer is not allowed to
相比之下，场景应该是什么样子如图35所示。客户直接从代理（“recvonly”）接收媒体，而所有三名参与者都参与了一个隐藏的会议。当然，不允许客户这样做
receive the mixed flows from the conference ('sendonly'), unlike the agent and the coach, who must both be aware of the whole conversation ('sendrecv').
接收来自会议的混合流（“sendonly”），与代理和coach不同，代理和coach都必须了解整个对话（“sendrecv”）。
MS
+---------------------------+
| |
UAC A | | UAC B
o-----<<-------+----<<----+----<<----+-------<<-----o
o----->>-------+ | +------->>-----o
| | v ^ |
| +~~~~~~~>[##]::::>::::+ |
| v^ |
| || |
| ++ |
| :| +
+------------v^-------------+
v^
:|
:|
oo
UAC C
MS
+---------------------------+
| |
UAC A | | UAC B
o-----<<-------+----<<----+----<<----+-------<<-----o
o----->>-------+ | +------->>-----o
| | v ^ |
| +~~~~~~~>[##]::::>::::+ |
| v^ |
| || |
| ++ |
| :| +
+------------v^-------------+
v^
:|
:|
oo
UAC C
Figure 35: Coaching Scenario: UAC Legs Mixed and Attached
图35：指导场景：UAC腿混合并连接
In the framework, this can be achieved by means of the Mixer Control Package, which, as demonstrated in the previous conferencing examples, can be exploited whenever mixing and joining entities are needed. The needed steps can be summarized in the following list:
在该框架中，这可以通过Mixer控制包实现，如前面的会议示例所示，只要需要混合和连接实体，就可以利用该控制包。所需步骤可总结在以下列表中：
1. First of all, a hidden conference is created.
1. 首先，创建一个隐藏的会议。
2. Then, the three participants are all attached to it, each with a custom mixing policy, specifically:
2. 然后，三个参与者都附加到它，每个人都有一个自定义的混合策略，具体来说：
* the customer (A) as 'sendonly'.
* 客户（A）应为“仅发送”。
* the agent (B) as 'sendrecv'.
* 代理（B）为“sendrecv”。
* the coach (C) as 'sendrecv' and with a gain of -3 dB to halve the volume of its own contribution (so that the agent actually hears the customer at a louder volume and hears the coach whispering).
* coach（C）被称为“sendrecv”，并以-3 dB的增益将其自身贡献的音量减半（以便代理能够以更大的音量实际听到客户的声音，并听到coach的耳语）。
3. Finally, the customer is joined to the agent as a passive receiver ('recvonly').
3. 最后，客户作为被动接收者（“RecvoOnly”）加入代理。
A diagram of such a sequence of transactions is depicted in Figure 36:
图36中描述了此类事务序列的示意图：
A B C AS MS
| | | | |
| | | | A1. CONTROL (create conference) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ create
| | | | | | conf and
| | | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| | | | B1. CONTROL (join A-->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join A
| | | | | | & confY
| | | | B2. 200 OK |<-+ sendonly
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
|######################################################>>|
| Customer (A) is mixed (sendonly) in the conference |
|######################################################>>|
| | | | |
| | | | C1. CONTROL (join B<->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join B
| | | | | | & confY
| | | | C2. 200 OK |<-+ sendrecv
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| |<<#############################################>>|
| | Agent (B) is mixed (sendrecv) in the conference |
| |<##############################################>>|
| | | | |
| | | | D1. CONTROL (join C<->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join C
| | | | | | & confY
| | | | D2. 200 OK |<-+ sendrecv
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| | |<<######################################>>|
| | | Coach (C) is mixed (sendrecv) as well |
| | |<<######################################>>|
| | | | |
A B C AS MS
| | | | |
| | | | A1. CONTROL (create conference) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ create
| | | | | | conf and
| | | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| | | | B1. CONTROL (join A-->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join A
| | | | | | & confY
| | | | B2. 200 OK |<-+ sendonly
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
|######################################################>>|
| Customer (A) is mixed (sendonly) in the conference |
|######################################################>>|
| | | | |
| | | | C1. CONTROL (join B<->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join B
| | | | | | & confY
| | | | C2. 200 OK |<-+ sendrecv
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| |<<#############################################>>|
| | Agent (B) is mixed (sendrecv) in the conference |
| |<##############################################>>|
| | | | |
| | | | D1. CONTROL (join C<->confY) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join C
| | | | | | & confY
| | | | D2. 200 OK |<-+ sendrecv
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
| | |<<######################################>>|
| | | Coach (C) is mixed (sendrecv) as well |
| | |<<######################################>>|
| | | | |
| | | | E1. CONTROL (join A<--B) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join
| | | | | | A & B
| | | | E2. 200 OK |<-+ recvonly
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
|<<######################################################|
| Finally, Customer (A) is joined (recvonly) to Agent (B)|
|<<######################################################|
| | | | |
. . . . .
. . . . .
| | | | E1. CONTROL (join A<--B) |
| | | |++++++++++++++++++++++++++++++++>>|
| | | | |--+ join
| | | | | | A & B
| | | | E2. 200 OK |<-+ recvonly
| | | |<<++++++++++++++++++++++++++++++++|
| | | | |
|<<######################################################|
| Finally, Customer (A) is joined (recvonly) to Agent (B)|
|<<######################################################|
| | | | |
. . . . .
. . . . .
Figure 36: Coaching Scenario: Framework Transactions
图36：指导场景：框架事务
o First of all, the AS creates a new hidden conference by means of a <createconference> request (A1). This conference is properly configured according to the use it is assigned to, i.e., to mix all the involved parties accordingly. Since only three participants will be joined to it, 'reserved-talkers' is set to 3. 'reserved-listeners', on the other hand, is set to 2, since only the agent and the coach must receive a mix, while the customer must be unaware of the coach. Finally, the video layout is set to <dual-view> for the same reason, since only the customer and the agent must appear in the mix.
o 首先，AS通过<createconference>请求（A1）创建一个新的隐藏会议。该会议根据其分配的用途进行适当配置，即相应地混合所有相关方。因为只有三名参与者将加入，所以“保留谈话者”设置为3另一方面，保留侦听器设置为2，因为只有代理和coach必须接收混音，而客户必须不知道coach。最后，出于同样的原因，视频布局设置为<dual view>，因为只有客户和代理必须出现在混合中。
o The MS sends notification of the successful creation of the new conference in a 200 framework message (A2). The identifier assigned to the conference, which will be used in subsequent requests addressed to it, is 1df080e.
o MS在200框架消息（A2）中发送成功创建新会议的通知。分配给会议的标识符为1df080e，将在随后向其发送的请求中使用。
o Now that the conference has been created, the AS joins the three actors to it with different policies, namely (i) the customer (A) is joined as 'sendonly' to the conference (B1), (ii) the agent (B) is joined as 'sendrecv' to the conference (C1), and (iii) the coach (C) is joined as 'sendrecv' (but audio only) to the conference and with a lower volume (D1). The custom policies are enforced by means of properly constructed <stream> elements.
o 既然会议已经创建，AS以不同的策略将三个参与者加入到会议中，即（i）客户（A）作为会议的“sendonly”（B1）加入，（ii）代理（B）作为会议的“sendrecv”（C1）加入，以及（iii）教练（C）作为“sendrecv”（但仅音频）加入以较低的音量（D1）出席会议。自定义策略通过正确构造的<stream>元素来实施。
o The MS takes care of the requests and acks them (B2, C2, D2). At this point, the conference will receive media from all the actors but only provide the agent and the coach with the resulting mix.
o MS负责处理请求并确认它们（B2、C2、D2）。此时，会议将接收来自所有参与者的媒体，但只向经纪人和教练提供由此产生的组合。
o To complete the scenario, the AS joins A with B directly as 'recvonly' (E1). The aim of this request is to provide A with media too, namely the media contributed by B. This way, A is unaware of the fact that its media are accessed by C by means of the hidden mixer.
o 为了完成该场景，AS将A与B直接连接为“recvonly”（E1）。此请求的目的是向A提供介质，即B提供的介质。这样，A就不知道C通过隐藏混合器访问其介质。
o The MS takes care of this request too and acks it (E2), concluding the scenario.
o MS也会处理该请求并确认它（E2），从而结束该场景。
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 329
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 329
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="3" reserved-listeners="2">
<audio-mixing type="nbest"/>
<video-layouts>
<video-layout min-participants='1'>
<dual-view/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
</createconference>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="3" reserved-listeners="2">
<audio-mixing type="nbest"/>
<video-layouts>
<video-layout min-participants='1'>
<dual-view/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
</createconference>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 238e1f2946e8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 238e1f2946e8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="1df080e"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="1df080e"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 2eb141f241b7 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 226
B1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 2eb141f241b7 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 226
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="1df080e">
<stream media="audio" direction="sendonly"/>
<stream media="video" direction="sendonly"/>
</join>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="1df080e">
<stream media="audio" direction="sendonly"/>
<stream media="video" direction="sendonly"/>
</join>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2eb141f241b7 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2eb141f241b7 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
C1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 122
C1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 122
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="756471213:c52ebf1b" id2="1df080e"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="756471213:c52ebf1b" id2="1df080e"/>
</mscmixer>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
D1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 221
D1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 221
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="z9hG4bK19461552:1353807a" id2="1df080e">
<stream media="audio">
<volume controltype="setgain" value="-3"/>
</stream>
</join>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="z9hG4bK19461552:1353807a" id2="1df080e">
<stream media="audio">
<volume controltype="setgain" value="-3"/>
</stream>
</join>
</mscmixer>
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 236
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 236
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="756471213:c52ebf1b">
<stream media="audio" direction="recvonly"/>
<stream media="video" direction="recvonly"/>
</join>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="756471213:c52ebf1b">
<stream media="audio" direction="recvonly"/>
<stream media="video" direction="recvonly"/>
</join>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
Within the context of conferencing, there could be a need for so-called sidebars, or side conferences. This would be the case, for instance, if two or more participants of a conference were willing to create a side conference among each other while still receiving part of the original conference mix in the background. Motivations for such a use case can be found in both [RFC4597] and [RFC5239]. It is clear that in such a case the side conference is actually a separate conference but must also somehow be related to the original conference. Although the application-level relationship is out of scope for this document (this "belongs" to Centralized Conferencing (XCON)), the media stream relationship is more relevant here, because there is a stronger relationship at the media level from the MEDIACTRL point of view. Consequently, it is interesting to analyze how sidebars could be used to construct the conference mixes according to the MEDIACTRL specification.
在会议环境中，可能需要所谓的侧栏或侧边会议。例如，如果一次会议的两个或两个以上参与者愿意在彼此之间创建一个旁听会议，同时仍在后台接收原始会议组合的一部分，则会出现这种情况。这种用例的动机可以在[RFC4597]和[RFC5239]中找到。显然，在这种情况下，会外会议实际上是一个单独的会议，但也必须以某种方式与原始会议相关。尽管应用程序级别的关系超出了本文档的范围（此“属于”集中式会议（XCON）），但媒体流关系在此处更为相关，因为从MEDIACTRL的角度来看，媒体级别的关系更强。因此，分析如何根据MEDIACTRL规范使用边栏构建会议混音是一件有趣的事情。
The scenario presented in this section is a conference hosting four different participants: A, B, C, and D. All these participants are attached to the conference as active senders and receivers of the existing media streams. At a certain point in time, two participants
本节介绍的场景是一个会议，它承载四个不同的参与者：a、B、C和D。所有这些参与者都作为现有媒体流的活动发送方和接收方连接到会议。在某个时间点，两名参与者
(B and D) decide to create a sidebar just for them. The sidebar they want to create is constructed so that only audio is involved. The audio mix of the sidebar must not be made available to the main conference. The mix of the conference must be attached to the sidebar, but with a lower volume (30%), because it is just background to the actual conversation. This would allow both B and D to talk to each other without A and C listening to them, while B and D could still have an overview of what's happening in the main conference.
（B和D）决定为他们创建一个侧栏。他们想要创建的侧边栏的构造只涉及音频。侧边栏的音频混音不能提供给主会议。会议的组合必须附在侧边栏上，但音量要小一些（30%），因为它只是实际对话的背景。这将允许B和D在没有A和C听的情况下彼此交谈，而B和D仍然可以大致了解主要会议中发生的事情。
From the media and framework perspective, such a scenario can be seen as depicted in Figure 37.
从媒体和框架的角度来看，这样的场景如图37所示。
+-------+
| UAC |
| C |
+-------+
" ^
C (RTP) " "
" "
" " A (RTP)
v "
+-------+ A (RTP) +--------+ D+[a+c] (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ C (RTP) +--------+ B (RTP) +-------+
^ "
" " B+[a+c] (RTP)
" "
D (RTP) " "
" v
+-------+
| UAC |
| D |
+-------+
+-------+
| UAC |
| C |
+-------+
" ^
C (RTP) " "
" "
" " A (RTP)
v "
+-------+ A (RTP) +--------+ D+[a+c] (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ C (RTP) +--------+ B (RTP) +-------+
^ "
" " B+[a+c] (RTP)
" "
D (RTP) " "
" v
+-------+
| UAC |
| D |
+-------+
Figure 37: Sidebars: Media Perspective
图37：侧栏：媒体透视图
From the framework point of view, when all the participants are attached to the main conference, what appears is shown in Figure 38.
从框架的角度来看，当所有参与者都连接到主会议时，出现的内容如图38所示。
UAC C
oo
:|
^v
^v
:|
+--------:|-------+
| :| |
| ++ |
UAC A | ^| | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC D
UAC C
oo
:|
^v
^v
:|
+--------:|-------+
| :| |
| ++ |
UAC A | ^| | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC D
Figure 38: Sidebars: UAC Legs in Main Conference
图38：侧栏：主会议中的UAC支腿
By contrast, what the scenario should look like is depicted in Figure 39. A new mixer is created to host the sidebar. The main mix is then attached as 'sendonly' to the sidebar mix at a lower volume (in order to provide the sidebar users with a background of the main conference). The two interested participants (B and D) have their audio leg detached from the main conference and attached to the sidebar. This detachment can be achieved by either actually detaching the leg or just modifying the status of the leg to 'inactive'. Note that this only affects the audio stream: the video of the two users is still attached to the main conference, and what happens at the application level may or may not have been changed accordingly (e.g., XCON protocol interactions).
相比之下，场景应该是什么样子如图39所示。将创建一个新的混合器来承载侧栏。然后将主混音作为“sendonly”以较低的音量附加到边栏混音中（以便为边栏用户提供主会议的背景）。两个感兴趣的参与者（B和D）将他们的音频腿从主会议中分离出来，并连接到侧边栏。这种分离可以通过实际分离支腿或仅将支腿的状态修改为“非活动”来实现。请注意，这只会影响音频流：两个用户的视频仍然连接到主会议，并且在应用程序级别发生的事情可能会也可能不会相应地发生更改（例如，XCON协议交互）。
Please note that the main conference is assumed to be in place and the involved participants (A, B, C, and D) attached ('sendrecv') to it.
请注意，假设主要会议已召开，相关参与者（A、B、C和D）附在会议上（“sendrecv”）。
UAC C
oo
:|
^v
^v
:|
+--------:|----------------+
| :| |
| ++ |
UAC A | ^| | UAC B
o----->>-------+~~~>{##}:::>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##} {##}<~~~+-------<<-----o
| ^: |
| ++ |
| |v |
+----------------|:--------+
|:
^v
^v
|:
oo
UAC D
UAC C
oo
:|
^v
^v
:|
+--------:|----------------+
| :| |
| ++ |
UAC A | ^| | UAC B
o----->>-------+~~~>{##}:::>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##} {##}<~~~+-------<<-----o
| ^: |
| ++ |
| |v |
+----------------|:--------+
|:
^v
^v
|:
oo
UAC D
Figure 39: Sidebars: UAC Legs Mixed and Attached
图39：侧栏：UAC支腿混合并连接
The situation may subsequently be reverted (e.g., destroying the sidebar conference and reattaching B and D to the main conference mix) in the same way. The AS would just need to unjoin B and D from the hidden conference and change their connection with the main conference back to 'sendrecv'. After unjoining the main mix and the sidebar mix, the sidebar conference could then be destroyed. For brevity, and because similar transactions have already been presented, these steps are not described here.
随后可能会以相同的方式恢复这种情况（例如，销毁侧栏会议并将B和D重新连接到主会议组合）。AS只需将B和D从隐藏会议中取消连接，并将它们与主会议的连接更改回“sendrecv”。在取消主混合和侧边栏混合后，侧边栏会议可能会被销毁。为了简洁起见，并且由于已经介绍了类似的事务，这里不描述这些步骤。
In the framework, just as in the previous section, the presented scenario can again be achieved by means of the Mixer Control Package. The needed steps can be summarized in the following list:
在该框架中，与前一节一样，可以通过Mixer控制包再次实现所呈现的场景。所需步骤可总结在以下列表中：
1. First of all, a hidden conference is created (the sidebar mix).
1. 首先，创建一个隐藏的会议（边栏混合）。
2. Then, the main conference mix is attached to it as 'sendonly' and with a gain of -5 dB to limit the volume of its own contribution to 30% (so that B and D can hear each other at a louder volume while still listening to what's happening in the main conference in the background).
2. 然后，主会议混音作为“sendonly”附加到它上，增益为-5 dB，以将其自身贡献的音量限制在30%（以便B和D能够以更大的音量听到对方，同时仍能在后台收听主会议中发生的事情）。
3. B and D are detached from the main mix for audio (<modifyjoin> with 'inactive' status).
3. B和D与音频主混音分离（<modifyjoin>处于“非活动”状态）。
4. B and D are attached to the hidden sidebar mix for audio.
4. B和D连接到隐藏的侧边栏混音，用于音频。
Note that for detaching B and D from the main mix, a <modifyjoin> with an 'inactive' status is used, instead of an <unjoin>. The motivation for this is related to how a subsequent rejoining of B and D to the main mix could take place. In fact, by using <modifyjoin> the resources created when first joining B and D to the main mix remain in place, even if marked as unused at the moment. An <unjoin>, on the other hand, would actually free those resources, which in turn could be granted to other participants joining the conference in the meantime. This means that when needing to reattach B and D to the main mix, the MS may not have the resources to do so, resulting in an undesired failure.
请注意，要从主混音中分离B和D，将使用具有“非活动”状态的<modifyjoin>，而不是<unjoin>。其动机与B和D随后如何重新加入主混合物有关。事实上，通过使用<modifyjoin>，在首次将B和D加入主混合时创建的资源保持不变，即使此时标记为未使用。另一方面，<unjoin>实际上可以释放这些资源，而这些资源又可以授予同时参加会议的其他与会者。这意味着当需要将B和D重新连接到主混合时，MS可能没有这样做的资源，从而导致意外故障。
A diagram of such a sequence of transactions (where confX is the identifier of the pre-existing main conference mix) is depicted in Figure 40:
图40中描述了此类事务序列图（其中confX是预先存在的主会议组合的标识符）：
B D AS MS
| | | |
| | | A1. CONTROL (create conference) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ create
| | | | | conf and
| | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | B1. CONTROL (join confX-->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join confX
| | | | | & confY
| | | B2. 200 OK |<-+ sendonly
| | |<<++++++++++++++++++++++++++++++++| (30% vol)
| | | |
| | | C1. CONTROL (modjoin B---confX) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modjoin B
| | | | | & confX
| | | C2. 200 OK |<-+ (inactive)
| | |<<++++++++++++++++++++++++++++++++|
| | | |
B D AS MS
| | | |
| | | A1. CONTROL (create conference) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ create
| | | | | conf and
| | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | B1. CONTROL (join confX-->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join confX
| | | | | & confY
| | | B2. 200 OK |<-+ sendonly
| | |<<++++++++++++++++++++++++++++++++| (30% vol)
| | | |
| | | C1. CONTROL (modjoin B---confX) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modjoin B
| | | | | & confX
| | | C2. 200 OK |<-+ (inactive)
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | D1. CONTROL (join B<-->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join B
| | | | | & confY
| | | D2. 200 OK |<-+ sendrecv
| | |<<++++++++++++++++++++++++++++++++| (audio)
| | | |
|<<##################################################>>|
| Participant B is mixed (sendrecv) in the sidebar |
| (A, C, and D can't listen to her/him anymore) |
|<<##################################################>>|
| | | |
| | | E1. CONTROL (modjoin D---confX) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modjoin D
| | | | | & confX
| | | E2. 200 OK |<-+ (inactive)
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | F1. CONTROL (join D<-->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join D
| | | | | & confY
| | | F2. 200 OK |<-+ sendrecv
| | |<<++++++++++++++++++++++++++++++++| (audio)
| | | |
| |<<########################################>>|
| | D is mixed (sendrecv) in the sidebar too |
| | (A and C can't listen to her/him anymore) |
| |<<########################################>>|
| | |
. . .
. . .
| | | D1. CONTROL (join B<-->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join B
| | | | | & confY
| | | D2. 200 OK |<-+ sendrecv
| | |<<++++++++++++++++++++++++++++++++| (audio)
| | | |
|<<##################################################>>|
| Participant B is mixed (sendrecv) in the sidebar |
| (A, C, and D can't listen to her/him anymore) |
|<<##################################################>>|
| | | |
| | | E1. CONTROL (modjoin D---confX) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modjoin D
| | | | | & confX
| | | E2. 200 OK |<-+ (inactive)
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | F1. CONTROL (join D<-->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join D
| | | | | & confY
| | | F2. 200 OK |<-+ sendrecv
| | |<<++++++++++++++++++++++++++++++++| (audio)
| | | |
| |<<########################################>>|
| | D is mixed (sendrecv) in the sidebar too |
| | (A and C can't listen to her/him anymore) |
| |<<########################################>>|
| | |
. . .
. . .
Figure 40: Sidebars: Framework Transactions
图40：侧栏：框架事务
o First of all, the hidden conference mix is created (A1). The request is basically the same as that presented in previous sections, i.e., a <createconference> request addressed to the Mixer package. The request is very lightweight and asks the MS to only reserve two listener seats ('reserved-listeners', since only B and D have to hear something) and three talker seats ('reserved-listeners', because in addition to B and D the main mix is also an active contributor to the sidebar). The mixing will be driven by directives from the AS (mix-type=controller). When the mix is successfully created, the MS provides the AS with its identifier (519c1b9).
o 首先，创建隐藏的会议组合（A1）。该请求基本上与前几节中的请求相同，即发往混音器包的<createconference>请求。该请求非常轻量级，要求MS只保留两个听众席（“保留的听众席”，因为只有B和D必须听到一些东西）和三个说话者席（“保留的听众席”，因为除了B和D之外，主混音也是侧边栏的积极参与者）。混合将由AS的指令驱动（混合类型=控制器）。成功创建混合后，MS向AS提供其标识符（519c1b9）。
o As a first transaction after that, the AS joins the audio from the main conference and the newly created sidebar conference mix (B1). Only audio needs to be joined (media=audio), with a 'sendonly' direction (i.e., only flowing from the main conference to the sidebar and not vice versa) and at 30% volume with respect to the original stream (setgain=-5 dB). A successful completion of the transaction is reported to the AS (B2).
o 作为之后的第一个事务，As加入来自主会议和新创建的侧栏会议组合（B1）的音频。只有音频需要加入（媒体=音频），具有“sendonly”方向（即，仅从主会议流向侧边栏，而不是从主会议流向侧边栏），音量为原始流的30%（设置增益=-5 dB）。向AS（B2）报告交易的成功完成。
o At this point, the AS makes the connection of B (2133178233: 18294826) and the main conference (2f5ad43) inactive by means of a <modifyjoin> directive (C1). The request is taken care of by the MS (C2), and B is actually excluded from the mix for sending as well as receiving.
o 此时，AS通过<modifyjoin>指令（C1）使B（2133178233:18294826）和主会议（2f5ad43）的连接处于非活动状态。请求由MS（C2）处理，B实际上被排除在发送和接收的混合中。
o After that, the AS (D1) joins B (2133178233:18294826) to the sidebar mix created previously (519c1b9). The MS attaches the requested connections and sends confirmation to the AS (D2).
o 之后，AS（D1）将B（2133178233:18294826）连接到先前创建的边栏混合（519c1b9）。MS连接请求的连接并向AS（D2）发送确认。
o The same transactions already done for B are done for D as well (id1=1264755310:2beeae5b), i.e., the <modifyjoin> to make the connection in the main conference inactive (E1-2) and the <join> to attach D to the sidebar mix (F1-2). At the end of these transactions, A and C will only listen to each other, while B and D will listen to each other and to the conference mix as a comfortable background.
o 已经为B完成的相同事务也为D完成（id1=1264755310:2beeae5b），即<modifyjoin>使主会议中的连接处于非活动状态（E1-2），以及<join>将D附加到边栏组合（F1-2）。在这些事务结束时，A和C将只听取对方的意见，而B和D将听取对方的意见，并将会议混音作为舒适的背景。
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 198
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 198
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="3" reserved-listeners="2">
<audio-mixing type="controller"/>
</createconference>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="3" reserved-listeners="2">
<audio-mixing type="controller"/>
</createconference>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7fdcc2331bef 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7fdcc2331bef 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="519c1b9"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="519c1b9"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL, join with setgain)
---------------------------------------------
CFW 4e6afb6625e4 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 226
B1. AS -> MS (CFW CONTROL, join with setgain)
---------------------------------------------
CFW 4e6afb6625e4 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 226
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="2f5ad43" id2="519c1b9">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-5"/>
</stream>
</join>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="2f5ad43" id2="519c1b9">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-5"/>
</stream>
</join>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 4e6afb6625e4 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 4e6afb6625e4 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
C1. AS -> MS (CFW CONTROL, modifyjoin with 'inactive' status)
-----------------------------------------------------------
CFW 3f2dba317c83 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 193
C1. AS -> MS (CFW CONTROL, modifyjoin with 'inactive' status)
-----------------------------------------------------------
CFW 3f2dba317c83 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 193
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="2133178233:18294826" id2="2f5ad43">
<stream media="audio" direction="inactive"/>
</modifyjoin>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="2133178233:18294826" id2="2f5ad43">
<stream media="audio" direction="inactive"/>
</modifyjoin>
</mscmixer>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3f2dba317c83 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3f2dba317c83 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
D1. AS -> MS (CFW CONTROL, join to sidebar)
-------------------------------------------
CFW 2443a8582d1d CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 181
D1. AS -> MS (CFW CONTROL, join to sidebar)
-------------------------------------------
CFW 2443a8582d1d CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 181
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="2133178233:18294826" id2="519c1b9">
<stream media="audio" direction="sendrecv"/>
</join>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="2133178233:18294826" id2="519c1b9">
<stream media="audio" direction="sendrecv"/>
</join>
</mscmixer>
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2443a8582d1d 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2443a8582d1d 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
E1. AS -> MS (CFW CONTROL, modifyjoin with 'inactive' status)
-----------------------------------------------------------
CFW 436c6125628c CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 193
E1. AS -> MS (CFW CONTROL, modifyjoin with 'inactive' status)
-----------------------------------------------------------
CFW 436c6125628c CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 193
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1264755310:2beeae5b" id2="2f5ad43">
<stream media="audio" direction="inactive"/>
</modifyjoin>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1264755310:2beeae5b" id2="2f5ad43">
<stream media="audio" direction="inactive"/>
</modifyjoin>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 436c6125628c 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 436c6125628c 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
F1. AS -> MS (CFW CONTROL, join to sidebar)
-------------------------------------------
CFW 7b7ed00665dd CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 181
F1. AS -> MS (CFW CONTROL, join to sidebar)
-------------------------------------------
CFW 7b7ed00665dd CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 181
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1264755310:2beeae5b" id2="519c1b9">
<stream media="audio" direction="sendrecv"/>
</join>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1264755310:2beeae5b" id2="519c1b9">
<stream media="audio" direction="sendrecv"/>
</join>
</mscmixer>
F2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7b7ed00665dd 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
F2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7b7ed00665dd 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
As described in [RFC4597], floor control is a feature typically needed and employed in most conference scenarios. In fact, while not a mandatory feature to implement when realizing a conferencing application, it provides additional control of the media streams contributed by participants, thus allowing for moderation of the available resources. The Centralized Conferencing (XCON) framework [RFC5239] suggests the use of the Binary Floor Control Protocol (BFCP) [RFC4582] to achieve the aforementioned functionality. That said, a combined use of floor control functionality and the tools made available by the MEDIACTRL specification for conferencing would definitely be interesting to investigate. [RFC5567] introduces two different approaches to integrating floor control with the MEDIACTRL architecture: (i) a topology where the floor control server is co-located with the AS and (ii) a topology where the floor control server is co-located with the MS. The two approaches are obviously different with respect to the amount of information the AS and the MS have to deal with, especially when thinking about the logic behind the floor queues and automated decisions. Nevertheless, considering how the Media Control Channel Framework is conceived, approach (ii) would need a dedicated package (be it an extension or a totally new package) in order to make the MS aware of floor control and allow the
如[RFC4597]所述，楼层控制是大多数会议场景中通常需要和使用的功能。事实上，虽然在实现会议应用程序时不是必须实现的功能，但它提供了对参与者贡献的媒体流的额外控制，从而允许对可用资源进行调节。集中式会议（XCON）框架[RFC5239]建议使用二进制楼层控制协议（BFCP）[RFC4582]来实现上述功能。也就是说，将楼层控制功能和MEDIACTRL会议规范提供的工具结合使用肯定是一个值得研究的问题。[RFC5567]介绍了将地板控制与MEDIACTRL体系结构集成的两种不同方法：（i）地板控制服务器与AS共存的拓扑结构；（ii）楼层控制服务器与MS位于同一位置的拓扑结构。这两种方法在AS和MS必须处理的信息量方面明显不同，特别是在考虑楼层队列和自动决策背后的逻辑时。然而，考虑到媒体控制渠道框架是如何构思的，方法（ii）需要一个专用包（无论是扩展包还是全新包），以使MS了解楼层控制并允许
MS to interact with the interested UAC accordingly. At the time of writing, such a package doesn't exist yet, and as a consequence only approach (i) will be dealt with in the presented scenario.
MS将相应地与感兴趣的UAC进行交互。在编写本文时，这样一个包还不存在，因此，在所呈现的场景中只处理方法（i）。
The scenario will then assume that the Floor Control Server (FCS) is co-located with the AS. This means that all the BFCP requests will be sent by Floor Control Participants (FCPs) to the FCS, which will make the AS directly aware of the floor statuses. For the sake of simplicity, the scenario assumes that the involved participants are already aware of all the identifiers needed in order to make BFCP requests for a specific conference. Such information may have been carried according to the COMEDIA negotiation as specified in [RFC4583]. It is important to note that such information must not reach the MS. This means that within the context of the 3PCC mechanism that may have been used in order to attach a UAC to the MS, all the BFCP-related information negotiated by the AS and the UAC must be removed before making the negotiation available to the MS, which may be unable to understand the specification. A simplified example of how this could be achieved is presented in Figure 41. Please note that within the context of this example scenario, different identifiers may be used to address the same entity. Specifically, in this case the UAC (the endpoint sending and receiving media) is also a FCP, as it negotiates a BFCP channel too.
然后，该场景将假定楼层控制服务器（FCS）与AS位于同一位置。这意味着所有BFCP请求将由楼层控制参与者（FCP）发送至FCS，FCS将使AS直接了解楼层状态。为了简单起见，该场景假设相关参与者已经知道为特定会议发出BFCP请求所需的所有标识符。此类信息可能已根据[RFC4583]中规定的喜剧谈判进行。需要注意的是，此类信息不得送达MS。这意味着在可能用于将UAC连接到MS的3PCC机制的上下文中，AS和UAC协商的所有BFCP相关信息必须在向MS提供协商之前移除，可能无法理解规范。图41给出了如何实现这一点的简化示例。请注意，在本示例场景的上下文中，可以使用不同的标识符来寻址同一实体。具体来说，在这种情况下，UAC（端点发送和接收媒体）也是FCP，因为它也协商BFCP信道。
UAC AS
(FCP) (FCS) MS
| | |
| INVITE (SDP: RTP+BFCP) | |
|-------------------------------->| |
| | INVITE (SDP: RTP) |
| |-------------------------------->|
| | 200 (SDP: RTP'+labels) |
| |<--------------------------------|
| match +--| |
| floors | | |
| & labels +->| |
| | |
| 200 (SDP: RTP'+BFCP'+labels) | |
|<--------------------------------| |
| ACK | |
|-------------------------------->| |
| | ACK |
| |-------------------------------->|
| | |
|<<###################### RTP MEDIA STREAMS ######################>>|
| | |
|<<******** BFCP CHANNEL *******>>| |
| | |
. . .
. . .
UAC AS
(FCP) (FCS) MS
| | |
| INVITE (SDP: RTP+BFCP) | |
|-------------------------------->| |
| | INVITE (SDP: RTP) |
| |-------------------------------->|
| | 200 (SDP: RTP'+labels) |
| |<--------------------------------|
| match +--| |
| floors | | |
| & labels +->| |
| | |
| 200 (SDP: RTP'+BFCP'+labels) | |
|<--------------------------------| |
| ACK | |
|-------------------------------->| |
| | ACK |
| |-------------------------------->|
| | |
|<<###################### RTP MEDIA STREAMS ######################>>|
| | |
|<<******** BFCP CHANNEL *******>>| |
| | |
. . .
. . .
Figure 41: Floor Control: Example of Negotiation
图41：楼层控制：协商示例
From the media and framework perspective, such a scenario doesn't differ much from the conferencing scenarios presented earlier. It is more interesting to focus on the chosen topology for the scenario, as depicted in Figure 42.
从媒体和框架的角度来看，这样的场景与前面介绍的会议场景没有太大区别。更有趣的是，将重点放在为场景选择的拓扑上，如图42所示。
+-------+ +--------+
| UAC | | AS | +-------+
| (FCP) |<****** BFCP ******>| (FCS) |<****** BFCP *******>| (FCC) |
+-------+ +--------+ +-------+
^ ^
| |
| CFW |
| |
| v
| +--------+
+----------RTP---------->| MS |
+--------+
+-------+ +--------+
| UAC | | AS | +-------+
| (FCP) |<****** BFCP ******>| (FCS) |<****** BFCP *******>| (FCC) |
+-------+ +--------+ +-------+
^ ^
| |
| CFW |
| |
| v
| +--------+
+----------RTP---------->| MS |
+--------+
Figure 42: Floor Control: Overall Perspective
图42：地板控制：整体透视图
The AS, besides maintaining the already-known SIP signaling among the involved parties, also acts as the FCS for the participants in the conferences for which it is responsible. In the scenario, two Floor Control Participants are involved: a basic Participant (FCP) and a Chair (FCC).
AS除了维护相关方之间已知的SIP信令外，还充当其负责的会议参与者的FCS。在该场景中，涉及两个楼层控制参与者：一个基本参与者（FCP）和一个主席（FCC）。
As in all of the previously described conferencing examples, in the framework this can be achieved by means of the Mixer Control Package. Assuming that the conference has been created, the participant has been attached ('recvonly') to it, and the participant is aware of the involved BFCP identifiers, the needed steps can be summarized in the following list:
与前面描述的所有会议示例一样，在框架中，这可以通过混音器控制包实现。假设会议已创建，参与者已附加（“recvonly”）到会议上，并且参与者知道所涉及的BFCP标识符，所需步骤可总结在以下列表中：
1. The assigned chair, FCC, sends a subscription for events related to the floor for which it is responsible (FloorQuery).
1. 指定的主席FCC发送与其负责的楼层相关的活动订阅（FloorQuery）。
2. The FCP sends a BFCP request (FloorRequest) to access the audio resource ("I want to speak").
2. FCP发送BFCP请求（FloorRequest）以访问音频资源（“我想说话”）。
3. The FCS (AS) sends a provisional response to the FCP (FloorRequestStatus PENDING) and handles the request in its queue. Since a chair is assigned to this floor, the request is forwarded to the FCC for a decision (FloorStatus).
3. FCS（AS）向FCP（FloorRequestStatus PENDING）发送临时响应，并在其队列中处理请求。由于该楼层分配了一名主席，因此请求被转发给FCC以供决定（FloorStatus）。
4. The FCC makes a decision and sends it to the FCS (ChairAction ACCEPTED).
4. FCC做出决策并将其发送给FCS（已接受行动）。
5. The FCS takes note of the decision and updates the queue accordingly. The decision is sent to the FCP (FloorRequestStatus ACCEPTED). The floor has not been granted yet.
5. FCS注意到该决定，并相应地更新队列。决策将发送给FCP（FloorRequestStatus已接受）。发言权尚未获得批准。
6. As soon as the queue allows it, the floor is actually granted to the FCP. The AS, which is co-located with the FCS, understands in its business logic that such an event is associated with the audio resource being granted to the FCP. As a consequence, a <modifyjoin> ('sendrecv') is sent through the Control Channel to the MS in order to unmute the FCP UAC in the conference.
6. 只要队列允许，地板实际上被授予FCP。AS与FCS位于同一地点，在其业务逻辑中理解此类事件与授予FCP的音频资源相关。因此，<modifyjoin>（'sendrecv'）通过控制信道发送到MS，以便在会议中解除FCP UAC的静音。
7. The FCP is notified of this event (FloorRequestStatus GRANTED), thus ending the scenario.
7. FCP将收到此事件的通知（FloorRequestStatus已授予），从而结束场景。
A diagram of such a sequence of transactions (also involving the BFCP message flow at a higher level) is depicted in Figure 43:
图43中描述了此类事务序列图（也涉及更高级别的BFCP消息流）：
UAC1 UAC2 AS
(FCP) (FCC) (FCS) MS
| | | |
|<<####################################################|
| UAC1 is muted (recvonly stream) in the conference |
|<<####################################################|
| | | |
| | FloorQuery |
| |*******>>| |
| | |--+ handle |
| | | | subscription |
| | |<-+ |
| | FloorStatus |
| |<<*******| |
| | | |
| FloorRequest | |
|*****************>>| |
| | |--+ handle |
| | | | request |
| Pending |<-+ (queue) |
|<<*****************| |
| | | |
| | FloorStatus |
| |<<*******| |
| | | |
| | ChairAction (ACCEPT) |
UAC1 UAC2 AS
(FCP) (FCC) (FCS) MS
| | | |
|<<####################################################|
| UAC1 is muted (recvonly stream) in the conference |
|<<####################################################|
| | | |
| | FloorQuery |
| |*******>>| |
| | |--+ handle |
| | | | subscription |
| | |<-+ |
| | FloorStatus |
| |<<*******| |
| | | |
| FloorRequest | |
|*****************>>| |
| | |--+ handle |
| | | | request |
| Pending |<-+ (queue) |
|<<*****************| |
| | | |
| | FloorStatus |
| |<<*******| |
| | | |
| | ChairAction (ACCEPT) |
| |*******>>| |
| | ChairActionAck |
| |<<*******| |
| | |--+ handle |
| | | | decision |
| | |<-+ (queue) |
| Accepted | |
|<<*****************| |
| | FloorStatus |
| |<<*******| |
| | | |
| | |--+ queue |
| | | | grants |
| | |<-+ floor |
| | | |
| | | 1. CONTROL (modjoin UAC<->conf) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modjoin
| | | | | UAC & conf
| | | 2. 200 OK |<-+ (sendrecv)
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<##################################################>>|
| UAC1 is now unmuted (sendrecv) in the conference |
| and can speak, contributing to the mix |
|<<##################################################>>|
| | | |
| Granted | |
|<<*****************| |
| | FloorStatus |
| |<<*******| |
| | | |
. . .
. . .
| |*******>>| |
| | ChairActionAck |
| |<<*******| |
| | |--+ handle |
| | | | decision |
| | |<-+ (queue) |
| Accepted | |
|<<*****************| |
| | FloorStatus |
| |<<*******| |
| | | |
| | |--+ queue |
| | | | grants |
| | |<-+ floor |
| | | |
| | | 1. CONTROL (modjoin UAC<->conf) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modjoin
| | | | | UAC & conf
| | | 2. 200 OK |<-+ (sendrecv)
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<##################################################>>|
| UAC1 is now unmuted (sendrecv) in the conference |
| and can speak, contributing to the mix |
|<<##################################################>>|
| | | |
| Granted | |
|<<*****************| |
| | FloorStatus |
| |<<*******| |
| | | |
. . .
. . .
Figure 43: Floor Control: Framework Transactions
图43：楼层控制：框架事务
As can easily be deduced from the above diagram, the complex interaction at the BFCP level only results in a single transaction at the MEDIACTRL level. In fact, the purpose of the BFCP transactions is to moderate access to the audio resource, which means providing the event trigger to MEDIACTRL-based conference manipulation
从上图可以很容易地推断，BFCP级别的复杂交互只会导致MEDIACTRL级别的单个事务。事实上，BFCP事务的目的是缓和对音频资源的访问，这意味着向基于MEDIACTRL的会议操纵提供事件触发器
transactions. Before being granted the floor, the FCP UAC is excluded from the conference mix at the MEDIACTRL level ('recvonly'). As soon as the floor has been granted, the FCP UAC is included in the mix. In MEDIACTRL words:
交易。在获得发言权之前，FCP UAC被排除在MEDIACTRL级别的会议组合之外（“RecvoOnly”）。一旦批准最低限额，FCP UAC即包含在混合料中。换句话说：
o Since the FCP UAC must be included in the audio mix, a <modifyjoin> is sent to the MS in a CONTROL directive. The <modifyjoin> has as identifiers the connectionid associated with the FCP UAC (e1e1427c:1c998d22) and the conferenceid of the mix (cf45ee2). The <stream> element tells the MS that the audio media stream between the two must become bidirectional ('sendrecv'), changing the previous status ('recvonly'). Please note that in this case only audio was involved in the conference; if video were involved as well, and video had to be unchanged, a <stream> directive for video had to be placed in the request as well in order to maintain its current status.
o 由于FCP UAC必须包含在音频混音中，因此在控制指令中将<modifyjoin>发送给MS。<modifyjoin>将与FCP UAC（e1e1427c:1c998d22）关联的connectionid和混合的conferenceid（cf45ee2）作为标识符。<stream>元素告诉MS两者之间的音频媒体流必须是双向的（'sendrecv'），从而改变先前的状态（'recvonly'）。请注意，在这种情况下，会议仅涉及音频；如果还涉及视频，并且视频必须保持不变，那么请求中也必须放置视频的<stream>指令以保持其当前状态。
1. AS -> MS (CFW CONTROL) ------------------------- CFW gh67ffg56w21 CONTROL Control-Package: msc-mixer/1.0 Content-Type: application/msc-mixer+xml Content-Length: 182
1. AS->MS（CFW控制）-------------CFW gh67ffg56w21控制包：msc mixer/1.0内容类型：application/msc mixer+xml内容长度：182
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="e1e1427c:1c998d22" id2="cf45ee2">
<stream media="audio" direction="sendrecv"/>
</modifyjoin>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="e1e1427c:1c998d22" id2="cf45ee2">
<stream media="audio" direction="sendrecv"/>
</modifyjoin>
</mscmixer>
2. AS <- MS (CFW 200 OK) ------------------------ CFW gh67ffg56w21 200 Timeout: 10 Content-Type: application/msc-mixer+xml Content-Length: 123
2. AS<-MS（CFW 200正常）---------------------------CFW gh67ffg56w21 200超时：10内容类型：应用程序/msc混合器+xml内容长度：123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
This section includes additional scenarios that can be of interest when dealing with AS<->MS flows. The aim of the following subsections is to present the use of features peculiar to the IVR package: specifically, variable announcements, VCR (video cassette
本节包括处理AS<->MS流时可能感兴趣的其他场景。以下小节的目的是介绍IVR软件包特有功能的使用：特别是可变公告、VCR（盒式录像带
recorder) prompts, parallel playback, recurring dialogs, and custom grammars. To describe how call flows involving such features might happen, three sample scenarios have been chosen:
录音机）提示、并行播放、循环对话框和自定义语法。为了描述涉及这些功能的调用流可能如何发生，我们选择了三个示例场景：
1. Voice Mail (variable announcements for digits, VCR controls).
1. 语音邮件（数字、VCR控件的可变通知）。
2. Current Time (variable announcements for date and time, parallel playback).
2. 当前时间（日期和时间的可变公告，并行播放）。
3. DTMF-driven Conference Manipulation (recurring dialogs, custom grammars).
3. DTMF驱动的会议操作（循环对话框、自定义语法）。
An application that typically uses the services an MS can provide is Voice Mail. In fact, while it is clear that many of its features are part of the application logic (e.g., the mapping of a URI with a specific user's voice mailbox, the list of messages and their properties, and so on), the actual media work is accomplished through the MS. Features needed by a Voice Mail application include the ability to record a stream and play it back at a later time, give verbose announcements regarding the status of the application, control the playout of recorded messages by means of VCR controls, and so on. These features are all supported by the MS through the IVR package.
通常使用MS可以提供的服务的应用程序是语音邮件。事实上，虽然它的许多特性显然是应用程序逻辑的一部分（例如，URI与特定用户的语音邮箱、消息列表及其属性的映射，等等），实际的媒体工作是通过MS完成的。语音邮件应用程序所需的功能包括录制流并在以后播放流的能力，提供有关应用程序状态的详细通知，通过VCR控件控制录制消息的播放，等等。MS通过IVR包支持所有这些功能。
Without delving into the details of a full Voice Mail application and all its possible use cases, this section will cover a specific scenario and try to deal with as many interactions as possible that may happen between the AS and the MS in such a context. This scenario, depicted as a sequence diagram in Figure 44, will be as follows:
在不深入研究完整语音邮件应用程序及其所有可能用例的细节的情况下，本节将介绍一个特定场景，并尝试处理在这种情况下as和MS之间可能发生的尽可能多的交互。该场景如图44中的序列图所示，如下所示：
1. The UAC INVITEs a URI associated with his mailbox, and the AS follows the previously explained procedure to have the UAC negotiate a new media session with the MS.
1. UAC邀请一个与他的邮箱相关联的URI，并按照前面解释的过程让UAC与MS协商一个新的媒体会话。
2. The UAC is first prompted with an announcement giving him the amount of available new messages in the mailbox. After that, the UAC can choose which message to access by sending a DTMF tone.
2. UAC首先会收到通知，告知其邮箱中可用的新邮件数量。之后，UAC可以通过发送DTMF音来选择要访问的消息。
3. The UAC is then presented with a VCR-controlled announcement, in which the chosen received mail is played back to him. VCR controls allow him to navigate through the prompt.
3. 然后，UAC会收到一个VCR控制的公告，其中所选择的接收邮件会播放给他。VCR控件允许他在提示中导航。
This is a quite oversimplified scenario, considering that it doesn't even allow the UAC to delete old messages or organize them but just to choose which received message to play. Nevertheless, it gives us
考虑到UAC甚至不允许删除旧消息或组织它们，而只允许选择播放哪个接收到的消息，这是一个非常简单的场景。然而，它给了我们
the chance to deal with variable announcements and VCR controls -- two typical features that a Voice Mail application would almost always take advantage of. Other features that a Voice Mail application would rely upon (e.g., recording streams, event-driven IVR menus, and so on) have been introduced in previous sections, and so representing them would be redundant. This means that the presented call flows assume that some messages have already been recorded and are available at reachable locations. The example also assumes that the AS has placed the recordings in its own storage facilities, since it is not safe to rely upon the internal MS storage, which is likely to be temporary.
处理各种公告和VCR控件的机会——语音邮件应用程序几乎总是利用这两个典型功能。语音邮件应用程序所依赖的其他功能（例如，录制流、事件驱动IVR菜单等）已在前面的章节中介绍，因此表示这些功能是多余的。这意味着呈现的呼叫流假设一些消息已经被记录，并且在可到达的位置可用。该示例还假设AS已将记录放在其自己的存储设施中，因为依赖内部MS存储（可能是临时的）是不安全的。
UAC AS MS
| | |
| | A1. CONTROL (play variables and |
| | collect the user's choice) |
| |++++++++++++++++++++++++++++++++>>|
| | | prepare &
| | |--+ start
| | | | the
| | A2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "You have five messages ..." |
|<<########################################################|
| | |
| | B1. CONTROL (<collectinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | B2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
| | C1. CONTROL (VCR for chosen msg) |
| |++++++++++++++++++++++++++++++++>>|
| | | prepare &
| | |--+ start
| | | | the
| | C2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "Hi there, I tried to call you but..." |--+
|<<########################################################| | handle
| | | | VCR-
|########################################################>>| | driven
| The UAC controls the playout using DTMF | | (DTMF)
|########################################################>>| |playout
| | |<-+
UAC AS MS
| | |
| | A1. CONTROL (play variables and |
| | collect the user's choice) |
| |++++++++++++++++++++++++++++++++>>|
| | | prepare &
| | |--+ start
| | | | the
| | A2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "You have five messages ..." |
|<<########################################################|
| | |
| | B1. CONTROL (<collectinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | B2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
| | C1. CONTROL (VCR for chosen msg) |
| |++++++++++++++++++++++++++++++++>>|
| | | prepare &
| | |--+ start
| | | | the
| | C2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "Hi there, I tried to call you but..." |--+
|<<########################################################| | handle
| | | | VCR-
|########################################################>>| | driven
| The UAC controls the playout using DTMF | | (DTMF)
|########################################################>>| |playout
| | |<-+
| | D1. CONTROL (<dtmfnotify>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. (other events are received in the meantime) |
. . .
| | E1. CONTROL (<controlinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | E2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
| | D1. CONTROL (<dtmfnotify>) |
| |<<++++++++++++++++++++++++++++++++|
| | D2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. (other events are received in the meantime) |
. . .
| | E1. CONTROL (<controlinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | E2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 44: Voice Mail: Framework Transactions
图44：语音邮件：框架事务
The framework transaction steps are as follows:
框架事务处理步骤如下所示：
o The first transaction (A1) is addressed to the IVR package (msc-ivr). It is basically an [RFC6231] 'promptandcollect' dialog, but with a slight difference: some of the prompts to play are actual audio files, for which a URI is provided (media loc="xxx"), while others are so-called <variable> prompts; these <variable> prompts are actually constructed by the MS itself according to the directives provided by the AS. In this example, the sequence of prompts requested by the AS is as follows:
o 第一个事务（A1）发往IVR包（msc IVR）。它基本上是一个[RFC6231]“promptandcollect”对话框，但有一点不同：一些播放的提示是实际的音频文件，其中提供了URI（media loc=“xxx”），而另一些则是所谓的<variable>提示；这些<variable>提示实际上是由MS本身根据AS提供的指令构造的。在本例中，系统请求的提示顺序如下：
1. play a wav file ("you have...").
1. 播放wav文件（“您有…”）。
2. play a digit ("five...") by building it (variable: digit=5).
2. 通过构建数字（变量：digit=5）来播放数字（“五…”）。
3. play a wav file ("messages...").
3. 播放wav文件（“消息…”）。
A DTMF collection is requested as well (<collect>) to be taken after the prompts have been played. The AS is only interested in a single digit (maxdigits=1).
播放提示后，还将请求进行DTMF采集（<collect>）。AS只对单个数字感兴趣（maxdigits=1）。
o The transaction is handled by the MS, and if everything works fine (i.e., the MS retrieved all the audio files and successfully built the variable announcements), the dialog is started; its start is reported, together with the associated identifier (5db01f4) to the AS in a terminating 200 OK message (A2).
o 事务由MS处理，如果一切正常（即MS检索到所有音频文件并成功构建变量公告），则启动对话框；在终止200 OK消息（A2）中，将其启动以及相关标识符（5db01f4）报告给AS。
o The AS then waits for the dialog to end in order to retrieve the results in which it is interested (in this case, the DTMF tone the UAC chooses, since it will affect which message will have to be played subsequently).
o AS然后等待对话框结束，以检索其感兴趣的结果（在本例中，UAC选择的DTMF音调，因为它将影响随后必须播放的消息）。
o The UAC hears the prompts and chooses a message to play. In this example, he wants to listen to the first message and so inputs "1". The MS intercepts this tone and notifies the AS of it in a newly created CONTROL event message (B1); this CONTROL includes information about how each single requested operation ended (<promptinfo> and <collectinfo>). Specifically, the event states that the prompt ended normally (termmode=completed) and that the subsequently collected tone is 1 (dtmf=1). The AS acks the event (B2), since the dialogid provided in the message is the same as that of the previously started dialog.
o UAC听到提示并选择要播放的消息。在本例中，他想要收听第一条消息，因此输入“1”。MS截获该音调并在新创建的控制事件消息（B1）中通知AS；此控件包含有关每个请求的操作如何结束的信息（<promptinfo>和<collectinfo>）。具体而言，该事件表示提示正常结束（termmode=已完成），随后采集的音调为1（dtmf=1）。AS确认事件（B2），因为消息中提供的对话框ID与先前启动的对话框的ID相同。
o At this point, the AS uses the value retrieved from the event to proceed with its business logic. It decides to present the UAC with a VCR-controllable playout of the requested message. This is done with a new request to the IVR package (C1), which contains two operations: <prompt> to address the media file to play (an old recording) and <control> to instruct the MS about how the playout of this media file shall be controlled via DTMF tones provided by the UAC (in this example, different DTMF digits are associated with different actions, e.g., pause/resume, fast forward, rewind, and so on). The AS also subscribes to DTMF events related to this control operation (matchmode=control), which means that the MS is to trigger an event any time that a DTMF associated with a control operation (e.g., 7=pause) is intercepted.
o 此时，AS使用从事件中检索到的值继续其业务逻辑。它决定向UAC提供所请求消息的VCR可控播放。这是通过对IVR包（C1）的新请求完成的，该请求包含两个操作：<prompt>寻址要播放的媒体文件（旧记录）和<control>指示MS如何通过UAC提供的DTMF音调控制该媒体文件的播放（在此示例中，不同的DTMF数字与不同的操作相关联，例如暂停/恢复、快进、快退等）。AS还订阅与此控制操作相关的DTMF事件（匹配模式=控制），这意味着MS将在DTMF与控制操作相关联的任何时间触发事件（例如，7=暂停）被截获。
o The MS prepares the dialog and, when the playout starts, sends notification in a terminating 200 OK message (C2). At this point, the UAC is presented with the prompt and can use DTMF digits to control the playback.
o MS准备对话，并在播放开始时，在终止200 OK消息（C2）中发送通知。此时，UAC将显示提示，并可以使用DTMF数字控制播放。
o As explained previously, any DTMF associated with a VCR operation is then reported to the AS, together with a timestamp stating when the event happened. An example is provided (D1) in which the UAC pressed the fast-forward key (6) at a specific time. Of course, as for any other MS-generated event, the AS acks it (D2).
o 如前所述，与VCR操作相关的任何DTMF随后都会报告给As，并附上一个时间戳，说明事件发生的时间。提供了一个示例（D1），其中UAC在特定时间按下快进键（6）。当然，对于任何其他MS生成的事件，as确认它（D2）。
o When the playback ends (whether because the media reached its termination or because any other interruption occurred), the MS triggers a concluding event with information about the whole dialog (E1). This event, besides including information about the prompt itself (<promptinfo>), also includes information related to the VCR operations (<controlinfo>), that is, all the VCR controls
o 当播放结束时（无论是因为媒体终止还是因为发生了任何其他中断），MS都会触发一个包含整个对话框（E1）信息的结束事件。此事件除了包括有关提示符本身的信息（<promptinfo>）外，还包括与VCR操作（<controlinfo>）相关的信息，即所有VCR控件
the UAC used (fast forward/rewind/pause/resume in this example) and when it happened. The final ack by the AS (E2) concludes the scenario.
UAC使用（本例中为快进/快退/暂停/恢复）以及发生的时间。AS（E2）的最终确认结束了该场景。
A1. AS -> MS (CFW CONTROL, play and collect)
--------------------------------------------
CFW 2f931de22820 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 429
A1. AS -> MS (CFW CONTROL, play and collect)
--------------------------------------------
CFW 2f931de22820 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 429
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/prompts/vm-youhave.wav"
type="audio/x-wav"/>
<variable value="5" type="digits"/>
<media
loc="http://www.example.net/prompts/vm-messages.wav"
type="audio/x-wav"/>
</prompt>
<collect maxdigits="1" escapekey="*"
cleardigitbuffer="true"/>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/prompts/vm-youhave.wav"
type="audio/x-wav"/>
<variable value="5" type="digits"/>
<media
loc="http://www.example.net/prompts/vm-messages.wav"
type="audio/x-wav"/>
</prompt>
<collect maxdigits="1" escapekey="*"
cleardigitbuffer="true"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2f931de22820 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2f931de22820 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="5db01f4"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="5db01f4"/>
</mscivr>
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 7c97adc41b3e CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 270
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 7c97adc41b3e CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 270
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5db01f4">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="11713" termmode="completed"/>
<collectinfo dtmf="1" termmode="match"/>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5db01f4">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="11713" termmode="completed"/>
<collectinfo dtmf="1" termmode="match"/>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 7c97adc41b3e 200
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 7c97adc41b3e 200
C1. AS -> MS (CFW CONTROL, VCR)
-------------------------------
CFW 3140c24614bb CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 423
C1. AS -> MS (CFW CONTROL, VCR)
-------------------------------
CFW 3140c24614bb CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 423
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt bargein="false">
<media
loc="http://www.example.com/messages/recording-4ca9fc2.mpg"/>
</prompt>
<control gotostartkey="1" gotoendkey="3"
ffkey="6" rwkey="4" pausekey="7" resumekey="9"
volupkey="#" voldnkey="*"/>
</dialog>
<subscribe>
<dtmfsub matchmode="control"/>
</subscribe>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt bargein="false">
<media
loc="http://www.example.com/messages/recording-4ca9fc2.mpg"/>
</prompt>
<control gotostartkey="1" gotoendkey="3"
ffkey="6" rwkey="4" pausekey="7" resumekey="9"
volupkey="#" voldnkey="*"/>
</dialog>
<subscribe>
<dtmfsub matchmode="control"/>
</subscribe>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3140c24614bb 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3140c24614bb 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="3e936e0"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="3e936e0"/>
</mscivr>
D1. AS <- MS (CFW CONTROL event, dtmfnotify)
--------------------------------------------
CFW 361840da0581 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 179
D1. AS <- MS (CFW CONTROL event, dtmfnotify)
--------------------------------------------
CFW 361840da0581 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 179
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="3e936e0">
<dtmfnotify matchmode="control" dtmf="6"
timestamp="2008-12-16T12:58:36Z"/>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="3e936e0">
<dtmfnotify matchmode="control" dtmf="6"
timestamp="2008-12-16T12:58:36Z"/>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 361840da0581 200
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 361840da0581 200
[..] The other VCR DTMF notifications are skipped for brevity [..]
[…]为简洁起见，跳过其他VCR DTMF通知[…]
E1. AS <- MS (CFW CONTROL event, dialogexit)
--------------------------------------------
CFW 3ffab81c21e9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 485
E1. AS <- MS (CFW CONTROL event, dialogexit)
--------------------------------------------
CFW 3ffab81c21e9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 485
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="3e936e0">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10270" termmode="completed"/>
<controlinfo>
<controlmatch dtmf="6" timestamp="2008-12-16T12:58:36Z"/>
<controlmatch dtmf="4" timestamp="2008-12-16T12:58:37Z"/>
<controlmatch dtmf="7" timestamp="2008-12-16T12:58:38Z"/>
<controlmatch dtmf="9" timestamp="2008-12-16T12:58:40Z"/>
</controlinfo>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="3e936e0">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="10270" termmode="completed"/>
<controlinfo>
<controlmatch dtmf="6" timestamp="2008-12-16T12:58:36Z"/>
<controlmatch dtmf="4" timestamp="2008-12-16T12:58:37Z"/>
<controlmatch dtmf="7" timestamp="2008-12-16T12:58:38Z"/>
<controlmatch dtmf="9" timestamp="2008-12-16T12:58:40Z"/>
</controlinfo>
</dialogexit>
</event>
</mscivr>
E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 3ffab81c21e9 200
E2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 3ffab81c21e9 200
An interesting scenario to create with the help of features provided by the MS is what is typically called 'Current Time'. A UAC calls a URI, which presents the caller with the current date and time. As can easily be deduced by the very nature of the application, variable announcements play an important role in this scenario. In fact, rather than having the AS build an announcement according to the current time using different framework messages, it is much easier to rely upon the "variable announcements" mechanism provided by the IVR package, as variable announcements provide several ways to deal with dates and times.
借助MS提供的功能创建的一个有趣的场景通常被称为“当前时间”。UAC调用URI，该URI向调用者显示当前日期和时间。从应用程序的本质可以很容易地推断，变量公告在这个场景中扮演着重要的角色。事实上，与使用不同的框架消息根据当前时间生成公告相比，依赖IVR包提供的“可变公告”机制要容易得多，因为可变公告提供了几种处理日期和时间的方法。
To make the scenario more interesting and have it cover more functionality, the application is also assumed to have background music played during the announcement. Because most of the announcements will be variable, a means is needed to have more streams played in parallel on the same connection. This can be achieved in two different ways:
为了使场景更有趣并涵盖更多功能，还假设应用程序在发布期间播放背景音乐。由于大多数公告都是可变的，因此需要一种方法在同一连接上并行播放更多的流。这可以通过两种不同的方式实现：
1. two separate and different dialogs, playing the variable announcements and the background track, respectively.
1. 两个独立且不同的对话框，分别播放变量公告和背景曲目。
2. a single dialog implementing a parallel playback.
2. 实现并行播放的单个对话框。
The first approach assumes that the available MS implements implicit mixing, which may or may not be supported since it's a recommended feature but not mandatory. The second approach assumes that the MS implements support for more streams of the same media type (in this case audio) in the same dialog, which, exactly as for the case of implicit mixing, is not to be taken for granted. Because the first approach is quite straightforward and easy to understand, the following scenario uses the second approach and assumes that the available MS supports parallel playback of more audio tracks within the context of the same dialog.
第一种方法假设可用的MS实现隐式混合，这可能受支持，也可能不受支持，因为这是推荐的特性，但不是强制性的。第二种方法假设MS在同一对话框中实现对相同媒体类型（在本例中为音频）的更多流的支持，这与隐式混合的情况完全一样，不是理所当然的。因为第一种方法非常简单易懂，下面的场景使用第二种方法，并假设可用的MS支持在同一对话框的上下文中并行播放更多的音频曲目。
That said, the covered scenario, depicted as a sequence diagram in Figure 45, will be as follows:
也就是说，图45中描述为序列图的覆盖场景如下所示：
1. The UAC INVITEs a URI associated with the Current Time application, and the AS follows the previously explained procedure to have the UAC negotiate a new media session with the MS.
1. UAC邀请一个与当前时间应用程序相关联的URI，并按照前面解释的过程让UAC与MS协商一个新的媒体会话。
2. The UAC is presented with an announcement including (i) a voice stating the current date and time; (ii) a background music track; and (iii) a mute background video track.
2. UAC收到一份公告，包括（i）说明当前日期和时间的声音；（ii）背景音乐曲目；以及（iii）静音背景视频曲目。
UAC AS MS
| | |
| | A1. CONTROL (play variables) |
| |++++++++++++++++++++++++++++++++>>| prepare
| | |--+ and
| | A2. 202 | | start
| |<<++++++++++++++++++++++++++++++++| | the
| | | | dialog
| | | | (takes
| | A3. REPORT (terminate) |<-+ time)
| |<<++++++++++++++++++++++++++++++++|
| | A4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "16th of december 2008, 5:31 PM..." |
|<<########################################################|
| | |
| | B1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | B2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
. . .
UAC AS MS
| | |
| | A1. CONTROL (play variables) |
| |++++++++++++++++++++++++++++++++>>| prepare
| | |--+ and
| | A2. 202 | | start
| |<<++++++++++++++++++++++++++++++++| | the
| | | | dialog
| | | | (takes
| | A3. REPORT (terminate) |<-+ time)
| |<<++++++++++++++++++++++++++++++++|
| | A4. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
|<<########################################################|
| "16th of december 2008, 5:31 PM..." |
|<<########################################################|
| | |
| | B1. CONTROL (<promptinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| | B2. 200 OK |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
. . .
Figure 45: Current Time: Framework Transactions
图45：当前时间：框架事务
The framework transaction steps are as follows:
框架事务处理步骤如下所示：
o The first transaction (A1) is addressed to the IVR package (msc-ivr); it is basically an [RFC6231] 'playannouncements' dialog, but, unlike all the scenarios presented so far, it includes directives for a parallel playback, as indicated by the <par> element. There are three flows to play in parallel:
o 第一个事务（A1）发往IVR包（msc IVR）；它基本上是一个[RFC6231]“playannouncements”对话框，但是，与目前介绍的所有场景不同，它包括并行播放的指令，如<par>元素所示。有三个流程可以并行运行：
* a sequence (<seq>) of variable and static announcements (the actual time and date).
* 可变和静态公告（实际时间和日期）的序列（<seq>）。
* a music track ('media=music.wav') to be played in the background at a lower volume (soundLevel=50%).
* 以较低音量（声级=50%）在后台播放的音乐曲目（“media=music.wav”）。
* a mute background video track (media=clock.mpg).
* 静音背景视频曲目（媒体=clock.mpg）。
The global announcement ends when the longest of the three parallel steps ends (endsync=last). This means that if one of the steps ends before the others, the step is muted for the rest of the playback. In this example, the series of static and <variable> announcements is requested by the AS:
当三个并行步骤中最长的一个步骤结束时，全局公告结束（endsync=last）。这意味着，如果其中一个步骤在其他步骤之前结束，则该步骤将在播放的其余部分静音。在本例中，AS请求一系列静态和<variable>公告：
* play a wav file ("Tuesday...").
* 播放wav文件（“星期二…”）。
* play a date ("16th of december 2008...") by building it (variable: date with a ymd=year/month/day format).
* 通过构建日期（变量：日期，ymd=年/月/日格式），播放日期（“2008年12月16日…”）。
* play a time ("5:31 PM...") by building it (variable: time with a t12=12 hour day format, am/pm).
* 通过构建时间来播放时间（“下午5:31…”）（变量：时间为t12=每天12小时格式，上午/下午）。
o The transaction is extended by the MS (A2) with a new timeout, as in this case the MS needs some more time to retrieve all the needed media files. Should the new timeout expire as well, the MS would send a further message to extend it again (a REPORT update), but for the sake of simplicity we assume that in this scenario it is not needed. If everything went fine (i.e., the MS retrieved all the audio files and successfully built the variable announcements, and it supports parallel playback as requested), the dialog is started. Its start is reported, together with the associated identifier (415719e), to the AS in a terminating REPORT message (A3).
o 事务由MS（A2）以新的超时进行扩展，因为在这种情况下，MS需要更多的时间来检索所有需要的媒体文件。如果新的超时也过期，MS将发送进一步的消息以再次延长它（报告更新），但是为了简单起见，我们假设在这种情况下不需要它。如果一切正常（即MS检索到所有音频文件并成功构建变量公告，并且支持按请求并行播放），则启动对话框。在终止报告消息（A3）中，将其开始与相关联的标识符（415719e）一起报告给AS。
o The AS acks the REPORT (A4) and waits for the dialog to end in order to either conclude the application or proceed to further steps if required by the application itself.
o AS确认报告（A4）并等待对话框结束，以便结束应用程序，或在应用程序本身需要时继续执行进一步的步骤。
o When the last of the three parallel announcements ends, the dialog terminates, and an event (B1) is triggered to the AS with the relevant information (promptinfo). The AS acks (B2) and terminates the scenario.
o 当三个并行公告中的最后一个结束时，对话框终止，并向AS触发一个事件（B1）和相关信息（PrompInfo）。AS确认（B2）并终止场景。
A1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 0c7680191bd2 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 506
A1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 0c7680191bd2 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 506
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="21c8e07b:055a893f">
<dialog>
<prompt bargein="true">
<par endsync="last">
<seq>
<media loc="http://www.example.com/day-2.wav"/>
<variable value="2008-12-16" type="date" format="ymd"/>
<variable value="17:31" type="time" format="t12"/>
</seq>
<media loc="http://www.example.com/music.wav"
soundLevel="50%"/>
<media loc="http://www.example.com/clock.mpg"/>
</par>
</prompt>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="21c8e07b:055a893f">
<dialog>
<prompt bargein="true">
<par endsync="last">
<seq>
<media loc="http://www.example.com/day-2.wav"/>
<variable value="2008-12-16" type="date" format="ymd"/>
<variable value="17:31" type="time" format="t12"/>
</seq>
<media loc="http://www.example.com/music.wav"
soundLevel="50%"/>
<media loc="http://www.example.com/clock.mpg"/>
</par>
</prompt>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 202)
----------------------
CFW 0c7680191bd2 202
Timeout: 5
A2. AS <- MS (CFW 202)
----------------------
CFW 0c7680191bd2 202
Timeout: 5
A3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 0c7680191bd2 REPORT
Seq: 1
Status: terminate
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
A3. AS <- MS (CFW REPORT terminate)
-----------------------------------
CFW 0c7680191bd2 REPORT
Seq: 1
Status: terminate
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="415719e"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="415719e"/>
</mscivr>
A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 0c7680191bd2 200
Seq: 1
A4. AS -> MS (CFW 200, ACK to 'REPORT terminate')
-------------------------------------------------
CFW 0c7680191bd2 200
Seq: 1
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 4481ca0c4fca CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 4481ca0c4fca CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="415719e">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="8046" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="415719e">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="8046" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4481ca0c4fca 200
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4481ca0c4fca 200
To complete the scenarios presented in Section 6.3, this section deals with how the AS can use the MS to detect DTMF tones from conference participants and take actions on the conference accordingly. A typical example is when participants in a conference are provided with specific codes to:
为了完成第6.3节中介绍的场景，本节将介绍AS如何使用MS检测来自会议参与者的DTMF音调，并在会议上采取相应的行动。一个典型的例子是，向会议参与者提供特定代码，以便：
o mute/unmute themselves in the conference;
o 在会议中静音/取消静音；
o change their volume in the conference, or the volume of the conference itself;
o 改变其在会议中的音量或会议本身的音量；
o change the video layout in the conference, if allowed;
o 如果允许，更改会议中的视频布局；
o kick abusive users out of the conference;
o 将辱骂用户踢出会议；
and so on. To achieve all this, the simplest thing an AS can do is to prepare a recurring DTMF collection for each participant with specific grammars to match. If the collected tones match the grammar, the MS would notify the AS of the tones and start the collection again. Upon receipt of <collectinfo> events, the AS would
等等要实现所有这些，AS可以做的最简单的事情就是为每个参与者准备一个重复的DTMF集合，其中包含要匹配的特定语法。如果收集到的音调符合语法，MS将通知AS这些音调并再次开始收集。在收到<collectinfo>事件后
in turn originate the proper related request, e.g., a <modifyjoin> on the participant's stream with the conference. This is made possible by three features provided by the IVR package:
反过来，发起适当的相关请求，例如，在参与者与会议的流上发起<modifyjoin>。通过IVR软件包提供的三个功能实现了这一点：
1. the 'repeatCount' attribute.
1. “repeatCount”属性。
2. the subscription mechanism.
2. 订阅机制。
3. the Speech Recognition Grammar Specification (SRGS) [SRGS].
3. 语音识别语法规范（SRGS）[SRGS]。
The first feature allows recurring instances of the same dialog without the need for additional requests upon completion of the dialog itself. In fact, the 'repeatCount' attribute indicates how many times the dialog has to be repeated. When the attribute has the value 0, it means that the dialog has to be repeated indefinitely, meaning that it's up to the AS to destroy it by means of a <dialogterminate> request when the dialog is no longer needed. The second feature allows the AS to subscribe to events related to the IVR package without waiting for the dialog to end, e.g., matching DTMF collections in this case. Finally, the last feature allows custom matching grammars to be specified. This way, only a subset of the possible DTMF strings can be specified, so that only those matches in which the AS is interested are reported. Grammars other than SRGS may be supported by the MS and will achieve the same result. This document will only describe the use of an SRGS grammar, since support for SRGS is mandated in [RFC6231].
第一个特性允许同一对话框的重复实例，而不需要在对话框本身完成时进行额外的请求。事实上，“repeatCount”属性指示对话框必须重复多少次。当该属性的值为0时，意味着该对话框必须无限期地重复，这意味着当不再需要该对话框时，由AS通过<dialogterminate>请求将其销毁。第二个功能允许AS订阅与IVR包相关的事件，而无需等待对话框结束，例如，在这种情况下，匹配DTMF集合。最后，最后一个特性允许指定自定义匹配语法。这样，只能指定可能的DTMF字符串的子集，以便只报告AS感兴趣的匹配。MS可能支持SRG以外的语法，并将获得相同的结果。由于[RFC6231]中规定了对SRGS的支持，因此本文档仅描述SRGS语法的使用。
To identify a single sample scenario, we assume that a participant has successfully joined a conference, e.g., as detailed in Figure 32. We also assume that the following codes are to be provided within the conference to participants in order to let them take advantage of advanced features:
为了确定单个示例场景，我们假设参与者已成功加入会议，如图32所示。我们还假设在会议中向与会者提供以下代码，以便他们利用高级功能：
1. *6 to mute/unmute themselves (on/off trigger).
1. *6静音/取消静音（开/关触发）。
2. *1 to lower their own volume in the conference and *3 to raise it.
2. *1降低自己在会议中的音量*3提高音量。
3. *7 to lower the volume of the conference stream they are receiving and *9 to raise it.
3. *7降低他们正在接收的会议流的音量*9提高音量。
4. *0 to leave the conference.
4. *0以离开会议。
This means that six different codes are supported and are to be matched in the requested DTMF collection. All other codes are collected by the MS but discarded, and no event is triggered to the AS. Because all the codes have the '*' (star) DTMF code in common, the following is an example of an SRGS grammar that may be used in the request by the AS:
这意味着支持六种不同的代码，并在请求的DTMF集合中进行匹配。MS收集所有其他代码，但将其丢弃，并且不会触发AS事件。由于所有代码都有共同的“*”（星型）DTMF代码，以下是AS在请求中可能使用的SRGS语法示例：
<grammar mode="dtmf" version="1.0"
xmlns="http://www.w3.org/2001/06/grammar">
<rule id="digit">
<one-of>
<item>0</item>
<item>1</item>
<item>3</item>
<item>6</item>
<item>7</item>
<item>9</item>
</one-of>
</rule>
<rule id="action" scope="public">
<item>
*
<item><ruleref uri="#digit"/></item>
</item>
</rule>
</grammar>
<grammar mode="dtmf" version="1.0"
xmlns="http://www.w3.org/2001/06/grammar">
<rule id="digit">
<one-of>
<item>0</item>
<item>1</item>
<item>3</item>
<item>6</item>
<item>7</item>
<item>9</item>
</one-of>
</rule>
<rule id="action" scope="public">
<item>
*
<item><ruleref uri="#digit"/></item>
</item>
</rule>
</grammar>
As can be deduced by looking at the grammar, the presented SRGS XML code specifies exactly the requirements for the collections to match. The rule is to match any string that has a star ('*') followed by a single supported digit (0, 1, 3, 6, 7, or 9). Such grammar, as stated in [RFC6231], may be either provided inline in the request itself or referenced externally by means of the 'src' attribute. In the example scenario, we'll put it inline, but an external reference to the same document would achieve exactly the same result.
通过查看语法可以推断，所提供的SRGS XML代码精确地指定了要匹配的集合的要求。规则是匹配任何具有星号（“*”）后跟支持的单个数字（0、1、3、6、7或9）的字符串。如[RFC6231]中所述，此类语法可以在请求本身中内联提供，也可以通过“src”属性在外部引用。在示例场景中，我们将其内联，但是对同一文档的外部引用将获得完全相同的结果。
Figure 46 shows how the AS might request the recurring collection for a UAC. As before, the example assumes that the UAC is already a participant in the conference.
图46显示了AS如何为UAC请求定期收集。与前面一样，该示例假设UAC已经是会议的参与者。
UAC AS MS
| | |
| | A1. CONTROL (recurring collection) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | A2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|########################################################>>|
| Recurring DTMF digit collection starts |--+ get
|########################################################>>| | DTMF
| | |<-+ digits
| | B1. CONTROL (dtmfinfo=*1) |
| |<<++++++++++++++++++++++++++++++++++++|
| | B2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ digits
| | C1. CONTROL (modifyjoin UAC1-->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ modify
| | | | UAC
| | C2. 200 OK |<-+ volume
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|########################################################>>|
| Volume of UAC in conference is lowered |
|########################################################>>|
| | |
| | D1. CONTROL (dtmfinfo=*9) |
| |<<++++++++++++++++++++++++++++++++++++|
| | D2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ digits
| | E1. CONTROL (modifyjoin UAC1<--conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ modify
| | | | conf
| | E2. 200 OK |<-+ volume
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| Now UAC can hear the conference mix at a higher volume |
|<<########################################################|
UAC AS MS
| | |
| | A1. CONTROL (recurring collection) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | A2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|########################################################>>|
| Recurring DTMF digit collection starts |--+ get
|########################################################>>| | DTMF
| | |<-+ digits
| | B1. CONTROL (dtmfinfo=*1) |
| |<<++++++++++++++++++++++++++++++++++++|
| | B2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ digits
| | C1. CONTROL (modifyjoin UAC1-->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ modify
| | | | UAC
| | C2. 200 OK |<-+ volume
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|########################################################>>|
| Volume of UAC in conference is lowered |
|########################################################>>|
| | |
| | D1. CONTROL (dtmfinfo=*9) |
| |<<++++++++++++++++++++++++++++++++++++|
| | D2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ digits
| | E1. CONTROL (modifyjoin UAC1<--conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ modify
| | | | conf
| | E2. 200 OK |<-+ volume
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| Now UAC can hear the conference mix at a higher volume |
|<<########################################################|
| | |
| | F1. CONTROL (dtmfinfo=*6) |
| |<<++++++++++++++++++++++++++++++++++++|
| | F2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ digits
| | G1. CONTROL (modifyjoin UAC1-->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ mute
| | | | UAC in
| | G2. 200 OK |<-+ conf
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|########################################################>>|
| UAC is now muted in the conference |
|########################################################>>|
| | |
| | H1. CONTROL (dtmfinfo=*0) |
| |<<++++++++++++++++++++++++++++++++++++|
| | H2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ digits
| | I1. CONTROL (destroy DTMF dialog) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ delete
| | | | the
| | I2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++++++| (DTMF
| | |collection
| | | stops)
| | J1. CONTROL (dialogexit) |
| |<<++++++++++++++++++++++++++++++++++++|
| | J2. 200 OK |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
|########################################################>>|
| No more tones from UAC are collected |
|########################################################>>|
| | |
| | K1. CONTROL (unjoin UAC1<-X->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ unjoin
| | | | UAC &
| | K2. 200 OK |<-+ conf
| |<<++++++++++++++++++++++++++++++++++++|
| | |
| | L1. CONTROL (unjoin-notify) |
| |<<++++++++++++++++++++++++++++++++++++|
| | |
| | F1. CONTROL (dtmfinfo=*6) |
| |<<++++++++++++++++++++++++++++++++++++|
| | F2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ digits
| | G1. CONTROL (modifyjoin UAC1-->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ mute
| | | | UAC in
| | G2. 200 OK |<-+ conf
| |<<++++++++++++++++++++++++++++++++++++|
| | |
|########################################################>>|
| UAC is now muted in the conference |
|########################################################>>|
| | |
| | H1. CONTROL (dtmfinfo=*0) |
| |<<++++++++++++++++++++++++++++++++++++|
| | H2. 200 OK |--+ get
| |++++++++++++++++++++++++++++++++++++>>| | DTMF
| | |<-+ digits
| | I1. CONTROL (destroy DTMF dialog) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ delete
| | | | the
| | I2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++++++| (DTMF
| | |collection
| | | stops)
| | J1. CONTROL (dialogexit) |
| |<<++++++++++++++++++++++++++++++++++++|
| | J2. 200 OK |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
|########################################################>>|
| No more tones from UAC are collected |
|########################################################>>|
| | |
| | K1. CONTROL (unjoin UAC1<-X->conf) |
| |++++++++++++++++++++++++++++++++++++>>|
| | |--+ unjoin
| | | | UAC &
| | K2. 200 OK |<-+ conf
| |<<++++++++++++++++++++++++++++++++++++|
| | |
| | L1. CONTROL (unjoin-notify) |
| |<<++++++++++++++++++++++++++++++++++++|
| | L2. 200 OK |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
| | L2. 200 OK |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 46: DTMF-Driven Conference Manipulation: Framework Transactions
图46：DTMF驱动的会议操作：框架事务
As can be deduced from the sequence diagram above, the AS, in its business logic, correlates the results of different transactions, addressed to different packages, to implement a more complex conferencing scenario. In fact, <dtmfnotify> events are used to take actions according to the functions of the DTMF codes. The framework transaction steps are as follows:
从上面的序列图可以推断出，As在其业务逻辑中关联了针对不同包的不同事务的结果，以实现更复杂的会议场景。事实上，<dtmfnotify>事件用于根据DTMF代码的功能采取操作。框架事务处理步骤如下所示：
o The UAC is already in the conference, and so the AS starts a recurring collect with a grammar to match. This is done by placing a CONTROL request addressed to the IVR package (A1). The operation to implement is a <collect>, and we are only interested in two-digit DTMF strings (maxdigits). The AS is not interested in a DTMF terminator (termchar is set to a non-conventional DTMF character), and the DTMF escape key is set to '#' (the default is '*', which would conflict with the code syntax for the conference and so needs to be changed). A custom SRGS grammar is provided inline (<grammar> with mode=dtmf). The whole dialog is to be repeated indefinitely (dialog has repeatCount=0), and the AS wants to be notified when matching collections occur (dtmfsub with matchmode=collect).
o UAC已经在会议中，因此AS开始使用语法匹配的循环收集。这是通过向IVR包（A1）发出控制请求来实现的。要实现的操作是<collect>，我们只对两位DTMF字符串（maxdigits）感兴趣。AS对DTMF终止符不感兴趣（termchar设置为非常规DTMF字符），DTMF转义键设置为“#”（默认值为“*”，这将与会议的代码语法冲突，因此需要更改）。内联提供了自定义SRGS语法（<grammar>with mode=dtmf）。整个对话框将无限期地重复（对话框的repeatCount=0），AS希望在发生匹配集合时收到通知（dtmfsub的matchmode=collect）。
o The request is handled by the MS (A2) and then successfully started (dialogid=01d1b38). This means that the MS has started collecting DTMF tones from the UAC.
o 请求由MS（A2）处理，然后成功启动（dialogid=01d1b38）。这意味着MS已开始从UAC收集DTMF音调。
o The MS collects a matching DTMF string from the UAC (*1). Since the AS subscribed to this kind of event, a CONTROL event notification (dtmfnotify) is triggered by the MS (B1), including the collected tones. Since the dialog is recurring, the MS immediately restarts the collection.
o MS从UAC（*1）收集匹配的DTMF字符串。由于AS订阅了此类事件，MS（B1）触发控制事件通知（dtmfnotify），包括收集的音调。由于对话框重复出现，MS会立即重新启动采集。
o The AS acks the event (B2) and in its business logic understands that the code '*1' means that the UAC wants its own volume to be lowered in the conference mix. The AS is able to associate the event with the right UAC by referring to the attached dialogid (01d1b38). It then acts accordingly by sending a <modifyjoin> (C1) that does exactly this: the provided <stream> child element instructs the MS to modify the volume of the UAC-->conference audio flow (setgain=-5 dB 'sendonly'). Note that the "setgain"
o AS确认事件（B2），并且在其业务逻辑中理解代码“*1”表示UAC希望在会议组合中降低自己的音量。AS能够通过引用附带的对话框ID（01d1b38）将事件与右UAC关联。然后，它通过发送一个<modifyjoin>（C1）进行相应的操作：提供的<stream>子元素指示MS修改UAC-->会议音频流的音量（setgain=-5 dB“sendonly”）。请注意，“设置增益”
value is the absolute volume level. If the user's request is to lower the volume level, the AS must remember the previously set volume level and from it calculate the new volume level. Note how the request also includes directives for the inverse direction. This verbose approach is needed; otherwise, the MS would not only change the volume in the requested direction but would also disable the media flow in the other direction. Having a proper <stream> addressing the UAC<--conf media flow as well ensures that this doesn't happen.
值是绝对音量级别。如果用户请求降低音量，AS必须记住以前设置的音量，并从中计算新的音量。请注意，请求还包括反向指令。这种冗长的方法是必要的；否则，MS不仅会更改请求方向上的卷，还会禁用另一方向上的媒体流。适当的<stream>寻址UAC<--conf媒体流也可以确保不会发生这种情况。
o The MS successfully enforces the requested operation (C2), changing the volume.
o MS成功实施请求的操作（C2），更改音量。
o A new matching DTMF string from the UAC is collected (*9). As before, an event is triggered to the AS (D1).
o 从UAC收集新的匹配DTMF字符串（*9）。与前面一样，As（D1）会触发一个事件。
o The AS acks the event (D2) and matches the new code ('*9') with its related operation (raise the volume of the conference mix for the UAC), taking the proper action. A different <modifyjoin> is sent (E1) with the new instructions (setgain=+3 dB 'recvonly'). The same considerations regarding how the incremental operation should be mapped to the command apply here as well. Note also how a <stream> for the inverse direction ('sendonly') is again provided just as a placeholder, which basically instructs the MS that the settings for that direction are not to be changed, maintaining the previous directives of (C1).
o AS确认事件（D2）并将新代码（'*9'）与其相关操作相匹配（提高UAC会议混合的音量），并采取适当的措施。另一个<modifyjoin>与新指令一起发送（E1）（setgain=+3 dB'RecvoOnly'）。关于如何将增量操作映射到命令的注意事项也适用于此处。另请注意，反向（'sendonly'）的<stream>是如何再次作为占位符提供的，它基本上指示MS该方向的设置不改变，保持（C1）的先前指令。
o The MS successfully enforces this requested operation as well (E2), changing the volume in the specified direction.
o MS也成功地执行了请求的操作（E2），在指定的方向上更改了卷。
o At this point, a further matching DTMF string from the UAC is collected (*6) and sent to the AS (F1).
o 此时，从UAC收集进一步匹配的DTMF字符串（*6）并发送到AS（F1）。
o After the required ack (F2), the AS reacts by implementing the action associated with the new code ('*6'), by which the UAC requested that it be muted within the conference. A new <modifyjoin> is sent (G1) with a properly constructed payload (setstate=mute 'sendonly'), and the MS enforces it (G2).
o 在所需的ack（F2）之后，AS通过执行与新代码（“*6”）相关联的操作作出反应，UAC通过该操作请求在会议中对其进行静音。一个新的<modifyjoin>被发送（G1）并带有一个正确构造的有效负载（setstate=mute'sendonly'），MS强制执行它（G2）。
o A last (in this scenario) matching DTMF string is collected by the MS (*0). As with all the previous codes, notification of this string is sent to the AS (H1).
o MS（*0）收集最后一个（在此场景中）匹配的DTMF字符串。与前面的所有代码一样，此字符串的通知被发送到As（H1）。
o The AS acks the event (H2) and understands that the UAC wants to leave the conference now (since the code is *0). This means that a series of actions must be taken:
o AS确认事件（H2）并理解UAC现在想要离开会议（因为代码是*0）。这意味着必须采取一系列行动：
* The recurring collection is stopped, since it's no longer needed.
* 循环收集已停止，因为不再需要它。
* The UAC is unjoined from the conference it is in.
* UAC与它所在的会议脱节。
* Additional operations might be considered, e.g., a global announcement stating that the UAC is leaving, but for the sake of conciseness such operations are not listed here.
* 可能会考虑其他操作，例如，全球公告，说明UAC将离开，但为简洁起见，此处未列出此类操作。
The former is accomplished by means of a <dialogterminate> request (I1) to the IVR package (dialogid=01d1b38) and the latter by means of an <unjoin> request (K1) to the Mixer package.
前者通过对IVR包（dialogid=01d1b38）的<dialogterminate>请求（I1）完成，后者通过对混音器包的<unjoin>请求（K1）完成。
o The <dialogterminate> request is handled by the MS (I2), and the dialog is terminated successfully. As soon as the dialog has actually been terminated, a <dialogexit> event is triggered as well to the AS (J1). This event has no report of the result of the last iteration (since the dialog was terminated abruptly with an immediate=true) and is acked by the AS (J2) to finally complete the dialog lifetime.
o <dialogterminate>请求由MS（I2）处理，对话框成功终止。一旦对话框实际终止，就会触发<dialogexit>事件以及As（J1）。此事件没有上一次迭代结果的报告（因为对话框突然终止，立即=true），并由AS（J2）确认，以最终完成对话框生命周期。
o The <unjoin> request is immediately enforced (K2). As a consequence of the unjoin operation, an <unjoin-notify> event notification is triggered by the MS (L1) to confirm to the AS that the requested entities are no longer attached to each other. The status in the event is set to 0, which, as stated in the specification, means that the join has been terminated by an <unjoin> request. The ack from the AS (L2) concludes this scenario.
o <unjoin>请求将立即强制执行（K2）。作为取消连接操作的结果，MS（L1）触发<unjoin notify>事件通知，以向As确认请求的实体不再彼此连接。事件中的状态设置为0，如规范中所述，这意味着连接已被<unjoin>请求终止。来自AS（L2）的ack结束了该场景。
A1. AS -> MS (CFW CONTROL, recurring collect with grammar)
----------------------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 809
A1. AS -> MS (CFW CONTROL, recurring collect with grammar)
----------------------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 809
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="14849028:37fc2523">
<dialog repeatCount="0">
<collect maxdigits="2" termchar="A" escapekey="#">
<grammar>
<grammar version="1.0" mode="dtmf"
xmlns="http://www.w3.org/2001/06/grammar">
<rule id="digit">
<one-of>
<item>0</item>
<item>1</item>
<item>3</item>
<item>6</item>
<item>7</item>
<item>9</item>
</one-of>
</rule>
<rule id="action" scope="public">
<example>*3</example>
<one-of>
<item>
*
<ruleref uri="#digit"/>
</item>
</one-of>
</rule>
</grammar>
</grammar>
</collect>
</dialog>
<subscribe>
<dtmfsub matchmode="collect"/>
</subscribe>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="14849028:37fc2523">
<dialog repeatCount="0">
<collect maxdigits="2" termchar="A" escapekey="#">
<grammar>
<grammar version="1.0" mode="dtmf"
xmlns="http://www.w3.org/2001/06/grammar">
<rule id="digit">
<one-of>
<item>0</item>
<item>1</item>
<item>3</item>
<item>6</item>
<item>7</item>
<item>9</item>
</one-of>
</rule>
<rule id="action" scope="public">
<example>*3</example>
<one-of>
<item>
*
<ruleref uri="#digit"/>
</item>
</one-of>
</rule>
</grammar>
</grammar>
</collect>
</dialog>
<subscribe>
<dtmfsub matchmode="collect"/>
</subscribe>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 238e1f2946e8 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 238e1f2946e8 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="01d1b38"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="01d1b38"/>
</mscivr>
B1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 1dd62e043c00 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
B1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 1dd62e043c00 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*1"
timestamp="2008-12-17T17:20:53Z"/>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*1"
timestamp="2008-12-17T17:20:53Z"/>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 1dd62e043c00 200
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 1dd62e043c00 200
C1. AS -> MS (CFW CONTROL, modifyjoin with setgain)
---------------------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 290
C1. AS -> MS (CFW CONTROL, modifyjoin with setgain)
---------------------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 290
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758:a5105056" id2="54b4ab3">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-5"/>
</stream>
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758:a5105056" id2="54b4ab3">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-5"/>
</stream>
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
D1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 4d674b3e0862 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
D1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 4d674b3e0862 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*9"
timestamp="2008-12-17T17:20:57Z"/>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*9"
timestamp="2008-12-17T17:20:57Z"/>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4d674b3e0862 200
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 4d674b3e0862 200
E1. AS -> MS (CFW CONTROL, modifyjoin with setgain)
---------------------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 292
E1. AS -> MS (CFW CONTROL, modifyjoin with setgain)
---------------------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 292
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758:a5105056" id2="54b4ab3">
<stream media="audio" direction="recvonly">
<volume controltype="setgain" value="+3"/>
</stream>
<stream media="audio" direction="sendonly"/>
</modifyjoin>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758:a5105056" id2="54b4ab3">
<stream media="audio" direction="recvonly">
<volume controltype="setgain" value="+3"/>
</stream>
<stream media="audio" direction="sendonly"/>
</modifyjoin>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
F1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 478ed6f1775b CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
F1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 478ed6f1775b CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*6"
timestamp="2008-12-17T17:21:02Z"/>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*6"
timestamp="2008-12-17T17:21:02Z"/>
</event>
</mscivr>
F2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 478ed6f1775b 200
F2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 478ed6f1775b 200
G1. AS -> MS (CFW CONTROL, modifyjoin with setstate)
----------------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 295
G1. AS -> MS (CFW CONTROL, modifyjoin with setstate)
----------------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 295
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758:a5105056" id2="54b4ab3">
<stream media="audio" direction="sendonly">
<volume controltype="setstate" value="mute"/>
</stream>
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="873975758:a5105056" id2="54b4ab3">
<stream media="audio" direction="sendonly">
<volume controltype="setstate" value="mute"/>
</stream>
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
G2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7fdcc2331bef 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
G2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7fdcc2331bef 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
H1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 750b917a5d4a CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
H1. AS <- MS (CFW CONTROL dtmfnotify event)
-------------------------------------------
CFW 750b917a5d4a CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 180
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*0"
timestamp="2008-12-17T17:21:05Z"/>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dtmfnotify matchmode="collect" dtmf="*0"
timestamp="2008-12-17T17:21:05Z"/>
</event>
</mscivr>
H2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 750b917a5d4a 200
H2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 750b917a5d4a 200
I1. AS -> MS (CFW CONTROL, dialogterminate)
-------------------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 128
I1. AS -> MS (CFW CONTROL, dialogterminate)
-------------------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 128
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogterminate dialogid="01d1b38" immediate="true"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogterminate dialogid="01d1b38" immediate="true"/>
</mscivr>
I2. AS <- MS (CFW 200 OK)
-------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 140
I2. AS <- MS (CFW 200 OK)
-------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 140
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog terminated"
dialogid="01d1b38"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog terminated"
dialogid="01d1b38"/>
</mscivr>
J1. AS <- MS (CFW CONTROL dialogexit event)
-------------------------------------------
CFW 76adc41122c1 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 155
J1. AS <- MS (CFW CONTROL dialogexit event)
-------------------------------------------
CFW 76adc41122c1 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 155
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dialogexit status="0" reason="Dialog terminated"/>
</event>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="01d1b38">
<dialogexit status="0" reason="Dialog terminated"/>
</event>
</mscivr>
J2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 76adc41122c1 200
J2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 76adc41122c1 200
K1. AS -> MS (CFW CONTROL, unjoin)
----------------------------------
CFW 4e6afb6625e4 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 127
K1. AS -> MS (CFW CONTROL, unjoin)
----------------------------------
CFW 4e6afb6625e4 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 127
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<unjoin id1="873975758:a5105056" id2="54b4ab3"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<unjoin id1="873975758:a5105056" id2="54b4ab3"/>
</mscmixer>
K2. AS <- MS (CFW 200 OK)
-------------------------
CFW 4e6afb6625e4 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 122
K2. AS <- MS (CFW 200 OK)
-------------------------
CFW 4e6afb6625e4 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 122
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join removed"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join removed"/>
</mscmixer>
L1. AS <- MS (CFW CONTROL unjoin-notify event)
----------------------------------------------
CFW 577696293504 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 157
L1. AS <- MS (CFW CONTROL unjoin-notify event)
----------------------------------------------
CFW 577696293504 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 157
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<event>
<unjoin-notify status="0"
id1="873975758:a5105056" id2="54b4ab3"/>
</event>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<event>
<unjoin-notify status="0"
id1="873975758:a5105056" id2="54b4ab3"/>
</event>
</mscmixer>
L2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 577696293504 200
L2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 577696293504 200
All the flows presented so far describe the interaction between a single AS and a single MS. This is the simplest topology that can be envisaged in a MEDIACTRL-compliant architecture, but it's not the only topology that is allowed. [RFC5567] presents several possible topologies that potentially involve several AS and several MS as well. To properly allow for such topologies, an additional element called the Media Resource Broker (MRB) has been introduced in the MEDIACTRL architecture. Such an entity, and the protocols needed to interact with it, has been standardized in [RFC6917].
到目前为止，提供的所有流都描述了单个AS和单个MS之间的交互。这是MEDIACTRL兼容体系结构中可以设想的最简单的拓扑，但它不是唯一允许的拓扑。[RFC5567]介绍了可能涉及多个AS和多个MS的几种拓扑。为了正确考虑这种拓扑，在MEDIACTRL体系结构中引入了一个称为媒体资源代理（MRB）的附加元素。[RFC6917]中对此类实体及其交互所需的协议进行了标准化。
An MRB is basically a locator that is aware of a pool of MS and makes them available to interested AS according to their requirements. For this reason, two different interfaces have been introduced:
MRB基本上是一个定位器，它知道一个MS池，并根据其需求将其提供给感兴趣的人。因此，引入了两种不同的接口：
o the Publishing interface (Section 7.1), which allows an MRB to subscribe for notifications at the MS it is handling (e.g., available and occupied resources, current state, etc.).
o 发布接口（第7.1节），允许MRB在其处理的MS订阅通知（例如，可用和占用的资源、当前状态等）。
o the Consumer interface (Section 7.2), which allows an interested AS to query an MRB for an MS capable of fulfilling its requirements.
o 消费者界面（第7.2节），允许感兴趣的AS查询MRB以获得能够满足其要求的MS。
The flows in the following sections will present some typical use-case scenarios involving an MRB and the different topologies in which it has been conceived to work.
以下各节中的流程将展示一些典型的用例场景，涉及MRB和其设想工作的不同拓扑。
Additionally, a few considerations on the handling of media dialogs whenever an MRB is involved are presented in Section 7.3.
此外，第7.3节介绍了涉及MRB时处理媒体对话框的一些注意事项。
An MRB uses the MS's Publishing interface to acquire relevant information. This Publishing interface, as specified in [RFC6917], is made available as a Control Package for the Media Control Channel Framework. This means that in order to receive information from an MS, an MRB must negotiate a Control Channel as explained in Section 5. This package allows an MRB to either request information in the form of a direct request/answer from an MS or subscribe for events.
MRB使用MS的发布界面获取相关信息。[RFC6917]中规定的发布接口作为媒体控制通道框架的控制包提供。这意味着为了从MS接收信息，MRB必须协商控制通道，如第5节所述。该包允许MRB以直接请求/应答的形式从MS请求信息或订阅事件。
Of course, since the MRB is interested in the Publishing interface, the previously mentioned negotiation must be changed in order to take into account the need for the MRB Control Package. The name of this package is 'mrb-publish/1.0', which means that the SYNC might look like the following:
当然，由于MRB对发布接口感兴趣，因此必须更改前面提到的协商，以考虑MRB控制包的需要。此程序包的名称为“mrb publish/1.0”，这意味着同步可能如下所示：
1. MRB -> MS (CFW SYNC) ----------------------- CFW 6b8b4567327b SYNC Dialog-ID: z9hG4bK-4542-1-0 Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0
1. MRB->MS（CFW同步）--------------------------CFW 6b8b4567327b同步对话框ID:z9hG4bK-4542-1-0保持活动状态：100个包：msc ivr/1.0、msc mixer/1.0、MRB发布/1.0
2. MRB <- MS (CFW 200) ---------------------- CFW 6b8b4567327b 200 Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0 Supported: msc-example-pkg/1.0
2. MRB<-MS（CFW 200）-------------------------CFW 6b8b4567327b 200保持活动状态：100个软件包：msc ivr/1.0、msc mixer/1.0、支持的MRB发布/1.0：msc示例软件包/1.0
The meaning of this negotiation was presented previously. It is enough to point out that the MRB in this case adds a new item to the 'Packages' it needs support for (mrb-publish/1.0). In this case, the MS supports it, and in fact it is added to the negotiated packages in the reply:
本次谈判的意义已在前面介绍过。只需指出，在这种情况下，MRB会向其需要支持的“包”（MRB publish/1.0）中添加一个新项。在这种情况下，MS支持它，事实上，它被添加到回复中的协商包中：
Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0
^^^^^^^^^^^^^^^
Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0
^^^^^^^^^^^^^^^
The MS as described in Section 5, on the other hand, did not have support for that package, since only 'msc-example-pkg/1.0' was part of the 'Supported' list.
另一方面，第5节中所述的MS不支持该软件包，因为只有“msc示例pkg/1.0”是“受支持”列表的一部分。
Figure 47 presents a ladder diagram of a typical interaction based on the MRB Control Package.
图47显示了基于MRB控制包的典型交互的梯形图。
MRB MS
| |
| A1. CONTROL (MRB subscription) |
|--------------------------------------------->|
| A2. 200 OK |
|<---------------------------------------------|
| |--+ collect
| | | requested
| |<-+ info
| B1. CONTROL (MRB notification) |
|<---------------------------------------------|
| B2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
| |
| |--+ collect
| | | up-to-date
| |<-+ info
| C1. CONTROL (MRB notification) |
|<---------------------------------------------|
| C2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
| |
| D1. CONTROL (Update MRB subscription) |
|--------------------------------------------->|
| D2. 200 OK |
|<---------------------------------------------|
| |
. .
. .
MRB MS
| |
| A1. CONTROL (MRB subscription) |
|--------------------------------------------->|
| A2. 200 OK |
|<---------------------------------------------|
| |--+ collect
| | | requested
| |<-+ info
| B1. CONTROL (MRB notification) |
|<---------------------------------------------|
| B2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
| |
| |--+ collect
| | | up-to-date
| |<-+ info
| C1. CONTROL (MRB notification) |
|<---------------------------------------------|
| C2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
| |
| D1. CONTROL (Update MRB subscription) |
|--------------------------------------------->|
| D2. 200 OK |
|<---------------------------------------------|
| |
. .
. .
Figure 47: Media Resource Brokering: Subscription and Notification
图47：媒体资源代理：订阅和通知
In this example, the MRB subscribes for information at the specified MS, and events are triggered on a regular, negotiated basis. All of these messages flow through the Control Channel, as do all of the messages discussed in this document. The framework transaction steps are as follows:
在本例中，MRB在指定的MS订阅信息，并且事件在定期协商的基础上触发。所有这些消息都流经控制通道，本文档中讨论的所有消息也是如此。框架事务处理步骤如下所示：
o The MRB sends a new CONTROL message (A1) addressed to the MRB package (mrb-publish/1.0); it is a subscription for information (<subscription>), and the MRB is asking to be notified at least every 10 minutes (<minfrequency>) or, if required, every 30 seconds at maximum. The subscription must last 30 minutes (<expires>), after which no additional notifications must be sent.
o MRB向MRB包（MRB发布/1.0）发送一条新的控制消息（A1）；这是一个信息订阅（<subscription>），MRB要求至少每10分钟（<minfrequency>）或（如果需要）最多每30秒通知一次。订阅必须持续30分钟（<expires>），之后不得发送其他通知。
o The MS acknowledges the request (A2) and sends notification of the success of the request in a 200 OK message (<mrbresponse>).
o MS确认请求（A2），并在200 OK消息（<mrbresponse>）中发送请求成功的通知。
o The MS prepares and sends the first notification to the MRB (B1). As has been done with other packages, the notification has been sent as an MS-generated CONTROL message; it is a notification related to the request in the first message, because the 'id' (p0T65U) matches that request. All of the information that the MRB subscribed for is provided in the payload.
o MS准备并向MRB（B1）发送第一个通知。与其他包一样，通知已作为MS生成的控制消息发送；这是与第一条消息中的请求相关的通知，因为“id”（p0T65U）与该请求匹配。MRB订阅的所有信息都在有效负载中提供。
o The MRB acknowledges the notification (B2) and uses the retrieved information to update its own information as part of its business logic.
o MRB确认通知（B2），并使用检索到的信息更新自己的信息，作为其业务逻辑的一部分。
o The previous step (the MRB acknowledges notifications and uses the retrieved information) repeats at the required frequency, with up-to-date information.
o 上一步（MRB确认通知并使用检索到的信息）以要求的频率重复，并提供最新信息。
o After a while, the MRB updates its subscription (D1) to get more frequent updates (minfrequency=1, an update every second at least). The MS accepts the update (D2), although it may adjust the frequency in the reply according to its policies (e.g., a lower rate, such as minfrequency=30). The notifications continue, but at the newer rate; the expiration is also updated accordingly (600 seconds again, since the update refreshes it).
o 一段时间后，MRB更新其订阅（D1）以获得更频繁的更新（minfrequency=1，至少每秒更新一次）。MS接受更新（D2），尽管它可以根据其策略（例如，较低的速率，例如minfrequency=30）调整应答中的频率。通知仍在继续，但速度较新；过期时间也会相应地更新（由于更新会刷新它，所以会再次更新600秒）。
A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 337
A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 337
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest>
<subscription action="create" seqnumber="1" id="p0T65U">
<expires>60</expires>
<minfrequency>600</minfrequency>
<maxfrequency>30</maxfrequency>
</subscription>
</mrbrequest>
</mrbpublish>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest>
<subscription action="create" seqnumber="1" id="p0T65U">
<expires>60</expires>
<minfrequency>600</minfrequency>
<maxfrequency>30</maxfrequency>
</subscription>
</mrbrequest>
</mrbpublish>
A2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW lidc30BZObiC 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 139
A2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW lidc30BZObiC 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 139
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish>
B1. MRB <- MS (CONTROL, event notification from MS)
---------------------------------------------------
CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 4157
B1. MRB <- MS (CONTROL, event notification from MS)
---------------------------------------------------
CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 4157
<mrbpublish version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbnotification seqnumber="1" id="p0T65U">
<media-server-id>a1b2c3d4</media-server-id>
<supported-packages>
<package name="msc-ivr/1.0"/>
<package name="msc-mixer/1.0"/>
<package name="mrb-publish/1.0"/>
<package name="msc-example-pkg/1.0"/>
</supported-packages>
<mrbpublish version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbnotification seqnumber="1" id="p0T65U">
<media-server-id>a1b2c3d4</media-server-id>
<supported-packages>
<package name="msc-ivr/1.0"/>
<package name="msc-mixer/1.0"/>
<package name="mrb-publish/1.0"/>
<package name="msc-example-pkg/1.0"/>
</supported-packages>
<active-rtp-sessions>
<rtp-codec name="audio/basic">
<decoding>10</decoding>
<encoding>20</encoding>
</rtp-codec>
</active-rtp-sessions>
<active-mixer-sessions>
<active-mix conferenceid="7cfgs43">
<rtp-codec name="audio/basic">
<decoding>3</decoding>
<encoding>3</encoding>
</rtp-codec>
</active-mix>
</active-mixer-sessions>
<non-active-rtp-sessions>
<rtp-codec name="audio/basic">
<decoding>50</decoding>
<encoding>40</encoding>
</rtp-codec>
</non-active-rtp-sessions>
<non-active-mixer-sessions>
<non-active-mix available="15">
<rtp-codec name="audio/basic">
<decoding>15</decoding>
<encoding>15</encoding>
</rtp-codec>
</non-active-mix>
</non-active-mixer-sessions>
<media-server-status>active</media-server-status>
<supported-codecs>
<supported-codec name="audio/basic">
<supported-codec-package name="msc-ivr/1.0">
<supported-action>encoding</supported-action>
<supported-action>decoding</supported-action>
</supported-codec-package>
<supported-codec-package name="msc-mixer/1.0">
<supported-action>encoding</supported-action>
<supported-action>decoding</supported-action>
</supported-codec-package>
</supported-codec>
</supported-codecs>
<active-rtp-sessions>
<rtp-codec name="audio/basic">
<decoding>10</decoding>
<encoding>20</encoding>
</rtp-codec>
</active-rtp-sessions>
<active-mixer-sessions>
<active-mix conferenceid="7cfgs43">
<rtp-codec name="audio/basic">
<decoding>3</decoding>
<encoding>3</encoding>
</rtp-codec>
</active-mix>
</active-mixer-sessions>
<non-active-rtp-sessions>
<rtp-codec name="audio/basic">
<decoding>50</decoding>
<encoding>40</encoding>
</rtp-codec>
</non-active-rtp-sessions>
<non-active-mixer-sessions>
<non-active-mix available="15">
<rtp-codec name="audio/basic">
<decoding>15</decoding>
<encoding>15</encoding>
</rtp-codec>
</non-active-mix>
</non-active-mixer-sessions>
<media-server-status>active</media-server-status>
<supported-codecs>
<supported-codec name="audio/basic">
<supported-codec-package name="msc-ivr/1.0">
<supported-action>encoding</supported-action>
<supported-action>decoding</supported-action>
</supported-codec-package>
<supported-codec-package name="msc-mixer/1.0">
<supported-action>encoding</supported-action>
<supported-action>decoding</supported-action>
</supported-codec-package>
</supported-codec>
</supported-codecs>
<application-data>TestbedPrototype</application-data>
<file-formats>
<supported-format name="audio/x-wav">
<supported-file-package>
msc-ivr/1.0
</supported-file-package>
</supported-format>
</file-formats>
<max-prepared-duration>
<max-time max-time-seconds="3600">
<max-time-package>msc-ivr/1.0</max-time-package>
</max-time>
</max-prepared-duration>
<dtmf-support>
<detect>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</detect>
<generate>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</generate>
<passthrough>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</passthrough>
</dtmf-support>
<mixing-modes>
<audio-mixing-modes>
<audio-mixing-mode package="msc-ivr/1.0"> \
nbest \
</audio-mixing-mode>
</audio-mixing-modes>
<video-mixing-modes activespeakermix="true" vas="true">
<video-mixing-mode package="msc-mixer/1.0"> \
single-view \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
dual-view \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
dual-view-crop \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
dual-view-2x1 \
</video-mixing-mode>
<application-data>TestbedPrototype</application-data>
<file-formats>
<supported-format name="audio/x-wav">
<supported-file-package>
msc-ivr/1.0
</supported-file-package>
</supported-format>
</file-formats>
<max-prepared-duration>
<max-time max-time-seconds="3600">
<max-time-package>msc-ivr/1.0</max-time-package>
</max-time>
</max-prepared-duration>
<dtmf-support>
<detect>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</detect>
<generate>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</generate>
<passthrough>
<dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
<dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
</passthrough>
</dtmf-support>
<mixing-modes>
<audio-mixing-modes>
<audio-mixing-mode package="msc-ivr/1.0"> \
nbest \
</audio-mixing-mode>
</audio-mixing-modes>
<video-mixing-modes activespeakermix="true" vas="true">
<video-mixing-mode package="msc-mixer/1.0"> \
single-view \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
dual-view \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
dual-view-crop \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
dual-view-2x1 \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
dual-view-2x1-crop \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
quad-view \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
multiple-5x1 \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
multiple-3x3 \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
multiple-4x4 \
</video-mixing-mode>
</video-mixing-modes>
</mixing-modes>
<supported-tones>
<supported-country-codes>
<country-code package="msc-ivr/1.0">GB</country-code>
<country-code package="msc-ivr/1.0">IT</country-code>
<country-code package="msc-ivr/1.0">US</country-code>
</supported-country-codes>
<supported-h248-codes>
<h248-code package="msc-ivr/1.0">cg/*</h248-code>
<h248-code package="msc-ivr/1.0">biztn/ofque</h248-code>
<h248-code package="msc-ivr/1.0">biztn/erwt</h248-code>
<h248-code package="msc-mixer/1.0">conftn/*</h248-code>
</supported-h248-codes>
</supported-tones>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
<asr-tts-support>
<asr-support>
<language xml:lang="en"/>
</asr-support>
<tts-support>
<language xml:lang="en"/>
</tts-support>
</asr-tts-support>
<vxml-support>
<vxml-mode package="msc-ivr/1.0" support="rfc6231"/>
</vxml-support>
<video-mixing-mode package="msc-mixer/1.0"> \
dual-view-2x1-crop \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
quad-view \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
multiple-5x1 \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
multiple-3x3 \
</video-mixing-mode>
<video-mixing-mode package="msc-mixer/1.0"> \
multiple-4x4 \
</video-mixing-mode>
</video-mixing-modes>
</mixing-modes>
<supported-tones>
<supported-country-codes>
<country-code package="msc-ivr/1.0">GB</country-code>
<country-code package="msc-ivr/1.0">IT</country-code>
<country-code package="msc-ivr/1.0">US</country-code>
</supported-country-codes>
<supported-h248-codes>
<h248-code package="msc-ivr/1.0">cg/*</h248-code>
<h248-code package="msc-ivr/1.0">biztn/ofque</h248-code>
<h248-code package="msc-ivr/1.0">biztn/erwt</h248-code>
<h248-code package="msc-mixer/1.0">conftn/*</h248-code>
</supported-h248-codes>
</supported-tones>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
<asr-tts-support>
<asr-support>
<language xml:lang="en"/>
</asr-support>
<tts-support>
<language xml:lang="en"/>
</tts-support>
</asr-tts-support>
<vxml-support>
<vxml-mode package="msc-ivr/1.0" support="rfc6231"/>
</vxml-support>
<media-server-location>
<civicAddress xml:lang="it">
<country>IT</country>
<A1>Campania</A1>
<A3>Napoli</A3>
<A6>Via Claudio</A6>
<HNO>21</HNO>
<LMK>University of Napoli Federico II</LMK>
<NAM>Dipartimento di Informatica e Sistemistica</NAM>
<PC>80210</PC>
</civicAddress>
</media-server-location>
<label>TestbedPrototype-01</label>
<media-server-address>
sip:MediaServer@ms.example.net
</media-server-address>
<encryption/>
</mrbnotification>
</mrbpublish>
<media-server-location>
<civicAddress xml:lang="it">
<country>IT</country>
<A1>Campania</A1>
<A3>Napoli</A3>
<A6>Via Claudio</A6>
<HNO>21</HNO>
<LMK>University of Napoli Federico II</LMK>
<NAM>Dipartimento di Informatica e Sistemistica</NAM>
<PC>80210</PC>
</civicAddress>
</media-server-location>
<label>TestbedPrototype-01</label>
<media-server-address>
sip:MediaServer@ms.example.net
</media-server-address>
<encryption/>
</mrbnotification>
</mrbpublish>
B2. MRB -> MS (200 to CONTROL)
------------------------------
CFW 03fff52e7b7a 200
B2. MRB -> MS (200 to CONTROL)
------------------------------
CFW 03fff52e7b7a 200
(C1 and C2 omitted for brevity)
（为简洁起见，省略C1和C2）
D1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW pyu788fc32wa CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 342
D1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW pyu788fc32wa CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 342
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest>
<subscription action="update" seqnumber="2" id="p0T65U">
<expires>600</expires>
<minfrequency>1</minfrequency>
</subscription>
</mrbrequest>
</mrbpublish>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest>
<subscription action="update" seqnumber="2" id="p0T65U">
<expires>600</expires>
<minfrequency>1</minfrequency>
</subscription>
</mrbrequest>
</mrbpublish>
D2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW pyu788fc32wa 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 332
D2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW pyu788fc32wa 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 332
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted">
<subscription action="create" seqnumber="2" id="p0T65U">
<expires>600</expires>
<minfrequency>30</minfrequency>
</subscription>
</mrbresponse>
</mrbpublish>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted">
<subscription action="create" seqnumber="2" id="p0T65U">
<expires>600</expires>
<minfrequency>30</minfrequency>
</subscription>
</mrbresponse>
</mrbpublish>
Whereas the Publishing interface is used by an MS to publish its functionality and up-to-date information to an MRB, the Consumer interface is used by an interested AS to access a resource. An AS can use the Consumer interface to contact an MRB and describe the resources it needs. The MRB then replies with the needed information: specifically, the address of an MS that is capable of meeting the requirements.
MS使用发布界面向MRB发布其功能和最新信息，而感兴趣的AS则使用使用者界面访问资源。AS可以使用消费者界面联系MRB并描述其所需的资源。然后，MRB回复所需信息：特别是能够满足要求的MS地址。
However, unlike the Publishing interface, the Consumer interface is not specified as a Control Package. Rather, it is conceived as an XML-based protocol that can be transported by means of either HTTP or SIP, as will be shown in the following sections.
但是，与发布接口不同，使用者接口未指定为控制包。相反，它被认为是一个基于XML的协议，可以通过HTTP或SIP进行传输，如下几节所示。
As specified in [RFC6917], the Consumer interface can be involved in two topologies: Query mode and Inline mode. In the Query mode (Section 7.2.1), the Consumer requests and responses are conveyed by means of HTTP. Once the AS gets the answer, the usual MEDIACTRL interactions occur between the AS and the MS chosen by the MRB. By contrast, in the Inline mode, the MRB is in the path between the AS and the pool of MS it is handling. In this case, an AS can place Consumer requests using SIP as a transport, by means of a multipart payload (Section 7.2.2) containing the Consumer request itself and an SDP related either to the creation of a Control Channel or to a UAC media dialog. This is called Inline-aware mode, since it assumes that the interested AS knows that an MRB is in place and knows how to talk to it. The MRB is also conceived to work with AS that are unaware of its functionality, i.e., unaware of the Consumer interface. In this kind of scenario, the Inline mode is still used, but with the AS thinking the MRB it is talking to is actually an MS. This approach is called Inline-unaware mode (Section 7.2.3).
如[RFC6917]中所述，使用者接口可涉及两种拓扑：查询模式和内联模式。在查询模式（第7.2.1节）中，消费者请求和响应通过HTTP传输。AS得到答案后，AS和MRB选择的MS之间会发生通常的MEDIACTRL交互。相反，在内联模式下，MRB位于AS和它正在处理的MS池之间的路径中。在这种情况下，AS可以通过包含消费者请求本身和与创建控制通道或UAC媒体对话框相关的SDP的多部分有效负载（第7.2.2节），使用SIP作为传输来放置消费者请求。这被称为内联感知模式，因为它假设感兴趣的AS知道MRB已经就位，并且知道如何与之对话。MRB还可以与不知道其功能的AS一起工作，即不知道用户界面。在这种情况下，仍然使用内联模式，但AS认为与之交谈的MRB实际上是MS。这种方法称为内联不知道模式（第7.2.3节）。
As discussed in the previous section, in the Query mode the AS sends Consumer requests by means of HTTP. Specifically, an HTTP POST is used to convey the request. The MRB is assumed to send its response by means of an HTTP 200 OK reply. Since a successful Consumer response contains information to contact a specific MS (the MS the MRB has deemed most capable of fulfilling the AS's requirements), an AS can subsequently directly contact the MS, as described in Section 5. This means that in the Query mode the MRB acts purely as a locator, and then the AS and the MS can talk 1:1.
如前一节所述，在查询模式下，As通过HTTP发送使用者请求。具体来说，HTTP POST用于传递请求。假设MRB通过HTTP 200 OK应答发送其响应。由于成功的消费者响应包含联系特定MS的信息（MRB认为最有能力满足AS要求的MS），AS随后可以直接联系MS，如第5节所述。这意味着在查询模式下，MRB仅充当定位器，然后as和MS可以1:1对话。
Figure 48 presents a ladder diagram of a typical Consumer request in the Query topology:
图48显示了查询拓扑中典型消费者请求的梯形图：
AS MRB
| |
| 1. HTTP POST (Consumer request) |
|--------------------------------------------->|
| |
| |
| |--+ Parse request
| | | and see if any
| |<-+ MS applies
| |
| 2. 200 OK (Consumer response) |
|<---------------------------------------------|
| |
|--+ Parse response and |
| | start session (SIP/COMEDIA/CFW) |
|<-+ with MS reported by MRB |
| |
. .
. .
AS MRB
| |
| 1. HTTP POST (Consumer request) |
|--------------------------------------------->|
| |
| |
| |--+ Parse request
| | | and see if any
| |<-+ MS applies
| |
| 2. 200 OK (Consumer response) |
|<---------------------------------------------|
| |
|--+ Parse response and |
| | start session (SIP/COMEDIA/CFW) |
|<-+ with MS reported by MRB |
| |
. .
. .
Figure 48: Media Resource Brokering: Query Mode
图48：媒体资源代理：查询模式
In this example, the AS is interested in an MS meeting a defined set of requirements. The MS must:
在本例中，AS对满足一组定义的需求的MS感兴趣。MS必须：
1. support both the IVR and Mixer packages.
1. 支持IVR和Mixer软件包。
2. provide at least 10 G.711 encoding/decoding RTP sessions for IVR purposes.
2. 为IVR目的提供至少10个G.711编码/解码RTP会话。
3. support HTTP-based streaming and support for the audio/x-wav file format in the IVR package.
3. 支持基于HTTP的流式传输，并支持IVR包中的音频/x-wav文件格式。
These requirements are properly formatted according to the MRB Consumer syntax. The framework transaction steps are as follows:
这些要求根据MRB使用者语法正确格式化。框架事务处理步骤如下所示：
o The AS sends an HTTP POST message to the MRB (1). The payload is, of course, the Consumer request, which is reflected by the Content-Type header (application/mrb-consumer+xml). The Consumer request (<mediaResourceRequest>, uniquely identified by its 'id' attribute set to the random value 'n3un93wd'), includes some general requirements (<generalInfo>) and some IVR-specific requirements (<ivrInfo>). The general part of the requests contains the set of required packages (<packages>). The IVR-specific section contains requirements concerning the number of required IVR sessions (<ivr-sessions>), the file formats that are to be supported (<file-formats>), and the required file transfer capabilities (<file-transfer-modes>).
o AS向MRB发送HTTP POST消息（1）。当然，有效负载是消费者请求，由内容类型头（application/mrb Consumer+xml）反映。使用者请求（<mediaResourceRequest>，由其设置为随机值“n3un93wd”的“id”属性唯一标识），包括一些一般要求（<generalInfo>）和一些IVR特定要求（<ivrInfo>）。请求的常规部分包含所需的包集（<packages>）。IVR特定部分包含有关所需IVR会话数量（<IVR会话>）、支持的文件格式（<file formats>）和所需文件传输功能（<file transfer modes>）的要求。
o The MRB gets the request and parses it. Then, according to its business logic, it realizes it can't find a single MS capable of targeting the request and as a consequence picks two MS instances that can handle 60 and 40 of the requested sessions, respectively. It prepares a Consumer response (2) to provide the AS with the requested information. The response (<mediaResourceResponse>, which includes the same 'id' attribute as the request) indicates success (status=200) and includes the relevant information (<response-session-info>). Specifically, the response includes transaction-related information (the same session-id and seq provided by the AS in its request, to allow proper request/ response matching) together with information on the duration of the reservation (expires=3600, i.e., after an hour the request will expire) and the SIP addresses of the chosen MS.
o MRB获取请求并解析它。然后，根据其业务逻辑，它意识到它找不到一个能够针对请求的MS，因此选择了两个MS实例，分别可以处理60和40个请求的会话。它准备消费者响应（2）以向AS提供请求的信息。响应（<mediaResourceResponse>，其中包含与请求相同的“id”属性）表示成功（状态=200），并包含相关信息（<response session info>）。具体地说，响应包括与事务相关的信息（AS在其请求中提供的相同会话id和seq，以允许适当的请求/响应匹配）以及关于保留的持续时间（expires＝3600，即，在一小时后请求将过期）和所选MS的SIP地址的信息。
Note how the sequence number the MRB returned is not 1. According to the MRB specification, this is the starting value to increment for the sequence number to be used in subsequent requests. This means that should the AS want to update or remove the session it should use 10 as a value for the sequence number in the related request. According to Section 12 of [RFC6917], this random value for the first sequence number is also a way to help prevent a malicious entity from messing with or disrupting another AS session with the MRB. In fact, sequence numbers in requests and responses have to match, and failure to provide the correct sequence number would result in session failure and a 405 error message.
请注意，MRB返回的序列号不是1。根据MRB规范，这是在后续请求中使用的序列号递增的起始值。这意味着，如果AS想要更新或删除会话，它应该在相关请求中使用10作为序列号的值。根据[RFC6917]第12节，第一个序列号的随机值也是一种帮助防止恶意实体干扰或中断与MRB的另一AS会话的方法。事实上，请求和响应中的序列号必须匹配，未能提供正确的序列号将导致会话失败和405错误消息。
1. AS -> MRB (HTTP POST, Consumer request) ------------------------------------------ POST /Mrb/Consumer HTTP/1.1 Content-Length: 893 Content-Type: application/mrb-consumer+xml Host: mrb.example.com:8080 Connection: Keep-Alive User-Agent: Apache-HttpClient/4.0.1 (java 1.5)
1. AS->MRB（HTTP POST，消费者请求）--------------------------------------POST/MRB/Consumer HTTP/1.1内容长度：893内容类型：应用程序/MRB消费者+xml主机：MRB.example.com:8080连接：保持活动用户代理：Apache HttpClient/4.0.1（java 1.5）
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="n3un93wd">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="n3un93wd">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
2. AS <- MRB (200 to POST, Consumer response) --------------------------------------------- HTTP/1.1 200 OK X-Powered-By: Servlet/2.5 Server: Sun GlassFish Communications Server 1.5 Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1 Content-Length: 1146 Date: Thu, 28 Jul 2011 10:34:45 GMT
2. AS<-MRB（200-to-POST，Consumer response）-------------------------------------------------------------HTTP/1.1 200 OK X-Powered-By:Servlet/2.5服务器：Sun GlassFish通信服务器1.5内容类型：应用程序/MRB消费者+xml；charset=ISO-8859-1内容长度：1146日期：2011年7月28日星期四10:34:45 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceResponse reason="Resource found" status="200"
id="n3un93wd">
<response-session-info>
<session-id>z603G3yaUzM8</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceResponse reason="Resource found" status="200"
id="n3un93wd">
<response-session-info>
<session-id>z603G3yaUzM8</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
For the sake of conciseness, the subsequent steps are not presented. They are very trivial, since they basically consist of the AS issuing a COMEDIA negotiation with either of the obtained MS, as already presented in Section 5. The same can be said with respect to attaching UAC media dialogs. In fact, since after the Query the AS<->MS interaction becomes 1:1, UAC media dialogs can be redirected directly to the proper MS using the 3PCC approach, e.g., as shown in Figure 10.
为简洁起见，不介绍后续步骤。它们是非常琐碎的，因为它们基本上包括和获得的任何一位女士进行喜剧谈判，如第5节所述。对于附加UAC媒体对话框也可以这样说。事实上，由于查询后AS<->MS交互变为1:1，UAC媒体对话框可以使用3PCC方法直接重定向到适当的MS，如图10所示。
Unlike the Query mode, in the Inline-Aware MRB Mode (IAMM) the AS sends Consumer requests by means of SIP. Of course, saying that the transport changes from HTTP to SIP is not as trivial as it seems. In fact, HTTP and SIP behave in very different ways, and this is reflected in the way the Inline-aware mode is conceived.
与查询模式不同，在内联感知MRB模式（IAMM）中，AS通过SIP发送消费者请求。当然，说传输从HTTP更改为SIP并不像看上去那么简单。事实上，HTTP和SIP的行为方式非常不同，这反映在内联感知模式的构思上。
An AS willing to issue a Consumer request by means of SIP has to do so by means of an INVITE. As specified in [RFC6917], the payload of the INVITE can't contain only the Consumer request itself. In fact, the Consumer request is assumed to be carried within a SIP transaction. A Consumer session is not strictly associated with the lifetime of any SIP transaction, meaning that Consumer requests belonging to the same session may be transported over different SIP messages; therefore, a hangup on any of these SIP dialogs would not affect a Consumer session.
愿意通过SIP发出消费者请求的AS必须通过INVITE发出请求。如[RFC6917]中所述，INVITE的有效负载不能仅包含使用者请求本身。事实上，假定消费者请求在SIP事务中进行。消费者会话与任何SIP事务的生存期没有严格关联，这意味着属于同一会话的消费者请求可以通过不同的SIP消息传输；因此，任何这些SIP对话框的挂断都不会影响使用者会话。
That said, as documented in [RFC6230], [RFC6917] envisages two kinds of SIP dialogs over which a Consumer request may be sent: a SIP control dialog (a SIP dialog sent by the AS in order to set up a Control Channel) and a UAC media dialog (a SIP dialog sent by the AS in order to attach a UAC to an MS). In both cases, the AS would prepare a multipart/mixed payload to achieve both ends, i.e., receiving a reply to its Consumer request and effectively carrying on the negotiation described in the SDP payload.
也就是说，如[RFC6230]中所述，[RFC6917]设想了两种SIP对话框，消费者请求可以通过它们发送：SIP控制对话框（as发送的SIP对话框，用于设置控制通道）和UAC媒体对话框（as发送的SIP对话框，用于将UAC连接到MS）。在这两种情况下，AS将准备多部分/混合有效载荷以实现两个目的，即，接收对其消费者请求的答复并有效地进行SDP有效载荷中描述的协商。
The behaviors in the two cases, which are called the CFW-based approach and the media dialog-based approach, respectively, are only slightly different, but both will be presented to clarify how they could be exploited. To make things clearer for the reader, the same Consumer request as the Consumer request presented in the Query mode will be sent, in order to clarify how the behavior of the involved parties may differ.
这两种情况下的行为，分别称为基于CFW的方法和基于媒体对话的方法，只是略有不同，但将介绍这两种方法，以阐明如何利用它们。为了让读者更清楚，将发送与查询模式中呈现的消费者请求相同的消费者请求，以澄清相关方的行为可能有何不同。
Figure 49 presents a ladder diagram of a typical Consumer request in the CFW-based Inline-aware topology:
图49显示了基于CFW的内联感知拓扑中典型消费者请求的梯形图：
AS MRB MS
| | |
| 1. INVITE | |
| (multipart/mixed: | |
| application/cfw, | |
| application/mrb-consumer+xml) |
|---------------------->| |
| 2. 100 (Trying) | |
|<----------------------| |
| |--+ Extract SDP and |
| | | MRB payloads; handle |
| |<-+ Consumer request to |
| | pick MS |
| | |
AS MRB MS
| | |
| 1. INVITE | |
| (multipart/mixed: | |
| application/cfw, | |
| application/mrb-consumer+xml) |
|---------------------->| |
| 2. 100 (Trying) | |
|<----------------------| |
| |--+ Extract SDP and |
| | | MRB payloads; handle |
| |<-+ Consumer request to |
| | pick MS |
| | |
| | 3. INVITE |
| | (application/cfw from 1.) |
| |-------------------------->|
| | 4. 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate
| | | | CFW Control
| | |<-+ Channel
| | 5. 200 OK |
| | (application/cfw from MS) |
| |<--------------------------|
| | 6. ACK |
| |-------------------------->|
| Prepare new +--| |
| payload with | | |
| SDP from MS and +->| |
| Consumer reply | |
| | |
| 7. 200 OK | |
| (multipart/mixed: | |
| application/cfw from MS, |
| application/mrb-consumer+xml) |
|<----------------------| |
| 8. ACK | |
|---------------------->| |
| | |
|--+ Read Consumer | |
| | reply and use SDP | |
|<-+ to create CFW Chn. | |
| | |
| |
|<<############## TCP CONNECTION #################>>|
| |
| CFW SYNC |
|++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
. . .
. . .
| | 3. INVITE |
| | (application/cfw from 1.) |
| |-------------------------->|
| | 4. 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate
| | | | CFW Control
| | |<-+ Channel
| | 5. 200 OK |
| | (application/cfw from MS) |
| |<--------------------------|
| | 6. ACK |
| |-------------------------->|
| Prepare new +--| |
| payload with | | |
| SDP from MS and +->| |
| Consumer reply | |
| | |
| 7. 200 OK | |
| (multipart/mixed: | |
| application/cfw from MS, |
| application/mrb-consumer+xml) |
|<----------------------| |
| 8. ACK | |
|---------------------->| |
| | |
|--+ Read Consumer | |
| | reply and use SDP | |
|<-+ to create CFW Chn. | |
| | |
| |
|<<############## TCP CONNECTION #################>>|
| |
| CFW SYNC |
|++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
. . .
. . .
Figure 49: Media Resource Brokering: CFW-Based Inline-Aware Mode
图49：媒体资源代理：基于CFW的内联感知模式
To make the scenario easier to understand, we assume that the AS is interested in exactly the same set of requirements as those presented in Section 7.2.1. This means that the Consumer request originated by the AS will be the same as before, with only the transport/topology changing.
为了使场景更容易理解，我们假设AS对与第7.2.1节中所述需求完全相同的需求集感兴趣。这意味着AS发起的使用者请求将与以前相同，只是传输/拓扑发生了变化。
Please note that to make the protocol contents easier to read, a simple 'Part' is used whenever a boundary for a multipart/mixed payload is provided, instead of the actual boundary that would be inserted in the SIP messages.
请注意，为了使协议内容更易于阅读，只要提供了多部分/混合负载的边界，就会使用一个简单的“部分”，而不是插入SIP消息中的实际边界。
The framework transaction steps (for simplicity's sake, only the payloads, and not the complete SIP transactions, are reported) are as follows:
框架事务步骤（为了简单起见，只报告有效负载，而不报告完整的SIP事务）如下所示：
1. AS -> MRB (INVITE multipart/mixed) ------------------------------------- [..] Content-Type: multipart/mixed;boundary="Part"
1. AS->MRB（邀请多部分/混合）--------------------------------------[..]内容类型：多部分/混合；boundary=“Part”
--Part
Content-Type: application/sdp
--Part
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
--Part Content-Type: application/mrb-consumer+xml
--零件内容类型：应用程序/mrb消费者+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="fr34asx1">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="fr34asx1">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
--Part
--部分
3. MRB -> MS (INVITE SDP only) ------------------------------ [..] Content-Type: application/sdp
3. MRB->MS（仅邀请SDP）-------------------------------------[…]内容类型：应用程序/SDP
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
v=0
o=- 2890844526 2890842807 IN IP4 as.example.com
s=MediaCtrl
c=IN IP4 as.example.com
t=0 0
m=application 48035 TCP cfw
a=connection:new
a=setup:active
a=cfw-id:vF0zD4xzUAW9
5. MRB <- MS (200 OK SDP) ------------------------- [..] Content-Type: application/sdp
5. MRB<-MS（200正常SDP）-------------[…]内容类型：应用程序/SDP
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
7. AS <- MRB (200 OK multipart/mixed) ------------------------------------- [..] Content-Type: multipart/mixed;boundary="Part"
7. AS<-MRB（200正常多部分/混合）--------------------------------------[..]内容类型：多部分/混合；boundary=“Part”
--Part
Content-Type: application/sdp
--Part
Content-Type: application/sdp
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:vF0zD4xzUAW9
--Part Content-Type: application/mrb-consumer+xml
--零件内容类型：应用程序/mrb消费者+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceResponse reason="Resource found" status="200"
id="fr34asx1">
<response-session-info>
<session-id>z603G3yaUzM8</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceResponse reason="Resource found" status="200"
id="fr34asx1">
<response-session-info>
<session-id>z603G3yaUzM8</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
--Part
--部分
The sequence diagram and the dumps effectively show the different approach with respect to the Query mode. The SIP INVITE sent by the AS (1.) includes both a Consumer request (the same as before) and an SDP to negotiate a CFW channel with an MS. The MRB takes care of the request exactly as before (provisioning two MS instances) but with a remarkable difference: first of all, it picks one of the two MS instances on behalf of the AS (negotiating the Control Channel in steps 3 to 6) and only then replies to the AS with both the MS side of the SDP negotiation (with information on how to set up the Control Channel) and the Consumer response itself.
序列图和转储有效地显示了查询模式的不同方法。AS（1.）发送的SIP INVITE包括消费者请求（与之前相同）和SDP，以与MS协商CFW通道。MRB与之前完全一样（提供两个MS实例）处理请求，但有一个显著的区别：首先，它代表AS从两个MS实例中选择一个（在步骤3至6中协商控制信道），然后才与SDP协商的MS侧（包含关于如何设置控制信道的信息）和消费者响应本身一起回复AS。
The Consumer response is also slightly different in the first place. In fact, as can be seen in 7., there's an additional element (<connection-id>) that the MRB has added to the message. This element contains the 'connection-id' that the AS and MS would have built out of the 'From' and 'To' tags as explained in Section 6, had the AS contacted the MS directly. Since the MRB has actually done the negotiation on behalf of the AS, without this information the AS and MS would refer to different connectionid attributes to target the same dialog, thus causing the CFW protocol not to behave as expected. This aspect will be more carefully described in the next section (for the media dialog-based approach), since the 'connection-id' attribute is strictly related to media sessions.
首先，消费者的反应也略有不同。事实上，如图7所示，MRB向消息中添加了一个额外的元素（<connection id>）。如第6节所述，如果AS直接与MS联系，该元素包含AS和MS本应使用“发件人”和“收件人”标记构建的“连接id”。由于MRB实际上代表AS进行了协商，如果没有此信息，AS和MS将引用不同的connectionid属性以指向同一个对话框，从而导致CFW协议的行为不符合预期。这方面将在下一节（对于基于媒体对话框的方法）中更详细地描述，因为“连接id”属性与媒体会话严格相关。
As before, for the sake of conciseness the subsequent steps of the previous transaction are quite trivial and therefore are not presented. In fact, as shown in the flow, the SIP negotiation has resulted in both the AS and the chosen MS negotiating a Control Channel. This means that the AS is only left to instantiate the Control Channel and send CFW requests according to its application logic.
与前面一样，为了简洁起见，前面事务的后续步骤非常琐碎，因此不提供。事实上，如流程所示，SIP协商已导致as和所选MS协商控制信道。这意味着AS只剩下实例化控制通道并根据其应用程序逻辑发送CFW请求。
It is worthwhile to highlight the fact that, as in the Query example, the AS gets the addresses of both of the chosen MS in this example as well, since a Consumer transaction has taken place. This means that, just as in the Query case, any UAC media dialog can be redirected directly to the proper MS using the 3PCC approach, e.g., as shown in Figure 10, rather than again using the MRB as a Proxy/B2BUA. Of course, a separate SIP control dialog would be needed before attempting to use the second MS instance.
值得强调的是，正如在查询示例中一样，as在本示例中也会获得两个所选MS的地址，因为已经发生了消费者事务。这意味着，就像在查询案例中一样，任何UAC媒体对话框都可以使用3PCC方法直接重定向到适当的MS，如图10所示，而不是再次使用MRB作为代理/B2BUA。当然，在尝试使用第二个MS实例之前，需要一个单独的SIP控制对话框。
There's a second way to take advantage of the IAMM mode, i.e., exploiting SIP dialogs related to UAC media dialogs as 'vessels' for Consumer messages. As will be made clearer in the following sequence diagram and protocol dumps, this scenario does not differ much from the scenario presented in Section 7.2.2.1 with respect to the Consumer request/response, but it may be useful to compare these two scenarios and show how they may differ with respect to the management of the media dialog itself and any CFW Control Channel that may be involved.
还有第二种方法可以利用IAMM模式，即利用与UAC媒体对话框相关的SIP对话框作为消费者消息的“容器”。如以下序列图和协议转储中所述，该场景与第7.2.2.1节中关于消费者请求/响应的场景差别不大，但是，比较这两种情况并说明它们在媒体对话框本身的管理和可能涉及的任何CFW控制通道方面的不同可能是有用的。
Figure 50 presents a ladder diagram of a typical Consumer request in the media dialog-based Inline-aware topology:
图50显示了基于媒体对话框的内联感知拓扑中典型消费者请求的梯形图：
UAC AS MRB MS
| | | |
| 1. INVITE | | |
| (audio/video) | | |
|-------------->| | |
| 2. 100 Trying | | |
|<--------------| | |
| | 3. INVITE | |
| | (multipart/mixed: | |
| | audio/video from 1., | |
| | application/mrb-consumer+xml) |
| |---------------------->| |
| | 4. 100 (Trying) | |
| |<----------------------| |
| | |--+ Extract SDP and |
| | | | MRB payloads; handle |
| | |<-+ Consumer request to |
| | | pick Media Servers |
| | | |
| | | 5. INVITE |
| | | (audio/video from 3.) |
| | |------------------------->|
UAC AS MRB MS
| | | |
| 1. INVITE | | |
| (audio/video) | | |
|-------------->| | |
| 2. 100 Trying | | |
|<--------------| | |
| | 3. INVITE | |
| | (multipart/mixed: | |
| | audio/video from 1., | |
| | application/mrb-consumer+xml) |
| |---------------------->| |
| | 4. 100 (Trying) | |
| |<----------------------| |
| | |--+ Extract SDP and |
| | | | MRB payloads; handle |
| | |<-+ Consumer request to |
| | | pick Media Servers |
| | | |
| | | 5. INVITE |
| | | (audio/video from 3.) |
| | |------------------------->|
| | | 6. 100 (Trying) |
| | |<-------------------------|
| | | +--|
| | | Handle media dialog | |
| | | (connection-id) +->|
| | | |
| | | 7. 200 OK |
| | | (audio/video from MS) |
| | |<-------------------------|
| | | 8. ACK |
| | |------------------------->|
| | Prepare new +--| |
| | payload with | | |
| | SDP from MS and +->| |
| | Consumer reply | |
| | | |
| | 9. 200 OK | |
| | (multipart/mixed: | |
| | audio/video from MS, |
| | application/mrb-consumer+xml) |
| |<----------------------| |
| | 10. ACK | |
| |---------------------->| |
| | | |
| |--+ Read Consumer | |
| | | reply and send | |
| |<-+ SDP back to UAC | |
| 11. 200 OK | | |
|(audio/video from MS) | |
|<--------------| | |
| 12. ACK | | |
|-------------->| | |
| | | |
|<<*************************** RTP ******************************>>|
| | | |
| |--+ Negotiate | |
| | | CFW channel | |
| |<-+ towards MS | |
| | (if needed) | |
. . . .
. . . .
| | | |
| |<<############## TCP CONNECTION ################>>|
| | |
| | | 6. 100 (Trying) |
| | |<-------------------------|
| | | +--|
| | | Handle media dialog | |
| | | (connection-id) +->|
| | | |
| | | 7. 200 OK |
| | | (audio/video from MS) |
| | |<-------------------------|
| | | 8. ACK |
| | |------------------------->|
| | Prepare new +--| |
| | payload with | | |
| | SDP from MS and +->| |
| | Consumer reply | |
| | | |
| | 9. 200 OK | |
| | (multipart/mixed: | |
| | audio/video from MS, |
| | application/mrb-consumer+xml) |
| |<----------------------| |
| | 10. ACK | |
| |---------------------->| |
| | | |
| |--+ Read Consumer | |
| | | reply and send | |
| |<-+ SDP back to UAC | |
| 11. 200 OK | | |
|(audio/video from MS) | |
|<--------------| | |
| 12. ACK | | |
|-------------->| | |
| | | |
|<<*************************** RTP ******************************>>|
| | | |
| |--+ Negotiate | |
| | | CFW channel | |
| |<-+ towards MS | |
| | (if needed) | |
. . . .
. . . .
| | | |
| |<<############## TCP CONNECTION ################>>|
| | |
| | CFW SYNC |
| |+++++++++++++++++++++++++++++++++++++++++++++++++>|
| | |
. . . .
. . . .
| | CFW SYNC |
| |+++++++++++++++++++++++++++++++++++++++++++++++++>|
| | |
. . . .
. . . .
Figure 50: Media Resource Brokering: Media Dialog-Based Inline-Aware Mode
图50：媒体资源代理：基于媒体对话框的内联感知模式
To make the scenario easier to understand, we assume that the AS is interested in exactly the same set of requirements as those presented in Section 7.2.1. This means that the Consumer request originated by the AS will be the same as before, with only the transport/topology changing.
为了使场景更容易理解，我们假设AS对与第7.2.1节中所述需求完全相同的需求集感兴趣。这意味着AS发起的使用者请求将与以前相同，只是传输/拓扑发生了变化。
Again, please note that to make the protocol contents easier to read, a simple 'Part' is used whenever a boundary for a multipart/mixed payload is provided, instead of the actual boundary that would be inserted in the SIP messages.
同样，请注意，为了使协议内容更易于阅读，只要提供了多部分/混合负载的边界，就会使用一个简单的“部分”，而不是插入SIP消息中的实际边界。
The framework transaction steps (for simplicity's sake, only the relevant headers and payloads, and not the complete SIP transactions, are reported) are as follows:
框架事务步骤（为了简单起见，只报告相关的头和有效负载，而不报告完整的SIP事务）如下所示：
1. UAC -> AS (INVITE with media SDP) ------------------------------------ [..] From: <sip:lminiero@users.example.com>;tag=1153573888 To: <sip:mediactrlDemo@as.example.com> [..] Content-Type: application/sdp
1. UAC->AS（邀请媒体SDP）--------------------------------------[…]发件人：<sip:lminiero@users.example.com>;标签=1153573888至：<sip:mediactrlDemo@as.example.com>[…]内容类型：应用程序/sdp
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
3. AS -> MRB (INVITE multipart/mixed) ------------------------------------- [..] From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5 To: <sip:Mrb@mrb.example.org> [..] Content-Type: multipart/mixed;boundary="Part"
3. AS->MRB（邀请多部分/混合）--------------------------------------[…]发件人：<sip:ApplicationServer@as.example.com>;标签=FD4FUS5至：<sip:Mrb@mrb.example.org>[…]内容类型：多部分/混合；boundary=“Part”
--Part
Content-Type: application/sdp
--Part
Content-Type: application/sdp
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
--Part Content-Type: application/mrb-consumer+xml
--零件内容类型：应用程序/mrb消费者+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="bnv3xc45">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="bnv3xc45">
<generalInfo>
<packages>
<package>msc-ivr/1.0</package>
<package>msc-mixer/1.0</package>
</packages>
</generalInfo>
<ivrInfo>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>100</decoding>
<encoding>100</encoding>
</rtp-codec>
</ivr-sessions>
<file-formats>
<required-format name="audio/x-wav"/>
</file-formats>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
<file-transfer-modes>
<file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
</file-transfer-modes>
</ivrInfo>
</mediaResourceRequest>
</mrbconsumer>
--Part
--部分
5. MRB -> MS (INVITE SDP only) ------------------------------ [..] From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8 To: <sip:MediaServer@ms.example.com:5080> [..] Content-Type: application/sdp
5. MRB->MS（仅邀请SDP）-------------------------------------[…]发件人：<sip:Mrb@mrb.example.org:5060>;标签=32pbdxZ8至：<sip:MediaServer@ms.example.com：5080>[…]内容类型：应用程序/sdp
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
v=0
o=lminiero 123456 654321 IN IP4 203.0.113.2
s=A conversation
c=IN IP4 203.0.113.2
t=0 0
m=audio 7078 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9078 RTP/AVP 98
7. MRB <- MS (200 OK SDP) ------------------------- [..] From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8 To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF [..] Content-Type: application/sdp
7. MRB<-MS（200正常SDP）-------------[…]发件人：<sip:Mrb@mrb.example.org:5060>;标签=32pbdxZ8至：<sip:MediaServer@ms.example.com:5080>;tag=KQw677BF[…]内容类型：应用程序/sdp
v=0
o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl
c=IN IP4 203.0.113.1
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
v=0
o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl
c=IN IP4 203.0.113.1
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
9. AS <- MRB (200 OK multipart/mixed) ------------------------------------- [..] From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5 To: <sip:Mrb@mrb.example.org>;tag=117652221 [..] Content-Type: multipart/mixed;boundary="Part"
9. AS<-MRB（200正常多部分/混合）---------------------------------------[…]来自：<sip:ApplicationServer@as.example.com>;标签=FD4FUS5至：<sip:Mrb@mrb.example.org>;标签=11765221[…]内容类型：多部分/混合；boundary=“Part”
--Part
Content-Type: application/sdp
--Part
Content-Type: application/sdp
v=0
o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl
c=IN IP4 203.0.113.1
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
v=0
o=lminiero 123456 654322 IN IP4 203.0.113.1
s=MediaCtrl
c=IN IP4 203.0.113.1
t=0 0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
--Part Content-Type: application/mrb-consumer+xml
--零件内容类型：应用程序/mrb消费者+xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200"
id="bnv3xc45">
<response-session-info>
<session-id>z1skKYZQ3eFu</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
<mediaResourceResponse reason="Resource found" status="200"
id="bnv3xc45">
<response-session-info>
<session-id>z1skKYZQ3eFu</session-id>
<seq>9</seq>
<expires>3600</expires>
<media-server-address
uri="sip:MediaServer@ms.example.com:5080">
<connection-id>32pbdxZ8:KQw677BF</connection-id>
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>60</decoding>
<encoding>60</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
<media-server-address
uri="sip:OtherMediaServer@pool.example.net:5080">
<ivr-sessions>
<rtp-codec name="audio/basic">
<decoding>40</decoding>
<encoding>40</encoding>
</rtp-codec>
</ivr-sessions>
</media-server-address>
</response-session-info>
</mediaResourceResponse>
</mrbconsumer>
--Part
--部分
11. UAC <- AS (200 OK SDP) -------------------------- [..] From: <sip:lminiero@users.example.com>;tag=1153573888 To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32 [..] Content-Type: application/sdp
11. UAC<-AS（200正常SDP）------------------------------------[…]发件人：<sip:lminiero@users.example.com>;标签=1153573888至：<sip:mediactrlDemo@as.example.com>;标签=bcd47c32[…]内容类型：应用程序/sdp
v=0 o=lminiero 123456 654322 IN IP4 203.0.113.1 s=MediaCtrl c=IN IP4 203.0.113.1 t=0 0
v=0 o=IP4 203.0.113.1中的lminiero 123456 654322 s=MediaCtrl c=IP4 203.0.113.1中的t=0
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
m=audio 63442 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=label:7eda834
m=video 33468 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 CIF=2
a=label:0132ca2
The first obvious difference is that the first INVITE (1.) is not originated by the AS itself (the AS was willing to set up a Control Channel in the previous example) but by an authorized UAC (e.g., to take advantage of a media service provided by the AS). As such, the first INVITE only contains an SDP to negotiate an audio and video channel. The AS in its business logic needs to attach this UAC to an MS according to some specific requirements (e.g., the called URI is associated to a specific service) and as such prepares a Consumer request to be sent to the MRB in order to obtain a valid MS for that purpose. As before, the Consumer request is sent together with the SDP to the MRB (3.). The MRB extracts the Consumer payload and takes care of it as usual; it picks two MS instances and attaches the UAC to the first MS instance (5.). Once the MS has successfully negotiated the audio and video streams (7.), the MRB takes note of the 'connection-id' associated with this call (which will be needed afterwards in order to manipulate the audio and video streams for this user) and sends back to the AS both the SDP returned by the MS and the Consumer response (9.). The AS extracts the Consumer response and takes note of both the MS instances it has been given and the connection-id information. It then completes the scenario by sending back to the UAC the SDP returned by the MS (11.).
第一个明显的区别是，第一个邀请（1）不是由AS本身发起的（AS在前一示例中愿意设置控制通道），而是由授权UAC发起的（例如，利用AS提供的媒体服务）。因此，第一个INVITE只包含一个SDP来协商音频和视频频道。AS在其业务逻辑中需要根据某些特定要求（例如，被调用的URI与特定服务相关联）将此UAC连接到MS，并因此准备将消费者请求发送到MRB，以获得用于该目的的有效MS。与前面一样，消费者请求与SDP一起发送到MRB（3）。MRB提取消费者有效载荷并照常处理；它选择两个MS实例并将UAC连接到第一个MS实例（5）。一旦MS成功协商音频和视频流（7），MRB将记录与此呼叫相关联的“连接id”（随后需要该id以便为该用户操作音频和视频流），并将MS返回的SDP和消费者响应（9）发送回AS。AS提取使用者响应，并记录已给出的MS实例和连接id信息。然后，它通过将MS返回的SDP发送回UAC来完成场景（11）。
At this point, the UAC has successfully been attached to an MS. The AS only needs to set up a Control Channel to that MS, if needed. This step may not be required, especially if the Consumer request is an update to an existing session rather than the preparation of a new session. Assuming that a Control Channel towards that MS doesn't exist yet, the AS creates it as usual by sending an INVITE directly to the MS for which it has an address. Once done with that, it can start manipulating the audio and video streams of the UAC. To do so, it refers to the <connection-id> element as reported by the MRB, rather than relying on the <connection-id> element that it is aware of. In fact, the AS is aware of a connection-id value (fd4fush5: 117652221, built out of the messages exchanged with the MRB), while the MS is aware of another (32pbdxZ8:KQw677BF, built out of the
此时，UAC已成功连接到MS。AS只需在需要时设置到该MS的控制通道。可能不需要此步骤，尤其是当使用者请求是对现有会话的更新而不是准备新会话时。假设指向该MS的控制通道还不存在，AS会像往常一样通过直接向其拥有地址的MS发送邀请来创建它。一旦完成，它就可以开始操作UAC的音频和视频流。为此，它引用MRB报告的<connection id>元素，而不是依赖于它知道的<connection id>元素。事实上，AS知道一个连接id值（FD4FUS5:11765221，构建于与MRB交换的消息），而MS知道另一个连接id值（32pbdxZ8:KQw677BF，构建于MRB）
MRB-MS interaction). The right connection-id is of course the one the MS is aware of, and as such the AS refers to that connection-id, which the MRB added to the Consumer response just for that purpose.
MRB-MS交互作用）。正确的连接id当然是MS知道的连接id，因此as指的是该连接id，MRB添加到消费者响应中就是为了这个目的。
Whereas in the Inline-aware mode the AS knows it is sending an INVITE to an MRB and not to an MS, and acts accordingly (using the multipart/mixed payload to query for an MS able to fulfill its requirements), in the Inline-Unaware MRB Mode (IUMM) the AS does not distinguish an MRB from an MS. This means that an MRB-unaware AS having access to an MRB talks to it as if it were a generic MEDIACTRL MS: i.e., the AS negotiates a Control Channel directly with the MRB and attaches its media dialogs there as well. Of course, since the MRB doesn't provide any MS functionality by itself, it must act as a Proxy/B2BUA between the AS and an MS for both the Control Channel dialog and the media dialogs. According to implementation or deployment choices, simple redirects could also be exploited for that purpose.
而在内联感知模式下，AS知道它正在向MRB而不是MS发送邀请，并在内联感知MRB模式（IUMM）下相应地采取行动（使用多部分/混合负载查询能够满足其要求的MS）AS不区分MRB和MS。这意味着，不知道AS有权访问MRB的MRB会像普通MEDIACTRL-MS一样与之交谈：即，AS直接与MRB协商控制通道，并将其媒体对话框连接在那里。当然，由于MRB本身不提供任何MS功能，因此它必须充当as和MS之间的代理/B2BUA，用于控制通道对话框和媒体对话框。根据实现或部署选择，也可以利用简单重定向来实现此目的。
The problem is that without any Consumer request being placed by the MRB-unaware AS the MRB can't rely on AS-originated directives to pick one MS rather than another. In fact, the MRB can't know what the AS is looking for. The MRB is then assumed to pick one according to its logic, which is implementation specific.
问题是，如果MRB不知道用户请求，MRB就不能依赖原始指令来选择一个MS而不是另一个MS。事实上，MRB不知道AS在寻找什么。然后假设MRB根据其逻辑选择一个，这是特定于实现的。
Figure 51 presents a ladder diagram of a typical Consumer request in the Inline-unaware topology:
图51显示了内联拓扑中典型消费者请求的梯形图：
AS MRB MS
| | |
| 1. INVITE | |
| (application/cfw) | |
|---------------------->| |
| 2. 100 (Trying) | |
|<----------------------| |
| |--+ Pick an MS |
| | | and redirect |
| |<-+ INVITE there |
| | |
| | 3. INVITE |
| | (application/cfw from 1.) |
| |-------------------------->|
| | 4. 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate
| | | | CFW Control
| | |<-+ Channel
| | 5. 200 OK |
| | (application/cfw from MS) |
| |<--------------------------|
| | 6. ACK |
| |-------------------------->|
| | |
| 7. 200 OK | |
|(application/cfw from MS) |
|<----------------------| |
| 8. ACK | |
|---------------------->| |
| | |
| |
|<<############## TCP CONNECTION #################>>|
| |
| CFW SYNC |
|++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
. . .
. . .
AS MRB MS
| | |
| 1. INVITE | |
| (application/cfw) | |
|---------------------->| |
| 2. 100 (Trying) | |
|<----------------------| |
| |--+ Pick an MS |
| | | and redirect |
| |<-+ INVITE there |
| | |
| | 3. INVITE |
| | (application/cfw from 1.) |
| |-------------------------->|
| | 4. 100 (Trying) |
| |<--------------------------|
| | |--+ Negotiate
| | | | CFW Control
| | |<-+ Channel
| | 5. 200 OK |
| | (application/cfw from MS) |
| |<--------------------------|
| | 6. ACK |
| |-------------------------->|
| | |
| 7. 200 OK | |
|(application/cfw from MS) |
|<----------------------| |
| 8. ACK | |
|---------------------->| |
| | |
| |
|<<############## TCP CONNECTION #################>>|
| |
| CFW SYNC |
|++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
. . .
. . .
Figure 51: Media Resource Brokering: Inline-Unaware Mode
图51：媒体资源代理：内联模式
As can be seen in the diagram, in this topology the MRB basically acts as a 3PCC between the AS and the chosen MS.
从图中可以看出，在这种拓扑结构中，MRB基本上充当As和所选MS之间的3PCC。
The same can be said with respect to attaching UAC media dialogs. The MRB remembers the MS it has chosen for the AS, and for every UAC media dialog the AS tries to attach to the MRB, it makes sure that it is somehow actually redirected to the MS.
对于附加UAC媒体对话框也可以这样说。MRB会记住它为AS选择的MS，对于AS尝试连接到MRB的每个UAC媒体对话框，它会确保它以某种方式实际重定向到MS。
No content for the presented messages is provided in this section, as in the IUMM mode no Consumer transaction is involved. In this example, a simple [RFC6230] Control Channel negotiation occurs where the MRB acts as an intermediary, that is, picking an MS for the AS according to some logic. In this case, in fact, the AS does not support the MRB specification and so just tries to set up a Control Channel according to its own logic.
本节未提供所呈现消息的内容，因为在IUMM模式下，不涉及消费者交易。在此示例中，发生简单的[RFC6230]控制信道协商，其中MRB充当中介，即，根据某些逻辑为as选择MS。在这种情况下，事实上，AS不支持MRB规范，因此仅尝试根据其自身的逻辑设置控制通道。
It is worth pointing out that the MRB may actually enforce its decision about the MS to grant to the AS in different ways. Specifically, the sentence "redirect the INVITE" that is used in Figure 51 does not necessarily mean that a SIP 302 message should be used for that purpose. A simple way to achieve this may be provisioning the unaware AS with different URIs, all actually transparently handled by the MRB itself; this would allow the MRB to simply map those URIs to different MS instances. The SIP 'Contact' header may also be used by the MRB in a reply to an INVITE coming from an AS to provide the actual URI on which the chosen MS might be reached. A motivation for such a discussion, and more details on this topic, are provided in Section 7.3.2.
值得指出的是，MRB实际上可能会以不同的方式强制执行MS授予AS的决定。具体地说，图51中使用的句子“重定向INVITE”并不一定意味着应为此目的使用SIP 302消息。实现这一点的一个简单方法可能是使用不同的uri来配置unknowledge，所有uri实际上都是由MRB本身透明地处理的；这将允许MRB简单地将这些URI映射到不同的MS实例。MRB还可以在答复来自AS的邀请时使用SIP“Contact”头，以提供可能到达所选MS的实际URI。第7.3.2节提供了此类讨论的动机以及有关此主题的更多详细信息。
It is worthwhile to briefly address how media dialogs would be managed whenever an MRB is involved in the following scenarios. In fact, the presence of an MRB may introduce an additional complexity compared to the quite straightforward 1:1 AS-MS topology.
当MRB涉及以下场景时，有必要简要说明如何管理媒体对话。事实上，与非常简单的1:1 AS-MS拓扑相比，MRB的存在可能会带来额外的复杂性。
Normally, especially in the Query and IAMM case, the MRB would only handle Consumer requests by an AS, and after that the AS and the MS picked by the MRB for a specific request would talk directly to each other by means of SIP. This is made possible by the fact that the AS gets the MS SIP URI in reply to its request. In this case, an AS can simply relay media dialogs associated with that session to the right MS to have them handled accordingly. Of course, in order for this to work it is assumed that the AS creates a Control Channel to a chosen MS before it has any requests to service.
通常，特别是在查询和IAMM的情况下，MRB将只处理AS发出的消费者请求，然后，MRB为特定请求选择的AS和MS将通过SIP直接相互交谈。这是因为AS获得MS SIP URI以响应其请求。在这种情况下，AS可以简单地将与该会话相关联的媒体对话框中继到正确的MS，以便对其进行相应的处理。当然，为了使其工作，假设AS在有任何服务请求之前创建了到所选MS的控制信道。
An example of such a scenario is presented in Figure 52. Please note that this diagram and subsequent diagrams in this section are simplified with respect to the actual protocol interactions. For
图52给出了这样一个场景的示例。请注意，此图和本节中的后续图根据实际协议交互进行了简化。对于
instance, the whole SIP transactions are not presented, and only the originating messages are presented in order to clarify the scenario in a simple way.
例如，不显示整个SIP事务，只显示原始消息，以便以简单的方式澄清场景。
UAC AS MRB MS
| | | |
| | 1. Consumer request | |
| |--------------------------->| |
| | | |
| | 2. Consumer response | |
| |<---------------------------| |
| | | |
| | 3. COMEDIA negotiation to create CFW channel |
| |-------------------------------------------------->|
| | | |
| |<<############## CFW CONNECTION #################>>|
| 4. INVITE xyz | | |
|--------------->| | |
| | 5. Attach UAC to MS (3PCC) |
| |-------------------------------------------------->|
| | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
UAC AS MRB MS
| | | |
| | 1. Consumer request | |
| |--------------------------->| |
| | | |
| | 2. Consumer response | |
| |<---------------------------| |
| | | |
| | 3. COMEDIA negotiation to create CFW channel |
| |-------------------------------------------------->|
| | | |
| |<<############## CFW CONNECTION #################>>|
| 4. INVITE xyz | | |
|--------------->| | |
| | 5. Attach UAC to MS (3PCC) |
| |-------------------------------------------------->|
| | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
Figure 52: Handling Media Dialogs in Query/IAMM
图52：在查询/IAMM中处理媒体对话框
As can be deduced from the diagram, the interactions among the components are quite straightforward. The AS knows which MS it has been assigned to (as a consequence of the MRB Consumer request, whether it has been achieved by means of HTTP or SIP), and so it can easily attach any UAC accessing its functionality to the MS itself and manipulate its media connections by using the CFW Control Channel as usual.
从图中可以推断，组件之间的交互非常简单。AS知道它被分配到了哪个MS（作为MRB消费者请求的结果，无论它是通过HTTP还是SIP实现的），因此它可以像往常一样轻松地将访问其功能的任何UAC连接到MS本身，并通过使用CFW控制信道操纵其媒体连接。
In such a scenario, the MRB is only involved as a locator. Once the MRB provides the AS with the URI of the required resource, it doesn't interfere with subsequent interactions unless it wants to perform monitoring (e.g., by exploiting the Publishing information reported by the MS). As a consequence, the scenario basically becomes 1:1 between the AS and the MS again.
在这种情况下，MRB仅作为定位器参与。一旦MRB向AS提供了所需资源的URI，它就不会干扰后续交互，除非它想要执行监视（例如，通过利用MS报告的发布信息）。因此，场景基本上在As和MS之间再次变成1:1。
Nevertheless, there are cases when having an MRB in the SIP signaling path as well might be a desired feature, e.g., for more control over the use of the resources. Considering how the Consumer interface has been envisaged, this feature is easily achievable, with no change to the protocol required at all. Specifically, in order to achieve such
然而，在SIP信令路径中具有MRB也可能是期望的特征的情况下，例如，为了对资源的使用进行更多控制。考虑到消费者界面是如何设想的，这一特性很容易实现，根本不需要更改协议。具体来说，为了实现这一目标
functionality, the MRB may reply to a Consumer request with a URI for which the MRB is responsible (rather than the MS SIP URI as discussed previously) and map this URI to the actual MS URI in its business logic; this would be transparent to the AS. This way, the AS would interact with the MRB as if it were the MS itself.
在功能上，MRB可以使用MRB负责的URI（而不是前面讨论的MS SIP URI）回复消费者请求，并将该URI映射到其业务逻辑中的实际MS URI；这对AS来说是透明的。这样，AS将与MRB交互，就好像它是MS本身一样。
Figure 53 shows how the scenario would change in this case.
图53显示了在这种情况下场景将如何变化。
UAC AS MRB MS
| | | |
| | 1. Consumer request | |
| |--------------------------->| |
| | | |
| | 2. Consumer response | |
| |<---------------------------| |
| | | |
| | 3. COMEDIA negotiation | |
| |--------------------------->| |
| | | 4. COMEDIA neg. |
| | |--------------------->|
| | | |
| |<<############## CFW CONNECTION #################>>|
| 5. INVITE xyz | | |
|--------------->| | |
| | 6. Attach UAC to MS (3PCC) | |
| |--------------------------->| |
| | | 7. Attach UAC (3PCC) |
| | |--------------------->|
| | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
UAC AS MRB MS
| | | |
| | 1. Consumer request | |
| |--------------------------->| |
| | | |
| | 2. Consumer response | |
| |<---------------------------| |
| | | |
| | 3. COMEDIA negotiation | |
| |--------------------------->| |
| | | 4. COMEDIA neg. |
| | |--------------------->|
| | | |
| |<<############## CFW CONNECTION #################>>|
| 5. INVITE xyz | | |
|--------------->| | |
| | 6. Attach UAC to MS (3PCC) | |
| |--------------------------->| |
| | | 7. Attach UAC (3PCC) |
| | |--------------------->|
| | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
Figure 53: Handling Media Dialogs in Query/IAMM: MRB in the Signaling Path
图53：在信令路径中处理查询/IAMM:MRB中的媒体对话框
This time, even though the MRB has picked a specific MS after a request from an AS, it replies with another SIP URI, a URI it would reply to itself. The AS would contact that URI in order to negotiate the Control Channel, and the MRB would proxy/forward the request to the actual MS transparently. Eventually, the Control Channel would be instantiated between the AS and the MS. The same happens for UACs handled by the AS; the AS would forward the calls to the URI provided to it, the one handled by the MRB, which would in turn relay the call to the MS in order to have the proper RTP channels created between the UAC and the MS.
这一次，即使MRB在AS的请求之后选择了一个特定的MS，它也会用另一个SIPURI进行回复，这个URI是它会回复自己的。AS将联系该URI以协商控制通道，MRB将透明地代理/转发请求到实际MS。最终，AS和MS之间的控制通道将被实例化。AS处理的UAC也是如此；AS将把调用转发给提供给它的URI，该URI由MRB处理，后者将把调用转发给MS，以便在UAC和MS之间创建正确的RTP通道。
This scenario is not very different from the previous scenario, except that the MRB is now on the signaling path for both the SIP control dialog and the SIP media dialogs, allowing it to have more control of the resources (e.g., triggering a BYE if a resource has expired). There are several possible approaches an MRB might take to allocate URIs to map to a requested MS. For example, an MRB might use SIP URI parameters to generate multiple SIP URIs that are unique but that all route to the same host and port, e.g., sip:MrbToMs@mrb.example.com:5080;p=1234567890. Alternatively, the MRB might simply allocate a pool of URIs for which it would be responsible and manage the associations with the requested MS services accordingly.
此场景与前一场景没有太大区别，除了MRB现在位于SIP控制对话框和SIP媒体对话框的信令路径上，允许其对资源进行更多控制（例如，如果资源已过期，则触发BYE）。MRB可以采取几种可能的方法来分配URI以映射到请求的MS。例如，MRB可以使用SIP URI参数来生成多个唯一但所有路由到同一主机和端口的SIP URI，例如：MrbToMs@mrb.example.com:5080;p=1234567890。或者，MRB可以简单地分配它将负责的URI池，并相应地管理与请求的MS服务的关联。
As mentioned previously, in the IUMM case the AS would interact with the MRB as if it were the MS itself. One might argue that this would make the AS act as it would in the IAMM case. This is not the case, however, since the AS actually provided the MRB with information about the resources it required, leading to the selection of a proper MS, while in the IUMM case the MRB would have to pick an MS with no help from the AS at all.
如前所述，在IUMM案例中，As将与MRB交互，就好像它是MS本身一样。有人可能会说，这将使AS像在IAMM案件中一样发挥作用。然而，情况并非如此，因为AS实际上向MRB提供了所需资源的信息，从而选择了合适的MS，而在IUMM的情况下，MRB将不得不在没有AS帮助的情况下选择MS。
That said, the IUMM case is also very interesting with respect to media dialog management. In fact, in the MRB-unaware mode, there would be no Consumer request, and an AS would actually see the MRB as an MS. Unlike the previous scenarios, because there is no AS<->MRB interaction and as such no MS selection process, the MRB would likely be in the signaling path anyway, at least when the AS first shows up. The MRB could either redirect the AS to an MS directly or transparently act as a Proxy/B2BUA and contact an MS (according to implementation-specific policies) on behalf of the unaware AS.
尽管如此，IUMM案例在媒体对话管理方面也非常有趣。事实上，在MRB Unknowledge模式下，将不会有消费者请求，AS实际上会将MRB视为MS。与之前的场景不同，因为没有AS<->MRB交互，因此没有MS选择过程，所以无论如何MRB都可能在信令路径中，至少在AS首次出现时是这样。MRB可以直接将AS重定向到MS，也可以透明地充当代理/B2BUA，并代表AS联系MS（根据具体实施策略）。
While apparently not a problem, this raises an issue when the same unaware AS has several sessions with different MS. The AS would only see one "virtual" MS (the MRB), and so it would relay all calls there, making it hard for the MRB to understand where these media dialogs should belong: specifically, whether the UAC calling belongs to the AS application logic leading to MS1 or MS2, or somewhere else.
虽然这显然不是问题，但当同一个AS与不同的MS有多个会话时，会产生一个问题。AS只会看到一个“虚拟”MS（MRB），因此它会在那里中继所有呼叫，使MRB很难理解这些媒体对话应该属于哪里：具体而言，UAC调用是否属于导致MS1或MS2的AS应用程序逻辑，或其他地方。
One possible, and very simple, approach to take care of this issue is to always relay the SIP dialogs from the same unaware AS to the same MS, as depicted in Figure 54.
解决此问题的一种可能且非常简单的方法是始终将SIP对话框从同一台机器中继到同一台机器，如图54所示。
UAC1 UAC2 AS MRB MS
| | | | |
| | | 1. COMEDIA negotiation (A) | |
| | |--------------------------->| |
| | | | 2. COMEDIA neg. (A) |
| | | |--------------------->|
| | | | |
| | |<<############## CFW CONNECTION #################>>|
| | | | |
| | | 3. COMEDIA negotiation (B) | |
| | |--------------------------->| |
| | | | 4. COMEDIA neg. (B) |
| | | |--------------------->|
| | | | |
| | |<<############## CFW CONNECTION #################>>|
| 5. INVITE xyz | | |
|--------------->| | |
| | | 6. Attach UAC1 to MS (3PCC)| |
| | |--------------------------->| |
| | | | 7. Attach UAC (3PCC) |
| | | |--------------------->|
| | | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | | |
| | 8. INVITE| | |
| | jkl | | |
| |--------->| | |
| | | 9. Attach UAC2 to MS (3PCC)| |
| | |--------------------------->| |
| | | | 10. Attach UAC (3PCC)|
| | | |--------------------->|
| | | | |
| |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | | |
. . . . .
. . . . .
UAC1 UAC2 AS MRB MS
| | | | |
| | | 1. COMEDIA negotiation (A) | |
| | |--------------------------->| |
| | | | 2. COMEDIA neg. (A) |
| | | |--------------------->|
| | | | |
| | |<<############## CFW CONNECTION #################>>|
| | | | |
| | | 3. COMEDIA negotiation (B) | |
| | |--------------------------->| |
| | | | 4. COMEDIA neg. (B) |
| | | |--------------------->|
| | | | |
| | |<<############## CFW CONNECTION #################>>|
| 5. INVITE xyz | | |
|--------------->| | |
| | | 6. Attach UAC1 to MS (3PCC)| |
| | |--------------------------->| |
| | | | 7. Attach UAC (3PCC) |
| | | |--------------------->|
| | | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | | |
| | 8. INVITE| | |
| | jkl | | |
| |--------->| | |
| | | 9. Attach UAC2 to MS (3PCC)| |
| | |--------------------------->| |
| | | | 10. Attach UAC (3PCC)|
| | | |--------------------->|
| | | | |
| |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | | |
. . . . .
. . . . .
Figure 54: Handling Media Dialogs in IUMM: Always the Same MS
图54：在IUMM中处理媒体对话框：始终使用相同的MS
In this example, the AS creates two different Control Channel sessions (A and B) to address two different business logic implementations; e.g., the AS SIP URI 'xyz' (associated with CFW session A) may be an IVR pizza-ordering application, while the AS SIP URI 'jkl' (associated with CFW session B) may be associated with a
在此示例中，AS创建两个不同的控制通道会话（A和B），以解决两个不同的业务逻辑实现；e、 例如，AS-SIP URI“xyz”（与CFW会话A相关联）可以是IVR比萨饼订购应用程序，而AS-SIP URI“jkl”（与CFW会话B相关联）可以与IVR比萨饼订购应用程序相关联
conference room. It's quite clear, then, that if the MRB forwarded the two CFW sessions to two different MS, the handling of UAC media dialogs would prove troublesome, because the MRB would have difficulty figuring out whether UAC1 should be attached to the MS managing CFW session A or the MS managing CFW session B. In this example, forwarding all CFW sessions and UAC media dialogs coming from the same MRB-unaware AS to the same MS would work as expected. The MRB would in fact leave the mapping of media dialogs and CFW sessions up to the AS.
会议室。很明显，如果MRB将两个CFW会话转发给两个不同的MS，UAC媒体对话框的处理将很麻烦，因为MRB将很难确定UAC1是否应连接到管理CFW会话A的MS或管理CFW会话B的MS。在本例中，将来自同一MRB的所有CFW会话和UAC媒体对话转发到同一MS将按预期工作。MRB实际上会将媒体对话和CFW会话的映射留给AS。
This approach, while very simple and indeed not very scalable, would actually help take care of the issue. In fact, no matter how many separate Control Channels the AS might have with the MRB/MS (in this example, Control Channel A would be mapped to application xyz and Control Channel B to application jkl), the termination point would still always be the same MS, which would consequently be the destination for all media dialogs as well.
这种方法虽然非常简单，实际上也不是很容易扩展，但实际上有助于解决这个问题。事实上，无论MRB/MS可能有多少独立的控制通道（在本例中，控制通道A将映射到应用程序xyz，控制通道B映射到应用程序jkl），终止点始终是相同的MS，因此也是所有媒体对话框的目的地。
To overcome the scalability limitations of such an approach, at least in regard to the MRB being in the SIP signaling path for all calls, a different approach needs to be exploited. In fact, especially in the case of different applications handled by the same unaware AS, it makes sense to try to exploit different MS for that purpose and to correctly track media dialogs being forwarded accordingly. This means that the MRB must find a way to somehow redirect the unaware AS to different MS when it predicts or realizes that a different application logic is involved.
为了克服这种方法的可伸缩性限制，至少就MRB位于所有呼叫的SIP信令路径而言，需要利用不同的方法。事实上，特别是在由同一个用户处理不同的应用程序的情况下，尝试利用不同的MS实现这一目的并正确跟踪相应转发的媒体对话是有意义的。这意味着，当MRB预测或意识到涉及不同的应用程序逻辑时，它必须找到一种方法，以某种方式将未知对象重定向到不同的MS。
To do so, the MRB might use different approaches. One approach would use redirection, e.g., by means of a SIP 302 message in reply to a Control Channel negotiation originated by an unaware AS. Such an approach is depicted in Figure 55.
为此，MRB可能会使用不同的方法。一种方法将使用重定向，例如通过SIP 302消息来响应由不知情AS发起的控制信道协商。这种方法如图55所示。
UAC1 AS MRB MS
| | | |
| | 1. COMEDIA negotiation | |
| |--------------------------->| |
| | | |
| | 2. 302 Moved (MS) | |
| |<---------------------------| |
| | | |
| | 3. COMEDIA negotiation | |
| |-------------------------------------------------->|
| | | |
| |<<############## CFW CONNECTION #################>>|
| | | |
| 4. INVITE xyz | | |
|--------------->| | |
| | 5. Attach UAC1 to MS (3PCC)| |
| |-------------------------------------------------->|
| | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
UAC1 AS MRB MS
| | | |
| | 1. COMEDIA negotiation | |
| |--------------------------->| |
| | | |
| | 2. 302 Moved (MS) | |
| |<---------------------------| |
| | | |
| | 3. COMEDIA negotiation | |
| |-------------------------------------------------->|
| | | |
| |<<############## CFW CONNECTION #################>>|
| | | |
| 4. INVITE xyz | | |
|--------------->| | |
| | 5. Attach UAC1 to MS (3PCC)| |
| |-------------------------------------------------->|
| | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
Figure 55: Handling Media Dialogs in IUMM: Redirection
图55：在IUMM中处理媒体对话框：重定向
With this approach, the MRB might redirect the AS to a specific MS whenever a new Control Channel is to be created, and as a consequence the AS would redirect the related calls there. This is similar to the first approach of the Query/IAMM case, with the difference that no Consumer request would be involved. The scenario would again fall back to a 1:1 topology between the AS and the MS, making the interactions quite simple.
通过这种方法，无论何时创建新的控制通道，MRB都可以将AS重定向到特定的MS，因此AS将重定向那里的相关调用。这与Query/IAMM案例的第一种方法类似，不同之处在于不涉及消费者请求。该场景将再次回到AS和MS之间的1:1拓扑，使得交互非常简单。
Just as before, the MRB might be interested in being in the signaling path for the SIP dialogs, instead of just acting as a locator. A third potential approach could be implementing the "virtual" URIs handled by the MRB, as described in the previous section. Rather than resorting to explicit redirection or always using the same MS,
与之前一样，MRB可能对SIP对话框的信令路径感兴趣，而不仅仅是充当定位器。第三种可能的方法是实现由MRB处理的“虚拟”URI，如前一节所述。而不是诉诸于显式重定向或始终使用相同的MS，
the MRB may redirect new SIP control dialogs to one of its own URIs, using the same approach previously presented in Figure 53. Such an approach, as applied to the IUMM case, is depicted in Figure 56.
MRB可以将新的SIP控制对话框重定向到它自己的一个URI，使用图53中先前介绍的相同方法。适用于IUMM案例的这种方法如图56所示。
UAC1 AS MRB MS
| | | |
| | 1. COMEDIA negotiation (MRB) | |
| |------------------------------>| |
| | | |
| | 2. 302 Moved (MRB') | |
| |<------------------------------| |
| | | |
| | 3. COMEDIA negotiation (MRB') | |
| |------------------------------>| |
| | | 4. COMEDIA neg. |
| | |------------------>
| | | |
| |<<############## CFW CONNECTION #################>>|
| | | |
| 5. INVITE xyz | | |
|--------------->| | |
| | 6. Attach UAC1 to MRB' (3PCC) | |
| |------------------------------>| |
| | | 7 Attach UAC (3PCC)
| | |------------------>
| | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
UAC1 AS MRB MS
| | | |
| | 1. COMEDIA negotiation (MRB) | |
| |------------------------------>| |
| | | |
| | 2. 302 Moved (MRB') | |
| |<------------------------------| |
| | | |
| | 3. COMEDIA negotiation (MRB') | |
| |------------------------------>| |
| | | 4. COMEDIA neg. |
| | |------------------>
| | | |
| |<<############## CFW CONNECTION #################>>|
| | | |
| 5. INVITE xyz | | |
|--------------->| | |
| | 6. Attach UAC1 to MRB' (3PCC) | |
| |------------------------------>| |
| | | 7 Attach UAC (3PCC)
| | |------------------>
| | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
Figure 56: Handling Media Dialogs in IUMM: MRB in the Signaling Path
图56：在信令路径中处理IUMM:MRB中的媒体对话框
It is worth pointing out, though, that in both cases there are scenarios where there could be no assurance that the 302 sent by the MRB would be seen by the AS. In fact, should a proxy be between the AS and the MRB, such a proxy could itself act on the 302. To properly cope with such an issue, the MRB might also use the 'Contact' header in the SIP responses to the INVITE to address the right MS. Although the AS is not required to use the information in such a header to reach the MS, it could be reasonable to exploit it for that purpose, as it would take care of the proxy scenario mentioned above.
不过，值得指出的是，在这两种情况下，都存在无法保证AS会看到MRB发送的302的情况。事实上，如果代理位于AS和MRB之间，那么这样的代理本身可以作用于302。为了正确处理此类问题，MRB还可以在SIP对邀请的响应中使用“联系人”头，以向正确的MS发送地址。尽管AS不需要使用此类头中的信息来到达MS，但出于该目的利用它是合理的，因为它将处理上述代理场景。
To conclude, there is a further approach an MRB might try to exploit to take care of the IUMM case. Since, as explained before, the issues related to the IUMM case mostly relate to the fact that the MRB is seen as a single MS instance by the AS, a simple way to overcome this might be to make the MRB look like a set of different MS right away; this can be done by simply provisioning the unaware AS with a series of different URIs, all handled by the MRB itself acting as a pool of "virtual" MS. This way, the AS may be designed to use different MS for different classes of calls, e.g., for different applications it is managing (two in the example presented in this section), and as such would contact two different provisioned URIs to create two distinct Control Channels towards two different MS. Since both of the URIs would be handled by the MRB, the MRB can use them to determine to which MS each call should be directed. Expanding on Figure 54 by removing the constraint to always use the same MS, this new scenario might look like that depicted in Figure 57.
总之，MRB可能会尝试利用另一种方法来处理IUMM病例。如前所述，由于与IUMM案例相关的问题主要与as将MRB视为单个MS实例的事实有关，因此克服这一问题的简单方法可能是立即使MRB看起来像一组不同的MS；这可以通过简单地使用一系列不同的URI配置AS来实现，所有这些URI都由MRB本身作为“虚拟”MS池来处理。这样，AS可以被设计为对不同类别的调用使用不同的MS，例如，对于它正在管理的不同应用程序（本节中给出的示例中有两个），因此，将联系两个不同的配置URI，以创建两个针对两个不同MS的不同控制通道。由于这两个URI都将由MRB处理，MRB可以使用它们来确定每个呼叫应定向到哪个MS。通过移除始终使用相同MS的约束来扩展图54，这个新场景可能与图57所示类似。
UAC1 UAC2 AS MRB MS1 MS2
| | | | | |
| | | 1. COMEDIA negotiation (A) | | |
| | | INVITE fake-ms1 | | |
| | |--------------------------->| | |
| | | | 2. COMEDIA (A) | |
| | | |---------------->| |
| | | | | |
| | |<<############## CFW CONNECTION 1 ##########>>| |
| | | | | |
| | | 3. COMEDIA negotiation (B) | | |
| | | INVITE fake-ms2 | | |
| | |--------------------------->| | |
| | | | 4. COMEDIA neg. (B) |
| | | |--------------------->|
| | | | | |
| | |<<############## CFW CONNECTION 2 ###############>>|
| | | | | |
| 5. INVITE xyz | | | |
|--------------->| | | |
| | | 6. Attach UAC1 to fake-ms1 (3PCC) | |
| | |--------------------------->| | |
| | | | 7. Attach UAC | |
| | | |---------------->| |
| | | | | |
|<<++++++++++++++++++++++ RTP channels +++++++++++++++++++++++>>| |
| | | | | |
| 8. INVITE jkl | | | |
|--------------->| | | |
| | | 9. Attach UAC2 to fake-ms2 (3PCC) | |
| | |--------------------------->| | |
| | | | 10. Attach UAC | |
| | | |--------------------->|
| | | | | |
|<<+++++++++++++++++++++++++ RTP channels +++++++++++++++++++++++++>>|
| | | | | |
. . . . . .
. . . . . .
UAC1 UAC2 AS MRB MS1 MS2
| | | | | |
| | | 1. COMEDIA negotiation (A) | | |
| | | INVITE fake-ms1 | | |
| | |--------------------------->| | |
| | | | 2. COMEDIA (A) | |
| | | |---------------->| |
| | | | | |
| | |<<############## CFW CONNECTION 1 ##########>>| |
| | | | | |
| | | 3. COMEDIA negotiation (B) | | |
| | | INVITE fake-ms2 | | |
| | |--------------------------->| | |
| | | | 4. COMEDIA neg. (B) |
| | | |--------------------->|
| | | | | |
| | |<<############## CFW CONNECTION 2 ###############>>|
| | | | | |
| 5. INVITE xyz | | | |
|--------------->| | | |
| | | 6. Attach UAC1 to fake-ms1 (3PCC) | |
| | |--------------------------->| | |
| | | | 7. Attach UAC | |
| | | |---------------->| |
| | | | | |
|<<++++++++++++++++++++++ RTP channels +++++++++++++++++++++++>>| |
| | | | | |
| 8. INVITE jkl | | | |
|--------------->| | | |
| | | 9. Attach UAC2 to fake-ms2 (3PCC) | |
| | |--------------------------->| | |
| | | | 10. Attach UAC | |
| | | |--------------------->|
| | | | | |
|<<+++++++++++++++++++++++++ RTP channels +++++++++++++++++++++++++>>|
| | | | | |
. . . . . .
. . . . . .
Figure 57: Handling Media Dialogs in IUMM: Provisioned URIs
图57：在IUMM中处理媒体对话框：配置的URI
In this new example, we still assume that the same unaware AS is handling two different applications, still associated with the same URIs as before. This time, though, we also assume that the AS has been designed to try to use different MS instances to handle the two very different applications for which it is responsible. We also assume that it has been configured to be able to use two different MS instances, reachable at SIP URI 'fake-ms1' and 'fake-ms2',
在这个新的示例中，我们仍然假设同一个应用程序正在处理两个不同的应用程序，仍然与前面的相同URI关联。不过，这一次，我们还假设AS的设计目的是尝试使用不同的MS实例来处理它负责的两个非常不同的应用程序。我们还假设它已配置为能够使用两个不同的MS实例，可在SIP URI“fake-ms1”和“fake-ms2”处访问，
respectively, and both actually handled by the MRB transparently. This results, just as before, in two different Control Channels (A and B) being created, but this time towards two different MS. Specifically, the MRB makes sure that for this AS the Control Channel negotiation towards 'fake-ms1' is actually redirected to MS1. At the same time, 'fake-ms2' is associated with MS2. Once the AS has set up the Control Channels with both of the MS, it is ready to handle media dialogs. UAC1 calls the SIP URI 'xyz' on the AS to order a pizza. The AS attaches the media dialog to the MS it knows is responsible for that branch of application logic, i.e., 'fake-ms1'. The MRB in turn makes sure that it reaches the right MS instance, MS1. Later on, a different user, UAC2, calls SIP URI 'jkl' to join a conference room. This time, the AS attaches this new media dialog to the MS instance handling the conference application, i.e., 'fake-ms2'. Again, the MRB makes sure that it is actually MS2 that receives the dialog.
两者都是由MRB透明处理的。与之前一样，这会导致创建两个不同的控制通道（A和B），但这次是针对两个不同的MS。具体而言，MRB会确保针对“fake-ms1”的控制通道协商实际上重定向到ms1。同时，“fake-ms2”与ms2关联。AS与两台MS建立控制通道后，即可处理媒体对话框。UAC1调用AS上的SIPURI“xyz”来订购比萨饼。AS将媒体对话框附加到它知道负责该应用程序逻辑分支的MS，即“fake-ms1”。MRB反过来确保它到达正确的MS实例MS1。稍后，另一个用户UAC2调用SIPURI“jkl”加入会议室。这一次，AS将这个新媒体对话框附加到处理会议应用程序的MS实例，即“fake-ms2”。同样，MRB确保接收对话框的实际上是MS2。
Again, this diagram is only meant to describe how the MRB might enforce its decisions. Just as described in the previous examples, the MRB may choose to either act as a Proxy/B2BUA between the AS and the MS instances or redirect the AS to the right MS instances when they're first contacted (e.g., by means of the Contact header and/or a SIP redirect, as explained before) and let the AS attach the media dialogs by itself.
同样，此图仅用于描述MRB如何执行其决策。正如在前面的示例中所描述的，MRB可以选择充当as和MS实例之间的代理/B2BUA，或者在第一次接触到as时将as重定向到正确的MS实例（例如，通过联系人头和/或SIP重定向，如前所述），并让as自行连接媒体对话框。
As shown in the previous diagrams, no matter what the topology, the AS and MS usually end up with a direct connection with respect to the CFW Control Channel. As such, it can be expected that the CFW protocol continue to work as it should, and as a consequence all the call flows presented in this document can easily be reproduced in those circumstances as well.
如前几张图所示，无论拓扑结构如何，As和MS通常都与CFW控制信道直接连接。因此，可以预期CFW协议将继续正常工作，因此，本文档中提供的所有调用流也可以在这些情况下轻松复制。
Nevertheless, one aspect needs to be considered very carefully. It's worthwhile to remind readers that both the AS and the MS use some SIP-related information to address the entities they manipulate. This is the case, for instance, for the <connectionid> element to which both the AS and the MS refer when addressing a specific UAC. As explained in Section 6, this 'connectionid' identifier is constructed by concatenating the 'From' and 'To' tags extracted from a SIP header: specifically, from the headers of the AS<->MS leg that allows a UAC to be attached to the MS. The presence of an additional component in the path between the AS and the MS, the MRB, might alter these tags, thus causing the AS to use tags (AS<->MRB) different than those used by the MS (MRB<->MS). This would result in the AS and MS using different 'connectionid' identifiers to address the same UAC, thus preventing the protocol from working as expected. As a
然而，有一个方面需要非常仔细地考虑。值得提醒读者的是，AS和MS都使用一些与SIP相关的信息来处理它们所操作的实体。例如，AS和MS在寻址特定UAC时所引用的<connectionid>元素就是这种情况。如第6节所述，该“connectionid”标识符是通过连接从SIP头中提取的“From”和“To”标记来构造的：具体地说，是从允许UAC连接到MS的As<->MS段的头中提取的。As和MS之间的路径中的附加组件MRB的存在可能会改变这些标记，从而导致AS使用不同于MS（MRB<->MS）使用的标签（AS<->MRB）。这将导致AS和MS使用不同的“connectionid”标识符来寻址同一UAC，从而阻止协议按预期工作。作为一个
consequence, it's very important that any MRB implementation take very good care to preserve the integrity of the involved SIP headers when proxying/forwarding SIP dialogs between the AS and MS, in order not to "break" the behavior of the protocol.
因此，在代理/转发AS和MS之间的SIP对话时，任何MRB实现都要非常小心地保持所涉及SIP头的完整性，以避免“破坏”协议的行为，这一点非常重要。
Let's take, for instance, the scenario depicted in Figure 53, especially steps 6 and 7, which specifically address a UAC being attached by an AS to an MS via the MRB. Let's assume that Figure 58 shows what happens to the 'From' and 'To' headers in that scenario, when dealing with the 3PCC approach to attach a specific UAC to the MS.
例如，让我们以图53中描述的场景为例，特别是步骤6和步骤7，它们专门解决由AS通过MRB连接到MS的UAC。让我们假设图58显示了在该场景中，当处理3PCC方法将特定UAC连接到MS时，“From”和“to”头会发生什么。
UAC AS MRB MS
| | | |
| INVITE xyz | | |
|--------------->| | |
| | SIP [..] | |
| | From: <..>;tag=a1b2c3 | |
| | To: <..>;tag=d4e5f6 | |
| |<------------------------>| |
| | | SIP [..] |
| | | From: <..>;tag=aaabbb |
| | | To: <..>;tag=cccddd |
| | |<---------------------->|
| | | |
| | 1. CONTROL (play announcement to UAC) |
| |-------------------------------------------------->|
| | 2. 200 (IVR Error!) |
| |<--------------------------------------------------|
| | | |
. . . .
. . . .
UAC AS MRB MS
| | | |
| INVITE xyz | | |
|--------------->| | |
| | SIP [..] | |
| | From: <..>;tag=a1b2c3 | |
| | To: <..>;tag=d4e5f6 | |
| |<------------------------>| |
| | | SIP [..] |
| | | From: <..>;tag=aaabbb |
| | | To: <..>;tag=cccddd |
| | |<---------------------->|
| | | |
| | 1. CONTROL (play announcement to UAC) |
| |-------------------------------------------------->|
| | 2. 200 (IVR Error!) |
| |<--------------------------------------------------|
| | | |
. . . .
. . . .
Figure 58: CFW Protocol Behavior in the Case of Manipulated Tags
图58：操纵标签情况下的CFW协议行为
In this example, once done with the 3PCC, and now that the UAC is attached to the MS, the AS and the MS end up with different interpretations of what the 'connectionid' for the UAC should be. In fact, the AS builds a 'connectionid' using the tags it is aware of (a1b2c3:d4e5f6), while the MS builds a different identifier after receiving different information from the MRB (aaabbb:cccddd).
在本例中，使用3PCC后，现在UAC连接到MS，AS和MS最终会对UAC的“连接ID”进行不同的解释。事实上，AS使用它知道的标记（a1b2c3:d4e5f6）构建“连接ID”，而MS在从MRB接收到不同的信息（aaabbb:cccddd）后构建不同的标识符。
As a consequence, when the AS tries to play an announcement to the UAC using the connectionid it correctly constructed, the MS just as correctly replies with an error, since it doesn't know that identifier. This is correct protocol behavior, because in this case it was caused by misuse of the information needed for it to work as expected.
因此，当As尝试使用正确构造的connectionid向UAC播放公告时，MS也会正确地回复错误，因为它不知道该标识符。这是正确的协议行为，因为在本例中，它是由于误用了使其按预期工作所需的信息而导致的。
1. AS -> MS (CFW CONTROL, play) ------------------------------- CFW ffhg45dzf123 CONTROL Control-Package: msc-ivr/1.0 Content-Type: application/msc-ivr+xml Content-Length: 284
1. AS->MS（CFW控制，播放）-------------CFW ffhg45dzf123控制包：msc ivr/1.0内容类型：应用程序/msc ivr+xml内容长度：284
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="a1b2c3:d4e5f6">
<dialog>
<prompt>
<media loc="http://www.example.net/hello.wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="a1b2c3:d4e5f6">
<dialog>
<prompt>
<media loc="http://www.example.net/hello.wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
2. AS <- MS (CFW 200 OK) ------------------------ CFW ffhg45dzf123 200 Timeout: 10 Content-Type: application/msc-ivr+xml Content-Length: 148
2. AS<-MS（CFW 200正常）---------------------------CFW ffhg45dzf123 200超时：10内容类型：应用程序/msc ivr+xml内容长度：148
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="407" reason="connectionid does not exist"
dialogid=""/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="407" reason="connectionid does not exist"
dialogid=""/>
</mscivr>
In an even worse scenario, the connectionid might actually exist but might be mapped to a different UAC. In such a case, the transaction would succeed, but a completely different UAC would be involved, thus causing a silent failure that neither the AS nor the MS would be aware of.
在更糟糕的情况下，connectionid可能实际存在，但可能映射到不同的UAC。在这种情况下，事务将成功，但将涉及完全不同的UAC，从而导致AS和MS都不知道的无声故障。
That said, proper management of these sensitive pieces of information by the MRB would prevent such failure scenarios from happening. How this issue is taken care of in the IAMM case (both CFW-based and media dialog-based) has already been described. Addressing this issue for the IUMM case is not documented in [RFC6917] as explicitly out of scope and as such may be implementation specific.
也就是说，MRB对这些敏感信息的适当管理将防止此类故障情况的发生。已经描述了在IAMM案例（基于CFW和基于媒体对话）中如何处理此问题。[RFC6917]中没有明确说明IUMM案例的这一问题，因为该问题超出了范围，因此可能是特定于实施的。
The same applies to SDP fields as well. In fact, the AS and MS use ad hoc SDP attributes to instantiate a Control Channel, as they use SDP labels to address specific media connections of a UAC media dialog when a fine-grained approach is needed. As a consequence, any
这同样适用于SDP字段。事实上，AS和MS使用特殊SDP属性来实例化控制通道，因为当需要细粒度方法时，它们使用SDP标签来处理UAC媒体对话框的特定媒体连接。因此，任何
MRB implementation should limit any SDP manipulation as much as possible or at least take very good care not to cause changes that could "break" the expected behavior of the CFW protocol.
MRB实施应尽可能限制任何SDP操作，或者至少要非常小心，不要导致可能“破坏”CFW协议预期行为的更改。
All the MEDIACTRL documents have strong statements regarding security considerations within the context of the interactions occurring at all levels among the involved parties. Considering the sensitive nature of the interaction between AS and MS, particular efforts have been devoted to providing guidance on how to secure what flows through a Control Channel. In fact, transactions concerning dialogs, connections, and mixes are quite strongly related to resources actually being deployed and used in the MS. This means that it is in the interest of both AS and MS that resources created and handled by an entity are not manipulated by a potentially malicious third party if permission was not granted.
所有MEDIACTRL文档都对涉及各方之间发生的所有级别的交互中的安全注意事项做出了强有力的陈述。考虑到AS和MS之间相互作用的敏感性质，特别致力于为如何确保通过控制通道的流量提供指导。事实上，有关对话框、连接和混合的事务与MS中实际部署和使用的资源密切相关。这意味着，如果未授予许可，则实体创建和处理的资源不会受到潜在恶意第三方的操纵符合AS和MS的利益。
Because strong statements are provided in the aforementioned documents and these documents provide good guidance to implementors with respect to these issues, this section will only provide the reader with some MEDIACTRL call flows that show how a single secured MS is assumed to reply to different AS when receiving requests that may cross the bounds within which each AS is constrained. This would be the case, for instance, for generic auditing requests, or explicit conference manipulation requests where the involved identifiers are not part of the context of the originating AS.
由于上述文件中提供了强有力的陈述，并且这些文件就这些问题为实施者提供了良好的指导，本节仅向读者提供一些MEDIACTRL调用流，这些调用流显示了当接收到可能跨越每个AS约束范围的请求时，如何假定单个安全MS对不同的AS进行应答。例如，对于一般审核请求或显式会议操纵请求，如果涉及的标识符不属于原始AS的上下文，则会出现这种情况。
To address a very specific scenario, let's assume that two different AS, AS1 and AS2, have established a Control Channel with the same MS. Considering the SYNC transaction that an AS and an MS use to set up a Control Channel, the MS is able to discern the requests coming from AS1 from the requests coming from AS2. In fact, as explained in Sections 5.1 and 5.2, an AS and an MS negotiate a cfw-id attribute in the SDP, and the same value is subsequently used in the SYNC message on the Control Channel that is created after the negotiation, thus reassuring both the AS and the MS that the Control Channel they share is in fact the channel they negotiated in the first place.
为了解决一个非常具体的场景，让我们假设两个不同的AS，AS1和AS2，已经使用相同的MS建立了一个控制通道。考虑到AS和MS用于建立控制通道的同步事务，MS能够区分来自AS1的请求和来自AS2的请求。事实上，如第5.1节和第5.2节所述，as和MS协商SDP中的cfw id属性，随后在协商后创建的控制通道上的同步消息中使用相同的值，因此，让AS和MS都放心，他们共享的控制通道实际上就是他们最初协商的通道。
Let's also assume that AS1 has created a conference mix (confid=74b6d62) to which it has attached some participants within the context of its business logic, while AS2 has created a currently active IVR dialog (dialogid=dfg3252) with a user agent it is handling (237430727:a338e95f). AS2 has also joined two connections to each other (1:75d4dd0d and 1:b9e6a659). Clearly, it is highly desirable that AS1 not be aware of what AS2 is doing with the MS and vice versa, and that they not be allowed to manipulate each other's resources. The following transactions will occur:
我们还假设AS1已经创建了一个会议组合（confid=74b6d62），在其业务逻辑上下文中，它已经将一些参与者附加到该组合中，而AS2已经创建了一个当前活动的IVR对话框（dialogid=dfg3252），其中有一个正在处理的用户代理（237430727:a338e95f）。AS2还相互连接了两个连接（1:75d4dd0d和1:b9e6a659）。显然，AS1不知道AS2对MS做了什么是非常可取的，反之亦然，并且不允许他们操纵彼此的资源。将发生以下交易：
1. AS1 places a generic audit request to both the Mixer and IVR packages.
1. AS1向Mixer和IVR软件包发出一般审核请求。
2. AS2 places a generic audit request to both the Mixer and IVR packages.
2. AS2向Mixer和IVR包发出一般审核请求。
3. AS1 tries to terminate the dialog created by AS2 (6791fee).
3. AS1尝试终止AS2创建的对话框（67913）。
4. AS2 tries to join a user agent it handles (1:272e9c05) to the conference mix created by AS1 (74b6d62).
4. AS2尝试将其处理的用户代理（1:272e9c05）加入到AS1（74b6d62）创建的会议组合中。
A sequence diagram of the above-mentioned transactions is depicted in Figure 59, which shows how the MS is assumed to reply in all cases, in order to avoid security issues:
图59中描述了上述事务的序列图，该图显示了如何假设MS在所有情况下回复，以避免安全问题：
AS1 AS2 MS
| | |
| A1. CONTROL (IVR audit) |
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
| | A2. 200 OK |
|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| B1. CONTROL (Mixer audit) |
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
| | B2. 200 OK |
|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| | C1. CONTROL (IVR audit) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 200 OK |
| |<<++++++++++++++++++++++++++++++++|
| | |
| | D1. CONTROL (Mixer audit) |
| |++++++++++++++++++++++++++++++++>>|
| | D2. 200 OK |
| |<<++++++++++++++++++++++++++++++++|
| | |
| E1. CONTROL (dialogterminate) |
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
| | E2. 403 Forbidden |
|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| | F1. CONTROL (join UAC&conf[AS1]) |
| |++++++++++++++++++++++++++++++++>>|
| | F2. 403 Forbidden |
| |<<++++++++++++++++++++++++++++++++|
| | |
. . .
. . .
AS1 AS2 MS
| | |
| A1. CONTROL (IVR audit) |
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
| | A2. 200 OK |
|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| B1. CONTROL (Mixer audit) |
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
| | B2. 200 OK |
|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| | C1. CONTROL (IVR audit) |
| |++++++++++++++++++++++++++++++++>>|
| | C2. 200 OK |
| |<<++++++++++++++++++++++++++++++++|
| | |
| | D1. CONTROL (Mixer audit) |
| |++++++++++++++++++++++++++++++++>>|
| | D2. 200 OK |
| |<<++++++++++++++++++++++++++++++++|
| | |
| E1. CONTROL (dialogterminate) |
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
| | E2. 403 Forbidden |
|<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| | F1. CONTROL (join UAC&conf[AS1]) |
| |++++++++++++++++++++++++++++++++>>|
| | F2. 403 Forbidden |
| |<<++++++++++++++++++++++++++++++++|
| | |
. . .
. . .
Figure 59: Security Considerations: Framework Transaction
图59：安全注意事项：框架事务
The expected outcome of the transaction is that the MS partially "lies" to both AS1 and AS2 when replying to the audit requests (not all of the identifiers are reported, but only those identifiers with which each AS is directly involved), and the MS denies the requests for the unauthorized operations (403). Looking at each transaction separately:
事务的预期结果是，MS在答复审计请求时部分“撒谎”给AS1和AS2（并非报告所有标识符，但仅报告每个AS直接涉及的标识符），并且MS拒绝未授权操作的请求（403）。分别查看每笔交易：
o In the first transaction (A1), AS1 places a generic <audit> request to the IVR package. The request is generic, since no attributes are passed as part of the request, meaning that AS1 is interested in the MS capabilities as well as all of the dialogs that the MS is currently handling. As can be seen in the reply (A2), the MS only reports in the <auditresponse> the package capabilities, while the <dialogs> element is empty; this is because the only dialog the MS is handling has actually been created by AS2, which causes the MS not to report the related identifier (6791fee) to AS1. In fact, AS1 could use that identifier to manipulate the dialog, e.g., by tearing it down and thus causing the service to be interrupted without AS2's intervention.
o 在第一个事务（A1）中，AS1向IVR包发出一个通用的<audit>请求。请求是通用的，因为没有属性作为请求的一部分传递，这意味着AS1对MS功能以及MS当前正在处理的所有对话框感兴趣。从回复（A2）中可以看出，MS仅在<auditresponse>中报告包功能，而<dialogs>元素为空；这是因为MS正在处理的唯一对话框实际上是由AS2创建的，这导致MS不向AS1报告相关标识符（6791fee）。事实上，AS1可以使用该标识符来操纵对话框，例如，将其拆下，从而导致服务在没有AS2干预的情况下中断。
o In the second transaction (B1), AS1 places an identical <audit> request to the Mixer package. The request is again generic, meaning that AS1 is interested in the package capabilities as well as all the mixers and connections that the package is handling at the moment. This time, the MS reports not only capabilities (B2) but information about mixers and connections as well. However, this information is not complete; in fact, only information about mixers and connections originated by AS1 is reported (mixer 74b6d62 and its participants), while the information originated by AS2 is omitted in the report. The motivation is the same as before.
o 在第二个事务（B1）中，AS1向混合器包发出相同的<audit>请求。该请求也是通用的，这意味着AS1对包的功能以及包目前正在处理的所有混频器和连接感兴趣。这一次，MS不仅报告功能（B2），还报告有关混音器和连接的信息。但是，这些信息并不完整；事实上，仅报告有关AS1发起的混合器和连接的信息（混合器74b6d62及其参与者），而报告中忽略了AS2发起的信息。动机和以前一样。
o In the third and fourth transactions (C1 and D1), it's AS2 that places an <audit> request to both the IVR and Mixer packages. As with the previous transactions, the audit requests are generic. Looking at the replies (C2 and D2), it's obvious that the capabilities section is identical to the replies given to AS1. In fact, the MS has no reason to "lie" about what it can do. The <dialogs> and <mixers> sections are totally different. AS2 in fact receives information about its own IVR dialog (6791fee), which was omitted in the reply to AS1, while it only receives information about the only connection it created (1:75d4dd0d and 1:b9e6a659) without any details related to the mixers and connections originated by AS1.
o 在第三和第四个事务（C1和D1）中，AS2向IVR和Mixer包发出<audit>请求。与以前的事务一样，审计请求是通用的。查看回复（C2和D2），很明显，能力部分与AS1的回复相同。事实上，微软没有理由“撒谎”它能做什么。<dialogs>和<mixers>部分完全不同。实际上，AS2接收有关其自己的IVR对话框（6791fee）的信息，该对话框在对AS1的回复中被省略，而它只接收有关其创建的唯一连接（1:75d4dd0d和1:b9e6a659）的信息，而没有任何与AS1发起的混音器和连接相关的详细信息。
o In the fifth transaction (E1), AS1, instead of just auditing the packages, tries to terminate (<dialogterminate>) the dialog created by AS2 (6791fee). Since the identifier has not been reported by the MS in the reply to the previous audit request, we assume that AS1 accessed it via a different out-of-band mechanism. This is assumed to be an unauthorized operation, because the above-mentioned dialog is outside the bounds of AS1; therefore, the MS, instead of handling the syntactically correct request, replies (E2) with a framework-level 403 message (Forbidden), leaving the dialog untouched.
o 在第五个事务（E1）中，AS1不只是审核包，而是尝试终止（<dialogterminate>）AS2创建的对话框（6791fee）。由于MS在回复之前的审核请求时未报告该标识符，因此我们假设AS1通过不同的带外机制访问该标识符。这被认为是未经授权的操作，因为上述对话框不在AS1的范围内；因此，MS没有处理语法正确的请求，而是使用框架级别403的消息（禁止）回复（E2），使对话框保持不变。
o Similarly, in the sixth and last transaction (F1), AS2 tries to attach (<join>) one of the UACs it is handling to the conference mix created by AS1 (74b6d62). Just as in the previous transaction, the identifier is assumed to have been accessed by AS2 via some out-of-band mechanism, since the MS didn't report it in the reply to the previous audit request. While one of the identifiers (the UAC) is actually handled by AS2, the other (the conference mix) is not; therefore, as with the fifth transaction, this last transaction is regarded by the MS as outside the bounds of AS2. For the same reason as before, the MS replies (F2) with a framework-level 403 message (Forbidden), leaving the mix and the UAC unjoined.
o 类似地，在第六个也是最后一个事务（F1）中，AS2尝试将其正在处理的一个UAC附加到AS1（74b6d62）创建的会议混音中。与前一个事务一样，假定AS2通过带外机制访问了该标识符，因为MS没有在对前一个审计请求的答复中报告它。虽然其中一个标识符（UAC）实际上由AS2处理，但另一个标识符（会议组合）不是；因此，与第五笔交易一样，MS认为最后一笔交易超出了AS2的范围。出于与之前相同的原因，MS以框架级别403的消息（禁止）回复（F2），使混合和UAC未连接。
A1. AS1 -> MS (CFW CONTROL, audit IVR)
--------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 81
A1. AS1 -> MS (CFW CONTROL, audit IVR)
--------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 81
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
A2. AS1 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 1419
A2. AS1 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 1419
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<auditresponse status="200">
<capabilities>
<dialoglanguages/>
<grammartypes/>
<recordtypes>
<mimetype>audio/x-wav</mimetype>
<mimetype>video/mpeg</mimetype>
</recordtypes>
<prompttypes>
<mimetype>audio/x-wav</mimetype>
<mimetype>video/mpeg</mimetype>
</prompttypes>
<variables>
<variabletype type="date"
desc="value formatted as YYYY-MM-DD">
<format desc="month day year">mdy</format>
<format desc="year month day">ymd</format>
<format desc="day month year">dmy</format>
<format desc="day month">dm</format>
</variabletype>
<variabletype type="time" desc="value formatted as HH:MM">
<format desc="24 hour format">t24</format>
<format desc="12 hour format with am/pm">t12</format>
</variabletype>
<variabletype type="digits" desc="value formatted as D+">
<format desc="general digit string">gen</format>
<format desc="cardinal">crn</format>
<format desc="ordinal">ord</format>
</variabletype>
</variables>
<maxpreparedduration>60s</maxpreparedduration>
<maxrecordduration>1800s</maxrecordduration>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<auditresponse status="200">
<capabilities>
<dialoglanguages/>
<grammartypes/>
<recordtypes>
<mimetype>audio/x-wav</mimetype>
<mimetype>video/mpeg</mimetype>
</recordtypes>
<prompttypes>
<mimetype>audio/x-wav</mimetype>
<mimetype>video/mpeg</mimetype>
</prompttypes>
<variables>
<variabletype type="date"
desc="value formatted as YYYY-MM-DD">
<format desc="month day year">mdy</format>
<format desc="year month day">ymd</format>
<format desc="day month year">dmy</format>
<format desc="day month">dm</format>
</variabletype>
<variabletype type="time" desc="value formatted as HH:MM">
<format desc="24 hour format">t24</format>
<format desc="12 hour format with am/pm">t12</format>
</variabletype>
<variabletype type="digits" desc="value formatted as D+">
<format desc="general digit string">gen</format>
<format desc="cardinal">crn</format>
<format desc="ordinal">ord</format>
</variabletype>
</variables>
<maxpreparedduration>60s</maxpreparedduration>
<maxrecordduration>1800s</maxrecordduration>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<dialogs>
</dialogs>
</auditresponse>
</mscivr>
</capabilities>
<dialogs>
</dialogs>
</auditresponse>
</mscivr>
B1. AS1 -> MS (CFW CONTROL, audit mixer)
----------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 87
B1. AS1 -> MS (CFW CONTROL, audit mixer)
----------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 87
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit/>
</mscmixer>
B2. AS1 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 903
B2. AS1 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 903
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<auditresponse status="200">
<capabilities>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<mixers>
<conferenceaudit conferenceid="74b6d62">
<participants>
<participant id="1864574426:e2192766"/>
<participant id="1:5a97fd79"/>
</participants>
<video-layout min-participants="1">
<quad-view/>
</video-layout>
</conferenceaudit>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<auditresponse status="200">
<capabilities>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<mixers>
<conferenceaudit conferenceid="74b6d62">
<participants>
<participant id="1864574426:e2192766"/>
<participant id="1:5a97fd79"/>
</participants>
<video-layout min-participants="1">
<quad-view/>
</video-layout>
</conferenceaudit>
<joinaudit id1="1864574426:e2192766" id2="74b6d62"/>
<joinaudit id1="1:5a97fd79" id2="74b6d62"/>
</mixers>
</auditresponse>
</mscmixer>
<joinaudit id1="1864574426:e2192766" id2="74b6d62"/>
<joinaudit id1="1:5a97fd79" id2="74b6d62"/>
</mixers>
</auditresponse>
</mscmixer>
C1. AS2 -> MS (CFW CONTROL, audit IVR)
--------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 81
C1. AS2 -> MS (CFW CONTROL, audit IVR)
--------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 81
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
C2. AS2 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 1502
C2. AS2 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 1502
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<auditresponse status="200">
<capabilities>
<dialoglanguages/>
<grammartypes/>
<recordtypes>
<mimetype>audio/wav</mimetype>
<mimetype>video/mpeg</mimetype>
</recordtypes>
<prompttypes>
<mimetype>audio/wav</mimetype>
<mimetype>video/mpeg</mimetype>
</prompttypes>
<variables>
<variabletype type="date"
desc="value formatted as YYYY-MM-DD">
<format desc="month day year">mdy</format>
<format desc="year month day">ymd</format>
<format desc="day month year">dmy</format>
<format desc="day month">dm</format>
</variabletype>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<auditresponse status="200">
<capabilities>
<dialoglanguages/>
<grammartypes/>
<recordtypes>
<mimetype>audio/wav</mimetype>
<mimetype>video/mpeg</mimetype>
</recordtypes>
<prompttypes>
<mimetype>audio/wav</mimetype>
<mimetype>video/mpeg</mimetype>
</prompttypes>
<variables>
<variabletype type="date"
desc="value formatted as YYYY-MM-DD">
<format desc="month day year">mdy</format>
<format desc="year month day">ymd</format>
<format desc="day month year">dmy</format>
<format desc="day month">dm</format>
</variabletype>
<variabletype type="time" desc="value formatted as HH:MM">
<format desc="24 hour format">t24</format>
<format desc="12 hour format with am/pm">t12</format>
</variabletype>
<variabletype type="digits" desc="value formatted as D+">
<format desc="general digit string">gen</format>
<format desc="cardinal">crn</format>
<format desc="ordinal">ord</format>
</variabletype>
</variables>
<maxpreparedduration>60s</maxpreparedduration>
<maxrecordduration>1800s</maxrecordduration>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<dialogs>
<dialogaudit dialogid="6791fee" state="started"
connectionid="237430727:a338e95f"/>
</dialogs>
</auditresponse>
</mscivr>
<variabletype type="time" desc="value formatted as HH:MM">
<format desc="24 hour format">t24</format>
<format desc="12 hour format with am/pm">t12</format>
</variabletype>
<variabletype type="digits" desc="value formatted as D+">
<format desc="general digit string">gen</format>
<format desc="cardinal">crn</format>
<format desc="ordinal">ord</format>
</variabletype>
</variables>
<maxpreparedduration>60s</maxpreparedduration>
<maxrecordduration>1800s</maxrecordduration>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<dialogs>
<dialogaudit dialogid="6791fee" state="started"
connectionid="237430727:a338e95f"/>
</dialogs>
</auditresponse>
</mscivr>
D1. AS2 -> MS (CFW CONTROL, audit mixer)
----------------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 87
D1. AS2 -> MS (CFW CONTROL, audit mixer)
----------------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 87
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit/>
</mscmixer>
D2. AS2 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 548
D2. AS2 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 548
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<auditresponse status="200">
<capabilities>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<mixers>
<joinaudit id1="1:75d4dd0d" id2="1:b9e6a659"/>
</mixers>
</auditresponse>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<auditresponse status="200">
<capabilities>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<mixers>
<joinaudit id1="1:75d4dd0d" id2="1:b9e6a659"/>
</mixers>
</auditresponse>
</mscmixer>
E1. AS1 -> MS (CFW CONTROL, dialogterminate)
--------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 127
E1. AS1 -> MS (CFW CONTROL, dialogterminate)
--------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 127
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogterminate dialogid="6791fee" immediate="true"/>
</mscivr>
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogterminate dialogid="6791fee" immediate="true"/>
</mscivr>
E2. AS1 <- MS (CFW 403 Forbidden)
---------------------------------
CFW 7fdcc2331bef 403
E2. AS1 <- MS (CFW 403 Forbidden)
---------------------------------
CFW 7fdcc2331bef 403
F1. AS2 -> MS (CFW CONTROL, join to conference)
-----------------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 117
F1. AS2 -> MS (CFW CONTROL, join to conference)
-----------------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 117
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1:272e9c05" id2="74b6d62"/>
</mscmixer>
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1:272e9c05" id2="74b6d62"/>
</mscmixer>
F2. AS2 <- MS (CFW 403 Forbidden)
---------------------------------
CFW 140e0f763352 403
F2. AS2 <- MS (CFW 403 Forbidden)
---------------------------------
CFW 140e0f763352 403
The authors would like to thank Dale Worley for the thorough review of the whole document and for contributing text to make the document easier to read.
作者要感谢Dale Worley对整个文件进行了全面审查，并提供了文本，使文件更易于阅读。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574]Levin，O.和G.Camarillo，“会话描述协议（SDP）标签属性”，RFC 45742006年8月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, May 2011.
[RFC6230]Boulton，C.，Melanchuk，T.，和S.McGrashan，“媒体控制渠道框架”，RFC 6230，2011年5月。
[RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", RFC 6231, May 2011.
[RFC6231]McGrashan，S.，Melanchuk，T.，和C.Boulton，“媒体控制频道框架的交互式语音应答（IVR）控制包”，RFC 62312011年5月。
[RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer Control Package for the Media Control Channel Framework", RFC 6505, March 2012.
[RFC6505]McGlashan，S.，Melanchuk，T.，和C.Boulton，“媒体控制频道框架的混音控制包”，RFC 65052012年3月。
[RFC6917] Boulton, C., Miniero, L., and G. Munson, "Media Resource Brokering", RFC 6917, April 2013.
[RFC6917]博尔顿，C.，米涅罗，L.，和G.芒森，“媒体资源经纪”，RFC 69172013年4月。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5239]Barnes，M.，Boulton，C.，和O.Levin，“集中会议的框架”，RFC 5239，2008年6月。
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4582]Camarillo，G.，Ott，J.，和K.Drage，“二进制地板控制协议（BFCP）”，RFC 4582，2006年11月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
[RFC4583]Camarillo，G.“二进制地板控制协议（BFCP）流的会话描述协议（SDP）格式”，RFC4583，2006年11月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的当前最佳实践”，BCP 85，RFC 37252004年4月。
[SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar Specification Version 1.0", W3C Recommendation, March 2004.
[SRGS]Hunt，A.和S.McGrashan，“语音识别语法规范1.0版”，W3C建议，2004年3月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597]伊恩，R.和N.伊斯梅尔，“会议场景”，RFC4597，2006年8月。
[RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.
[RFC5567]Melanchuk，T.，“媒体服务器控制的体系结构框架”，RFC5567，2009年6月。
Authors' Addresses
作者地址
Alessandro Amirante University of Napoli Via Claudio 21 Napoli 80125 Italy
那不勒斯亚历桑德罗阿米兰特大学21克劳迪奥意大利那不勒斯80125
EMail: alessandro.amirante@unina.it
EMail: alessandro.amirante@unina.it
Tobia Castaldi Meetecho Via Carlo Poerio 89 Napoli 80100 Italy
Tobia Castaldi Meetecho Via Carlo Poerio 89那不勒斯80100意大利
EMail: tcastaldi@meetecho.com
EMail: tcastaldi@meetecho.com
Lorenzo Miniero Meetecho Via Carlo Poerio 89 Napoli 80100 Italy
Lorenzo Miniero Meetecho Via Carlo Poerio 89那不勒斯80100意大利
EMail: lorenzo@meetecho.com
EMail: lorenzo@meetecho.com
Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy
西蒙彼得洛罗马诺大学那不勒斯经由克劳迪奥21那不勒斯80125意大利
EMail: spromano@unina.it
EMail: spromano@unina.it