[要約] RFC 7058は、メディア制御チャネルフレームワーク（CFW）の呼び出しフローの例を提供するものであり、その目的はCFWの実装者に対して、実際の使用例を提供することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]に準拠したMedia Resource Brokerを使用して、より多くのエンティティを含むいくつかのフローが示されています。読者が（SIPダイアログとメディアコントロールチャネルフレームワーク（CFW）トランザクションの両方に関連する）すべてのフローを理解できるように、すべてのシナリオでASとMSをホストするドメインは、「as.example.com」と「ms」と呼ばれます。それぞれ、[RFC2606]によるexample.net '。フローは、他の関連するプロトコル（SIP [RFC3261]、セッション記述プロトコル（SDP）[RFC3264]、RTP [RFC3550]など）ではなく、CFW [RFC6230]の相互作用に重点を置くことがよくあります。
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構文に従います。 1行あたり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コントロール：VCR（ビデオカセットレコーダー）コントローラーの機能に似た方法で、ユーザーが送信したデュアルトーンマルチ周波数（DTMF）信号を介して、速度や音量などのオーディオ再生の側面のランタイムコントロール。
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」、および「エラー」（エラーメッセージは特定の数値コードに対応します）の場合です。 。追加の入力は、上位層から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.
4つの図が提供されています。それらの2つ（図1および2）は、フレームワークの通常の操作を説明しています。図3には、非同期イベント通知を説明する2つの図が含まれています。図1はMSパースペクティブを採用していますが、図2はAS側を示しています。図3の上部は、AS宛のCONTROLメッセージを発行することにより、MS側でイベントがどのように生成されるかを示しています。イベントは、標準の200応答を通じてASによって確認されます。したがって、MSの動作を反映したASの動作は、図の下部に示されています。
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からのCONTROLメッセージを受信するとアクティブになることを示しています。 CONTROLメッセージは、使用可能な制御パッケージの1つに属する特定のコマンドの実行に関してMSに指示します。受信したコマンドの実行は、高速である場合と、時間がかかる場合があります。前者の場合、その操作が完了した直後に、MSはASに200メッセージを送り返します。これは基本的に、呼び出されたタスクの正しい終了を確認します。後者の場合、MSは最初に「タイムアウト」値を含む対話型の202メッセージを送り返します。新しい状態にある間、MSは呼び出されたタスクを実行し続けます。指定されたタイムアウト時間内にタスクが完了しない場合、サーバーは定期的に「REPORT update」メッセージを発行して、コントロールチャネルの反対側のASを更新します。このような各メッセージは、ASによって（ '200'応答を介して）確認される必要があります。最終的に、MSが必要なサービスを完了すると、MSはASに「REPORT terminate」メッセージを送信します。 ASがメッセージの受信を確認すると、トランザクションが終了します。 MSが要求に後のREPORT終了要求では報告できないエラーが含まれていないと判断した後、MSが202応答を送信する可能性があることを指摘する価値があります。 MSが202応答を送信した後、MSが（またはAPIが）要求で検出したエラーは、最後のREPORT終了要求で報告されます。ここでも、図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 |<----------------+
+---------------+
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
Figure 2: Application Server CFW State Diagram
図2：アプリケーションサーバーCFWの状態図
+--------------+
+-->| CONTROL sent |
| +--------------+
| |
| |
API CONTROL/ | | 200/-
send CONTROL | |
| |
+------------------+ |
| Idle/'terminate' |<----+
+------------------+
(Media Server perspective)
（メディアサーバーの観点）
+------------------+ 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間の相互作用への準備手順は、2つの間の制御チャネルの確立です。次のサブセクションで説明するように、これはコネクション型メディア（COMEDIA）[RFC4145] [RFC4572]ネゴシエーションによって実現されます。このネゴシエーションにより、ASとMSの間に信頼できる接続を作成できます。ここでASとMSは、使用するトランスポートレベルのプロトコル（TCP /ストリーム制御伝送プロトコル（SCTP））と、アプリケーションレベルのセキュリティが必要かどうか（TLSなど）について合意します。簡単にするために、暗号化されていないTCP接続が2つの関係するエンティティ間でネゴシエートされると仮定します。それらが接続すると、ASからMSに送信されたSYNCメッセージが制御チャネルを統合します。次の段落では、キープアライブメッセージがトリガーされる方法の例も示します。完全を期すために、このセクションには、制御チャネルの確立を処理するときに発生する可能性のあるいくつかの一般的な誤りも含まれています。
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はControl SIPダイアログを確立します。これは通常、AS自体によって発生します。 ASは、SDP本体に、MSと確立したいTCP接続に関する情報を含むSIP INVITEメッセージを生成します。提供された例（図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」属性は、Dialog-IDを指定するため、最も重要です。これは、[RFC6230]で指定されているように、ASとMSの両方によって引き続き参照されます。
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：COMEDIAネゴシエーション：シーケンス図
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 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許可：INVITE、ACK、CANCEL、OPTIONS、BYE、UPDATE、REGISTER Content-Type：application / sdp Content-Length：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
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; \ 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
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 OK）------------------------ SIP / 2.0 200 OK Via：SIP / 2.0 / UDP 203.0.113.1:5060 ; \ branch = z9hG4bK-d8754z-9b07c8201c3aa510-1 --- d8754z-; rport = 5060連絡先：<sip：MediaServer@ms.example.net：5060>宛先：<sip：MediaServer@ms.example.net：5060>; tag = 499a5b74 From：<sip：ApplicationServer@as.example.com：5060>; tag = 4354ec63 Call-ID：MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY。 CSeq：1 INVITE許可：INVITE、ACK、CANCEL、OPTIONS、BYE、UPDATE、REGISTER Content-Type：application / sdp Content-Length：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
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 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
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ダイアログによって行われ、これによりTCP接続の作成が可能になります。これにより、上記のエンティティ（SIPダイアログとTCP接続）の間に適切な相関関係が必要になるため、MSは、接続を要求したASからの接続であることを確認できます。これは、SYNCメッセージと呼ばれる専用のフレームワークメッセージによって実現されます。このSYNCメッセージは、Dialog-IDと呼ばれる一意の識別子を使用して、コントロールチャネルを検証します。この識別子は、以前に紹介したように、グローバルに一意であることを意図しており、発信者（コールフローのAS）によって適切に生成され、SDPメディア属性（cfw-id）としてCOMEDIAネゴシエーションに追加されます。その価値を知っている両方のエンティティ：
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 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).
a = cfw-id：5feb6486792a ^^^^^^^^^^^^また、追加の交渉メカニズムも提供します。実際、ASはSYNCを使用して、前に説明したように適切に相関するだけでなく、MSと関係するコントロールパッケージをネゴシエートし、両方のASで必要な「キープアライブ」タイマーに同意します。そして、MSは、接続で問題が発生したかどうかを彼らが知るようにします。提供されている例（図6および関連するコールフローを参照）では、ASは、必要に応じて（SIPダイアログからの 'cfw-id'属性を使用して）構築されたDialog-IDでSYNCを送信し、2つの制御パッケージへのアクセスを要求します。具体的には、Interactive Voice Response（IVR）パッケージとMixerパッケージです。 ASは、キープアライブメッセージに100秒のタイムアウトを使用することもMSに指示します。 MSは、受信したDialog-IDをSIPダイアログの値と照合することで要求を検証し、ASがアクセスを要求したコントロールパッケージをサポートしていると想定します（このドキュメントでは、そうしていると想定しています）。 200メッセージ。さらに、MSはASに、サポートする他の要求されていないパッケージのリストを提供します（この場合、テスト機能を提供するダミーパッケージのみ）。
AS MS
. .
. .
| |
| 1. SYNC (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNC
| |<-+
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
Figure 6: SYNC: Sequence Diagram
図6：SYNC：シーケンス図
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 SYNC）---------------------- CFW 6e5e86f95609 SYNC Dialog-ID：5feb6486792a Keep-Alive：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-mixer / 1.0サポート：msc-example-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.
ASは応答を元の要求に一致させる必要があるため、フレームワークレベルのトランザクション識別子は、要求と応答の両方で明らかに同じです（6e5e86f95609）。この時点で、最終的に制御チャネルが確立され、MSからのサービスを要求するためにASで使用できます。
[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 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.
[RFC6230]は、キープアライブ機能を実装するためのメカニズムを提供します。このようなメカニズムは、ASとMSの間のパスにNATまたはファイアウォールが存在する場合に特に役立ちます。実際、NATとファイアウォールには、それらが処理するTCP接続のタイムアウト値がある場合があります。つまり、特定の時間内にこれらの接続でトラフィックが検出されない場合、シャットダウンされる可能性があります。これは、ASとMSの間に確立されたがしばらく使用されない制御チャネルの場合です。このため、[RFC6230]は、ASとMSがTCP接続でトラフィックを生成してそれを維持するために使用できる専用フレームワークメッセージ（K-ALIVE）を指定しています。
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で説明したように、キープアライブメカニズムのタイムアウト値はSYNC要求によって設定されます。具体的には、この例では、ASは100秒の値を指定しました。実際、タイムアウト値は、どちらのエンドポイントがアクティブな役割を果たしているかによって単に指定されるため、ASとMSの間で実際にネゴシエートされません。ほとんどの場合、TCP接続をシャットダウンする前に使用するタイムアウト値は約2分であるため、100秒の値は、NATおよびファイアウォールの通常の実装方法に準拠しています。このような値は、このメカニズムのコンテキスト内で強い意味を持ちます。実際、アクティブなロール（この場合は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 | |
. .
. .
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はフレームワークレベルのK-ALIVEメッセージをMSに送信します。プロトコルメッセージダンプに表示されるメッセージは、ヘッダーが1行も含まれていないため、非常に軽量です。 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. 最初のSYNCで誤ったDialog-IDをMSに提供するAS
2. an AS sending a generic CONTROL message instead of SYNC as a first transaction.
2. ASが最初のトランザクションとしてSYNCの代わりに汎用CONTROLメッセージを送信します。
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 |
|------------------------------>|
| |
. .
. .
Figure 8: SYNC with Wrong Dialog-ID: Sequence Diagram
図8：間違ったダイアログIDを持つSYNC：シーケンス図
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で示したシナリオと似ていますが、違いがあります。SYNCメッセージ（5feb6486792a、COMEDIAを介してネゴシエートされたもの）で期待される正しいDialog-IDを使用する代わりに、ASは誤った値を使用します（4hrn7490012c） 。これにより、SYNCトランザクションが失敗します。まず、MSはフレームワークレベルの481メッセージを送信します。この応答は、SYNCメッセージへの応答として提供される場合、提供されたDialog-ID（間違った識別子）に関連付けられたSIPダイアログが存在しないことを意味します。その結果、コントロールチャネルを破棄する必要があるため、MSはSYNCメッセージを受信した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（間違ったDialog-IDのCFW SYNC）------------------------------------- ------ CFW 2b4dd8724f27 SYNC Dialog-ID：4hrn7490012c Keep-Alive：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.
2番目のシナリオを図9に示します。
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]は、COMEDIAネゴシエーション後の最初のトランザクションが設定を完了するためのSYNCであることを義務付けています。 ASがSYNCメッセージをトリガーするのではなく、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（SYNCではなくCFW CONTROL）--------------------------------------- -CFW 101fbbd62c35 CONTROLコントロール-パッケージ：msc-ivr / 1.0 Content-Type：application / msc-ivr + xml Content-Length：78
<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 Forbidden）------------------------------- 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シグナリング（UAC <-> 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 |
|<<###########################################>>|
| | |
. . .
. . .
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 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.
よく注意してください：これは、UAC、AS、およびMS間のサードパーティコール制御（3PCC）ネゴシエーションを含む可能なアプローチの例にすぎません。そのため、必須の方法とは見なされず、最善でもありません。提示されたシナリオでの一般的な慣行。 [RFC3725]は、いくつかの異なるソリューションと、3PCCを実現する方法について多くの長所と短所を提供します。図に表示されている2つのINVITEが異なる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が担当するSIP URIにコールを発信します。 URIとそれが提供するサービスとの間のマッピングの背後にあるアプリケーションロジックはASにとってのみ重要な問題であるため、特定のURIは例には関係ありません。したがって、すべての例で一般的な「sip：mediactrlDemo@as.example.com」が使用されますが、ASロジックでこのURIが関連付けられているサービスは、シナリオごとに調査中のケースにマッピングされます。 UAC INVITEは、[RFC5567]で想定されているとおりに扱われます。 INVITEは、UACが提供するSDPに触れずに、ASがサードパーティ経由でMSに転送し（3PCCアプローチなど）、その説明に従ってMSがセッションを完全にネゴシエートするようにします。 MSはUACの提案を独自の機能と一致させ、200 OKで回答を提供します。次に、この回答は、再びSDPコンテンツに触れずに、ASによってターゲットUACに転送されます。このようにして、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の間に1つ以上のメディア接続が作成されます。次に、[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 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
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連絡先：<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：通話の有効期限： 120 Content-Length：330 v = 0 o = lminiero 123456 654321 IN IP4 203.0.113.2 s =会話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 Ringing）------------------------------ SIP / 2.0 180 Ringing Via：SIP / 2.0 / UDP 203.0.113.2:5063;rport=5063; \ branch = z9hG4bK1396873708連絡先：<sip：mediactrlDemo@as.example.com>宛先：<sip：mediactrlDemo@as.example.com>; tag = bcd47c32 From：<sip：lminiero@users.example.com>; tag = 1153573888 Call-ID：1355333098 CSeq：20 INVITE Content-Length：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 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
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許可：INVITE、ACK、CANCEL、OPTIONS、BYE、UPDATE、REGISTER Content-Type：application / sdp Content-Length：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
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; \ 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
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 OK）------------------------ SIP / 2.0 200 OK Via：SIP / 2.0 / UDP 203.0.113.1:5060 ; \ branch = z9hG4bK-d8754z-8723e421ebc45f6b-1 --- d8754z-; rport = 5060連絡先：<sip：MediaServer@ms.example.net：5060>宛先：<sip：MediaServer@ms.example.net：5060>; tag = 6a900179 From：<sip：ApplicationServer@as.example.com：5060>; tag = 10514b7f Call-ID：NzI0ZjQ0ZTBlMTEzMGU1ZjVhMjk5NTliMmJmZjE0NDQ。 CSeq：1 INVITE許可：INVITE、ACK、CANCEL、OPTIONS、BYE、UPDATE、REGISTER Content-Type：application / sdp Content-Length：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
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 OK）------------------------- SIP / 2.0 200 OK Via：SIP / 2.0 / UDP 203.0.113.2： 5063; rport = 5063; \ branch = z9hG4bK1396873708連絡先：<sip：mediactrlDemo@as.example.com>宛先：<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
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 ACK）---------------------- ACK sip：mediactrlDemo@as.example.com SIP / 2.0 Via：SIP / 2.0 / UDP 203.0.113.2:5063;rport;branch=z9hG4bK1113338059差出人：<sip：lminiero@users.example.com>; tag = 1153573888差出人：<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
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 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
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
^^^^^^^^
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=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 ^^^^^^^これらの4つの識別子により、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、以前の値とlabel属性の関連付けは、UACセッションのメディア接続の1つ（この場合はオーディオストリーム）のみをアドレス指定します。例のシナリオでより明確になるように、リクエストの明示的な識別子は「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は、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) +--------+
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 |
| |
+------+
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:
これらの考慮事項から始めて、エコーテストシナリオへの2つの異なるアプローチはこの資料で探求されます：
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から受信する各フレームがリアルタイムでそれに返されることを意味します。
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 |
|<<######################################################>>|
| | |
. . .
. . .
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は、会議制御パッケージ（msc-mixer / 1.0）専用のCONTROL要求（1）をMSに送信することにより、それ自体への接続の参加を要求します。 <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によって送信されたすべてのフレームがそれに返信されることを意味します。操作の結果を報告するために、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 CONTROL）------------------------- CFW 4fed9bf147e2 CONTROL Control-Package：msc-mixer / 1.0 Content-Type：application / msc-mixer + xml Content-Length：130
<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 OK）------------------------ CFW 4fed9bf147e2 200タイムアウト：10 Content-Type：application / msc-mixer + xmlコンテンツの長さ：125
<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
+--|---+ |
+~~~~~~~~~~~<<~~~~~~~~~~~~+
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]を使用して実現できます。これは、レコーディングフェーズとプレイアウトフェーズの両方を担当します。ただし、シナリオ全体を単一のトランザクションで実行することはできません。実際には、少なくとも2つのステップを実行する必要があります。
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:
つまり、2つの個別のトランザクションを呼び出す必要があります。潜在的な複数トランザクションのシーケンス図を図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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
Figure 16: Recording-Based Echo: Two Framework Transactions
図16：録音ベースのエコー：2つのフレームワークトランザクション
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から発信されたCONTROL要求に対して200メッセージで応答しないことです。代わりに、202暫定メッセージが最初に送信され、その後にREPORTメッセージが送信されます。 202 + REPORT（s）メカニズムは、要求された操作が制御パッケージの定義で指定された制限よりも時間がかかる可能性があることをMSがASに伝えたい場合に常に使用されます。そのため、Direct Echoシナリオの<join>操作は非常に短時間で実行されると予想されていましたが、IVR要求はより長く続くと想定されていました。ダイアログの準備がすぐに行われない場合があるため、202メッセージはタイムアウト値を提供し、ASに少し待機するように指示します。この例では、準備はタイムアウトの前に終了するため、トランザクションは「REPORT terminate」で終了し、トランザクションの終了を報告します（前の例の200メッセージと同様）。準備がタイムアウトよりも長くかかった場合、「REPORT終了」による完了まで、追加の「REPORT更新」が新しいタイムアウト値とともに送信されます。
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.
示されているREPORTメカニズムは、その動作を明確にするためにのみ示されていることに注意してください。実際、202 + REPORTメカニズムは、要求されたトランザクションに長い時間がかかることが予想される場合（たとえば、外部サーバーからプロンプト用の大きなメディアファイルを取得する場合）にのみ関与すると想定されています。このシナリオでは、トランザクションははるかに短い時間で準備されるため、単純なCONTROL + 200要求/応答のコンテキスト内で完了する可能性が非常に高くなります。次のシナリオは、厳密に必要な場合にのみ202 + REPORTを含みます。
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).
ダイアログ自体については、要求されたダイアログが開始するとすぐに、ASから発生したCONTROLトランザクションがどのように終了するかに注意してください。 [RFC6231]で指定されているように、MSはフレームワークのCONTROLメッセージを使用して、ダイアログの結果とダイアログの進行状況を報告します。以下で説明するように、2つのトランザクション（AS生成のCONTROL要求とMS生成のCONTROLイベント）は、関連するダイアログ識別子を使用して関連付けられます。以前と同様に、トランザクションステップには番号が付けられています。 2つのトランザクションは、前の文字で区別されます（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 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.
o ASは、最初のトランザクションとして、CONTROL要求（A1）を使用してUAC接続の記録を呼び出します。本文はIVRパッケージ（msc-ivr / 1.0）用であり、新しい記録コンテキスト（<record>）の開始（<dialogstart>）を要求します。録音の前にはアナウンス（<prompt>）が必要であり、10秒（maxtime）を超えてはならず、DTMFトーン（dtmfterm = false）によって中断することはできません。これは1回だけ行われます（欠落しているrepeatCount属性は、<dialog>のデフォルトでは1です）。つまり、記録が初めて成功しない場合、トランザクションは失敗する必要があります。関連付けられた接続にオーディオとビデオの両方が含まれ、記録するストリームに制限が適用されていないことを考慮して、ネゴシエートされたメディアストリームの両方から供給されるビデオ記録が要求されます。 UACに通知するには、録音が始まる直前にビープ音を鳴らす必要があります（beep = true）。
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が提供されているアナウンスファイルを取得し、リクエストの形式が正しいことを確認することにより）、問題がなければ、それを開始し、ASに終了ステータスの新しいレポート（A3）。前に説明したように、202メッセージで提供されたタイムアウトよりも準備に時間がかかった場合（たとえば、HTTP経由でリソースを取得するのに予想よりも時間がかかった場合）、更新ステータスのある対話型のREPORTメッセージが送信されます。ダイアログが準備されて開始されると、UAC接続はIVRパッケージに渡され、最初に接続でアナウンスが再生され、続いてビープ音が鳴り、すべての着信フレームがバッファーに記録されます。 MSは、ASに、それが参照するダイアログに関する後続のすべてのイベント通知で使用される一意のダイアログ識別子（dialogid）も提供します。
o The AS acks the latest REPORT (A4), thus terminating this transaction, and waits for the results.
o ASは最新のREPORT（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は通知CONTROL（B1）を準備します。 <event>本体は、通知がその特定のダイアログに関連しているという事実をASに認識させるために、以前に提供されたダイアログ識別子への明示的な参照で準備されます。イベント本体は、記録関連情報（<recordinfo>）で完了します。この場合、ASが必要なものに使用できる記録ファイル（ここではHTTP URL）へのパスです。ペイロードには、プロンプトに関する情報（<promptinfo>）も含まれますが、シナリオには関係ありません。
o The AS concludes this first recording transaction by acking the CONTROL event (B2).
o ASは、CONTROLイベント（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を再生させることで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 2番目のトランザクションでは、ASは新しいCONTROL要求（C1）によってUAC接続でプレイアウトを呼び出します。本文は再びIVRパッケージ（msc-ivr / 1.0）用ですが、今回は新しいアナウンスコンテキスト（<prompt>）の開始（<dialogstart>）を要求します。再生されるファイルは、以前に記録されたファイルです（<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は新しいダイアログを準備して開始し、終了ステータスの新しいREPORT（C3）でASに通知します。接続はIVRパッケージに渡され、そこでファイルが再生されます。
o The AS acks the terminating REPORT (C4), now waiting for the announcement to end.
o ASは終了するREPORT（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は、本体（<promptinfo>）に、完了したばかりのアナウンスに関する情報を含むCONTROLイベント（D1）を送信します。以前と同様に、適切なダイアログIDが正しいダイアログへの参照として使用されます。
o The AS concludes this second and last transaction by acking the CONTROL event (D2).
o ASは、CONTROLイベント（D2）を確認することにより、この2番目と最後のトランザクションを終了します。
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
<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
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>
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
<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
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>
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
<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
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>
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間の相互作用を伴う可能性のある別のシナリオは、2つの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.
これらのケースの1つは、2つのUACにサポートされている共通のコーデックがない場合です。2つのUACが直接セッションをネゴシエートすると、使用可能なメディアのないセッションが発生します。この場合、MSをトランスコーダとして使用しても、2つのUACが通信できます。もう1つの興味深いケースは、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.
このようなシナリオがMedia Control Channel Frameworkによってどのように達成されるかを検討する前に、すべての関係者を含む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 | |
| |<--------------------| |
| | 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に電話をかけたいと考えています。これを行うには、オファーAとともにINVITEをASに送信します。ASはオファーのないINVITEをUAC2に送信します。 UAC2が180で応答すると、同じメッセージがASによってUAC1に転送され、呼び出し先が呼び出し中であることが通知されます。一方、ASは、セクション6の冒頭で説明したように、MSにUAC1のレッグも追加します。これを行うには、UAC1が行ったオファーAを使用します。 UAC2が200で独自のオファーBを提供してコールを受け入れると、ASはオファーBのレッグをMSに追加します。この時点で、MSがネゴシエートしたSDP応答を2つのUACに提供することにより、ネゴシエーションを完了することができます（それぞれ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.
交渉が終了すると、2つのUACはまだ通信していません。実際、以前に説明したようにUACに関連付けられた接続識別子を参照することにより、MSをアクティブにトリガーして何らかの方法でメディアストリームを相互にアタッチするのはASの責任です。このドキュメントでは、達成する必要があることに従って、2つの異なるアプローチを紹介します。通話シナリオの一般的なメディアの視点を図18に示します。MSは基本的に2つのUAC間のメディアパスにあります。
+-------+ 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
| |
+--------------+
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.
直接接続のアプローチは、2つのUAC間の通話を機能させるための最も簡単で簡単な方法です。この考え方は、基本的にダイレクトエコーアプローチの考え方と同じです。 <join>ディレクティブは、必要に応じて、MSを利用してフローフレームのトランスコーディング/適応のみを処理することにより、1つのUACを別のUACに直接接続するために使用されます。
This approach is depicted in Figure 20.
このアプローチを図20に示します。
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*>| | |
. . . .
. . . .
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のメディア接続を自身に接続することは想定されていませんが、2つの異なる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 CONTROL）------------------------- CFW 0600855d24c8 CONTROL Control-Package：msc-mixer / 1.0 Content-Type：application / msc-mixer + xml Content-Length：130
<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 OK）------------------------ CFW 0600855d24c8 200タイムアウト：10 Content-Type：application / msc-mixer + xmlコンテンツの長さ：125
<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.
このような単純なアプローチには欠点があります。たとえば、このようなアプローチでは、2人のユーザー間の会話を録音するのが難しい場合があります。実際、混合は含まれないため、単一の接続（UAC1 <-> MSおよびUAC2 <-> MS）のみを記録できます。いずれにしても、ASが会話録音サービスの提供を希望する場合は、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.
アイデアは、2つのUAC間のブリッジとして機能するMS内の混合エンティティを使用することです。このエンティティが存在することで、例として提供されている会話の録音のように、会話で実行する必要があることをさらにカスタマイズできます。このアプローチを図22に示します。MSのミキシング機能については、次のセクション（会議関連の多くのシナリオを扱います）で詳しく説明します。そのため、ここでは、アプローチの基本的な理解のために、いくつかのヒントのみを示します。
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は、これがMedia Control Channel Frameworkでどのように達成されるかを示しています。この例では、いつものように、UACと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*>| | |
| | | |
. . . .
. . . .
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はこのシナリオを達成するために2つの異なるパッケージを使用します。ミキサーパッケージ（ミキシングエンティティを作成して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」値と同様に、「予約済みトーカー」と「予約済みリスナー」の両方が2に設定されます。ビデオレイアウトもそれに応じて設定されます（<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は、ビデオ録画（type = video / mpeg）に関心があります。これは、3時間（maxtime = 10800s）より長く続くことはできません。その後、録画を終了する必要があります。さらに、会議でビープ音を鳴らす必要はなく（beep = false）、オーディオアクティビティが報告されているかどうかにかかわらず、すぐに録音を開始する必要があります（vadinitial = falseは<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によって処理され、ダイアログが正常に開始されると、200 OKがASに発行されます（B2）。メッセージには、ダイアログ（00b29fb）に関連付けられたダイアログIDが含まれています。これは、ASが後で通知するために参照する必要があります。
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は2つの別々の<join>ディレクティブ（C1 / D1）を使用して、両方のUACを会議に接続します。 MSが両方の操作（C2 / D2）の成功を確認すると、2つのUACは実際には互いに接触しています（間接的にですが、気づいていない非表示の会議がパス上にあるため）。記録。
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>
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>
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>
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>
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>
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>
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>
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>
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時間に達した）またはダイアログ自体の中断（たとえば、ASが録音の中断をアクティブに要求するUACは終了しました）。
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が2つのUAC間の通話を録音する場合、ミキサーなしで<join>ディレクティブのみを使用すると、ASは個別の録音コマンドに依存するだけになります。つまり、ASは、各メディアレッグを流れるメディアを個別に記録するようにMSに指示するだけです。UAC1からのすべてのデータの記録と、UAC2からのすべてのデータの異なる記録です。その後誰かが会話全体にアクセスしたい場合、ASは少なくとも2つの異なるアプローチを取る場合があります。
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. 2つのレコーディングの組み合わせを含む単一のファイルを取得するために、2つのレコーディング自体を（たとえば、オフラインのミキシングエンティティに委任することによって）混合する場合があります。この方法では、セクション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自体が提供するミキシング機能を利用することもできます。これを行う1つの方法は、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.
このセクションでは、2番目のアプローチについて検討します。図24で説明されているフレームワークトランザクションは、UAC1とUAC2の両方の録音がすでに要求され、通話が終了し、ASがMSから両方の録音へのURIを正常に受信したことを前提としています。これらの手順は、6.1.2で説明した手順と非常に似ているため、再度説明しません。前述のように、アイデアは、適切に構成された非表示の会議を使用して、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>) |
| |<<++++++++++++++++++++++++++++++++|
| | 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は録音のプレイアウトを要求できます。そのために、UAC1（REC1）とUAC2（REC2）の記録にそれぞれ対応する2つの<prompt>ディレクティブ（C1とD1）を同時に要求します。 <dialog>要素の 'conferenceid'属性から推定できるように、両方のプロンプトは、UAC3ではなく、以前に作成された会議で再生する必要があります。
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）、次に、プレイアウトが終了するとすぐに、関連するCONTROLメッセージがMS（E1、F1）によってトリガーされます。この通知には、プレイアウトがどのように進行したか（たとえば、プレイアウトが正常に完了したか、DTMFトーンによって中断されたかなど）に関する情報を含む<promptinfo>要素が含まれる場合があります。
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
<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
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が提供できる最も重要なサービスの1つは、ミキシングです。これには、多くの場合ユーザーごとのポリシー、設定、およびエンコーディングに従って、さまざまなソースからのメディアストリームを混合し、結果のミックスを各関係者に配信することが含まれます。ミキシングを含む典型的なシナリオは、もちろん、メディア会議です。このようなシナリオでは、各参加者によって送信されたメディアが混合され、各参加者は通常、全体のミックスを受信します。自分の投稿を除き、交渉した形式でエンコードされます。この例は、ミキシングが関係する各エンティティのプロファイルをどのように処理する必要があるかを非常に明確に指摘しています。
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) +-------+
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
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. 単純なブリッジングシナリオ。これは、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).
上記のシナリオはすべて、混合エンティティの可用性に依存します。このようなエンティティは、会議パッケージによってMedia Control Channel Frameworkで提供されます。ダイレクトエコーテストのセクションにあるように、メディアソースの相互接続を可能にするほかに、このパッケージでは、複数の接続に参加できる抽象接続を作成できます。会議と呼ばれるこれらの抽象的な接続は、接続されている各接続の貢献を混合し、それに応じてフィードします（たとえば、「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 Frameworkで新しい会議インスタンスを作成するための一般的なフレームワークトランザクションを図27に示します。
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は、CONTROL要求（1）によって新しい会議インスタンスの作成を呼び出します。この要求は、会議パッケージ（msc-mixer / 1.0）に送信され、新しい会議インスタンスに必要なすべての設定を含むディレクティブ（<createconference>）が本文に含まれています。以下の例では、最大10人のリスナーが許可されている間、ミキシングポリシーは5人の（ 'reserved-talkers'）ラウドスピーカー（nbest）をミックスすることです。アクティブなビデオソースを選択するために使用されるメカニズム（<controller>、ASが明示的にMSに指示することを意味します）やビデオレイアウトに関する詳細など、ビデオ設定が構成され、利用可能になります。この例では、ASは、1つのビデオソースのみがアクティブな場合は<single-view>レイアウトを使用し、少なくとも2つのビデオソースがアクティブな場合は<quad-view>レイアウトに渡して、 <multiple-5x1>ソースの数が5つ以上の場合のレイアウト。最後に、ASは「active-talkers」イベントもサブスクライブします。これは、アクティブな参加者が話しているときはいつでも（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 CONTROL）------------------------- CFW 3032e5fb79a1 CONTROL Control-Package：msc-mixer / 1.0 Content-Type：application / msc-mixer + xml Content-Length：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>
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 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="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
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）に示されているように、新しい会議インスタンスを作成することです。会議インスタンスがすでに作成されていると仮定すると、参加者の会議インスタンスへのブリッジは非常に簡単であり、ダイレクトエコーテストのシナリオに見られるように実行できます。ここでの唯一の違いは、各参加者が自分自身（直接エコー）または別のUAC（直接接続）に直接接続されておらず、代わりにブリッジに接続されていることです。図29は、2つの異なるUACが同じ会議に参加する例を示しています。この例では、いつものように、2つのUACのそれぞれとASの間の以前の対話を隠し、代わりに、参加者が実際にブリッジに参加して参加者が会議で対話できるようにするためにASが行うことに焦点を当てています。また、図を読みやすくするために、シナリオの導入に以前に使用された識別子（UAC A、B、C）の代わりに2つの異なる識別子（UAC1とUAC2）が使用されていることにも注意してください。
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）に参加させます。これら2つの操作の結果、両方のUACが会議で混合されます。どのトランザクションでも<stream>が明示的に提供されていないため、UACからのすべてのメディア（オーディオ/ビデオ）が会議に接続されます（もちろん、会議が両方をサポートするように適切に構成されている限り）。
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>
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>
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>
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>
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.
1人以上の参加者がブリッジに接続されると、その接続と、ブリッジによるメディアの処理方法は、<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) |
|<<######################################################|
| | | |
. . . .
. . . .
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が1つ以上の結合された接続をアドレス指定するときはいつでも、ASは結合構成の変更を要求しています。この場合、ASは、以前に接続されていた会議（id2）のUAC1（id1 = UAC1）をミュート（<stream> media = audio、direction = recvonly）するようにMSに指示します。それらの間に存在する他の接続は変更されません。
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での会議を指します。つまり、必要な変更は、メッセージの<stream>要素で指定されたストリームに、「id1」から「id2」に向かう方向に沿って適用する必要があります（メッセージの<modifyjoin>要素で指定） 。提供されている例では、ASは会議に関してUAC1をミュートしたいと考えています。これを行うには、方向を「recvonly」に設定します。これは、id1に影響するものについては、メディアストリームのみが受信されることを意味します。 id1が会議を参照し、id2がUAC1を参照する場合、同じ結果を得るには、方向を「sendonly」に設定する必要があります。つまり、「id1（会議）はid2（UAC1）にのみ送信でき、メディアストリームは受け取った」。 <ストリーム>の追加設定（オーディオボリューム、リージョンの割り当てなど）は、後続のセクションで説明するように、同じアプローチに従います。
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 CONTROL）------------------------- CFW 57f2195875c9 CONTROL Control-Package：msc-mixer / 1.0 Content-Type：application / msc-mixer + xml Content-Length：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>
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 OK）------------------------ CFW 57f2195875c9 200タイムアウト：10 Content-Type：application / msc-mixer + xmlコンテンツの長さ：123
<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 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.
前のシナリオは、既存の会議システムによく見られる追加機能で強化できます。典型的な例には、IVRベースのメニュー（PINベースの会議アクセス用のDTMFコレクションなど）、会議での部分的および完全な記録（たとえば、「名前を述べる」機能、および会議全体の記録）、プライベートおよびグローバルが含まれます。アナウンスなど。これはすべて、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
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を招待し、ASは前述の手順に従って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が参加者と実際に対話して会議ブリッジに参加するために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>) |
| |<<++++++++++++++++++++++++++++++++|
| 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 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.
oこれはプライベートな会議なので、UACにはパスワードの要求（この場合はPIN番号）が提示されます。そのために、ASはMS（A1）に指定されたUAC（connectionid = UAC）から一連のDTMFディジットを収集するように指示します。要求には、音声メッセージ（<prompt>）と説明された番号収集コンテキスト（<collect>）の両方が含まれます。 PINは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生成のCONTROLイベント（B1）によってMSから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からのオーディオのみを記録します（ストリームでは、media = audio / sendonly、media = video / inactive）。 ）。ビープ音は、録音が始まる直前に鳴らす必要があり（beep = true）、録音は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 connections attached to the conference that are allowed to receive media from it. The AS specifically requests that two media files be played:
o最後に、新しい参加者が到着したことを他の参加者に通知するために、ASは会議でのグローバルなアナウンスを要求します。これは、前のセクションで説明したように（特にセクション6.1.2など）、IVRパッケージ（F1）への単純な<prompt>リクエストですが、わずかな違いがあります。プロンプトのターゲットはconnectionidではありません（aメディア接続）しかし、会議自体（conferenceid = 6146dd5）。このトランザクションの結果、アナウンスは、会議からメディアを受信することが許可されている、会議に接続されているすべてのメディア接続で再生されます。 ASは特に、2つのメディアファイルの再生を要求します。
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
<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
<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
<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
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>
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>
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>
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
<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
<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
<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
<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
<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
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は、Bに正しい提案を与え、会話全体を認識するために、Aと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) +-------+
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
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 receive the mixed flows from the conference ('sendonly'), unlike the agent and the coach, who must both be aware of the whole conversation ('sendrecv').
対照的に、シナリオはどのように見えるかを図35に示します。顧客はエージェントから直接メディアを受け取り（「recvonly」）、関係する3人の参加者全員が非表示の会議に参加します。もちろん、会話全体（ 'sendrecv'）の両方を認識しているエージェントとコーチとは異なり、顧客は会議から混合フロー（ 'sendonly'）を受け取ることはできません。
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:
フレームワークでは、これはミキサーコントロールパッケージを使用して実現できます。これは、前の会議の例で示したように、エンティティの混合と結合が必要なときにいつでも利用できます。必要な手順を次のリストにまとめます。
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. 次に、3人の参加者がすべてそれにアタッチされ、それぞれにカスタムミキシングポリシーが割り当てられます。具体的には、次のとおりです。
* the customer (A) as 'sendonly'.
* 「sendonly」としての顧客（A）。
* the agent (B) as 'sendrecv'.
* 「sendrecv」としてのエージェント（B）。
* 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).
* コーチ（C）は「sendrecv」として、-3 dBのゲインで、それ自体の寄与の音量を半分にします（エージェントが実際に大きな音量で顧客の声を聞き、コーチがささやくのを聞きます）。
3. Finally, the customer is joined to the agent as a passive receiver ('recvonly').
3. 最後に、顧客はパッシブレシーバー（「recvonly」）としてエージェントに参加します。
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 |
| | |<<######################################>>|
| | | | |
| | | | 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人だけなので、 'reserved-talkers'は3に設定されます。一方、 'reserved-listeners'は2に設定されます。これは、エージェントとコーチのみがミックスを受信する必要があるためです。顧客はコーチを知らない必要があります。最後に、同じ理由でビデオレイアウトは<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は3つのアクターに異なるポリシーで参加します。つまり、（i）顧客（A）が「送信専用」として会議に参加します（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に提供することです。このようにして、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
<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
<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
<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
<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
<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
<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
<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
<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
<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
<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.
会議のコンテキスト内では、いわゆるサイドバーまたはサイド会議が必要になる可能性があります。たとえば、会議の2人以上の参加者がバックグラウンドで元の会議ミックスの一部を受信しながら、相互にサイド会議を作成する場合です。このようなユースケースの動機は、[RFC4597]と[RFC5239]の両方にあります。このような場合、サイド会議は実際には別の会議ですが、何らかの形で元の会議と関連付けられている必要があることは明らかです。アプリケーションレベルの関係はこのドキュメントの範囲外ですが（これは一元化された会議（XCON）に「属します」）、メディアストリームの関係はここでより重要です。見る。したがって、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 (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.
このセクションで紹介するシナリオは、A、B、C、Dの4人の異なる参加者をホストする会議です。これらの参加者はすべて、既存のメディアストリームのアクティブな送信者と受信者として会議に接続されます。ある時点で、2人の参加者（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 |
+-------+
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
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のようになります。サイドバーをホストするために新しいミキサーが作成されます。メインミックスは、サイドバーユーザーにメインカンファレンスの背景を提供するために、「送信のみ」としてサイドバーミックスに少量で接続されます。関心のある2人の参加者（BとD）のオーディオレッグがメイン会議から切り離され、サイドバーに接続されています。この切り離しは、実際にレッグを切り離すか、レッグのステータスを「非アクティブ」に変更するだけで実現できます。これはオーディオストリームにのみ影響することに注意してください。2人のユーザーのビデオは引き続きメインの会議に添付され、アプリケーションレベルで行われる処理はそれに応じて変更される場合と変更されない場合があります（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
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:
フレームワークでは、前のセクションと同様に、提示されたシナリオは、ミキサーコントロールパッケージを使用して再び実現できます。必要な手順を次のリストにまとめます。
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>が 'inactive'ステータス）。
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をメインミックスからデタッチする場合、<unjoin>ではなく、ステータスが「inactive」の<modifyjoin>が使用されることに注意してください。これの動機は、メインミックスへの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:
そのような一連のトランザクションの図（confXは既存のメイン会議ミックスの識別子です）を図40に示します。
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) |
| |<<########################################>>|
| | |
. . .
. . .
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>リクエストです。リクエストは非常に軽量で、BとDに加えて、2つのリスナーシート（「予約済みリスナー」、BとDだけが何かを聞く必要があるため）と3つのトーカーシート（「予約済みリスナー」）だけを予約するようにMSに要求します。メインミックスもサイドバーへのアクティブな貢献者です）。ミキシングは、AS（mix-type = controller）からのディレクティブによって駆動されます。ミックスが正常に作成されると、MSはASにID（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）に参加します。オーディオのみを結合する必要があり（media = audio）、「sendonly」方向（つまり、メイン会議からサイドバーにのみ流れ、逆は流れません）で、元のストリームに対して30％の音量（setgain =- 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
<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
<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
<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
<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
<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
<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
<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
<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
<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
<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
<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
<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 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.
[RFC4597]で説明されているように、フロア制御は、ほとんどの会議シナリオで通常必要とされ、採用されている機能です。実際、会議アプリケーションを実現するときに実装する必須の機能ではありませんが、参加者が提供するメディアストリームをさらに制御できるため、使用可能なリソースを調整できます。集中会議（XCON）フレームワーク[RFC5239]は、前述の機能を実現するためにBinary Floor Control Protocol（BFCP）[RFC4582]を使用することを提案しています。とは言うものの、会議用のMEDIACTRL仕様によって利用可能になったフロア制御機能とツールを組み合わせて使用することは、調査することは間違いなく興味深いでしょう。 [RFC5567]は、MEDIACTRLアーキテクチャとフロア制御を統合する2つの異なるアプローチを紹介します。（i）フロア制御サーバーがASと同じ場所に配置されているトポロジと、（ii）フロア制御サーバーがMS。 2つのアプローチは、特にフロアキューの背後にあるロジックと自動化された決定について考える場合、ASとMSが処理する必要がある情報の量に関して明らかに異なります。それにもかかわらず、メディアコントロールチャネルフレームワークがどのように考えられるかを考えると、アプローチ（ii）は、MSにフロア制御を認識させ、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.
このシナリオでは、Floor Control Server（FCS）がASと同じ場所に配置されていると想定します。これは、すべてのBFCP要求がフロア制御参加者（FCP）によってFCSに送信されることを意味します。これにより、ASはフロアのステータスを直接認識します。簡単にするために、シナリオでは、関係する参加者が特定の会議のBFCP要求を行うために必要なすべての識別子をすでに認識していると想定しています。このような情報は、[RFC4583]で指定されているCOMEDIA交渉に従って運ばれた可能性があります。そのような情報がMSに到達してはならないことに注意することが重要です。これは、MSにUACを接続するために使用された可能性のある3PCCメカニズムのコンテキスト内で、MSがネゴシエーションを利用できるようにする前に、ASとUACによってネゴシエートされたすべてのBFCP関連情報を削除する必要があることを意味します。仕様が理解できない場合があります。これを実現する方法の簡単な例を図41に示します。このシナリオ例のコンテキスト内では、同じエンティティをアドレス指定するために異なる識別子が使用される場合があることに注意してください。具体的には、この場合、UAC（メディアを送受信するエンドポイント）もBCPチャネルをネゴシエートするため、FCPでもあります。
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 |
+--------+
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としても機能します。このシナリオでは、2つのフロア制御参加者、つまり基本参加者（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に送信します（ChairAction ACCEPTED）。
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 ACCEPTED）に送信されます。フロアはまだ許可されていません。
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に付与されます。 FCSと同じ場所に配置されているASは、そのようなイベントがFCPに許可されているオーディオリソースに関連付けられていることをビジネスロジックで理解しています。その結果、会議でFCP UACのミュートを解除するために、<modifyjoin>（ 'sendrecv'）が制御チャネルを介してMSに送信されます。
7. The FCP is notified of this event (FloorRequestStatus GRANTED), thus ending the scenario.
7. FCPにこのイベントが通知され（FloorRequestStatus GRANTED）、シナリオが終了します。
A diagram of such a sequence of transactions (also involving the BFCP message flow at a higher level) is depicted in Figure 43:
そのような一連のトランザクションの図（より高いレベルのBFCPメッセージフローも含む）を図43に示します。
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 |
| |<<*******| |
| | | |
. . .
. . .
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 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:
上の図から簡単に推測できるように、BFCPレベルでの複雑な相互作用は、MEDIACTRLレベルでの単一トランザクションのみをもたらします。実際、BFCPトランザクションの目的は、オーディオリソースへのアクセスを管理することです。つまり、MEDIACTRLベースの会議操作トランザクションにイベントトリガーを提供します。発言権が付与される前は、FCP UACはMEDIACTRLレベル（ 'recvonly'）の会議ミックスから除外されています。フロアが許可されるとすぐに、FCP UACがミックスに含まれます。 MEDIACTRLの言葉で：
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をオーディオミックスに含める必要があるため、CONTROLディレクティブで<modifyjoin>がMSに送信されます。 <modifyjoin>には、FCP UACに関連付けられた接続ID（e1e1427c：1c998d22）とミックスの会議ID（cf45ee2）が識別子として含まれています。 <stream>要素は、2つの間のオーディオメディアストリームが双方向（ 'sendrecv'）になり、以前のステータス（ 'recvonly'）を変更する必要があることをMSに通知します。この場合、会議に参加したのは音声のみでした。ビデオも含まれていて、ビデオを変更する必要がない場合は、現在のステータスを維持するために、ビデオの<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 CONTROL）------------------------- CFW gh67ffg56w21 CONTROL Control-Package：msc-mixer / 1.0 Content-Type：application / msc-mixer + xml Content-Length：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>
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 OK）------------------------ CFW gh67ffg56w21 200タイムアウト：10 Content-Type：application / msc-mixer + xmlコンテンツの長さ：123
<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 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:
このセクションには、AS <-> MSフローを処理するときに重要になる可能性がある追加のシナリオが含まれています。次のサブセクションの目的は、IVRパッケージに固有の機能の使用を示すことです。具体的には、可変アナウンス、VCR（ビデオカセットレコーダー）プロンプト、並行再生、繰り返しダイアログ、およびカスタム文法です。このような機能を含むコールフローがどのように発生するかを説明するために、3つのサンプルシナリオが選択されています。
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コントロールを使用して録音されたメッセージの再生を制御する機能などがあります。これらの機能はすべて、IVRパッケージを通じてMSによってサポートされています。
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を招待し、ASは前述の手順に従って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 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.
UACで古いメッセージを削除したり整理したりすることはできず、再生する受信メッセージを選択することだけを考えれば、これは非常に単純化されたシナリオです。それにもかかわらず、ボイスメールアプリケーションがほとんど常に利用する2つの典型的な機能である可変アナウンスとVCRコントロールに対処する機会を私たちに与えます。ボイスメールアプリケーションが依存する他の機能（たとえば、レコーディングストリーム、イベントドリブンIVRメニューなど）は前のセクションで紹介されているため、それらを表すことは冗長です。つまり、提示されたコールフローは、一部のメッセージがすでに録音されており、到達可能な場所で利用可能であることを前提としています。この例では、一時的なものである可能性が高い内部MSストレージに依存することが安全ではないため、ASが独自のストレージ設備に記録を配置したことも想定しています。
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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
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>プロンプトは、ASによって提供されるディレクティブに従って、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）を作成して、桁（ "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は1桁（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がすべてのオーディオファイルを取得して変数アナウンスを正常に構築した場合）、ダイアログが開始されます。その開始は、関連付けられた識別子（5db01f4）とともに、終了200 OKメッセージ（A2）で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はこのトーンを傍受し、新しく作成されたCONTROLイベントメッセージ（B1）でASに通知します。このCONTROLには、要求された各操作がどのように終了したかに関する情報が含まれます（<promptinfo>および<collectinfo>）。具体的には、このイベントは、プロンプトが正常に終了し（termmode = completed）、その後に収集されたトーンが1（dtmf = 1）であることを示しています。メッセージで提供されたダイアログIDは以前に開始されたダイアログのものと同じであるため、ASはイベント（B2）を確認します。
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>と、このメディアの再生方法をMSに指示する<control>の2つの操作が含まれます。ファイルは、UACによって提供されるDTMFトーンを介して制御されます（この例では、さまざまなDTMF数字がさまざまなアクション（たとえば、一時停止/再開、早送り、巻き戻しなど）に関連付けられています）。 ASは、この制御操作（matchmode = control）に関連するDTMFイベントもサブスクライブします。つまり、MSは、制御操作（7 =一時停止など）に関連付けられたDTMFがインターセプトされるといつでもイベントをトリガーします。
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に報告されます。 UACが特定の時間に早送りキー（6）を押した例（D1）が提供されています。もちろん、他の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 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.
o再生が終了すると（メディアが終了に達したため、またはその他の中断が発生したため）、MSはダイアログ全体に関する情報（E1）で終了イベントをトリガーします。このイベントには、プロンプト自体に関する情報（<promptinfo>）に加えて、VCR操作（<controlinfo>）に関連する情報も含まれます。つまり、すべてのVCRが、使用される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
<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
<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
<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
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>
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>
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>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 361840da0581 200
[..] The other VCR DTMF notifications are skipped for brevity [..]
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>
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は現在の日付と時刻を発信者に提示します。アプリケーションの性質によって容易に推測できるため、このシナリオでは可変アナウンスが重要な役割を果たします。実際、さまざまなフレームワークメッセージを使用してASが現在の時間に従ってアナウンスを作成するのではなく、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:
シナリオをより面白くし、より多くの機能をカバーするために、アプリケーションはアナウンス中にバックグラウンドミュージックを再生することも想定されています。ほとんどのアナウンスは可変であるため、同じ接続でより多くのストリームを並行して再生する手段が必要です。これは、2つの異なる方法で実現できます。
1. two separate and different dialogs, playing the variable announcements and the background track, respectively.
1. 変数アナウンスとバックグラウンドトラックをそれぞれ再生する2つの別々の異なるダイアログ。
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.
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.
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. 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.
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 |
| |++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
. . .
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>要素で示されるように、並行再生のディレクティブが含まれています。並行してプレイする3つのフローがあります。
* 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%).
* 低い音量（soundLevel = 50％）でバックグラウンドで再生される音楽トラック（ 'media = music.wav'）。
* a mute background video track (media=clock.mpg).
* ミュートバックグラウンドビデオトラック（media = 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:
グローバルアナウンスは、3つの並行ステップの最長の終了時に終了します（endsync = last）。つまり、ステップの1つが他のステップより先に終了した場合、残りの再生ではそのステップがミュートされます。この例では、一連の静的および<変数>アナウンスがASによって要求されます。
* 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).
* 日付（「2008年12月16日...」）を作成して再生します（変数：ymd = year / month / day形式の日付）。
* play a time ("5:31 PM...") by building it (variable: time with a t12=12 hour day format, am/pm).
* 時間（ "5:31 PM ..."）を構築して再生します（変数：t12 = 12時間形式の時間、am / pm）。
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は必要なすべてのメディアファイルを取得するためにさらに時間が必要であるため、トランザクションはMS（A2）によって新しいタイムアウトで拡張されます。新しいタイムアウトも期限切れになると、MSはそれを再度延長するためにさらにメッセージを送信します（レポート更新）。ただし、簡単にするために、このシナリオでは不要であると想定しています。すべてがうまくいった場合（つまり、MSがすべてのオーディオファイルを取得し、変数アナウンスを正常に構築し、要求に応じて並行再生をサポートしている場合）、ダイアログが開始されます。その開始は、関連する識別子（415719e）とともに、終了するREPORTメッセージ（A3）で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 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 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 3つの並行アナウンスの最後が終了すると、ダイアログが終了し、関連情報（promptinfo）を使用してASに対してイベント（B1）がトリガーされます。 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
<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
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>
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
<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
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 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:
等々。これをすべて実現するために、ASが実行できる最も簡単なことは、一致する特定の文法を持つ各参加者に対して繰り返しDTMFコレクションを準備することです。収集されたトーンが文法と一致する場合、MSはASにトーンを通知し、収集を再開します。 ASは、<collectinfo>イベントを受信すると、会議の参加者のストリームに<modifyjoin>などの適切な関連リクエストを送信します。これは、IVRパッケージによって提供される3つの機能によって可能になります。
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].
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].
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:
これは、6つの異なるコードがサポートされ、要求された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>
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 |
|<<########################################################|
| | |
| | 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 |
| |++++++++++++++++++++++++++++++++++++>>|
| | |
. . .
. . .
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）にアドレス指定されたCONTROL要求を配置することによって行われます。実装する操作は<collect>であり、2桁のDTMF文字列（maxdigits）のみに関心があります。 ASはDTMFターミネーターに関心がなく（termcharは従来とは異なるDTMF文字に設定されています）、DTMFエスケープキーは '＃'に設定されています（デフォルトは '*'で、これはコード構文と競合します会議などを変更する必要があります）。カスタムSRGS文法がインラインで提供されます（<grammar>とmode = dtmf）。ダイアログ全体が無期限に繰り返され（ダイアログにはrepeatCount = 0が含まれます）、ASは一致するコレクションが発生したときに通知されることを望みます（matchmode = collectを指定したdtmfsub）。
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から一致するDTMF文字列を収集します（* 1）。 ASがこの種のイベントにサブスクライブしたため、収集されたトーンを含むCONTROLイベント通知（dtmfnotify）がMS（B1）によってトリガーされます。ダイアログは繰り返し発生するため、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" 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.
o ASはイベント（B2）を確認し、そのビジネスロジックでは、コード '* 1'は会議ミックスでUACが自身のボリュームを下げることを望んでいることを理解しています。 ASは、添付されたダイアログID（01d1b38）を参照することにより、イベントを適切なUACに関連付けることができます。次に、これを正確に実行する<modifyjoin>（C1）を送信することにより、それに応じて動作します。提供された<stream>子要素は、UACのボリュームを変更するようにMSに指示します->会議オーディオフロー（setgain = -5 dB 'sendonly' ）。 「setgain」値は絶対音量レベルであることに注意してください。ユーザーの要求が音量レベルを下げることである場合、ASは以前に設定された音量レベルを記憶し、そこから新しい音量レベルを計算する必要があります。リクエストには逆方向のディレクティブも含まれていることに注意してください。この冗長なアプローチが必要です。そうしないと、MSは要求された方向のボリュームを変更するだけでなく、他の方向のメディアフローも無効にします。 UAC <-confメディアフローに対応する適切な<stream>があると、これが起こらないことが保証されます。
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>が新しい命令（setgain = + 3 dB 'recvonly'）とともに送信されます（E1）。増分操作をコマンドにマップする方法に関する同じ考慮事項がここでも適用されます。逆方向（ 'sendonly'）の<stream>がプレースホルダーとして再び提供される方法にも注意してください。これは、基本的に、（C1）の以前のディレクティブを維持しながら、その方向の設定を変更しないことをMSに指示します。
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 必要な確認応答（F2）の後、ASは、新しいコード（ '* 6'）に関連付けられたアクションを実装することによって反応します。これにより、UACは会議内でミュートすることを要求しました。新しい<modifyjoin>が適切に構築されたペイロード（setstate = mute 'sendonly'）とともに送信され（G1）、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 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 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.
* 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.
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）によって実現され、後者はMixerパッケージへの<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）に対してもトリガーされます。このイベントには、最後の反復の結果に関するレポートはなく（ダイアログはimmediate = 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）。参加解除操作の結果として、<unjoin-notify>イベント通知がMS（L1）によってトリガーされ、要求されたエンティティーが互いに接続されなくなったことをASに確認します。イベントのステータスは0に設定されます。これは、仕様に記載されているように、結合が<unjoin>リクエストによって終了されたことを意味します。 AS（L2）からの確認応答により、このシナリオは終了します。
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>
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>
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>
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
<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
<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
<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
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>
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>
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>
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
<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
<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
<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
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>
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>
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>
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
<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
<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
<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
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にも潜在的に関与するいくつかの可能なトポロジを示しています。このようなトポロジを適切に可能にするために、メディアリソースブローカー（MRB）と呼ばれる追加要素がMEDIACTRLアーキテクチャに導入されました。そのようなエンティティ、およびそれと対話するために必要なプロトコルは、[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のプールを認識し、要件に応じて関心のあるASで利用できるようにするロケーターです。このため、2つの異なるインターフェースが導入されています。
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 MRBが処理しているMSで通知をサブスクライブできるようにするパブリッシングインターフェイス（7.1節）（たとえば、使用可能なリソースと占有されているリソース、現在の状態など）。
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は、要件を満たすことができるMSについてMRBにクエリを実行できます。
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.
さらに、MRBが関係する場合のメディアダイアログの処理に関するいくつかの考慮事項をセクション7.3に示します。
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から情報を受信するために、セクション5で説明したように、MRBが制御チャネルをネゴシエートする必要があることを意味します。このパッケージにより、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はPublishingインターフェイスに関心があるため、MRBコントロールパッケージの必要性を考慮するために、前述のネゴシエーションを変更する必要があります。このパッケージの名前は「mrb-publish / 1.0」です。つまり、SYNCは次のようになります。
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 SYNC）----------------------- CFW 6b8b4567327b SYNC Dialog-ID：z9hG4bK-4542-1-0 Keep-Alive：100パッケージ：msc-ivr / 1.0、msc-mixer / 1.0、mrb-publish / 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-publish / 1.0サポート：msc-example-pkg / 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
^^^^^^^^^^^^^^^
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-example-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 |
|<---------------------------------------------|
| |
. .
. .
Figure 47: Media Resource Brokering: Subscription and Notification
図47：Media Resource Brokering：サブスクリプションと通知
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-publish / 1.0）宛ての新しいCONTROLメッセージ（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生成のCONTROLメッセージとして送信されました。 '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
<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
<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
<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>
<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>
<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
(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
<?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
<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がPublishingインターフェースを使用してその機能と最新情報をMRBに公開するのに対し、Consumerインターフェースは関係する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.
ただし、発行インターフェイスとは異なり、コンシューマーインターフェイスはコントロールパッケージとして指定されていません。むしろ、次のセクションで示すように、HTTPまたはSIPのいずれかを使用して転送できるXMLベースのプロトコルとして考えられています。
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]で指定されているように、コンシューマインターフェイスは、クエリモードとインラインモードの2つのトポロジに関与できます。クエリモード（セクション7.2.1）では、コンシューマの要求と応答はHTTPによって伝達されます。 ASが応答を取得すると、MRBによって選択されたASと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）に連絡するための情報が含まれているため、セクション5で説明されているように、ASはその後直接MSに連絡できます。 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 |
| |
. .
. .
Figure 48: Media Resource Brokering: Query Mode
図48：Media Resource Brokering：クエリモード
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とミキサーの両方のパッケージをサポートします。
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パッケージのaudio / 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は、HTTP POSTメッセージをMRBに送信します（1）。ペイロードはもちろん、コンシューマーリクエストであり、Content-Typeヘッダー（application / mrb-consumer + xml）によって反映されます。コンシューマーリクエスト（<mediaResourceRequest>、ランダムな値 'n3un93wd'に設定された 'id'属性によって一意に識別される）には、いくつかの一般的な要件（<generalInfo>）といくつかのIVR固有の要件（<ivrInfo>）が含まれます。リクエストの一般的な部分には、必要なパッケージのセット（<packages>）が含まれています。 IVR固有のセクションには、必要なIVRセッションの数（<ivr-sessions>）、サポートされるファイル形式（<file-formats>）、および必要なファイル転送機能（<file-transfer-モード>）。
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 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.
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 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）
<?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からPOST、消費者の応答）-------------------------------------- ------- 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日付：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>
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で説明したように、取得したMSのいずれかとのCOMEDIAネゴシエーションを発行するASで基本的に構成されるため、それらは非常に簡単です。UACメディアダイアログのアタッチに関しても同じことが言えます。実際、クエリの後、AS <-> MSの相互作用は1：1になるため、UACメディアダイアログは、たとえば図10に示すように、3PCCアプローチを使用して適切なMSに直接リダイレクトできます。
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]は、コンシューマ要求を送信できる2種類のSIPダイアログを想定しています。SIP制御ダイアログ（制御チャネルを設定するためにASによって送信されるSIPダイアログ）とUACメディアダイアログ（UACをMSに接続するためにASによって送信されるSIPダイアログ）。どちらの場合も、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.
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.
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 |
| | |
| | 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（INVITE multipart / mixed）------------------------------------- [.. ] Content-Type：multipart / mixed; boundary = "Part"
--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
--Part Content-Type: application/mrb-consumer+xml
--Part Content-Type：application / mrb-consumer + 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>
<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（INVITE SDPのみ）------------------------------ [..] 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
5. MRB <- MS (200 OK SDP) ------------------------- [..] Content-Type: application/sdp
5. MRB <-MS（200 OK SDP）------------------------- [..] 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
7. AS <- MRB (200 OK multipart/mixed) ------------------------------------- [..] Content-Type: multipart/mixed;boundary="Part"
7. AS <-MRB（200 OKマルチパート/混合）------------------------------------- [。 。] Content-Type：multipart / mixed; boundary = "Part"
--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
--Part Content-Type: application/mrb-consumer+xml
--Part Content-Type: application/mrb-consumer+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>
<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
--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によって送信されたSIP INVITE（1.）には、コンシューマ要求（以前と同じ）と、MSとCFWチャネルをネゴシエートするためのSDPの両方が含まれています。 MRBは以前とまったく同じように（2つのMSインスタンスをプロビジョニングする）要求を処理しますが、顕著な違いがあります。まず、ASに代わって2つのMSインスタンスの1つを選択します（ステップ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が「From」および「To」タグから構築する「connection-id」が含まれます。 MRBは実際にはASに代わってネゴシエーションを行ったため、この情報がないと、ASとMSは同じconnectionid属性を参照して同じダイアログをターゲットにし、CFWプロトコルが期待どおりに動作しなくなります。 'connection-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の両方のアドレスを取得するという事実を強調することは価値があります。これは、クエリの場合と同様に、MRBをProxy / B2BUAとして再度使用するのではなく、図10に示すように、3PCCアプローチを使用してUACメディアダイアログを適切なMSに直接リダイレクトできることを意味します。もちろん、2番目の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モードを利用する2つ目の方法があります。つまり、UACメディアダイアログに関連するSIPダイアログをコンシューマーメッセージの「ベッセル」として利用します。次のシーケンス図とプロトコルダンプでより明確になるように、このシナリオは、コンシューマーの要求/応答に関してセクション7.2.2.1で提示されたシナリオと大差ありませんが、これら2つのシナリオを比較して表示すると役立つ場合がありますメディアダイアログ自体と、関与する可能性のある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.) |
| | |------------------------->|
| | | 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 |
| |+++++++++++++++++++++++++++++++++++++++++++++++++>|
| | |
. . . .
. . . .
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メッセージに挿入される実際の境界ではなく、マルチパート/混合ペイロードの境界が提供される場合は常に、単純な「Part」が使用されます。
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を使用したINVITE）------------------------------------ [..]差出人：<sip：lminiero@users.example.com>; tag = 1153573888差出人：<sip：mediactrlDemo@as.example.com> [..]コンテンツタイプ：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
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 (INVITE multipart/mixed) ------------------------------------- [..] From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5 To: <sip:Mrb@mrb.example.org> [..] Content-Type: multipart/mixed;boundary="Part"
--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
--Part Content-Type: application/mrb-consumer+xml
--Part Content-Type：application / mrb-consumer + 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>
<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（INVITE SDPのみ）------------------------------ [..] From：<sip：Mrb @ mrb.example.org:5060>;tag=32pbdxZ8 To：<sip：MediaServer@ms.example.com：5080> [..] 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
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 OK SDP）------------------------- [..] From：<sip：Mrb@mrb.example.org ：5060>; tag = 32pbdxZ8 To：<sip：MediaServer@ms.example.com：5080>; tag = KQw677BF [..] 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
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 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"
--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
--Part Content-Type: application/mrb-consumer+xml
--Part Content-Type: application/mrb-consumer+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>
--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 OK SDP）-------------------------- [..] From：<sip：lminiero@users.example。 com>; tag = 1153573888 To：<sip：mediactrlDemo@as.example.com>; tag = bcd47c32 [..] 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
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.).
最初の明らかな違いは、最初のINVITE（1.）はAS自体（元の例ではASはコントロールチャネルを設定する用意があった）ではなく、承認されたUAC（たとえば、メディアを利用するため）から発信されていることです。 ASによって提供されるサービス）。そのため、最初のINVITEには、オーディオおよびビデオチャネルをネゴシエートするためのSDPのみが含まれています。ビジネスロジックのASは、いくつかの特定の要件（たとえば、呼び出されたURIが特定のサービスに関連付けられている）に従ってこのUACをMSにアタッチする必要があるため、MRBに送信されるコンシューマ要求を準備して、その目的のための有効なMS。以前と同様に、コンシューマ要求はSDPとともにMRBに送信されます（3.）。 MRBはコンシューマーペイロードを抽出し、通常どおり処理します。 2つのMSインスタンスを選択し、UACを最初のMSインスタンスに接続します（5.）。 MSがオーディオストリームとビデオストリームのネゴシエーションに成功すると（7。）、MRBはこの呼び出しに関連付けられた 'connection-id'をメモします（後でこのユーザーのオーディオストリームとビデオストリームを操作するために必要になります）。そして、MSから返されたSDPとコンシューマー応答の両方をASに送り返します（9.）。 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 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.
この時点で、UACはMSに正常に接続されています。 ASは、必要に応じて、そのMSへの制御チャネルを設定するだけで済みます。特にコンシューマーリクエストが新しいセッションの準備ではなく既存のセッションの更新である場合、この手順は必要ない場合があります。そのMSへの制御チャネルがまだ存在しないと仮定すると、ASは、アドレスを持っているMSに直接INVITEを送信することにより、通常どおりにそれを作成します。それが完了すると、UACのオーディオストリームとビデオストリームの操作を開始できます。そのためには、認識している<connection-id>要素に依存するのではなく、MRBによって報告された<connection-id>要素を参照します。実際、ASは接続ID値（fd4fush5：117652221、MRBと交換されたメッセージから作成）を認識していますが、MSは別の値（32pbdxZ8：KQw677BF、MRB-MS相互作用から作成）を認識しています。 。もちろん、正しい接続IDはMSが認識しているIDであり、ASはそのため、その目的のためにMRBがコンシューマ応答に追加したその接続IDを参照します。
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は、INVITEをMSではなくMRBに送信していることを認識し、それに応じて動作します（マルチパート/混合ペイロードを使用して、要件を満たすことができるMSを照会します）。非認識MRBモード（IUMM）ASは、MRBとMSを区別しません。これは、MRBにアクセスできるMRB非対応ASが、一般的な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を認識しないASによってコンシューマー要求が出されないと、MRBがASから発信されたディレクティブに依存して、1つのMSではなく1つの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 |
|++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
. . .
. . .
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メッセージをその目的で使用する必要があることを必ずしも意味しません。これを実現する簡単な方法は、認識されていないASにさまざまなURIをプロビジョニングすることであり、実際にはすべてMRB自体によって透過的に処理されます。これにより、MRBはこれらのURIを異なるMSインスタンスにマップするだけで済みます。選択されたMSに到達する可能性のある実際のURIを提供するために、ASからのINVITEへの応答でMRBがSIP「Contact」ヘッダーを使用することもできます。このような議論の動機、およびこのトピックの詳細については、セクション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が次のシナリオに関与する場合は常に、メディアダイアログがどのように管理されるかを簡単に説明することは価値があります。実際、MRBが存在すると、非常に単純な1：1 AS-MSトポロジに比べて複雑さが増す可能性があります。
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 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.
このようなシナリオの例を図52に示します。この図およびこのセクションの後続の図は、実際のプロトコルの相互作用に関して簡略化されていることに注意してください。たとえば、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 ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
Figure 52: Handling Media Dialogs in Query/IAMM
図52：Query / 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 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.
それにもかかわらず、SIPシグナリングパスにMRBがあることも、たとえばリソースの使用をより詳細に制御するために望ましい機能である場合があります。コンシューマーインターフェイスがどのように想定されているかを考えると、この機能はプロトコルをまったく変更することなく簡単に実現できます。具体的には、そのような機能を実現するために、MRBは、（前述のMS SIP URIではなく）MRBが担当するURIを使用してコンシューマ要求に応答し、このURIをビジネスロジック内の実際のMS URIにマップします。 ;これはASに対して透過的です。このように、ASは、まるでMS自体であるかのようにMRBと対話します。
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 ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
Figure 53: Handling Media Dialogs in Query/IAMM: MRB in the Signaling Path
図53：Query / 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.
今回は、ASからの要求の後にMRBが特定のMSを選択した場合でも、MRBは別のSIP URIで応答します。これは、それ自体が応答するURIです。 ASはコントロールチャネルをネゴシエートするためにそのURIにアクセスし、MRBは要求を実際のMSに透過的にプロキシ/転送します。最終的に、制御チャネルはASとMSの間でインスタンス化されます。 ASによって処理されるUACについても同じことが起こります。 ASは、MRBが処理するURIに提供されたURIに通話を転送し、MRBは、UACとMSの間に適切なRTPチャネルを作成するために、通話をMSに中継します。
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メディアダイアログの両方のシグナリングパス上にあり、リソースをより詳細に制御できるようにする（例：リソースが期限切れです）。リクエストされたMSにマップするためにURIを割り当てるためにMRBがとる可能性のあるいくつかのアプローチがあります。たとえば、MRBはSIP URIパラメータを使用して、一意であるが、すべて同じホストとポートにルーティングする複数のSIP URIを生成する場合があります（例：sip：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はあたかもMS自体であるかのようにMRBと対話します。これにより、IAMMの場合と同様にASが機能するようになると主張する人もいるかもしれません。ただし、これは当てはまりません。ASが実際に必要なリソースに関する情報をMRBに提供し、適切なMSを選択するためです。一方、IUMMの場合、MRBは、MSを選択せずに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非対応モードでは、コンシューマ要求はなく、ASは実際にはMRBをMSと見なします。以前のシナリオとは異なり、AS <-> MRBの相互作用がないため、MSの選択プロセスもないため、少なくともASが最初に表示されたときは、MRBはおそらくシグナリングパスにあります。 MRBは、ASを直接MSにリダイレクトするか、透過的にProxy / 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）を1つしか認識しないため、そこですべてのコールを中継し、MRBがこれらのメディアダイアログがどこに属すべきか（具体的には、UAC呼び出しがASアプリケーションに属しているかどうか）を理解するのを難しくします。 MS1またはMS2、または他のどこかにつながるロジック。
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.
図54に示すように、この問題に対処するための1つの考えられる非常にシンプルなアプローチは、常に同じ認識されていないASから同じMSにSIPダイアログをリレーすることです。
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 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.
この例では、ASは2つの異なるコントロールチャネルセッション（AおよびB）を作成して、2つの異なるビジネスロジック実装に対処します。たとえば、AS SIP URI 'xyz'（CFWセッションAに関連付けられている）はIVRピザ注文アプリケーションであり、AS SIP URI 'jkl'（CFWセッションBに関連付けられている）は会議室に関連付けられている場合があります。 MRBが2つのCFWセッションを2つの異なるMSに転送した場合、UAB1をMSに接続してCFWセッションAを管理する必要があるかどうかをMRBが把握することが困難になるため、UACメディアダイアログの処理が面倒であることが明らかです。または、MSがCFWセッションBを管理しています。この例では、同じMRB非対応ASからのすべての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.
このアプローチは非常にシンプルであり、実際にはそれほどスケーラブルではありませんが、実際には問題の処理に役立ちます。実際、ASが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シグナリングパスにあるという点で、別のアプローチを利用する必要があります。実際、特に同じ認識されていないASによって処理される異なるアプリケーションの場合、その目的のために異なるMSを活用し、それに応じて転送されるメディアダイアログを正しく追跡することは理にかなっています。つまり、MRBは、異なるアプリケーションロジックが関与していることを予測または認識したときに、認識されていないASを何らかの方法で別の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は異なるアプローチを使用する場合があります。 １つのアプローチは、例えば、認識されていないＡＳによって開始された制御チャネル折衝に応答して、ＳＩＰ３０２メッセージによって、リダイレクトを使用することになる。このようなアプローチを図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 ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
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が関連する呼び出しをそこにリダイレクトします。これは、クエリ/ 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, 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ダイアログのシグナリングパスに参加することに関心を持つ可能性があります。 3つ目の可能性のあるアプローチは、前のセクションで説明したように、MRBによって処理される「仮想」URIを実装することです。明示的なリダイレクトに頼ったり、常に同じMSを使用したりするのではなく、MRBは、以前に図53に示したのと同じアプローチを使用して、新しいSIPコントロールダイアログを独自のURIの1つにリダイレクトします。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 ++++++++++++++++++++++++++++>>|
| | | |
. . . .
. . . .
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.
ただし、どちらの場合でも、MRBによって送信された302がASによって認識される保証がないシナリオが存在することを指摘しておく必要があります。実際、プロキシがASとMRBの間にある場合、そのようなプロキシ自体が302に作用する可能性があります。そのような問題に適切に対処するために、MRBはINVITEへのSIP応答で「Contact」ヘッダーを使用することもあります。適切な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ケースに関連する問題は、主にMRBがASによって単一のMSインスタンスと見なされるという事実に関連しているため、これを克服する簡単な方法は、MRBを一連の異なるMSすぐに;これは、「仮想」MSのプールとして機能するMRB自体によってすべて処理される一連の異なるURIを使用して、認識されていないASをプロビジョニングするだけで実行できます。このように、ASは、異なるクラスのコール、たとえば、管理しているさまざまなアプリケーション（このセクションで示す例では2つ）に異なるMSを使用するように設計されている可能性があります。 2つの異なる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 +++++++++++++++++++++++++>>|
| | | | | |
. . . . . .
. . . . . .
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', 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.
この新しい例では、同じ無意識のASが2つの異なるアプリケーションを処理し、以前と同じURIに関連付けられていると想定しています。ただし今回は、ASが異なるMSインスタンスを使用して、それが担当する2つの非常に異なるアプリケーションを処理しようとするように設計されていることも想定しています。また、SIP URI「fake-ms1」と「fake-ms2」でそれぞれ到達可能な2つの異なるMSインスタンスを使用できるように設定されており、どちらも実際にはMRBによって透過的に処理されているものとします。これにより、以前と同様に、2つの異なる制御チャネル（AとB）が作成されますが、今回は2つの異なるMSに向かっています。具体的には、MRBはこのASに対して、 'fake-ms1'への制御チャネルネゴシエーションが実際にMS1にリダイレクトされることを確認します。同時に、「fake-ms2」はMS2に関連付けられています。 ASが両方のMSでコントロールチャネルをセットアップすると、メディアダイアログを処理する準備が整います。 UAC1はASでSIP URI 'xyz'を呼び出してピザを注文します。 ASは、アプリケーションロジックのそのブランチに責任があることがわかっているMSにメディアダイアログをアタッチします（つまり、「fake-ms1」）。 MRBは、適切なMSインスタンスであるMS1に到達することを確認します。その後、別のユーザーUAC2がSIP URI '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として機能するか、または最初に接続されたときに（たとえば、Contactを使用して）適切なMSインスタンスにASをリダイレクトするかを選択できます。前に説明したように、ヘッダーまたは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 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.
それでも、1つの側面を非常に慎重に検討する必要があります。 ASとMSの両方がSIPに関連する情報を使用して、操作するエンティティに対処することを読者に思い出させることは価値があります。これは、たとえば、特定のUACをアドレス指定するときにASとMSの両方が参照する<connectionid>要素の場合です。セクション6で説明したように、この「connectionid」識別子は、SIPヘッダーから抽出された「From」タグと「To」タグを連結することによって構築されます。具体的には、UACの接続を許可するAS <-> MSレッグのヘッダーからMSに。 ASとMSの間のパスに追加のコンポーネントが存在すると、MRBがこれらのタグを変更し、ASがMSが使用するタグとは異なるタグ（AS <-> MRB）を使用する（MRB <->） MS）。これにより、ASとMSは異なる「connectionid」識別子を使用して同じUACをアドレス指定し、プロトコルが期待どおりに機能しなくなります。その結果、プロトコルの動作を「壊さない」ために、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.
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.
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の「connectionid」がどうあるべきかについて異なる解釈をすることになります。実際、ASは認識しているタグ（a1b2c3：d4e5f6）を使用して「connectionid」を作成しますが、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を使用してASが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 CONTROL、play）------------------------------- CFW ffhg45dzf123 CONTROL Control-Package：msc- ivr / 1.0 Content-Type：application / msc-ivr + xml Content-Length：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>
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 OK）------------------------ CFW ffhg45dzf123 200タイムアウト：10 Content-Type：application / 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>
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ベースとメディアダイアログベースの両方）でこの問題がどのように処理されるかについては、既に説明しました。 IUMMケースのこの問題への対処は、明示的に範囲外であり、実装固有である可能性があるため、[RFC6917]に文書化されていません。
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 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.
同じことがSDPフィールドにも当てはまります。実際、ASとMSは、細かいアプローチが必要な場合にSACラベルを使用してUACメディアダイアログの特定のメディア接続に対処するため、アドホックSDP属性を使用してコントロールチャネルをインスタンス化します。結果として、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.
前述のドキュメントでは強力なステートメントが提供されており、これらのドキュメントはこれらの問題に関して実装者に適切なガイダンスを提供するため、このセクションでは、単一のセキュアなMSが異なるASに応答すると想定される方法を示す一部のMEDIACTRLコールフローのみを読者に提供します各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.
非常に具体的なシナリオに対処するために、2つの異なるAS、AS1とAS2が同じMSで制御チャネルを確立したと仮定します。 ASとMSが制御チャネルをセットアップするために使用するSYNCトランザクションを考えると、MSはAS1からの要求とAS2からの要求を区別できます。実際、セクション5.1と5.2で説明したように、ASとMSはSDPのcfw-id属性をネゴシエートし、その後、ネゴシエーション後に作成される制御チャネルのSYNCメッセージで同じ値が使用されるため、安心できます。 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は、2つの接続を互いに結合しました（1：75d4dd0dおよび1：b9e6a659）。明らかに、AS1がAS2がMSで何をしているか、またその逆を認識していないこと、およびAS2が互いのリソースを操作することを許可されていないことが非常に望ましいです。次のトランザクションが発生します。
1. AS1 places a generic audit request to both the Mixer and IVR packages.
1. AS1は、ミキサーパッケージと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によって作成されたダイアログを終了しようとします（6791fee）。
4. AS2 tries to join a user agent it handles (1:272e9c05) to the conference mix created by AS1 (74b6d62).
4. AS2は、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 |
| |<<++++++++++++++++++++++++++++++++|
| | |
. . .
. . .
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が直接関与している識別子のみが報告されます）。不正な操作のリクエストを拒否します（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は一般的な<audit>要求をIVRパッケージに送信します。リクエストの一部として属性が渡されないため、リクエストは汎用的です。つまり、AS1は、MS機能と、MSが現在処理しているすべてのダイアログに関心があります。応答（A2）からわかるように、MSは<auditresponse>でパッケージ機能のみを報告し、<dialogs>要素は空です。これは、MSが処理する唯一のダイアログが実際にはAS2によって作成されたため、MSが関連する識別子（6791fee）をAS1に報告しないためです。実際、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 2番目のトランザクション（B1）では、AS1がMixerパッケージに同一の<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 3番目と4番目のトランザクション（C1およびD1）では、ASVがIVRパッケージとミキサーパッケージの両方に<audit>リクエストを送信します。以前のトランザクションと同様に、監査要求は汎用です。返信（C2とD2）を見ると、機能セクションがAS1に与えられた返信と同じであることは明らかです。実際、MSは何ができるかについて「嘘をつく」理由はありません。 <dialogs>セクションと<mixers>セクションはまったく異なります。 AS2は、AS1への応答で省略された独自のIVRダイアログ（6791fee）に関する情報を実際に受け取りますが、ミキサーに関連する詳細なしで、作成した唯一の接続（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 5番目のトランザクション（E1）では、AS1はパッケージを監査するだけでなく、AS2によって作成されたダイアログ（6791fee）を終了（<dialogterminate>）しようとします。 IDは前の監査要求への応答でMSによって報告されていないため、AS1は別の帯域外メカニズムを介してIDにアクセスしたと想定します。上記のダイアログは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 同様に、6番目と最後のトランザクション（F1）で、AS2は、AS1によって作成された会議ミックス（74b6d62）に処理しているUACの1つをアタッチ（<join>）しようとします。前のトランザクションと同様に、MSは前の監査要求への応答でIDを報告しなかったため、IDは何らかの帯域外メカニズムを介してAS2によってアクセスされたと見なされます。識別子の1つ（UAC）は実際にはAS2によって処理されますが、他の1つ（会議ミックス）は処理されません。したがって、5番目のトランザクションと同様に、この最後のトランザクションは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
<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
<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>
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>
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>
<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
<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
<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>
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>
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>
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>
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
<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
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.
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.
[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：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年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 4574、2006年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 4145、2005年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。、「Session Description Protocol（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., and S. McGlashan, "Media Control Channel Framework", RFC 6230, May 2011.
[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] McGlashan、S.、Melanchuk、T。、およびC. Boulton、「メディアコントロールチャネルフレームワーク用のインタラクティブ音声応答（IVR）制御パッケージ」、RFC 6231、2011年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、「Media Control Channel Frameworkのミキサーコントロールパッケージ」、RFC 6505、2012年3月。
[RFC6917] Boulton, C., Miniero, L., and G. Munson, "Media Resource Brokering", RFC 6917, April 2013.
[RFC6917] Boulton, C., Miniero, L., and G. Munson, "Media Resource Brokering", RFC 6917, April 2013.
[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、「The Binary Floor Control Protocol（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）形式」、RFC 4583、2006年11月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレイクD.およびA.パニッツ、「予約済みトップレベルDNS名」、BCP 32、RFC 2606、1999年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、「Session Initiation Protocol（SIP）でのサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、2004年4月。
[SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar Specification Version 1.0", W3C Recommendation, March 2004.
[SRGS] Hunt、A.、S。McGlashan、「Speech Recognition Grammar Specification Version 1.0」、W3C勧告、2004年3月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.
[RFC5567] Melanchuk、T。、「An Architectural Framework for Media Server Control」、RFC 5567、2009年6月。
Authors' Addresses
著者のアドレス
Alessandro Amirante University of Napoli Via Claudio 21 Napoli 80125 Italy
アレッサンドロアミランテナポリ大学Via Claudio 21 Naples 80125 Italy
EMail: alessandro.amirante@unina.it
Tobia Castaldi Meetecho Via Carlo Poerio 89 Napoli 80100 Italy
Tobia Castaldi Meetecho Via Carlo Poerio 89ナポリイタリア
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
Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy
サイモンピエトロロマーノナポリ大学Claudio 21 Naples 80125イタリア
EMail: spromano@unina.it