[要約] RFC 6917は、メディアリソースブローカリングの概要と目的を提供しています。このRFCの目的は、異なるメディアリソースを効果的に管理し、配信するためのプロトコルとアーキテクチャを定義することです。
Internet Engineering Task Force (IETF) C. Boulton
Request for Comments: 6917 NS-Technologies
Category: Standards Track L. Miniero
ISSN: 2070-1721 Meetecho
G. Munson
AT&T
April 2013
Media Resource Brokering
メディアリソースブローカー
Abstract
概要
The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.
IETFのMediaCtrlワーキンググループは、メディアサービスを制御するためのアーキテクチャを提案しています。セッション開始プロトコル（SIP）は、メッセージルーティングに固有の多くの機能を提供するシグナリングプロトコルとして使用されます。このようなシグナリングプロパティに加えて、非静的なシグナリングプロパティに基づくインテリジェントなアプリケーションレベルのメディアサービス選択が必要です。これは、アプリケーションサーバーとメディアサーバーの1：MとM：Nの組み合わせを含む展開アーキテクチャと組み合わせて考えると特に当てはまります。このドキュメントでは、メディアサーバーの可用性とアプリケーションサーバーのメディアリソースの需要を管理するメディアリソースブローカー（MRB）エンティティを紹介します。このドキュメントには、MRBの潜在的な展開オプションと、アプリケーションサーバーおよびメディアサーバーへの適切なインターフェイスが含まれています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6917.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6917で入手できます。
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 ....................................................3
2. Conventions and Terminology .....................................6
3. Problem Discussion ..............................................6
4. Deployment Scenario Options .....................................7
4.1. Query MRB ..................................................8
4.1.1. Hybrid Query MRB ....................................9
4.2. In-Line MRB ...............................................11
5. MRB Interface Definitions ......................................12
5.1. Media Server Resource Publish Interface ...................12
5.1.1. Control Package Definition .........................13
5.1.2. Element Definitions ................................15
5.1.3. <mrbrequest> .......................................15
5.1.4. <mrbresponse> ......................................17
5.1.5. <mrbnotification> ..................................19
5.2. Media Service Resource Consumer Interface .................30
5.2.1. Query Mode/HTTP Consumer Interface Usage ...........31
5.2.2. In-Line Aware Mode/SIP Consumer Interface Usage ....32
5.2.3. Consumer Interface Lease Mechanism .................35
5.2.4. <mrbconsumer> ......................................38
5.2.5. Media Service Resource Request .....................39
5.2.6. Media Service Resource Response ....................51
5.3. In-Line Unaware MRB Interface .............................54
6. MRB Acting as a B2BUA ..........................................54
7. Multimodal MRB Implementations .................................55
8. Relative Merits of Query Mode, IAMM, and IUMM ..................56
9. Examples .......................................................58
9.1. Publish Example ...........................................58
9.2. Consumer Examples .........................................64
9.2.1. Query Example ......................................64
9.2.2. IAMM Examples ......................................68
10. Media Service Resource Publisher Interface XML Schema .........83
11. Media Service Resource Consumer Interface XML Schema .........106
12. Security Considerations ......................................127
13. IANA Considerations ..........................................130
13.1. Media Control Channel Framework Package Registration ....130
13.2. application/mrb-publish+xml Media Type ..................130
13.3. application/mrb-consumer+xml Media Type .................131
13.4. URN Sub-Namespace Registration for mrb-publish ..........132
13.5. URN Sub-Namespace Registration for mrb-consumer .........132
13.6. XML Schema Registration for mrb-publish .................132
13.7. XML Schema Registration for mrb-consumer ................133
14. Acknowledgements .............................................133
15. References ...................................................133
15.1. Normative References ....................................133
15.2. Informative References ..................................135
As IP-based multimedia infrastructures mature, the complexity and demands from deployments increase. Such complexity will result in a wide variety of capabilities from a range of vendors that should all be interoperable using the architecture and protocols produced by the MediaCtrl working group. It should be possible for a controlling entity to be assisted in Media Server selection so that the most appropriate resource is selected for a particular operation. The importance increases when one introduces a flexible level of deployment scenarios, as specified in RFC 5167 [RFC5167] and RFC 5567 [RFC5567]. These documents make statements like "it should be possible to have a many-to-many relationship between Application Servers and Media Servers that use this protocol". This leads to the following deployment architectures being possible when considering media resources, to provide what can be effectively described as media resource brokering.
IPベースのマルチメディアインフラストラクチャが成熟するにつれて、展開の複雑さと要求が増大します。このような複雑さにより、MediaCtrlワーキンググループによって作成されたアーキテクチャとプロトコルを使用して相互運用可能な、さまざまなベンダーの幅広い機能が実現します。特定の操作に最も適切なリソースが選択されるように、制御エンティティがメディアサーバーの選択を支援できるようにする必要があります。 RFC 5167 [RFC5167]およびRFC 5567 [RFC5567]で指定されているように、柔軟なレベルの展開シナリオを導入すると、重要性が高まります。これらのドキュメントでは、「このプロトコルを使用するアプリケーションサーバーとメディアサーバーの間に多対多の関係を構築することが可能である必要があります」と述べています。これにより、メディアリソースを検討するときに、メディアリソースブローカリングとして効果的に説明できるものを提供するために、次の展開アーキテクチャが可能になります。
The simplest deployment view is illustrated in Figure 1.
最も単純な配置ビューを図1に示します。
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-------MS Control------>| Server |
+-------------+ +-------------+
Figure 1: Basic Architecture
図1：基本的なアーキテクチャ
This simply involves a single Application Server and Media Server. Expanding on this view, it is also possible for an Application Server to control multiple (greater than 1) Media Server instances at any one time. This deployment view is illustrated in Figure 2. Typically, such architectures are associated with application logic that requires high-demand media services. It is more than possible that each Media Server possesses a different media capability set. Media Servers may offer different media services as specified in the MediaCtrl architecture document [RFC5567]. A Media Server may have similar media functionality but may have different capacity or media codec support.
これには、単一のアプリケーションサーバーとメディアサーバーが含まれます。このビューを展開すると、アプリケーションサーバーが複数の（1を超える）Media Serverインスタンスを一度に制御することもできます。この展開ビューを図2に示します。通常、このようなアーキテクチャは、高需要のメディアサービスを必要とするアプリケーションロジックに関連付けられています。各Media Serverが異なるメディア機能セットを所有することは可能です。メディアサーバーは、MediaCtrlアーキテクチャドキュメント[RFC5567]で指定されているように、異なるメディアサービスを提供する場合があります。メディアサーバーは同様のメディア機能を備えている場合がありますが、容量やメディアコーデックのサポートが異なる場合があります。
+---+-----+---+
| Media |
+----->| Server |
| +-------------+
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<--MS Control-----+----->| Server |
+-------------+ | +-------------+
|
| +---+-----+---+
+----->| Media |
| Server |
+-------------+
Figure 2: Multiple Media Servers
図2：複数のメディアサーバー
Figure 3 conveys the opposite view to that in Figure 2. In this model, there are a number of (greater than 1) Application Servers, possibly supporting dissimilar applications, controlling a single Media Server. Typically, such architectures are associated with application logic that requires low-demand media services.
図3は、図2とは逆のビューを示しています。このモデルには、複数の（1より大きい）アプリケーションサーバーがあり、異なるアプリケーションをサポートし、単一のメディアサーバーを制御しています。通常、このようなアーキテクチャは、低需要のメディアサービスを必要とするアプリケーションロジックに関連付けられています。
+---+-----+---+
| Application |
| Server |<-----+
+-------------+ |
|
+---+-----+---+ | +---+-----+---+
| Application | | | Media |
| Server |<-----+-----MS Control-->| Server |
+-------------+ | +-------------+
|
+---+-----+---+ |
| Application | |
| Server |<-----+
+-------------+
Figure 3: Multiple Application Servers
図3：複数のアプリケーションサーバー
The final deployment view is the most complex (Figure 4). In this model (M:N), there exist any number of Application Servers and any number of Media Servers. It is again possible in this model that Media Servers might not be homogeneous, and they might have different capability sets and capacities.
最終的な展開ビューは最も複雑です（図4）。このモデル（M：N）では、任意の数のアプリケーションサーバーと任意の数のメディアサーバーが存在します。このモデルでも、メディアサーバーが均一でなく、機能セットと容量が異なる可能性があります。
+---+-----+---+ +---+-----+---+
| Application | | Media |
| Server |<-----+ +---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | | | Media |
| Server |<-----+-MS Control-+---->| Server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
| Application | | +---->| Media |
| Server |<-----+ | Server |
+-------------+ +---+-----+---+
Figure 4: Many-to-Many Architecture
図4：多対多のアーキテクチャ
The remaining sections in this specification will focus on a new entity called a Media Resource Broker (MRB), which can be utilized in the deployment architectures described previously in this section. The MRB entity provides the ability to obtain media resource information and appropriately allocate (broker) on behalf of client applications.
この仕様の残りのセクションでは、メディアリソースブローカー（MRB）と呼ばれる新しいエンティティに焦点を当てます。このエンティティは、このセクションで前述した展開アーキテクチャで利用できます。 MRBエンティティは、メディアリソース情報を取得し、クライアントアプリケーションに代わって適切に割り当てる（ブローカー）機能を提供します。
The high-level deployment options discussed in this section rely on network architecture and policy to prohibit inappropriate use. Such policies are out of scope for this document.
このセクションで説明する高レベルの展開オプションは、不適切な使用を禁止するネットワークアーキテクチャとポリシーに依存しています。このようなポリシーは、このドキュメントの範囲外です。
This document will take a look at the specific problem areas related to such deployment architectures. It is recognized that the solutions proposed in this document should be equally adaptable to all of the previously described deployment models. It is also recognized that the solution is far more relevant to some of the previously discussed deployment models and can almost be viewed as redundant on others.
このドキュメントでは、このような展開アーキテクチャに関連する特定の問題領域について説明します。このドキュメントで提案されているソリューションは、前述のすべての展開モデルに等しく適応できる必要があることは認識されています。また、このソリューションは、前述の展開モデルの一部との関連性がはるかに高く、他のモデルではほとんど冗長であると見なすことができることも認識されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document inherits terminology proposed in RFC 5567 [RFC5567] and in "Media Control Channel Framework" [RFC6230]. In addition, the following terms are defined for use in this document and for use in the context of the MediaCtrl working group in the IETF:
このドキュメントは、RFC 5567 [RFC5567]および「Media Control Channel Framework」[RFC6230]で提案されている用語を継承しています。さらに、このドキュメントで使用するため、およびIETFのMediaCtrlワーキンググループのコンテキストで使用するために、次の用語が定義されています。
Media Resource Broker (MRB): A logical entity that is responsible for both collection of appropriate published Media Server (MS) information and selecting appropriate Media Server resources on behalf of consuming entities.
メディアリソースブローカー（MRB）：適切な公開されたMedia Server（MS）情報の収集と、消費エンティティに代わって適切なMedia Serverリソースの選択の両方を担当する論理エンティティ。
Query MRB: An instantiation of an MRB (see previous definition) that provides an interface for an Application Server to retrieve the address of an appropriate Media Server. The result returned to the Application Server can be influenced by information contained in the query request.
クエリMRB：アプリケーションサーバーが適切なメディアサーバーのアドレスを取得するためのインターフェイスを提供するMRBのインスタンス化（前の定義を参照）。アプリケーションサーバーに返される結果は、クエリ要求に含まれる情報の影響を受ける可能性があります。
In-line MRB: An instantiation of an MRB (see previous definition) that directly receives requests on the signaling path. There is no separate query.
インラインMRB：シグナリングパスで要求を直接受信するMRB（前の定義を参照）のインスタンス化。別のクエリはありません。
CFW: Media Control Channel Framework, as specified in [RFC6230].
CFW：[RFC6230]で指定されているMedia Control Channel Framework。
Within the context of In-line MRBs, additional terms are defined:
インラインMRBのコンテキスト内で、追加の用語が定義されています。
In-line Aware MRB Mode (IAMM): Defined in Section 5.2.2.1.
インライン対応MRBモード（IAMM）：セクション5.2.2.1で定義。
In-line Unaware MRB Mode (IUMM): Defined in Section 5.3.
インライン非対応MRBモード（IUMM）：セクション5.3で定義。
The document will often specify when a specific identifier in a protocol message needs to be unique. Unless stated otherwise, such uniqueness will always be within the scope of the Media Servers controlled by the same MRB. The interaction between different MRB instances, e.g., the partitioning of a logical MRB, is out of scope for this document.
ドキュメントでは、プロトコルメッセージの特定の識別子を一意にする必要がある場合を指定することがよくあります。特に明記しない限り、そのような一意性は常に、同じMRBによって制御されるメディアサーバーの範囲内にあります。異なるMRBインスタンス間の相互作用（論理MRBのパーティション化など）は、このドキュメントの範囲外です。
As discussed in Section 1, a goal of the MediaCtrl working group is to produce a solution that will service a wide variety of deployment architectures. Such architectures range from the simplest 1:1 relationship between Media Servers and Application Servers to potentially linearly scaling 1:M, M:1, and M:N deployments.
セクション1で説明したように、MediaCtrlワーキンググループの目標は、さまざまな展開アーキテクチャにサービスを提供するソリューションを作成することです。このようなアーキテクチャは、メディアサーバーとアプリケーションサーバー間の最も単純な1：1の関係から、1：M、M：1、およびM：Nの展開に線形にスケーリングする可能性まであります。
Managing such deployments is itself non-trivial for the proposed solution until an additional number of factors that increase complexity are included in the equation. As Media Servers evolve, it must be taken into consideration that, where many can exist in a deployment, they may not have been produced by the same vendor and may not have the same capability set. It should be possible for an Application Server that exists in a deployment to select a media service based on a common, appropriate capability set. In conjunction with capabilities, it is also important to take available resources into consideration. The ability to select an appropriate media service function is an extremely useful feature but becomes even more powerful when considered with available resources for servicing a request.
複雑さを増加させる追加の要素が方程式に含まれるまで、そのような展開の管理は提案されたソリューションにとってそれ自体重要です。メディアサーバーが進化するにつれ、デプロイメントに多数存在する可能性がある場合、それらは同じベンダーによって作成されたものではなく、同じ機能セットを持たない可能性があることを考慮する必要があります。展開内に存在するアプリケーションサーバーが、共通の適切な機能セットに基づいてメディアサービスを選択できるようにする必要があります。機能と併せて、利用可能なリソースを考慮することも重要です。適切なメディアサービス機能を選択する機能は非常に便利な機能ですが、リクエストを処理するために利用可能なリソースを考慮すると、さらに強力になります。
In conclusion, the intention is to create a toolkit that allows MediaCtrl deployments to effectively utilize the available media resources. It should be noted that in the simplest deployments where only a single Media Server exists, an MRB function is probably not required. Only a single capability set exists, and resource availability can be handled using the appropriate underlying signaling, e.g., SIP response. This document does not prohibit such uses of an MRB; it simply provides the tools for various entities to interact where appropriate. It is also worth noting that the functions specified in this document aim to provide a 'best effort' view of media resources at the time of request for initial Media Server routing decisions. Any dramatic change in media capabilities or capacity after a request has taken place should be handled by the underlying protocol.
結論として、MediaCtrlの展開で利用可能なメディアリソースを効果的に利用できるようにするツールキットを作成することが目的です。 Media Serverが1つだけ存在する最も単純な展開では、MRB機能はおそらく必要ありません。単一の機能セットのみが存在し、リソースの可用性は、SIP応答などの適切な基盤となるシグナリングを使用して処理できます。このドキュメントでは、MRBのそのような使用を禁止していません。さまざまなエンティティが適切な場所で対話するためのツールを提供するだけです。また、このドキュメントで指定されている機能は、最初のMedia Serverルーティング決定の要求時にメディアリソースの「ベストエフォート」ビューを提供することを目的としていることにも注意してください。要求が行われた後のメディア機能または容量の劇的な変更は、基盤となるプロトコルで処理する必要があります。
It should be noted that there may be additional information that is desirable for the MRB to have for purposes of selecting a Media Server resource, such as resource allocation rules across different applications, planned or unplanned downtime of Media Server resources, the planned addition of future Media Server resources, or Media Server resource capacity models. How the MRB acquires such information is outside the scope of this document. The specific techniques used for selecting an appropriate media resource by an MRB is also outside the scope of this document.
異なるアプリケーションにわたるリソース割り当てルール、Media Serverリソースの計画的または計画外のダウンタイム、将来の計画的な追加など、MRBがMedia Serverリソースを選択するために必要とする追加情報がある場合があることに注意してください。 Media Serverリソース、またはMedia Serverリソース容量モデル。 MRBがこのような情報を取得する方法は、このドキュメントの範囲外です。 MRBによって適切なメディアリソースを選択するために使用される特定のテクニックも、このドキュメントの範囲外です。
Research into media resource brokering concluded that a couple of high-level models provided an appropriate level of flexibility. The general principles of "in-line" and "query" MRB concepts are discussed in the rest of this section. It should be noted that while the interfaces are different, they both use common underlying mechanisms defined in this specification.
メディアリソースブローカーの調査では、いくつかの高レベルモデルが適切なレベルの柔軟性を提供すると結論付けました。 「インライン」および「クエリ」のMRBの概念の一般原則については、このセクションの残りの部分で説明します。インターフェースは異なりますが、どちらもこの仕様で定義されている共通の基本的なメカニズムを使用しています。
The "Query" model for MRB interactions provides the ability for a client of media services (for example, an Application Server) to "ask" an MRB for an appropriate Media Server, as illustrated in Figure 5.
図5に示すように、MRBインタラクションの「クエリ」モデルは、メディアサービス（たとえば、アプリケーションサーバー）のクライアントが適切なメディアサーバーについてMRBに「質問」する機能を提供します。
+---+-----+---+
+------------>| MRB |<----------+----<-----+---+
| +-------------+ (1)| | |
| | | |
|(2) +---+--+--+---+ | |
| | Media | | |
| +---->| Server | | |
| | +-------------+ | |
| | (1)| |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ (3) | +-------------+ |
| |
| +---+-----+---+ (1)|
+---->| Media | |
| Server |--->---+
+---+-----+---+
Figure 5: Query MRB
図5：MRBのクエリ
In this deployment, the Media Servers use the Media Server Resource Publish interface, as discussed in Section 5.1, to convey capability sets as well as resource information. This is depicted by (1) in Figure 5. It is then the MRB's responsibility to accumulate all appropriate information relating to media services in the logical deployment cluster. The Application Server (or other media services client) is then able to query the MRB for an appropriate resource (as identified by (2) in Figure 5). Such a query would carry specific information related to the media service required and enable the MRB to provide increased accuracy in its response. This particular interface is discussed in "Media Service Resource Consumer Interface" (Section 5.2). The Application Server is then able to direct control commands (for example, create a conference) and media dialogs to the appropriate Media Server, as shown by (3) in Figure 5. Additionally, with Query mode, the MRB is not directly in the signaling path between the Application Server and the selected Media Server resource.
この展開では、セクション5.1で説明したように、メディアサーバーはメディアサーバーのリソース発行インターフェイスを使用して、機能セットとリソース情報を伝達します。これを図5の（1）に示します。その場合、論理展開クラスター内のメディアサービスに関連するすべての適切な情報を蓄積するのは、MRBの責任です。アプリケーションサーバー（または他のメディアサービスクライアント）は、適切なリソースをMRBに照会できます（図5の（2）で識別されます）。このようなクエリは、必要なメディアサービスに関連する特定の情報を伝達し、MRBが応答の精度を向上できるようにします。この特定のインターフェイスについては、「メディアサービスリソースコンシューマインターフェイス」（セクション5.2）で説明しています。その後、アプリケーションサーバーは、図5の（3）に示すように、制御コマンド（会議の作成など）とメディアダイアログを適切なメディアサーバーに送信できます。さらに、クエリモードでは、MRBは直接アプリケーションサーバーと選択したメディアサーバーリソース間のシグナリングパス。
As mentioned previously, it is the intention that a toolkit is provided for MRB functionality within a MediaCtrl architecture. It is expected that in specific deployment scenarios the role of the MRB might be co-hosted as a hybrid logical entity with an Application Server, as shown in Figure 6.
前述のように、MediaCtrlアーキテクチャ内のMRB機能用にツールキットが提供されることが目的です。図6に示すように、特定の展開シナリオでは、MRBの役割がアプリケーションサーバーとのハイブリッド論理エンティティとしてホストされる可能性があります。
+------------<----------------<---------+----<-----+---+
| (1) | | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
V +---->| Server | | |
+------+------+ | +-------------+ | |
| MRB | | | |
+---+--+--+---+ | +---+-----+---+ | |
| Application | | | Media | | |
| Server |<-----+-MS Control-+---->| Server |->-+ |
+-------------+ | +-------------+ |
| |
| +---+-----+---+ |
+---->| Media | |
| Server |--->---+
+---+-----+---+
Figure 6: Hybrid Query MRB - Application Server Hosted
図6：ハイブリッドクエリMRB-ホストされているアプリケーションサーバー
This diagram is identical to that in Figure 5 with the exception that the MRB is now hosted on the Application Server. The Media Server Publish interface is still being used to accumulate resource information at the MRB, but as it is co-hosted on the Application Server, the Media Server Consumer interface has collapsed. It might still exist within the Application Server/MRB interaction, but this is an implementation issue. This type of deployment suits a single Application Server environment, but it should be noted that a Media Server Consumer interface could then be offered from the hybrid if required.
この図は、MRBがアプリケーションサーバーでホストされていることを除いて、図5の図と同じです。 Media Server Publishインターフェイスは、MRBでリソース情報を蓄積するために引き続き使用されていますが、アプリケーションサーバー上でホストされているため、Media Server Consumerインターフェイスは折りたたまれています。それはまだApplication Server / MRB相互作用内に存在する可能性がありますが、これは実装の問題です。この種類の展開は単一のアプリケーションサーバー環境に適していますが、必要に応じてハイブリッドからMedia Serverコンシューマーインターフェイスを提供できることに注意してください。
In a similar manner, the Media Server could also act as a hybrid for the deployment cluster, as illustrated in Figure 7.
同様に、図7に示すように、メディアサーバーは展開クラスターのハイブリッドとしても機能します。
(1) +---+-----+---+
+---+---+------------->---------------->----------->| MRB |
| | | +---+--+--+---+ +---+-----+---+
| | +-<-| Application | | Media |
| | | Server |<--+-MS Control-+------->| Server |
| | +-------------+ | +-------------+
| | |
| | +---+--+--+---+ |
| +---<---| Application | |
| | Server |<--+-MS Control-+--+
| +-------------+ |
| |
| +---+--+--+---+ |
+---<-------| Application | |
| Server |<--+-MS Control-+--+
+-------------+
Figure 7: Hybrid Query MRB - MS Hosted
図7：ハイブリッドクエリMRB-MSホスト
In this example, the MRB has collapsed and is co-hosted by the Media Server. The Media Server Consumer interface is still available to the Application Servers (1) to query Media Server resources. The Media Server Publish interface has collapsed onto the Media Server. It might still exist within the Media Server/MRB interaction, but this is an implementation issue. This type of deployment suits a single Media Server environment, but it should be noted that a Media Server Publish interface could then be offered from the hybrid if required. A typical use case scenario for such a topology would be a single Media Server representing a pool of MSs in a cluster. In this case, the MRB would actually be handling a cluster of Media Servers, rather than one.
この例では、MRBは折りたたまれており、メディアサーバーによって共同ホストされています。 Media Serverコンシューマインターフェイスは、Media Serverリソースをクエリするためにアプリケーションサーバー（1）で引き続き使用できます。 Media Server PublishインターフェイスはMedia Serverに折りたたまれています。それはまだMedia Server / MRB相互作用内に存在する可能性がありますが、これは実装の問題です。このタイプの展開は単一のMedia Server環境に適していますが、必要に応じて、ハイブリッドからMedia Server Publishインターフェイスを提供できることに注意してください。このようなトポロジの典型的なユースケースシナリオは、クラスター内のMSのプールを表す単一のメディアサーバーです。この場合、MRBは実際には1つではなくメディアサーバーのクラスターを処理します。
The "In-line" MRB is architecturally different from the "Query" model discussed in the previous section. The concept of a separate query disappears. The client of the MRB simply uses the media resource control and media dialog signaling to involve the MRB. This type of deployment is illustrated in Figure 8.
「インライン」MRBは、前のセクションで説明した「クエリ」モデルとはアーキテクチャが異なります。別のクエリの概念は消えます。 MRBのクライアントは、メディアリソース制御とメディアダイアログシグナリングを使用してMRBを関与させます。このタイプの配置を図8に示します。
+-------<----------+----<-------+---+
| | (1) | |
| | | |
| +---+--+--+---+ | |
| | Media | | |
| +------>| Server | | |
| |(3) +-------------+ | |
| | (1)| |
+---+--+--+---+ | | +---+-----+---+ | |
| Application | (2) +---+--V--+---+ (3) | Media | | |
| Server |----->| MRB |----->| Server |->-+ |
+-------------+ +---+-----+---+ +-------------+ |
| |
| (3) +---+-----+---+ (1)|
+------>| Media | |
| Server |--->---+
+---+-----+---+
Figure 8: In-Line MRB
図8：インラインMRB
The Media Servers still use the Media Server Publish interface to convey capabilities and resources to the MRB, as illustrated by (1). The Media Server Control Channels (and media dialogs as well, if required) are sent to the MRB (2), which then selects an appropriate Media Server (3) and remains in the signaling path between the Application Server and the Media Server resources.
（1）に示されているように、メディアサーバーは引き続き機能とリソースをMRBに伝達するためにメディアサーバー公開インターフェイスを使用します。メディアサーバーコントロールチャネル（および必要に応じてメディアダイアログも）がMRBに送信され（2）、適切なメディアサーバーが選択され（3）、アプリケーションサーバーとメディアサーバーリソース間のシグナリングパスに残ります。
The In-line MRB can be split into two distinct logical roles that can be applied on a per-request basis. They are:
インラインMRBは、リクエストごとに適用できる2つの異なる論理的な役割に分割できます。彼らです：
In-line Unaware MRB Mode (IUMM): Allows an MRB to act on behalf of clients requiring media services who are not aware of an MRB or its operation. In this case, the Application Server does not provide explicit information on the kind of Media Server resource it needs (as in Section 5.2), and the MRB is left to deduce it by potentially inspecting other information in the request from the Application Server (for example, Session Description Protocol (SDP) content, or address of the requesting Application Server, or additional Request-URI parameters as per RFC 4240 [RFC4240]).
インライン非対応MRBモード（IUMM）：MRBまたはその操作を認識していないメディアサービスを必要とするクライアントに代わってMRBが動作できるようにします。この場合、アプリケーションサーバーは、必要なメディアサーバーリソースの種類に関する明示的な情報を提供せず（セクション5.2のように）、MRBは、アプリケーションサーバーからの要求に含まれる他の情報を検査することにより、それを推測することになります（たとえば、セッション記述プロトコル（SDP）のコンテンツ、要求元のアプリケーションサーバーのアドレス、またはRFC 4240 [RFC4240]に基づく追加のRequest-URIパラメーター）。
In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of clients requiring media services who are aware of an MRB and its operation. In particular, it allows the Application Server to explicitly convey matching characteristics to those provided by Media Servers, as does the Query MRB mode (as in Section 5.2).
インライン対応MRBモード（IAMM）：MRBがその動作を認識しているメディアサービスを必要とするクライアントに代わってMRBが動作できるようにします。特に、（セクション5.2のように）クエリMRBモードと同様に、アプリケーションサーバーはメディアサーバーによって提供される特性に一致する特性を明示的に伝えることができます。
In either of the previously described roles, signaling as specified by the Media Control Channel Framework ([RFC6230]) would be involved, and the MRB would deduce that the selected Media Server resources are no longer needed when the Application Server or Media Server terminates the corresponding SIP dialog. The two modes are discussed in more detail in Section 5.3.
前述のいずれかの役割では、メディアコントロールチャネルフレームワーク（[RFC6230]）で指定されたシグナリングが含まれ、MRBは、アプリケーションサーバーまたはメディアサーバーが終了したときに、選択されたメディアサーバーリソースが不要になったと推定します。対応するSIPダイアログ。 2つのモードについては、セクション5.3で詳しく説明します。
The intention of this specification is to provide a toolkit for a variety of deployment architectures where media resource brokering can take place. Two main interfaces are required to support the differing requirements. The two interfaces are described in the remainder of this section and have been named the Media Server Resource Publish and Media Server Resource Consumer interfaces.
この仕様の目的は、メディアリソースブローカリングを実行できるさまざまな展開アーキテクチャ用のツールキットを提供することです。異なる要件をサポートするには、2つの主要なインターフェースが必要です。 2つのインターフェースについては、このセクションの残りの部分で説明し、Media Server Resource PublishおよびMedia Server Resource Consumerインターフェースと呼ばれています。
It is beyond the scope of this document to define exactly how to construct an MRB using the interfaces described. It is, however, important that the two interfaces are complimentary so that development of appropriate MRB functionality is supported.
説明されているインターフェイスを使用してMRBを構築する方法を正確に定義することは、このドキュメントの範囲を超えています。ただし、適切なMRB機能の開発がサポートされるように、2つのインターフェースが補完的であることが重要です。
The Media Server Resource Publish interface is responsible for providing an MRB with appropriate Media Server resource information. As such, this interface is assumed to provide both general and specific details related to Media Server resources. This information needs to be conveyed using an industry standard mechanism to provide increased levels of adoption and interoperability. A Control Package for the Media Control Channel Framework will be specified to fulfill this interface requirement. It provides an establishment and monitoring mechanism to enable a Media Server to report appropriate statistics to an MRB. The Publish interface is used with both the Query mode and In-line mode of MRB operation.
Media Server Resource Publishインターフェイスは、適切なMedia Serverリソース情報をMRBに提供する役割を果たします。そのため、このインターフェイスは、メディアサーバーリソースに関連する一般的な詳細と特定の詳細の両方を提供すると想定されています。この情報は、採用と相互運用性のレベルを高めるために、業界標準のメカニズムを使用して伝達する必要があります。 Media Control Channel Frameworkのコントロールパッケージは、このインターフェイスの要件を満たすように指定されます。 Media Serverが適切な統計をMRBに報告できるようにする確立および監視メカニズムを提供します。 Publishインターフェイスは、MRB操作のクエリモードとインラインモードの両方で使用されます。
As already discussed in Section 1, the MRB view of Media Server resource availability will in reality be approximate -- i.e., partial and imperfect. The MRB Publish interface does not provide an exhaustive view of current Media Server resource consumption; the Media Server may in some cases provide a best-effort computed view of resource consumption parameters conveyed in the Publish interface (e.g., Digital Signal Processors (DSPs) with a fixed number of streams versus Graphics Processing Units (GPUs) with CPU availability). Media resource information may only be reported periodically over the Publish interface to an MRB.
セクション1ですでに説明したように、メディアサーバーリソースの可用性のMRBビューは実際には概算になります-つまり、部分的で不完全です。 MRBパブリッシュインターフェイスは、現在のMedia Serverリソース消費の完全なビューを提供しません。メディアサーバーは、パブリッシュインターフェイスで伝えられるリソース消費パラメーターのベストエフォート計算ビューを提供する場合があります（例：固定数のストリームを備えたデジタルシグナルプロセッサー（DSP）と、CPUが利用可能なグラフィックスプロセッシングユニット（GPU））。メディアリソース情報は、発行インターフェイスを介してMRBに定期的にのみ報告されます。
It is also worth noting that while the scope of the MRB is in providing interested Application Servers with the available resources, the MRB also allows for the retrieval of information about consumed resources. While this is of course a relevant piece of information (e.g., for monitoring purposes), such functionality inevitably raises security considerations, and implementations should take this into account. See Section 12 for more details.
また、MRBの範囲は関心のあるアプリケーションサーバーに利用可能なリソースを提供することですが、MRBでは消費されたリソースに関する情報の取得も可能です。これはもちろん関連情報（たとえば、監視目的）ですが、そのような機能は必然的にセキュリティの考慮事項を提起するので、実装ではこれを考慮に入れる必要があります。詳細については、セクション12を参照してください。
The MRB Publish interface uses the Media Control Channel Framework ([RFC6230]) as the basis for interaction between a Media Server and an MRB. The Media Control Channel Framework uses an extension mechanism to allow specific usages that are known as Control Packages. Section 5.1.1 defines the Control Package that MUST be implemented by any Media Server wanting to interact with an MRB entity.
MRB Publishインターフェイスは、Media ServerとMRB間の相互作用の基礎としてMedia Control Channel Framework（[RFC6230]）を使用します。メディアコントロールチャネルフレームワークは、拡張メカニズムを使用して、コントロールパッケージと呼ばれる特定の使用法を許可します。セクション5.1.1は、MRBエンティティとの対話を希望するすべてのメディアサーバーによって実装される必要がある制御パッケージを定義します。
This section fulfills the requirement for information that must be specified during the definition of a Control Framework package, as detailed in Section 8 of [RFC6230].
このセクションは、[RFC6230]のセクション8で詳しく説明されているように、制御フレームワークパッケージの定義中に指定する必要がある情報の要件を満たします。
The Media Channel Control Framework requires a Control Package definition to specify and register a unique name and version.
メディアチャネルコントロールフレームワークでは、一意の名前とバージョンを指定して登録するためのコントロールパッケージ定義が必要です。
The name and version of this Control Package is "mrb-publish/1.0".
このコントロールパッケージの名前とバージョンは「mrb-publish / 1.0」です。
The MRB Publish interface allows a Media Server to convey available capabilities and resources to an MRB entity.
MRBパブリッシュインターフェイスを使用すると、メディアサーバーは利用可能な機能とリソースをMRBエンティティに伝達できます。
This package defines XML elements in Section 5.1.2 and provides an XML schema in Section 10.
このパッケージは、セクション5.1.2でXML要素を定義し、セクション10でXMLスキーマを提供します。
The XML elements in this package are split into requests, responses, and event notifications. Requests are carried in CONTROL message bodies; the <mrbrequest> element is defined as a package request. This request can be used for creating new subscriptions and updating/ removing existing subscriptions. Event notifications are also carried in CONTROL message bodies; the <mrbnotification> element is defined for package event notifications. Responses are carried either in REPORT message or Control Framework 200 response bodies; the <mrbresponse> element is defined as a package-level response.
このパッケージのXML要素は、要求、応答、およびイベント通知に分割されます。リクエストはCONTROLメッセージ本文で送信されます。 <mrbrequest>要素は、パッケージリクエストとして定義されます。このリクエストは、新しいサブスクリプションの作成および既存のサブスクリプションの更新/削除に使用できます。イベント通知もCONTROLメッセージ本文で運ばれます。 <mrbnotification>要素は、パッケージイベント通知用に定義されています。応答は、REPORTメッセージまたはControl Framework 200応答本体のいずれかで送信されます。 <mrbresponse>要素は、パッケージレベルの応答として定義されます。
Note that package responses are different from framework response codes. Framework error response codes (see Section 7 of [RFC6230]) are used when the request or event notification is invalid; for example, a request has invalid XML (400) or is not understood (500). Package-level responses are carried in framework 200 response or REPORT message bodies. This package's response codes are defined in Section 5.1.4.
パッケージ応答はフレームワーク応答コードとは異なることに注意してください。フレームワークのエラー応答コード（[RFC6230]のセクション7を参照）は、リクエストまたはイベント通知が無効な場合に使用されます。たとえば、リクエストに無効なXML（400）があるか、または理解されていません（500）。パッケージレベルの応答は、フレームワーク200応答またはREPORTメッセージ本文で伝達されます。このパッケージの応答コードは、セクション5.1.4で定義されています。
The Media Control Channel Framework [RFC6230] requires a Control Package definition to specify if the attributes for media dialog or conference references are required.
メディアコントロールチャネルフレームワーク[RFC6230]では、メディアダイアログまたは会議参照の属性が必要かどうかを指定するためのコントロールパッケージ定義が必要です。
The Publish interface defined in Section 10 does import and make use of the common XML schema defined in the Media Control Channel Framework.
セクション10で定義されている発行インターフェイスは、メディアコントロールチャネルフレームワークで定義されている共通のXMLスキーマをインポートして利用します。
The Consumer interface defined in Section 11 does import and make use of the common XML schema defined in the Media Control Channel Framework.
セクション11で定義されているコンシューマインターフェイスは、メディアコントロールチャネルフレームワークで定義されている共通のXMLスキーマをインポートして利用します。
A valid CONTROL message body MUST conform to the schema defined in Section 10 and described in Section 5.1.2. XML messages appearing in CONTROL messages MUST contain either an <mrbrequest> or <mrbnotification> element.
有効なCONTROLメッセージ本文は、セクション10で定義され、セクション5.1.2で説明されているスキーマに準拠する必要があります。 CONTROLメッセージに表示されるXMLメッセージには、<mrbrequest>または<mrbnotification>要素を含める必要があります。
A valid REPORT message body MUST conform to the schema defined in Section 10 and described in Section 5.1.2. XML messages appearing in REPORT messages MUST contain an <mrbresponse> element.
有効なREPORTメッセージ本文は、セクション10で定義され、セクション5.1.2で説明されているスキーマに準拠する必要があります。 REPORTメッセージに表示されるXMLメッセージには、<mrbresponse>要素が含まれている必要があります。
The 'mrb-publish/1.0' Media Control Channel Framework package does not require any additional auditing capability.
「mrb-publish / 1.0」メディアコントロールチャネルフレームワークパッケージは、追加の監査機能を必要としません。
This section defines the XML elements for the Publish interface Media Control Channel package defined in Section 5.1. The formal XML schema definition for the Publish interface can be found in Section 10.
このセクションでは、セクション5.1で定義された発行インターフェースメディアコントロールチャネルパッケージのXML要素を定義します。 Publishインターフェイスの正式なXMLスキーマ定義は、セクション10にあります。
The root element is <mrbpublish>. All other XML elements (requests, responses, notifications) are contained within it. The MRB Publish interface request element is detailed in Section 5.1.3. The MRB Publish interface notification element is detailed in Section 5.1.5. The MRB Publish interface response element is detailed in Section 5.1.4.
ルート要素は<mrbpublish>です。他のすべてのXML要素（要求、応答、通知）は、その中に含まれています。 MRB Publishインターフェイスリクエストエレメントの詳細は、セクション5.1.3を参照してください。 MRB Publishインターフェイス通知要素の詳細は、セクション5.1.5を参照してください。 MRB Publishインターフェースの応答要素の詳細は、セクション5.1.4を参照してください。
The <mrbpublish> element has the following attributes:
<mrbpublish>要素には次の属性があります。
version: a token specifying the mrb-publish package version. The value is fixed as '1.0' for this version of the package. The attribute MUST be present.
version：mrb-publishパッケージのバージョンを指定するトークン。このバージョンのパッケージでは、値は「1.0」に固定されています。属性が存在しなければなりません。
The <mrbpublish> element has the following child elements, and there MUST NOT be more than one such child element in any <mrbpublish> message:
<mrbpublish>要素には次の子要素があり、<mrbpublish>メッセージ内にそのような子要素が複数存在してはなりません（MUST NOT）。
<mrbrequest> for sending an MRB request. See Section 5.1.3.
MRBリクエストを送信するための<mrbrequest>。セクション5.1.3を参照してください。
<mrbresponse> for sending an MRB response. See Section 5.1.4.
<mrbresponse>：MRB応答を送信します。セクション5.1.4を参照してください。
<mrbnotification> for sending an MRB notification. See Section 5.1.5.
MRB通知を送信するための<mrbnotification>。セクション5.1.5を参照してください。
This section defines the <mrbrequest> element used to initiate requests from an MRB to a Media Server. The element describes information relevant for the interrogation of a Media Server.
このセクションでは、MRBからメディアサーバーへのリクエストを開始するために使用される<mrbrequest>要素を定義します。要素は、メディアサーバーの問い合わせに関連する情報を記述します。
The <mrbrequest> element has no defined attributes.
<mrbrequest>要素には、定義された属性はありません。
The <mrbrequest> element has the following child element:
<mrbrequest>要素には、次の子要素があります。
<subscription> for initiating a subscription to a Media Server from an MRB. See Section 5.1.3.1.
<subscription> MRBからMedia Serverへのサブスクリプションを開始します。セクション5.1.3.1を参照してください。
The <subscription> element is included in a request from an MRB to a Media Server to provide the details relating to the configuration of updates (known as a subscription session). This element can be used either to request a new subscription or to update an existing one (e.g., to change the frequency of the updates), and to remove ongoing subscriptions as well (e.g., to stop an indefinite update). The MRB will inform the Media Server regarding how long it wishes to receive updates and the frequency that updates should be sent. Updates related to the subscription are sent using the <mrbnotification> element.
<subscription>要素は、MRBからMedia Serverへのリクエストに含まれ、更新の構成（サブスクリプションセッションと呼ばれる）に関する詳細を提供します。この要素は、新しいサブスクリプションを要求するか、既存のサブスクリプションを更新する（たとえば、更新の頻度を変更する）か、進行中のサブスクリプションも削除する（たとえば、無期限の更新を停止する）ために使用できます。 MRBは、更新を受信する期間と更新の送信頻度についてMedia Serverに通知します。サブスクリプションに関連する更新は、<mrbnotification>要素を使用して送信されます。
The <subscription> element has the following attributes:
<subscription>要素には次の属性があります。
id: Indicates a unique token representing the subscription session between the MRB and the Media Server. The attribute MUST be present.
id：MRBとメディアサーバー間のサブスクリプションセッションを表す一意のトークンを示します。属性が存在しなければなりません。
seqnumber: Indicates a sequence number to be used in conjunction with the subscription session ID to identify a specific subscription command. The first subscription MUST contain a non-zero number 'seqnumber', and subsequent subscriptions MUST contain a higher number than the previous 'seqnumber' value. If a subsequent 'seqnumber' is not higher, a 405 response code is generated as per Section 5.1.4. The attribute MUST be present.
seqnumber：特定のサブスクリプションコマンドを識別するためにサブスクリプションセッションIDと共に使用されるシーケンス番号を示します。最初のサブスクリプションにはゼロ以外の番号「seqnumber」が含まれている必要があり、後続のサブスクリプションには以前の「seqnumber」値よりも大きい番号が含まれている必要があります。後続の 'seqnumber'が大きくない場合、セクション5.1.4に従って405応答コードが生成されます。属性が存在しなければなりません。
action: Provides the operation that should be carried out on the subscription:
アクション：サブスクリプションで実行する必要がある操作を提供します。
* The value of 'create' instructs the Media Server to attempt to set up a new subscription.
* 「作成」の値は、新しいサブスクリプションのセットアップを試みるようにメディアサーバーに指示します。
* The value of 'update' instructs the Media Server to attempt to update an existing subscription.
* 「更新」の値は、既存のサブスクリプションの更新を試みるようにメディアサーバーに指示します。
* The value of 'remove' instructs the Media Server to attempt to remove an existing subscription and consequently stop any ongoing related notification.
* 'remove'の値は、既存のサブスクリプションを削除して、結果として進行中の関連する通知を停止するようにメディアサーバーに指示します。
The attribute MUST be present.
属性が存在しなければなりません。
The <subscription> element has zero or more of the following child elements:
<subscription>要素には、0個以上の次の子要素があります。
<expires>: Provides the amount of time in seconds that a subscription should be installed for notifications at the Media Server. Once the amount of time has passed, the subscription expires, and the MRB has to subscribe again if it is still interested in receiving notifications from the Media Server. The element MAY be present.
<expires>：メディアサーバーでの通知のためにサブスクリプションをインストールする必要がある時間を秒単位で提供します。一定の時間が経過するとサブスクリプションが期限切れになり、メディアサーバーからの通知の受信に関心がある場合、MRBは再度サブスクライブする必要があります。要素が存在してもかまいません。
<minfrequency>: Provides the minimum frequency in seconds that the MRB wishes to receive notifications from the Media Server. The element MAY be present.
<minfrequency>：MRBがメディアサーバーから通知を受信する最小頻度を秒単位で提供します。要素が存在してもかまいません。
<maxfrequency>: Provides the maximum frequency in seconds that the MRB wishes to receive notifications from the Media Server. The element MAY be present.
<maxfrequency>：MRBがメディアサーバーから通知を受信する最大頻度を秒単位で提供します。要素が存在してもかまいません。
Please note that these three optional pieces of information provided by the MRB only act as a suggestion: the Media Server MAY change the proposed values if it considers the suggestions unacceptable (e.g., if the MRB has requested a notification frequency that is too high). In such a case, the request would not fail, but the updated, acceptable values would be reported in the <mrbresponse> accordingly.
MRBによって提供されるこれら3つのオプションの情報は、提案としてのみ機能することに注意してください。メディアサーバーは、提案が受け入れられないと見なした場合（たとえば、MRBが高すぎる通知頻度を要求した場合）、提案された値を変更できます（MAY）。このような場合、リクエストは失敗しませんが、更新された許容値は、それに応じて<mrbresponse>で報告されます。
Responses to requests are indicated by an <mrbresponse> element.
リクエストへの応答は、<mrbresponse>要素で示されます。
The <mrbresponse> element has the following attributes:
<mrbresponse>要素には次の属性があります。
status: numeric code indicating the response status. The attribute MUST be present.
status：応答ステータスを示す数値コード。属性が存在しなければなりません。
reason: string specifying a reason for the response status. The attribute MAY be present.
reason：応答ステータスの理由を指定する文字列。属性が存在する場合があります。
The <mrbresponse> element has a single child element:
<mrbresponse>要素には単一の子要素があります。
<subscription> for providing details related to a subscription requested by a Media Server (see below in this section).
<subscription>メディアサーバーによって要求されたサブスクリプションに関連する詳細を提供します（このセクションの下記を参照）。
The following status codes are defined for 'status':
以下のステータスコードが「ステータス」に定義されています。
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 400 | Syntax error |
| | |
| 401 | Unable to create Subscription |
| | |
| 402 | Unable to update Subscription |
| | |
| 403 | Unable to remove Subscription |
| | |
| 404 | Subscription does not exist |
| | |
| 405 | Wrong sequence number |
| | |
| 406 | Subscription already exists |
| | |
| 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+
Table 1: <mrbresponse> Status Codes
If a new subscription request made by an MRB (action='create') has been accepted, the Media Server MUST reply with an <mrbresponse> with status code 200. The same rule applies whenever a request to update (action='update') or remove (action='remove') an existing transaction can be fulfilled by the Media Server.
MRB（action = 'create'）によって作成された新しいサブスクリプション要求が受け入れられた場合、メディアサーバーは、ステータスコード200の<mrbresponse>で応答する必要があります。更新要求（action = 'update' ）または削除（action = 'remove'）して、既存のトランザクションをメディアサーバーで実行できます。
A subscription request, nevertheless, may fail for several reasons. In such a case, the status codes defined in Table 1 must be used instead. Specifically, if the Media Server fails to handle a request due to a syntax error in the request itself (e.g., incorrect XML, violation of the schema constraints, or invalid values in any of the attributes/elements), the Media Server MUST reply with an <mrbresponse> with status code 400. If a syntactically correct request fails because the request also includes any attribute/element the Media Server doesn't understand, the Media Server MUST reply with an <mrbresponse> with status code 420. If a syntactically correct request fails because the MRB wants to create a new subscription, but the provided unique 'id' for the subscription already exists, the Media Server MUST reply with an <mrbresponse> with status code 406. If a syntactically correct request fails because the MRB wants to update/remove a subscription that doesn't exist, the Media Server MUST reply with an <mrbresponse> with status code 404. If the Media Server is unable to accept a request for any other reason (e.g., the MRB has no more resources to fulfill the request), the Media Server MUST reply with an <mrbresponse> with status code 401/402/403, depending on the action the MRB provided in its request:
それにもかかわらず、サブスクリプション要求はいくつかの理由で失敗する可能性があります。そのような場合は、表1で定義されているステータスコードを代わりに使用する必要があります。具体的には、リクエスト自体の構文エラー（たとえば、不正なXML、スキーマ制約違反、または属性/要素の無効な値）のためにメディアサーバーがリクエストを処理できない場合、メディアサーバーは次のように応答する必要があります。ステータスコード400の<mrbresponse>。リクエストにメディアサーバーが理解できない属性/要素も含まれているために構文的に正しいリクエストが失敗した場合、メディアサーバーはステータスコード420の<mrbresponse>で応答する必要があります。 MRBは新しいサブスクリプションを作成する必要があるため、正しいリクエストは失敗しますが、サブスクリプションに指定された一意の 'id'はすでに存在します。メディアサーバーは、ステータスコード406の<mrbresponse>で応答する必要があります。存在しないサブスクリプションを更新/削除したい場合、メディアサーバーは、ステータスコード404の<mrbresponse>で応答する必要があります。メディアサーバーが他の理由（例：MRB hリクエストを満たすためのリソースがないため、メディアサーバーは、MRBがリクエストで提供したアクションに応じて、ステータスコード401/402/403の<mrbresponse>で応答する必要があります。
o action='create' --> 401;
o action = 'create'-> 401;
o action='update' --> 402;
o action = 'update'-> 402;
o action='remove' --> 403;
o action = 'remove'-> 403;
A response to a subscription request that has a status code of 200 indicates that the request is successful. The response MAY also contain a <subscription> child that describes the subscription. The <subscription> child MAY contain 'expires', 'minfrequency', and 'maxfrequency' values even if they were not contained in the request.
ステータスコード200のサブスクリプション要求への応答は、要求が成功したことを示します。応答には、サブスクリプションを説明する<subscription>子も含まれる場合があります。 <subscription>子には、リクエストに含まれていなくても、「expires」、「minfrequency」、および「maxfrequency」の値が含まれる場合があります。
The Media Server can choose to change the suggested 'expires', 'minfrequency', and 'maxfrequency' values provided by the MRB in its <mrbrequest> if it considers them unacceptable (e.g., the requested frequency range is too high). In such a case, the response MUST contain a <subscription> element describing the subscription as the Media Server accepted it, and the Media Server MUST include in the <subscription> element all of those values that it modified relative to the request, to inform the MRB about the change.
メディアサーバーは、MRBが<mrbrequest>で提供する提案された「expires」、「minfrequency」、および「maxfrequency」の値を受け入れられないと見なした場合（たとえば、要求された周波数範囲が高すぎる場合）を変更することを選択できます。このような場合、応答には、メディアサーバーがサブスクリプションを受け入れたときのサブスクリプションを説明する<subscription>要素が含まれている必要があり、メディアサーバーは、リクエストに関連して変更したすべての値を<subscription>要素に含める必要があります。変更に関するMRB。
The <mrbnotification> element is included in a request from a Media Server to an MRB to provide the details relating to current status. The Media Server will inform the MRB of its current status as defined by the information in the <subscription> element. Updates are sent using the <mrbnotification> element.
<mrbnotification>要素は、現在のステータスに関する詳細を提供するために、メディアサーバーからMRBへのリクエストに含まれています。メディアサーバーは、<subscription>要素の情報で定義されている現在のステータスをMRBに通知します。更新は<mrbnotification>要素を使用して送信されます。
The <mrbnotification> element has the following attributes:
<mrbnotification>要素には次の属性があります。
id: indicates a unique token representing the session between the MRB and the Media Server and is the same as the one appearing in the <subscription> element. The attribute MUST be present.
id：MRBとMedia Serverの間のセッションを表す一意のトークンを示し、<subscription>要素に表示されるものと同じです。属性が存在しなければなりません。
seqnumber: indicates a sequence number to be used in conjunction with the subscription session ID to identify a specific notification update. The first notification update MUST contain a non-zero number 'seqnumber', and subsequent notification updates MUST contain a higher number than the previous 'seqnumber' value. If a subsequent 'seqnumber' is not higher, the situation should be considered an error by the entity receiving the notification update. How the receiving entity deals with this situation is implementation specific. The attribute MUST be present.
seqnumber：特定の通知更新を識別するためにサブスクリプションセッションIDと組み合わせて使用されるシーケンス番号を示します。最初の通知の更新には、ゼロ以外の番号「seqnumber」が含まれている必要があり、その後の通知の更新には、以前の「seqnumber」値よりも大きい番号が含まれている必要があります。後続の 'seqnumber'がそれより大きくない場合、通知の更新を受信するエンティティは、状況をエラーと見なす必要があります。受信エンティティがこの状況にどのように対処するかは、実装によって異なります。属性が存在しなければなりません。
It's important to point out that the 'seqnumber' that appears in an <mrbnotification> is not related to the 'seqnumber' appearing in a <subscription>. In fact, the latter is associated with subscriptions and would increase at every command issued by the MRB, while the former is associated with the asynchronous notifications the Media Server would trigger according to the subscription and as such would increase at every notification message to enable the MRB to keep track of them.
<mrbnotification>に表示される「seqnumber」は、<subscription>に表示される「seqnumber」とは関係がないことを指摘することが重要です。実際、後者はサブスクリプションに関連付けられており、MRBによって発行されるコマンドごとに増加しますが、前者は非同期通知に関連付けられており、Media Serverはサブスクリプションに従ってトリガーするため、通知メッセージごとに増加して、それらを追跡するMRB。
The following sub-sections provide details of the child elements that make up the contents of the <mrbnotification> element.
次のサブセクションでは、<mrbnotification>要素のコンテンツを構成する子要素の詳細について説明します。
The <media-server-id> element provides a unique system-wide identifier for a Media Server instance. The element MUST be present and MUST be chosen such that it is extremely unlikely that two different Media Servers would present the same id to a given MRB.
<media-server-id>要素は、Media Serverインスタンスに一意のシステム全体の識別子を提供します。要素は存在しなければならず、2つの異なるメディアサーバーが特定のMRBに同じIDを提示する可能性が非常に低いように選択する必要があります。
The <supported-packages> element provides the list of Media Control Channel packages supported by the Media Server. The element MAY be present.
<supported-packages>要素は、メディアサーバーによってサポートされるメディアコントロールチャネルパッケージのリストを提供します。要素が存在してもかまいません。
The <supported-packages> element has no attributes.
<supported-packages>要素には属性はありません。
The <supported-packages> element has a single child element:
<supported-packages>要素には、単一の子要素があります。
<package>: Gives the name of a package supported by the Media Server. The <package> element has a single attribute, 'name', which provides the name of the supported Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230].
<package>：メディアサーバーがサポートするパッケージの名前を示します。 <package>要素には「name」という単一の属性があり、[RFC6230]のセクション13.1.1に準拠する、サポートされているMedia Control Channel Frameworkパッケージの名前を提供します。
The <active-rtp-sessions> element provides information detailing the current active Real-time Transport Protocol (RTP) sessions. The element MAY be present.
<active-rtp-sessions>要素は、現在アクティブなリアルタイムトランスポートプロトコル（RTP）セッションの詳細情報を提供します。要素が存在してもかまいません。
The <active-rtp-sessions> element has no attributes.
<active-rtp-sessions>要素には属性はありません。
The <active-rtp-sessions> element has a single child element:
<active-rtp-sessions>要素には、単一の子要素があります。
<rtp-codec>: Describes a supported codec and the number of active sessions using that codec. The <rtp-codec> element has one attribute. The value of the attribute, 'name', is a media type (which can include parameters per [RFC6381]). The <rtp-codec> element has two child elements. The child element <decoding> has as content the decimal number of RTP sessions being decoded using the specified codec, and the child element <encoding> has as content the decimal number of RTP sessions being encoded using the specified codec.
<rtp-codec>：サポートされているコーデックと、そのコーデックを使用するアクティブなセッションの数について説明します。 <rtp-codec>要素には1つの属性があります。属性 'name'の値はメディアタイプです（[RFC6381]のパラメータを含めることができます）。 <rtp-codec>要素には2つの子要素があります。子要素<decoding>には、指定されたコーデックを使用してデコードされるRTPセッションの10進数のコンテンツが含まれ、子要素<encoding>には、指定されたコーデックを使用してエンコードされるRTPセッションの10進数のコンテンツが含まれます。
The <active-mixer-sessions> element provides information detailing the current active mixed RTP sessions. The element MAY be present.
<active-mixer-sessions>要素は、現在アクティブな混合RTPセッションの詳細情報を提供します。要素が存在してもかまいません。
The <active-mixer-sessions> element has no attributes.
<active-mixer-sessions>要素には属性はありません。
The <active-mixer-sessions> element has a single child element:
<active-mixer-sessions>要素には単一の子要素があります：
<active-mix>: Describes a mixed active RTP session. The <active-mix> element has one attribute. The value of the attribute, 'conferenceid', is the name of the mix. The <active-mix> element has one child element. The child element, <rtp-codec>, contains the same information relating to RTP sessions as that defined in Section 5.1.5.3. The element MAY be present.
<active-mix>：混合アクティブRTPセッションについて説明します。 <active-mix>要素には1つの属性があります。属性 'conferenceid'の値は、ミックスの名前です。 <active-mix>要素には1つの子要素があります。子要素<rtp-codec>には、セクション5.1.5.3で定義されたものと同じRTPセッションに関する情報が含まれています。要素が存在してもかまいません。
The <non-active-rtp-sessions> element provides information detailing the currently available inactive RTP sessions, that is, how many more RTP streams this Media Server can support. The element MAY be present.
<non-active-rtp-sessions>要素は、現在使用可能な非アクティブなRTPセッションの詳細、つまり、このメディアサーバーがサポートできるRTPストリームの数を詳しく示します。要素が存在してもかまいません。
The <non-active-rtp-sessions> element has no attributes.
<non-active-rtp-sessions>要素には属性はありません。
The <non-active-rtp-sessions> element has a single child element:
<non-active-rtp-sessions>要素には、単一の子要素があります。
<rtp-codec>: Describes a supported codec and the number of non-active sessions for that codec. The <rtp-codec> element has one attribute. The value of the attribute, 'name', is a media type (which can include parameters per [RFC6381]). The <rtp-codec> element has two child elements. The child element <decoding> has as content the decimal number of RTP sessions available for decoding using the specified codec, and the child element <encoding> has as content the decimal number of RTP sessions available for encoding using the specified codec.
<rtp-codec>：サポートされているコーデックと、そのコーデックでアクティブでないセッションの数について説明します。 <rtp-codec>要素には1つの属性があります。属性 'name'の値はメディアタイプです（[RFC6381]のパラメータを含めることができます）。 <rtp-codec>要素には2つの子要素があります。子要素<decoding>には、指定されたコーデックを使用したデコードに使用可能なRTPセッションの10進数のコンテンツが含まれ、子要素<encoding>には、指定されたコーデックを使用したエンコードに使用可能なRTPセッションの10進数のコンテンツが含まれます。
The <non-active-mixer-sessions> element provides information detailing the current inactive mixed RTP sessions, that is, how many more mixing sessions this Media Server can support. The element MAY be present.
<non-active-mixer-sessions>要素は、現在の非アクティブな混合RTPセッション、つまりこのメディアサーバーがサポートできるミキシングセッションの数の詳細を提供します。要素が存在してもかまいません。
The <non-active-mixer-sessions> element has no attributes.
<non-active-mixer-sessions>要素には属性はありません。
The <non-active-mixer-sessions> element has a single child element:
<non-active-mixer-sessions>要素には、単一の子要素があります。
<non-active-mix>: Describes available mixed RTP sessions. The <non-active-mix> element has one attribute. The value of the attribute, 'available', is the number of mixes that could be used using that profile. The <non-active-mix> element has one child element. The child element, <rtp-codec>, contains the same information relating to RTP sessions as that defined in Section 5.1.5.5. The element MAY be present.
<non-active-mix>：使用可能な混合RTPセッションについて説明します。 <non-active-mix>要素には1つの属性があります。属性の値「available」は、そのプロファイルを使用して使用できるミックスの数です。 <non-active-mix>要素には1つの子要素があります。子要素<rtp-codec>には、セクション5.1.5.5で定義されたものと同じRTPセッションに関する情報が含まれています。要素が存在してもかまいません。
The <media-server-status> element provides information detailing the current status of the Media Server. The element MUST be present. It can return one of the following values:
<media-server-status>要素は、メディアサーバーの現在のステータスの詳細情報を提供します。要素が存在しなければなりません。次のいずれかの値を返します。
active: Indicates that the Media Server is available for service.
アクティブ：メディアサーバーがサービスに利用可能であることを示します。
deactivated: Indicates that the Media Server has been withdrawn from service, and as such requests should not be sent to it before it becomes 'active' again.
非アクティブ化：メディアサーバーがサービスから撤回されたことを示します。そのため、要求が再度「アクティブ」になるまで送信されるべきではありません。
unavailable: Indicates that the Media Server continues to process past requests but cannot accept new requests, and as such should not be contacted before it becomes 'active' again.
利用不可：メディアサーバーは過去のリクエストを処理し続けますが、新しいリクエストを受け入れることができないため、再び「アクティブ」になる前にアクセスしてはならないことを示します。
The <media-server-status> element has no attributes.
<media-server-status>要素には属性はありません。
The <media-server-status> element has no child elements.
<media-server-status>要素には子要素はありません。
The <supported-codecs> element provides information detailing the current codecs supported by a Media Server and associated actions. The element MAY be present.
<supported-codecs>要素は、メディアサーバーによってサポートされている現在のコーデックおよび関連するアクションの詳細情報を提供します。要素が存在してもかまいません。
The <supported-codecs> element has no attributes.
<supported-codecs>要素には属性はありません。
The <supported-codecs> element has a single child element:
<supported-codecs>要素には、単一の子要素があります。
<supported-codec>: Has a single attribute, 'name', which provides the name of the codec about which this element provides information. A valid value is a media type that, depending on its definition, can include additional parameters (e.g., [RFC6381]). The <supported-codec> element then has a further child element, <supported-codec-package>. The <supported-codec-package> element has a single attribute, 'name', which provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the codec support applies. The <supported-codec-package> element has zero or more <supported-action> children, each one of which describes an action that a Media Server can apply to this codec:
<supported-codec>：この要素が情報を提供するコーデックの名前を提供する単一の属性 'name'があります。有効な値はメディアタイプであり、その定義に応じて、追加のパラメーターを含めることができます（[RFC6381]など）。 <supported-codec>要素には、さらに<supported-codec-package>という子要素があります。 <supported-codec-package>要素には、単一の属性「name」があり、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。これには、コーデックサポートが適用されます。 <supported-codec-package>要素には、0個以上の<supported-action>子があります。それぞれの子は、メディアサーバーがこのコーデックに適用できるアクションを記述します。
* 'decoding', meaning a decoder for this codec is available;
* 「デコード」は、このコーデックのデコーダが利用可能であることを意味します。
* 'encoding', meaning an encoder for this codec is available;
* 'encoding'、つまりこのコーデックのエンコーダーが利用可能であることを意味します。
* 'passthrough', meaning the Media Server is able to pass a stream encoded using that codec through, without re-encoding.
* 「パススルー」は、メディアサーバーが、再エンコードせずに、そのコーデックを使用してエンコードされたストリームをパススルーできることを意味します。
The <application-data> element provides an arbitrary string of characters as application-level data. This data is meant to only have meaning at the application-level logic and as such is not otherwise restricted by this specification. The set of allowed characters is the same as those in XML (viz., tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646.2012] (see also Section 2.2 of <http://www.w3.org/TR/xml/>)). The element MAY be present.
<application-data>要素は、アプリケーションレベルのデータとして任意の文字列を提供します。このデータは、アプリケーションレベルのロジックでのみ意味を持つことを意図しているため、この仕様による制限はありません。許可される文字のセットは、XMLの文字と同じです（つまり、タブ、キャリッジリターン、ラインフィード、UnicodeおよびISO / IEC 10646 [ISO.10646.2012]の有効な文字）（<http：/のセクション2.2も参照） /www.w3.org/TR/xml/>））。要素が存在してもかまいません。
The <application-data> element has no attributes.
<application-data>要素には属性はありません。
The <application-data> element has no child elements.
<application-data>要素には子要素はありません。
The <file-formats> element provides a list of file formats supported for the purpose of playing media. The element MAY be present.
<file-formats>要素は、メディアの再生を目的としてサポートされているファイル形式のリストを提供します。要素が存在してもかまいません。
The <file-formats> element has no attributes.
<file-formats>要素には属性はありません。
The <file-formats> element has zero of more the following child elements:
<file-formats>要素には、次の子要素がありません。
<supported-format>: Has a single attribute, 'name', which provides the type of file format that is supported. A valid value is a media type that, depending on its definition, can include additional parameters (e.g., [RFC6381]). The <supported-format> element then has a further child element, <supported-file-package>. The <supported-file-package> element provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the file format support applies.
<supported-format>：サポートされているファイル形式のタイプを提供する単一の属性 'name'があります。有効な値はメディアタイプであり、その定義に応じて、追加のパラメーターを含めることができます（[RFC6381]など）。 <supported-format>要素には、さらに<supported-file-package>という子要素があります。 <supported-file-package>要素は、[RFC6230]のセクション13.1.1に準拠したMedia Control Channel Frameworkパッケージの名前を提供し、ファイル形式のサポートが適用されます。
The <max-prepared-duration> element provides the maximum amount of time a media dialog will be kept in the prepared state before timing out (see Section 4.4.2.2.6 of RFC 6231 [RFC6231]. The element MAY be present.
<max-prepared-duration>要素は、メディアダイアログがタイムアウトになるまで準備された状態で保持される最大時間を提供します（RFC 6231 [RFC6231]のセクション4.4.2.2.6を参照）。この要素は存在してもかまいません。
The <max-prepared-duration> element has no attributes.
<max-prepared-duration>要素には属性はありません。
The <max-prepared-duration> element has a single child element:
<max-prepared-duration>要素には単一の子要素があります：
<max-time>: Has a single attribute, 'max-time-seconds', which provides the amount of time in seconds that a media dialog can be in the prepared state. The <max-time> element then has a further child element, <max-time-package>. The <max-time-package> element provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the time period applies.
<max-time>：「max-time-seconds」という単一の属性があり、メディアダイアログが準備された状態になることができる秒数を提供します。 <max-time>要素には、さらに<max-time-package>という子要素があります。 <max-time-package>要素は、期間が適用される[RFC6230]のセクション13.1.1に準拠するMedia Control Channel Frameworkパッケージの名前を提供します。
The <dtmf-support> element specifies the supported methods to detect Dual-Tone Multi-Frequency (DTMF) tones and to generate them. The element MAY be present.
<dtmf-support>要素は、Dual-Tone Multi-Frequency（DTMF）トーンを検出して生成するためにサポートされているメソッドを指定します。要素が存在してもかまいません。
The <dtmf-support> element has no attributes.
<dtmf-support>要素には属性はありません。
The <dtmf-support> element has zero of more of the following child elements:
<dtmf-support>要素には、次の子要素がありません。
<detect>: Indicates the support for DTMF detection. The <detect> element has no attributes. The <detect> element then has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF being used, and it can only be a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (detecting tones as signals from the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<detect>：DTMF検出のサポートを示します。 <detect>要素には属性はありません。 <detect>要素には、さらに<dtmf-type>という子要素があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 'name'属性は、使用されるDTMFのタイプを提供します。これは、 'RFC4733' [RFC4733]または 'Media'（オーディオストリームからの信号としてのトーンの検出）を含む、大文字と小文字を区別しない文字列のみです。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
<generate>: Indicates the support for DTMF generation. The <generate> element has no attributes. The <generate> element then has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF being used, and it can only be a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (generating tones as signals in the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<generate>：DTMF生成のサポートを示します。 <generate>要素には属性はありません。 <generate>要素には、さらに<dtmf-type>という子要素があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 'name'属性は、使用されるDTMFのタイプを提供します。これは、 'RFC4733' [RFC4733]または 'Media'（オーディオストリームの信号としてトーンを生成する）のいずれかを含む、大文字と小文字を区別しない文字列のみです。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
<passthrough>: Indicates the support for passing DTMF through without re-encoding. The <passthrough> element has no attributes. The <passthrough> element then has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF being used, and it can only be a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<passthrough>：再エンコードせずにDTMFを通過させるためのサポートを示します。 <passthrough>要素には属性はありません。 <passthrough>要素には、さらに<dtmf-type>という子要素があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 'name'属性は、使用されるDTMFのタイプを提供します。これは、 'RFC4733' [RFC4733]または 'Media'（オーディオストリームを介して信号としてトーンを渡す）のいずれかを含む、大文字と小文字を区別しない文字列のみです。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
The <mixing-modes> element provides information about the support for audio and video mixing of a Media Server, specifically a list of supported algorithms to mix audio and a list of supported video presentation layouts. The element MAY be present.
<mixing-modes>要素は、メディアサーバーのオーディオとビデオのミキシングのサポートに関する情報、具体的には、オーディオを混合するためにサポートされているアルゴリズムのリストとサポートされているビデオプレゼンテーションレイアウトのリストを提供します。要素が存在してもかまいません。
The <mixing-modes> element has no attributes.
<mixing-modes>要素には属性はありません。
The <mixing-modes> element has zero or more of the following child elements:
<mixing-modes>要素には、次の子要素が0個以上含まれています。
<audio-mixing-modes>: Describes the available algorithms for audio mixing. The <audio-mixing-modes> element has no attributes. The <audio-mixing-modes> element has one child element. The child element, <audio-mixing-mode>, contains a specific available algorithm. Valid values for the <audio-mixing-mode> element are algorithm names, e.g., 'nbest' and 'controller' as defined in [RFC6505]. The element has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the algorithm support applies.
<audio-mixing-modes>：オーディオミキシングに使用できるアルゴリズムについて説明します。 <audio-mixing-modes>要素には属性はありません。 <audio-mixing-modes>要素には1つの子要素があります。子要素<audio-mixing-mode>には、利用可能な特定のアルゴリズムが含まれています。 <audio-mixing-mode>要素の有効な値は、[RFC6505]で定義されている「nbest」や「controller」などのアルゴリズム名です。要素には、単一の属性「package」があります。属性「package」は、[RFC6230]のセクション13.1.1に準拠したMedia Control Channel Frameworkパッケージの名前を提供し、アルゴリズムサポートが適用されます。
<video-mixing-modes>: Describes the available video presentation layouts and the supported functionality related to video mixing. The <video-mixing-modes> element has two attributes: 'vas' and 'activespeakermix'. The 'vas' attribute is of type boolean with a value of 'true' indicating that the Media Server supports automatic Voice Activated Switching. The 'activespeakermix' is of type boolean with a value of 'true' indicating that the Media Server is able to prepare an additional video stream for the loudest speaker participant without its contribution. The <video-mixing-modes> element has one child element. The child element, <video-mixing-mode>, contains the name of a specific video presentation layout. The name may refer to one of the predefined video layouts defined in the XCON conference information data model [RFC6501], or to non-XCON layouts as well, as long as they are properly prefixed according to the schema they belong to. The <video-mixing-mode> element has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the algorithm support applies.
<video-mixing-modes>：使用可能なビデオプレゼンテーションレイアウトと、ビデオミキシングに関連してサポートされる機能について説明します。 <video-mixing-modes>要素には、「vas」と「activespeakermix」の2つの属性があります。 'vas'属性はブール型で、値が 'true'の場合、メディアサーバーは自動音声起動切り替えをサポートすることを示します。 「activespeakermix」はブール型であり、値が「true」の場合、メディアサーバーは、最大のスピーカー参加者のために追加のビデオストリームを提供せずに準備できることを示します。 <video-mixing-modes>要素には1つの子要素があります。子要素<video-mixing-mode>には、特定のビデオプレゼンテーションレイアウトの名前が含まれています。この名前は、XCON会議情報データモデル[RFC6501]で定義されている定義済みのビデオレイアウトの1つを指す場合と、XCON以外のレイアウトを指す場合があります（それらが属するスキーマに従って適切にプレフィックスが付けられている場合）。 <video-mixing-mode>要素には、単一の属性「package」があります。属性「package」は、[RFC6230]のセクション13.1.1に準拠したMedia Control Channel Frameworkパッケージの名前を提供し、アルゴリズムサポートが適用されます。
The <supported-tones> element provides information about which tones a Media Server is able to play and recognize. In particular, the support is reported by referring to both support for country codes (ISO 3166-1 [ISO.3166-1]) and supported functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present.
<supported-tones>要素は、Media Serverが再生および認識できるトーンに関する情報を提供します。特に、サポートは国コードのサポート（ISO 3166-1 [ISO.3166-1]）とサポートされている機能（ITU-T勧告Q.1950 [ITU-T.Q.1950]）の両方を参照して報告されます。要素が存在してもかまいません。
The <supported-tones> element has no attributes.
<supported-tones>要素には属性はありません。
The <supported-tones> element has zero or more of the following child elements:
<supported-tones>要素には、次の子要素が0個以上含まれています。
<supported-country-codes>: Describes the supported country codes with respect to tones. The <supported-country-codes> element has no attributes. The <supported-country-codes> element has one child element. The child element, <country-code>, reports support for a specific country code, compliant with the ISO 3166-1 [ISO.3166-1] specification. The <country-code> element has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], in which the tones from the specified country code are supported.
<supported-country-codes>：トーンに関してサポートされている国コードについて説明します。 <supported-country-codes>要素には属性はありません。 <supported-country-codes>要素には1つの子要素があります。子要素<country-code>は、ISO 3166-1 [ISO.3166-1]仕様に準拠した特定の国コードのサポートを報告します。 <country-code>要素には、単一の属性「package」があります。属性「package」は、[RFC6230]のセクション13.1.1に準拠したMedia Control Channel Frameworkパッケージの名前を提供し、指定された国コードからのトーンがサポートされます。
<supported-h248-codes>: Describes the supported H.248 codes with
respect to tones. The <supported-h248-codes> element has no
attributes. The <supported-h248-codes> element has one child
element. The child element, <h248-code>, reports support for a
specific H.248 code, compliant with the ITU-T Recommendation
Q.1950 [ITU-T.Q.1950] specification. The codes can be either
specific (e.g., cg/dt to only report the Dial Tone from the Call
Progress Tones package) or generic (e.g., cg/* to report all the
tones from the Call Progress Tones package), using wildcards. The
<h248-code> element has a single attribute, 'package'. The
attribute 'package' provides the name of the Media Control Channel
Framework package, compliant with Section 13.1.1 of [RFC6230], in
which the specified codes are supported.
The <file-transfer-modes> element allows the Media Server to specify which scheme names are supported for transferring files to a Media Server for each Media Control Channel Framework package type, for example, whether the Media Server supports fetching resources via HTTP, HTTPS, NFS, etc. The element MAY be present.
<file-transfer-modes>要素を使用すると、メディアサーバーは、各メディアコントロールチャネルフレームワークパッケージタイプのファイルをメディアサーバーに転送するためにサポートされるスキーム名を指定できます。たとえば、メディアサーバーがHTTP、HTTPSを介したリソースのフェッチをサポートするかどうか、NFSなど。要素は存在してもかまいません。
The <file-transfer-modes> element has no attributes.
<file-transfer-modes>要素には属性はありません。
The <file-transfer-modes> element has a single child element:
<file-transfer-modes>要素には、単一の子要素があります。
<file-transfer-mode>: Has two attributes: 'name' and 'package'. The 'name' attribute provides the scheme name of the protocol that can be used for file transfer (e.g., HTTP, HTTPS, NFS, etc.); the value of the attribute is case insensitive. The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the scheme name applies.
<file-transfer-mode>：「name」と「package」の2つの属性があります。 'name'属性は、ファイル転送（HTTP、HTTPS、NFSなど）に使用できるプロトコルのスキーム名を提供します。属性の値は大文字と小文字を区別しません。 'package'属性は、関連するIANAレジストリの仕様（「msc-ivr / 1.0」など）に準拠し、スキーム名が適用されるMedia Control Channel Frameworkパッケージの名前を提供します。
It is important to point out that this element provides no information about whether or not the Media Server supports any flavor of live streaming: for instance, a value of "HTTP" for the IVR (Interactive Voice Response) Package would only mean the 'http' scheme makes sense to the Media Server within the context of that package. Whether or not the Media Server can make use of HTTP to only fetch resources, or also to attach an HTTP live stream to a call, is to be considered implementation specific to the Media Server and irrelevant to the Application Server and/or MRB. Besides, the Media Server supporting a scheme does not imply that it also supports the related secure versions: for instance, if the Media Server supports both HTTP and HTTPS, both the schemes will appear in the element. A lack of the "HTTPS" value would need to be interpreted as a lack of support for the 'https' scheme.
この要素は、メディアサーバーがライブストリーミングのフレーバーをサポートするかどうかについての情報を提供しないことを指摘することが重要です。たとえば、IVR（インタラクティブボイスレスポンス）パッケージの「HTTP」の値は、「http 'スキームは、そのパッケージのコンテキスト内でメディアサーバーに意味があります。メディアサーバーがHTTPを使用してリソースをフェッチするだけか、またはHTTPライブストリームを通話にアタッチできるかどうかは、メディアサーバーに固有の実装と見なされ、アプリケーションサーバーやMRBとは無関係です。さらに、スキームをサポートするメディアサーバーは、関連する安全なバージョンもサポートすることを意味しません。たとえば、メディアサーバーがHTTPとHTTPSの両方をサポートする場合、両方のスキームが要素に表示されます。 「HTTPS」値の欠如は、「https」スキームのサポートの欠如として解釈される必要があります。
The <asr-tts-support> element provides information about the support for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) functionality in a Media Server. The functionality is reported by referring to the supported languages (using ISO 639-1 [ISO.639.2002] codes) regarding both ASR and TTS. The element MAY be present.
<asr-tts-support>要素は、メディアサーバーでの自動音声認識（ASR）および音声合成（TTS）機能のサポートに関する情報を提供します。機能は、ASRとTTSの両方に関してサポートされている言語（ISO 639-1 [ISO.639.2002]コードを使用）を参照して報告されます。要素が存在してもかまいません。
The <asr-tts-support> element has no attributes.
<asr-tts-support>要素には属性はありません。
The <asr-tts-support> element has zero or more of the following child elements:
<asr-tts-support>要素には、次の子要素が0個以上含まれています。
<asr-support>: Describes the available languages for ASR. The <asr-support> element has no attributes. The <asr-support> element has one child element. The child element, <language>, reports that the Media Server supports ASR for a specific language. The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1 [ISO.639.2002] code of the supported language.
<asr-support>：ASRで使用可能な言語について説明します。 <asr-support>要素には属性はありません。 <asr-support>要素には1つの子要素があります。子要素<language>は、メディアサーバーが特定の言語のASRをサポートすることを報告します。 <language>要素には、単一の属性「xml：lang」があります。属性「xml：lang」には、サポートされている言語のISO 639-1 [ISO.639.2002]コードが含まれています。
<tts-support>: Describes the available languages for TTS. The <tts-support> element has no attributes. The <tts-support> element has one child element. The child element, <language>, reports that the Media Server supports TTS for a specific language. The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1 [ISO.639.2002] code of the supported language.
<tts-support>：TTSで使用可能な言語について説明します。 <tts-support>要素には属性はありません。 <tts-support>要素には1つの子要素があります。子要素<language>は、メディアサーバーが特定の言語のTTSをサポートしていることを報告します。 <language>要素には、単一の属性「xml：lang」があります。属性「xml：lang」には、サポートされている言語のISO 639-1 [ISO.639.2002]コードが含まれています。
The <vxml-support> element specifies if the Media Server supports VoiceXML (VXML) and, if it does, through which protocols the support is exposed (e.g., via the control framework, RFC 4240 [RFC4240], or RFC 5552 [RFC5552]). The element MAY be present.
<vxml-support>要素は、メディアサーバーがVoiceXML（VXML）をサポートするかどうかを指定し、サポートする場合、サポートを公開するプロトコルを介して（たとえば、制御フレームワーク、RFC 4240 [RFC4240]、またはRFC 5552 [RFC5552]を介して） ）。要素が存在してもかまいません。
The <vxml-support> element has no attributes.
<vxml-support>要素には属性はありません。
The <vxml-support> element has a single child element:
<vxml-support>要素には単一の子要素があります。
<vxml-mode>: Has two attributes: 'package' and 'support'. The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the VXML support applies. The 'support' attribute provides the type of VXML support provided by the Media Server (e.g., RFC 5552 [RFC5552], RFC 4240 [RFC4240], or the IVR Package [RFC6231]), and valid values are case-insensitive RFC references (e.g., "rfc6231" to specify that the Media Server supports VoiceXML as provided by the IVR Package [RFC6231]).
<vxml-mode>：「package」と「support」の2つの属性があります。 「package」属性は、VXMLサポートが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。 'support'属性は、メディアサーバーによって提供されるVXMLサポートのタイプ（たとえば、RFC 5552 [RFC5552]、RFC 4240 [RFC4240]、またはIVRパッケージ[RFC6231]）を提供し、有効な値は大文字と小文字を区別しないRFC参照（たとえば、 "rfc6231"は、メディアサーバーがIVRパッケージ[RFC6231]によって提供されるVoiceXMLをサポートすることを指定します。
The presence of at least one <vxml-mode> child element would indicate that the Media Server does support VXML as specified by the child element itself. An empty <vxml> element would otherwise indicate that the Media Server does not support VXML at all.
少なくとも1つの<vxml-mode>子要素の存在は、メディアサーバーが子要素自体で指定されたVXMLをサポートしていることを示します。空の<vxml>要素は、メディアサーバーがVXMLをまったくサポートしていないことを示します。
The <media-server-location> element provides information about the civic location of a Media Server. Its description makes use of the Civic Address Schema standardized in RFC 5139 [RFC5139]. The element MAY be present. More precisely, this section is entirely optional, and it's implementation specific to fill it with just the details each implementer deems necessary for any optimization that may be needed.
<media-server-location>要素は、メディアサーバーの都市の場所に関する情報を提供します。その説明では、RFC 5139 [RFC5139]で標準化されたCivic Address Schemaを利用しています。要素が存在してもかまいません。より正確には、このセクションは完全にオプションであり、各実装者が必要とする可能性のある最適化に必要であると見なす詳細のみを記入することは、実装固有です。
The <media-server-location> element has no attributes.
<media-server-location>要素には属性はありません。
The <media-server-location> element has a single child element:
<media-server-location>要素には単一の子要素があります。
<civicAddress>: Describes the civic address location of the Media Server, whose representation refers to Section 4 of RFC 5139 [RFC5139].
<civicAddress>：RFC 5139 [RFC5139]のセクション4を参照するメディアサーバーの都市アドレスの場所について説明します。
The <label> element allows a Media Server to declare a piece of information that will be understood by the MRB. For example, the Media Server can declare if it's a blue or green one. It's a string to allow arbitrary values to be returned to allow arbitrary classification. The element MAY be present.
<label>要素により、メディアサーバーはMRBが理解する情報の一部を宣言できます。たとえば、メディアサーバーは、それが青か緑かを宣言できます。これは、任意の値を返して任意の分類を可能にする文字列です。要素が存在してもかまいません。
The <label> element has no attributes.
<label>要素には属性はありません。
The <label> element has no child elements.
<label>要素には子要素はありません。
The <media-server-address> element allows a Media Server to provide a direct SIP URI where it can be reached (e.g., the URI that the Application Server would call in order to set up a Control Channel and relay SIP media dialogs). The element MAY be present.
<media-server-address>要素を使用すると、メディアサーバーは、到達可能な直接のSIP URI（たとえば、アプリケーションサーバーがコントロールチャネルをセットアップしてSIPメディアダイアログをリレーするために呼び出すURI）を提供できます。要素が存在してもかまいません。
The <media-server-address> element has no attributes.
<media-server-address>要素には属性はありません。
The <media-server-address> element has no child elements.
<media-server-address>要素には子要素はありません。
The <encryption> element allows a Media Server to declare support for encrypting RTP media streams using RFC 3711 [RFC3711]. The element MAY be present. If the element is present, then the Media Server supports DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP) extension for Datagram Transport Layer Security (DTLS)) [RFC5763].
<encryption>要素により、Media ServerはRFC 3711 [RFC3711]を使用したRTPメディアストリームの暗号化のサポートを宣言できます。要素が存在してもかまいません。要素が存在する場合、メディアサーバーはDTLS-SRTP（データグラムトランスポート層セキュリティ（DTLS）のセキュアリアルタイムトランスポートプロトコル（SRTP）拡張）[RFC5763]をサポートします。
The <encryption> element has no attributes.
<encryption>要素には属性はありません。
The <encryption> element has no child elements.
<encryption>要素には子要素はありません。
The Media Server Consumer interface provides the ability for clients of an MRB, such as Application Servers, to request an appropriate Media Server to satisfy specific criteria. This interface allows a client to pass detailed meta-information to the MRB to help select an appropriate Media Server. The MRB is then able to make an informed decision and provide the client with an appropriate Media Server resource. The MRB Consumer interface includes both 1) the In-line Aware MRB Mode (IAMM), which uses the Session Initiation Protocol (SIP) and 2) the Query mode, which uses the Hypertext Transfer Protocol (HTTP) [RFC2616]. The MRB Consumer interface does not include the In-line Unaware Mode (IUMM), which is further explained in Section 5.3. The following sub-sections provide guidance on using the Consumer interface, which is represented by the 'application/mrb-consumer+xml' media type in Section 11, with HTTP and SIP.
メディアサーバーコンシューマインターフェイスは、アプリケーションサーバーなどのMRBのクライアントが特定の条件を満たすために適切なメディアサーバーを要求する機能を提供します。このインターフェイスを使用すると、クライアントは詳細なメタ情報をMRBに渡して、適切なメディアサーバーを選択できます。 MRBは情報に基づいた決定を行い、クライアントに適切なMedia Serverリソースを提供できます。 MRBコンシューマインターフェイスには、1）セッション開始プロトコル（SIP）を使用するインライン対応MRBモード（IAMM）と2）ハイパーテキスト転送プロトコル（HTTP）[RFC2616]を使用するクエリモードの両方が含まれます。 MRBコンシューマーインターフェイスには、インライン非認識モード（IUMM）は含まれていません。これについては、セクション5.3で詳しく説明します。次のサブセクションでは、HTTPおよびSIPでのセクション11の「application / mrb-consumer + xml」メディアタイプで表されるコンシューマーインターフェイスの使用に関するガイダンスを示します。
An appropriate interface for such a 'query' style interface is in fact an HTTP usage. Using HTTP and XML combined reduces complexity and encourages the use of common tools that are widely available in the industry today. The following information explains the primary operations required to request and then receive information from an MRB, by making use of HTTP [RFC2616] and HTTPS [RFC2818] as transport for a query for a media resource, and the appropriate response.
そのような「クエリ」スタイルのインターフェースに適したインターフェースは、実際にはHTTPの使用法です。 HTTPとXMLを組み合わせて使用すると、複雑さが軽減され、今日の業界で広く利用可能な一般的なツールの使用が促進されます。次の情報では、メディアリソースのクエリのトランスポートとしてHTTP [RFC2616]およびHTTPS [RFC2818]を使用して、MRBから情報を要求して受信するために必要な主な操作と、適切な応答について説明します。
The media resource query, as defined by the <mediaResourceRequest> element from Section 11, MUST be carried in the body of an HTTP/HTTPS POST request. The media type contained in the HTTP/HTTPS request/ response MUST be 'application/mrb-consumer+xml'. This value MUST be reflected in the appropriate HTTP headers, such as 'Content-Type' and 'Accept'. The body of the HTTP/HTTPS POST request MUST only contain an <mrbconsumer> root element with only one child <mediaResourceRequest> element as defined in Section 11.
セクション11の<mediaResourceRequest>要素で定義されているメディアリソースクエリは、HTTP / HTTPS POSTリクエストの本文に含める必要があります。 HTTP / HTTPS要求/応答に含まれるメディアタイプは、「application / mrb-consumer + xml」である必要があります。この値は、「Content-Type」や「Accept」などの適切なHTTPヘッダーに反映する必要があります。セクション11で定義されているように、HTTP / HTTPS POSTリクエストの本文には、子<mediaResourceRequest>要素を1つだけ含む<mrbconsumer>ルート要素のみを含める必要があります。
The media resource response to a query, as defined by the <mediaResourceResponse> element from Section 11, MUST be carried in the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS POST request. The media type contained in the HTTP/HTTPS request/ response MUST be 'application/mrb-consumer+xml'. This value MUST be reflected in the appropriate HTTP headers, such as 'Content-Type' and 'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain an <mrbconsumer> root element with only one child <mediaResourceResponse> element as defined in Section 11.
セクション11の<mediaResourceResponse>要素で定義されている、クエリに対するメディアリソースの応答は、元のHTTP / HTTPS POST要求に対するHTTP / HTTPS 200応答の本文に含める必要があります。 HTTP / HTTPS要求/応答に含まれるメディアタイプは、「application / mrb-consumer + xml」である必要があります。この値は、「Content-Type」や「Accept」などの適切なHTTPヘッダーに反映する必要があります。セクション11で定義されているように、HTTP / HTTPS 200応答の本文には、子<mediaResourceResponse>要素を1つだけ含む<mrbconsumer>ルート要素のみを含める必要があります。
When an Application Server wants to release previously awarded media resources granted through a prior request/response exchange with an MRB, it will send a new request with an <action> element with value 'remove', as described in Section 5.2.3 ("Consumer Interface Lease Mechanism").
アプリケーションサーバーは、MRBとの以前のリクエスト/レスポンス交換を通じて付与された、以前に付与されたメディアリソースを解放する場合、セクション5.2.3で説明されているように、値が「remove」の<action>要素を含む新しいリクエストを送信します（ "消費者インターフェースリースメカニズム」）。
This document provides a complete toolkit for MRB deployment that includes the ability to interact with an MRB using SIP for the Consumer interface. The following information explains the primary operations required to request and then receive information from an MRB, by making use of SIP [RFC3261] as transport for a request for media resources, and the appropriate response when using IAMM as the mode of operation (as discussed in Section 5.2.2.1).
このドキュメントは、コンシューマインターフェイスにSIPを使用してMRBと対話する機能を含む、MRB展開のための完全なツールキットを提供します。次の情報は、メディアリソースの要求のトランスポートとしてSIP [RFC3261]を使用することにより、MRBから情報を要求して受信するために必要な主な操作と、IAMMを操作モードとして使用する場合の適切な応答（説明）について説明しています。セクション5.2.2.1で）。
The use of IAMM, besides having the MRB select appropriate media resources on behalf of a client application, includes setting up either a Control Framework Control Channel between an Application Server and one of the Media Servers (Section 5.2.2.1) or a media dialog session between an Application Server and one of the Media Servers (Section 5.2.2.2). Note that in either case the SIP URIs of the selected Media Servers are made known to the requesting Application Server in the SIP 200 OK response by means of one or more <media-server-address> child elements in the <response-session-info> element (Section 5.2.6).
クライアントアプリケーションに代わってMRBが適切なメディアリソースを選択することに加えて、IAMMの使用には、アプリケーションサーバーといずれかのメディアサーバー（セクション5.2.2.1）またはメディアダイアログセッション間のコントロールフレームワークコントロールチャネルの設定が含まれます。アプリケーションサーバーといずれかのメディアサーバーの間（セクション5.2.2.2）。どちらの場合でも、選択されたメディアサーバーのSIP URIは、<response-session-infoの1つ以上の<media-server-address>子要素によって、SIP 200 OK応答で要求元のアプリケーションサーバーに通知されます。 >要素（セクション5.2.6）。
The media resource request information, as defined by the <mediaResourceRequest> element from Section 11, is carried in a SIP INVITE request. The INVITE request will be constructed as it would have been to connect to a Media Server, as defined by the Media Control Channel Framework [RFC6230]. It should be noted that this specification does not exclude the use of an offerless INVITE as defined in RFC 3261 [RFC3261]. Using offerless INVITE messages to an MRB can potentially cause confusion when applying resource selection algorithms, and an MRB, like any other SIP device, can choose to reject with a 4xx response. For an offerless INVITE to be treated appropriately, additional contextual information would need to be provided with the request; this is out of scope for this document. The following additional steps MUST be followed when using the Consumer interface:
セクション11の<mediaResourceRequest>要素で定義されているメディアリソース要求情報は、SIP INVITE要求で伝送されます。メディアコントロールチャネルフレームワーク[RFC6230]で定義されているように、INVITEリクエストは、メディアサーバーへの接続と同じように構築されます。この仕様は、RFC 3261 [RFC3261]で定義されているオファーのないINVITEの使用を除外しないことに注意してください。 MRBにオファーのないINVITEメッセージを使用すると、リソース選択アルゴリズムを適用するときに混乱が生じる可能性があり、MRBは、他のSIPデバイスと同様に、4xx応答で拒否することを選択できます。オファーのないINVITEを適切に処理するには、リクエストに追加のコンテキスト情報を提供する必要があります。これはこのドキュメントの範囲外です。コンシューマーインターフェイスを使用する場合は、次の追加手順に従う必要があります。
o The Consumer client will include a payload in the SIP INVITE request of type 'multipart/mixed' [RFC2046]. One of the parts to be included in the 'multipart/mixed' payload MUST be the 'application/sdp' format, which is constructed as specified in the Media Control Channel Framework [RFC6230].
o コンシューマークライアントは、タイプ 'multipart / mixed' [RFC2046]のSIP INVITEリクエストにペイロードを含めます。 'multipart / mixed'ペイロードに含まれるパーツの1つは、 'application / sdp'形式である必要があります。これは、Media Control Channel Framework [RFC6230]で指定されているように構築されます。
o Another part of the 'multipart/mixed' payload MUST be of type 'application/mrb-consumer+xml', as specified in this document and defined in Section 11. The body part MUST be an XML document without prolog and whose root element is <mediaResourceRequest>.
o 「multipart / mixed」ペイロードの別の部分は、このドキュメントで指定され、セクション11で定義されているように、「application / mrb-consumer + xml」タイプである必要があります。本体部分は、プロローグなしのルート要素であるXMLドキュメントである必要があります。 <mediaResourceRequest>。
o The INVITE request will then be dispatched to the MRB, as defined by [RFC6230].
o 次に、[RFC6230]で定義されているように、INVITE要求がMRBにディスパッチされます。
On receiving a SIP INVITE request containing the multipart/mixed payload as specified previously, the MRB will complete a number of steps to fulfill the request. It will:
MRBは、以前に指定されたマルチパート/混合ペイロードを含むSIP INVITE要求を受信すると、要求を満たすためにいくつかの手順を実行します。そうなる：
o Extract the multipart MIME payload from the SIP INVITE request. It will then use the contextual information provided by the client in the 'application/mrb-consumer+xml' part to determine which Media Server (or Media Servers, if more than one is deemed to be needed) should be selected to service the request.
o SIP INVITE要求からマルチパートMIMEペイロードを抽出します。次に、「application / mrb-consumer + xml」の部分でクライアントから提供されたコンテキスト情報を使用して、要求を処理するために選択する必要があるメディアサーバー（複数ある場合はメディアサーバー）を決定します。
o Extract the 'application/sdp' part from the payload and use it as the body of a new SIP INVITE request for connecting the client to one of the selected Media Servers, as defined in the Media Channel Control Framework [RFC6230]. The policy the MRB follows to pick a specific Media Server out of the Media Servers it selects is implementation specific and out of scope for this document. It is important to configure the SIP elements between the MRB and the Media Server in such a way that the INVITE will not fork. In the case of a failure in reaching the chosen Media Server, the MRB SHOULD proceed to the next one, if available.
o ペイロードから「application / sdp」部分を抽出し、メディアチャネルコントロールフレームワーク[RFC6230]で定義されているように、選択したメディアサーバーの1つにクライアントを接続するための新しいSIP INVITEリクエストの本文として使用します。 MRBが選択するメディアサーバーから特定のメディアサーバーを選択するためにMRBが従うポリシーは、実装固有であり、このドキュメントの範囲外です。 INVITEが分岐しないように、MRBとメディアサーバーの間でSIP要素を構成することが重要です。選択したメディアサーバーへの到達に失敗した場合、MRBは、可能な場合は次のサーバーに進む必要があります（SHOULD）。
If none of the available Media Servers can be reached, the MRB MUST reply with a SIP 503 error message that includes a Retry-After header with a non-zero value. The Application Server MUST NOT attempt to set up a new session before the time that the MRB asked it to wait has passed.
使用可能なメディアサーバーに到達できない場合、MRBは、ゼロ以外の値のRetry-Afterヘッダーを含むSIP 503エラーメッセージで応答する必要があります。アプリケーションサーバーは、MRBが待機するように要求した時間が経過する前に、新しいセッションのセットアップを試みてはなりません。
If at least one Media Server is reachable, the MRB acts as a Back-to-Back User Agent (B2BUA) that extracts the 'application/ mrb-consumer+xml' information from the SIP INVITE request and then sends a corresponding SIP INVITE request to the Media Server it has selected, to negotiate a Control Channel as defined in the Media Channel Control Framework [RFC6230].
少なくとも1つのMedia Serverに到達できる場合、MRBは、SIP INVITEリクエストから「application / mrb-consumer + xml」情報を抽出し、対応するSIP INVITEリクエストを送信するバックツーバックユーザーエージェント（B2BUA）として機能します。メディアチャネルコントロールフレームワーク[RFC6230]で定義されているコントロールチャネルをネゴシエートするために、選択したメディアサーバーに。
In the case of a failure in negotiating the Control Channel with the Media Server, the MRB SHOULD proceed to the next one, if available, as explained above. If none of the available Media Servers can be reached, or the negotiations of the Control Channel with all of them fail, the MRB MUST reply with a SIP 503 error message that includes a Retry-After header with a non-zero value. The Application Server MUST NOT attempt to set up a new session before the time that the MRB asked it to wait has expired.
メディアサーバーとの制御チャネルのネゴシエーションに失敗した場合、MRBは、上記のように、可能な場合は次のチャネルに進む必要があります（SHOULD）。使用可能なメディアサーバーに到達できない場合、またはすべてのサーバーとの制御チャネルのネゴシエーションが失敗した場合、MRBは、ゼロ以外の値のRetry-Afterヘッダーを含むSIP 503エラーメッセージで応答する必要があります。アプリケーションサーバーは、MRBが待機するように要求した時間が経過する前に、新しいセッションのセットアップを試みてはなりません。
Once the MRB receives the SIP response from the selected media resource (i.e., Media Server), it will in turn respond to the requesting client (i.e., Application Server).
MRBが選択されたメディアリソース（つまり、メディアサーバー）からSIP応答を受信すると、要求元のクライアント（つまり、アプリケーションサーバー）に応答します。
The media resource response generated by an MRB to a request, as defined by the <mediaResourceResponse> element from Section 11, MUST be carried in the payload of a SIP 200 OK response to the original SIP INVITE request. The SIP 200 OK response will be constructed as it would have been to connect from a Media Server, as defined by the Media Control Channel Framework [RFC6230]. The following additional steps MUST be followed when using the Consumer interface:
セクション11の<mediaResourceResponse>要素で定義されているように、MRBによって要求に対して生成されたメディアリソース応答は、元のSIP INVITE要求に対するSIP 200 OK応答のペイロードで運ばれる必要があります。メディアコントロールチャネルフレームワーク[RFC6230]で定義されているように、SIP 200 OK応答は、メディアサーバーからの接続と同じように作成されます。コンシューマーインターフェイスを使用する場合は、次の追加手順に従う必要があります。
o Include a payload in the SIP 200 response of type 'multipart/ mixed' as per RFC 2046 [RFC2046]. One of the parts to be included in the 'multipart/mixed' payload MUST be the 'application/sdp' format, which is constructed as specified in the Media Control Channel Framework [RFC6230] and based on the incoming response from the selected media resource.
o RFC 2046 [RFC2046]に従って、タイプ 'multipart / mixed'のSIP 200応答にペイロードを含めます。 'multipart / mixed'ペイロードに含まれるパーツの1つは 'application / sdp'形式でなければなりません。これは、メディアコントロールチャネルフレームワーク[RFC6230]で指定されたとおりに構成され、選択されたメディアリソースからの着信応答に基づいています。 。
o Another part of the 'multipart/mixed' payload MUST be of type 'application/mrb-consumer+xml', as specified in this document and defined in Section 11. Only the <mediaResourceResponse> and its child elements can be included in the payload.
o 「multipart / mixed」ペイロードの別の部分は、このドキュメントで指定され、セクション11で定義されているように、「application / mrb-consumer + xml」タイプである必要があります。ペイロードに含めることができるのは、<mediaResourceResponse>とその子要素のみです。 。
o The SIP 200 response will then be dispatched from the MRB.
o 次に、SIP 200応答がMRBからディスパッチされます。
o A SIP ACK to the 200 response will then be sent back to the MRB.
o 次に、200応答に対するSIP ACKがMRBに返送されます。
Considering that the use of SIP as a transport for Consumer transactions may result in failure, the IAMM relies on a successful INVITE transaction to address the previously discussed sequence (using the 'seq' XML element) increment mechanism. This means that if the INVITE is unsuccessful for any reason, the Application Server MUST use the same 'seq' value as previously used for the next Consumer request that it may want to send to the MRB for the same session.
コンシューマトランザクションのトランスポートとしてSIPを使用すると失敗する可能性があることを考慮して、IAMMは、成功したINVITEトランザクションに依存して、前述のシーケンス（「seq」XML要素を使用）の増分メカニズムに対処します。つまり、何らかの理由でINVITEが失敗した場合、アプリケーションサーバーは、同じセッションでMRBに送信する可能性のある次のコンシューマー要求に以前に使用されたものと同じ「seq」値を使用する必要があります。
An MRB implementation may be programmed to conclude that the requested resources are no longer needed when it receives a SIP BYE from the Application Server or Media Server that concludes the SIP dialog that initiated the request, or when the lease (Section 5.2.3) interval expires.
MRB実装は、要求を開始したSIPダイアログを終了するアプリケーションサーバーまたはメディアサーバーからSIP BYEを受信したとき、またはリース（セクション5.2.3）間隔が終了したときに、要求されたリソースが不要になったと結論付けるようにプログラムできます。期限切れ。
This scenario is identical to the description in the previous section for setting up a Control Framework Control Channel, with the exception that the application/sdp payload conveys content appropriate for setting up the media dialog to the media resource, as per RFC 3261 [RFC3261], instead of setting up a Control Channel.
このシナリオは、RFC 3261 [RFC3261]に従って、アプリケーション/ sdpペイロードがメディアダイアログをメディアリソースに設定するために適切なコンテンツを伝えることを除いて、コントロールフレームワークコントロールチャネルを設定するための前のセクションの説明と同じです。 、コントロールチャネルを設定する代わりに。
The Consumer interface defined in Sections 5.2 and 11 allows a client to request an appropriate media resource based on information included in the request (either an HTTP POST or SIP INVITE message). In the case of success, the response that is returned to the client MUST contain a <response-session-info> element in either the SIP 200 or HTTP 200 response. The success response contains the description of certain resources that have been reserved to a specific Consumer client in a (new or revised) "resource session", which is identified in the <response-session-info>. The resource session is a "lease", in that the reservation is scheduled to expire at a particular time in the future, releasing the resources to be assigned for other uses. The lease may be extended or terminated earlier by future Consumer client requests that identify and reference a specific resource session.
セクション5.2と11で定義されているコンシューマインターフェイスを使用すると、リクエストに含まれる情報（HTTP POSTまたはSIP INVITEメッセージ）に基づいて、クライアントが適切なメディアリソースをリクエストできます。成功した場合、クライアントに返される応答には、SIP 200またはHTTP 200応答のいずれかに<response-session-info>要素が含まれている必要があります。成功応答には、<response-session-info>で識別される（新規または改訂された）「リソースセッション」で特定のコンシューマクライアントに予約されている特定のリソースの説明が含まれています。リソースセッションは「リース」であり、予約は将来の特定の時間に期限切れになるようにスケジュールされ、リソースを解放して他の用途に割り当てます。リースは、特定のリソースセッションを識別および参照する将来のコンシューマクライアント要求によって、早期に延長または終了される場合があります。
Before delving into the details of such a lease mechanism, it is worth clarifying its role within the context of the Consumer interface. As explained in Section 5.1, the knowledge the MRB has of the resources of all the Media Servers it is provisioned to manage is not real-time. How an MRB actually manages such resources is implementation specific -- for example, an implementation may choose to have the MRB keeping track and state of the allocated resources, or simply rely on the Media Servers themselves to provide the information using the Publish interface. Further information may also be inferred by the signaling, in the case where an MRB is in the path of media dialogs.
このようなリースメカニズムの詳細を掘り下げる前に、コンシューマインターフェイスのコンテキスト内での役割を明確にする価値があります。セクション5.1で説明したように、MRBが管理するためにプロビジョニングされているすべてのメディアサーバーのリソースについてMRBが持つ知識はリアルタイムではありません。 MRBがこのようなリソースを実際に管理する方法は実装固有です。たとえば、実装は、割り当てられたリソースの追跡と状態をMRBに保持させるか、または単に発行インターフェースを使用して情報を提供するためにメディアサーバー自体に依存することを選択できます。さらに詳しい情報は、MRBがメディアダイアログのパスにある場合、シグナリングによって推測されます。
The <mediaResourceResponse> element returned from the MRB contains a <response-session-info> element if the request is successful. The <response-session-info> element has zero or more of the following child elements, which provide the appropriate resource session information:
リクエストが成功した場合、MRBから返される<mediaResourceResponse>要素には<response-session-info>要素が含まれます。 <response-session-info>要素には、適切なリソースセッション情報を提供する次の子要素が0個以上含まれます。
o <session-id> is a unique identifier that enables a Consumer client and MRB to correlate future media resource requests related to an initial media resource request. The <session-id> MUST be included in all future related requests (see the <session-id> paragraph later in this section, where constructing a subsequent request is discussed).
o <session-id>は、コンシューマクライアントとMRBが初期メディアリソース要求に関連する将来のメディアリソース要求を関連付けることができるようにする一意の識別子です。 <session-id>は、今後のすべての関連リクエストに含める必要があります（このセクションの後半にある<session-id>の段落を参照してください。後続のリクエストの作成について説明します）。
o <seq> is a numeric value returned to the Consumer client. On issuing any future requests related to the media resource session (as determined by the <session-id> element), the Consumer client MUST increment the value returned in the <seq> element and include it in the request (see the <seq> paragraph later in this section, where constructing a subsequent request is discussed). Its value is a non-negative integer that MUST be limited within the 0..2^31-1 range.
o <seq>は、コンシューマークライアントに返される数値です。 （<session-id>要素によって決定される）メディアリソースセッションに関連する将来の要求を発行するときに、コンシューマークライアントは<seq>要素で返される値をインクリメントし、要求に含める必要があります（<seq>を参照）このセクションの後半の段落で、後続のリクエストの作成について説明します）。その値は負でない整数で、0..2 ^ 31-1の範囲内に制限する必要があります。
o <expires> provides a value indicating the number of seconds that the request for media resources is deemed alive. The Consumer client should issue a refresh of the request, as discussed later in this section, if the expiry is due to fire and the media resources are still required.
o <expires>は、メディアリソースの要求が有効であると見なされる秒数を示す値を提供します。このセクションの後半で説明するように、有効期限が火災によるものであり、メディアリソースが引き続き必要な場合、コンシューマクライアントはリクエストの更新を発行する必要があります。
o <media-server-address> provides information representing an assigned Media Server. More instances of this element may appear should the MRB assign more Media Servers to a Consumer request.
o <media-server-address>は、割り当てられたメディアサーバーを表す情報を提供します。 MRBがコンシューマリクエストに割り当てるメディアサーバーを増やすと、この要素のインスタンスがさらに表示される場合があります。
The <mediaResourceRequest> element is used in subsequent Consumer interface requests if the client wishes to manipulate the session. The Consumer client MUST include the <session-info> element, which enables the receiving MRB to determine an existing media resource allocation session. The <session-info> element has the following child elements, which provide the appropriate resource session information to the MRB:
<mediaResourceRequest>要素は、クライアントがセッションを操作したい場合に、後続のコンシューマーインターフェイス要求で使用されます。コンシューマークライアントは<session-info>要素を含める必要があります。これにより、受信側MRBが既存のメディアリソース割り当てセッションを決定できるようになります。 <session-info>要素には、MRBに適切なリソースセッション情報を提供する次の子要素があります。
o <session-id> is a unique identifier that allows a Consumer client to indicate the appropriate existing media resource session to be manipulated by the MRB for this request. The value was provided by the MRB in the initial request for media resources, as discussed earlier in this section (<session-id> element included as part of the <session-info> element in the initial <mediaResourceResponse>).
o <session-id>は、コンシューマクライアントが、このリクエストに対してMRBによって操作される適切な既存のメディアリソースセッションを示すことを可能にする一意の識別子です。この値は、このセクションで前述したように、メディアリソースの最初のリクエストでMRBによって提供されました（最初の<mediaResourceResponse>の<session-info>要素の一部として含まれる<session-id>要素）。
o <seq> is a numeric value returned to the Consumer client in the initial request for media resources, as discussed earlier in this section (<seq> element included as part of the <session-info> element in the initial <mediaResourceResponse>). On issuing any future requests related to the specific media resource session (as determined by the <session-id> element), the Consumer client MUST increment the value returned in the <seq> element from the initial response (contained in the <mediaResourceResponse>) for every new request. The value of the <seq> element in requests acts as a counter and when used in conjunction with the unique <session-id> allows for unique identification of a request. As anticipated before, the <seq> value is limited to the 0..2^31-1 range: in the unlikely case that the counter increases to reach the highest allowed value, the <seq> value MUST be set to 0. The first numeric value for the <seq> element is not meant to be '1' but SHOULD be generated randomly by the MRB: this is to reduce the chances of a malicious MRB disrupting the session created by this MRB, as explained in Section 12.
o <seq>は、このセクションで前述したように、メディアリソースの最初のリクエストでコンシューマクライアントに返される数値です（<seq>要素は、最初の<mediaResourceResponse>の<session-info>要素の一部として含まれています）。特定のメディアリソースセッション（<session-id>要素で決定される）に関連する将来の要求を発行する際、コンシューマークライアントは、<seq>要素で返される値を初期応答（<mediaResourceResponse>に含まれる）からインクリメントする必要があります。 ）新しいリクエストごとに。リクエストの<seq>要素の値はカウンターとして機能し、一意の<session-id>と組み合わせて使用すると、リクエストの一意の識別が可能になります。以前に予想されたように、<seq>の値は0..2 ^ 31-1の範囲に制限されています。まれに、カウンターが増加して最大許容値に達する場合、<seq>の値は0に設定する必要があります。 <seq>要素の最初の数値は「1」ではありませんが、MRBによってランダムに生成する必要があります。これは、セクション12で説明するように、悪意のあるMRBがこのMRBによって作成されたセッションを中断する可能性を減らすためです。
o <action> provides the operation to be carried out by the MRB on receiving the request:
o <action>は、リクエストの受信時にMRBによって実行される操作を提供します。
* The value of 'update' is a request by the Consumer client to update the existing session on the MRB with alternate media resource requirements. If the requested resource information is identical to the existing MRB session, the MRB will attempt a session refresh. If the information has changed, the MRB will attempt to update the existing session with the new information. If the operation is successful, the 200 status code in the response is returned in the status attribute of the <mediaResourceResponseType> element. If the operation is not successful, a 409 status code in the response is returned in the status attribute of the <mediaResourceResponseType> element.
* 「更新」の値は、代替メディアリソース要件でMRBの既存のセッションを更新するためのコンシューマクライアントによる要求です。要求されたリソース情報が既存のMRBセッションと同一である場合、MRBはセッションの更新を試みます。情報が変更されている場合、MRBは既存のセッションを新しい情報で更新しようとします。操作が成功すると、応答の200ステータスコードが<mediaResourceResponseType>要素のstatus属性で返されます。操作が成功しなかった場合、レスポンスの409ステータスコードが<mediaResourceResponseType>要素のステータス属性に返されます。
* The value of 'remove' is a request by the Consumer client to remove the session on the MRB. This provides a mechanism for Consumer clients to release unwanted resources before they expire. If the operation is successful, a 200 status code in the response is returned in the status attribute of the <mediaResourceResponseType> element. If the operation is not successful, a 410 status code in the response is returned in the status attribute of the <mediaResourceResponseType> element.
* 「remove」の値は、MRBのセッションを削除するためのコンシューマクライアントによる要求です。これにより、コンシューマークライアントが不要なリソースを期限切れになる前に解放するメカニズムが提供されます。操作が成功すると、応答の200ステータスコードが<mediaResourceResponseType>要素のstatus属性で返されます。操作が成功しなかった場合、レスポンスの410ステータスコードが<mediaResourceResponseType>要素のstatus属性で返されます。
Omitting the 'action' attribute means requesting a new set of resources.
'action'属性を省略すると、新しいリソースセットをリクエストすることになります。
When used with HTTP, the <session-info> element MUST be included in an HTTP POST message (as defined in [RFC2616]). When used with SIP, the <session-info> element MUST instead be included in either a SIP INVITE or a SIP re-INVITE (as defined in [RFC3261]), or in a SIP UPDATE (as defined in [RFC3311]) request: in fact, any SIP dialog, be it a new or an existing one, can be exploited to carry leasing information, and as such new SIP INVITE messages can update other leases as well as request a new one.
HTTPと共に使用する場合、<session-info>要素をHTTP POSTメッセージに含める必要があります（[RFC2616]で定義）。 SIPで使用する場合、<session-info>要素は代わりにSIP INVITEまたはSIP re-INVITE（[RFC3261]で定義）またはSIP UPDATE（[RFC3311]で定義）要求に含める必要があります：実際、新しいSIPでも既存のSIPダイアログでも、リース情報を運ぶために利用できます。そのため、新しいSIP INVITEメッセージは、他のリースを更新したり、新しいリースを要求したりできます。
With IAMM, the Application Server or Media Server will eventually send a SIP BYE to end the SIP session, whether it was for a Control Channel or a media dialog. That BYE contains no Consumer interface lease information.
IAMMを使用すると、アプリケーションサーバーまたはメディアサーバーは、最終的にSIP BYEを送信してSIPセッションを終了します。これは、それがコントロールチャネル用であろうとメディアダイアログ用であろうと関係ありません。そのBYEには、コンシューマインターフェイスのリース情報は含まれていません。
This section defines the XML elements for the Consumer interface. The formal XML schema definition for the Consumer interface can be found in Section 11.
このセクションでは、コンシューマインターフェイスのXML要素を定義します。 Consumerインターフェースの正式なXMLスキーマ定義は、セクション11にあります。
The root element is <mrbconsumer>. All other XML elements (requests, responses) are contained within it. The MRB Consumer interface request element is detailed in Section 5.2.5.1. The MRB Consumer interface response element is detailed in Section 5.2.6.1.
ルート要素は<mrbconsumer>です。他のすべてのXML要素（要求、応答）は、その中に含まれています。 MRBコンシューマインターフェースリクエストエレメントの詳細は、セクション5.2.5.1を参照してください。 MRBコンシューマインターフェースの応答要素の詳細は、セクション5.2.6.1を参照してください。
The <mrbconsumer> element has the following attributes:
<mrbconsumer>要素には次の属性があります。
version: a token specifying the mrb-consumer package version. The value is fixed as '1.0' for this version of the package. The attribute MUST be present.
version：mrb-consumerパッケージのバージョンを指定するトークン。このバージョンのパッケージでは、値は「1.0」に固定されています。属性が存在しなければなりません。
The <mrbconsumer> element may have zero or more children of one of the following child element types:
<mrbconsumer>要素には、次のいずれかの子要素タイプのゼロ以上の子が含まれる場合があります。
<mediaResourceRequest> for sending a Consumer request. See Section 5.2.5.1.
<mediaResourceRequest>は、コンシューマリクエストを送信します。セクション5.2.5.1を参照してください。
<mediaResourceResponse> for sending a Consumer response. See Section 5.2.6.1.
<mediaResourceResponse>：コンシューマ応答を送信します。セクション5.2.6.1を参照してください。
This section provides the element definitions for use in Consumer interface requests. The requests are carried in the <mediaResourceRequest> element.
このセクションでは、コンシューマインターフェイスリクエストで使用する要素の定義を示します。リクエストは<mediaResourceRequest>要素で伝達されます。
The <mediaResourceRequest> element provides information for clients wishing to query an external MRB entity. The <mediaResourceRequest> element has a single mandatory attribute, 'id': this attribute contains a random identifier, generated by the client, that will be included in the response in order to map it to a specific request. The <mediaResourceRequest> element has <generalInfo>, <ivrInfo>, and <mixerInfo> as child elements. These three elements are used to describe the requirements of a client requesting a Media Server and are covered in Sections 5.2.5.1.1, 5.2.5.1.2, and 5.2.5.1.3, respectively.
<mediaResourceRequest>要素は、外部MRBエンティティを照会したいクライアントに情報を提供します。 <mediaResourceRequest>要素には、単一の必須属性「id」があります。この属性には、特定の要求にマップするために応答に含まれる、クライアントによって生成されたランダムな識別子が含まれます。 <mediaResourceRequest>要素には、子要素として<generalInfo>、<ivrInfo>、および<mixerInfo>があります。これらの3つの要素は、メディアサーバーを要求するクライアントの要件を説明するために使用され、それぞれセクション5.2.5.1.1、5.2.5.1.2、および5.2.5.1.3で説明されています。
The <generalInfo> element provides general Consumer request information that is neither IVR specific nor mixer specific. This includes session information that can be used for subsequent requests as part of the leasing mechanism described in Section 5.2.3. The following sub-sections describe the <session-info> and <packages> elements, as used by the <generalInfo> element.
<generalInfo>要素は、IVR固有でもミキサー固有でもない一般的なコンシューマー要求情報を提供します。これには、セクション5.2.3で説明されているリースメカニズムの一部として後続のリクエストに使用できるセッション情報が含まれます。次のサブセクションでは、<generalInfo>要素で使用される<session-info>および<packages>要素について説明します。
The <session-info> element is included in Consumer requests when an update is being made to an existing media resource session. The ability to change and remove an existing media resource session is described in more detail in Section 5.2.3. The element MAY be present.
<session-info>要素は、既存のメディアリソースセッションが更新されるときに、コンシューマーリクエストに含まれます。既存のメディアリソースセッションを変更および削除する機能については、セクション5.2.3で詳しく説明します。要素が存在してもかまいません。
The <session-info> element has no attributes.
<session-info>要素には属性はありません。
The <session-info> element has zero or more of the following child elements:
<session-info>要素には、次の子要素が0個以上含まれています。
<session-id>: A unique identifier that explicitly references an existing media resource session on the MRB. The identifier is included to update the existing session and is described in more detail in Section 5.2.3.
<session-id>：MRBの既存のメディアリソースセッションを明示的に参照する一意の識別子。識別子は既存のセッションを更新するために含まれており、セクション5.2.3でより詳細に説明されています。
<seq>: Used in association with the <session-id> element in a subsequent request to update an existing media resource session on an MRB. The <seq> number is incremented from its original value returned in response to the initial request for media resources. Its value is a non-negative integer that MUST be limited within the 0..2^31-1 range. In the unlikely case that the counter increases to reach the highest allowed value, the <seq> value MUST be set to 0. More information about its use is provided in Section 5.2.3.
<seq>：MRBの既存のメディアリソースセッションを更新する後続のリクエストで<session-id>要素と関連付けて使用されます。 <seq>番号は、メディアリソースの最初の要求に応答して返された元の値から増分されます。その値は負でない整数で、0..2 ^ 31-1の範囲内に制限する必要があります。万一、カウンターが増加して最大許容値に到達する場合、<seq>値を0に設定する必要があります。その使用方法の詳細については、セクション5.2.3を参照してください。
<action>: Provides the operation that should be carried out on an existing media resource session on an MRB:
<action>：MRBの既存のメディアリソースセッションで実行する必要がある操作を提供します。
* The value of 'update' instructs the MRB to attempt to update the existing media resource session with the information contained in the <ivrInfo> and <mixerInfo> elements.
* 'update'の値は、<ivrInfo>および<mixerInfo>要素に含まれる情報で既存のメディアリソースセッションを更新するようにMRBに指示します。
* The value of 'remove' instructs the MRB to attempt to remove the existing media resource session. More information on its use is provided in Section 5.2.3.
* 'remove'の値は、既存のメディアリソースセッションを削除するようにMRBに指示します。使用方法の詳細については、セクション5.2.3を参照してください。
The <packages> element provides a list of Media Control Channel Framework compliant packages that are required by the Consumer client. The element MAY be present.
<packages>要素は、コンシューマクライアントに必要なMedia Control Channel Framework準拠のパッケージのリストを提供します。要素が存在してもかまいません。
The <packages> element has no attributes.
<packages>要素には属性はありません。
The <packages> element has a single child element:
<packages>要素には、単一の子要素があります。
<package>: Contains a string representing the Media Control Channel Framework package required by the Consumer client. The <package> element can appear multiple times. A valid value is a Control Package name compliant with Section 13.1.1 of [RFC6230].
<package>：コンシューマークライアントに必要なMedia Control Channel Frameworkパッケージを表す文字列が含まれています。 <package>要素は複数回出現できます。有効な値は、[RFC6230]のセクション13.1.1に準拠するコントロールパッケージ名です。
The <ivrInfo> element provides information for general Consumer request information that is IVR specific. The following sub-sections describe the elements of the <ivrInfo> element: <ivr-sessions>, <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>, <encryption>, <application-data>, <max-prepared-duration>, and <file-transfer-modes>.
<ivrInfo>要素は、IVR固有の一般的なコンシューマーリクエスト情報の情報を提供します。次のサブセクションでは、<ivrInfo>要素の要素について説明します：<ivr-sessions>、<file-formats>、<dtmf>、<tones>、<asr-tts>、<vxml>、<location>、< encryption>、<application-data>、<max-prepared-duration>、および<file-transfer-modes>。
The <ivr-sessions> element indicates the number of IVR sessions that a Consumer client requires from a media resource. The element MAY be present.
<ivr-sessions>要素は、コンシューマクライアントがメディアリソースから要求するIVRセッションの数を示します。要素が存在してもかまいません。
The <ivr-sessions> element has no attributes.
<ivr-sessions>要素には属性はありません。
The <ivr-sessions> element has a single child element:
<ivr-sessions>要素には、単一の子要素があります。
<rtp-codec>: Describes a required codec and the number of sessions using that codec. The <rtp-codec> element has one attribute. The value of the attribute, 'name', is a media type (which can include parameters per [RFC6381]). The <rtp-codec> element has two child elements. The child element <decoding> contains the number of RTP sessions required for decoding using the specified codec, and the child element <encoding> contains the number of RTP sessions required for encoding using the specified codec.
<rtp-codec>：必要なコーデックとそのコーデックを使用するセッションの数について説明します。 <rtp-codec>要素には1つの属性があります。属性 'name'の値はメディアタイプです（[RFC6381]のパラメータを含めることができます）。 <rtp-codec>要素には2つの子要素があります。子要素<decoding>には、指定されたコーデックを使用したデコードに必要なRTPセッションの数が含まれ、子要素<encoding>には、指定されたコーデックを使用したエンコードに必要なRTPセッションの数が含まれます。
The <file-formats> element provides a list of file formats required for the purpose of playing media. It should be noted that this element describes media types and might better have been named "media-formats", but due to existing implementations the name "file-formats" is being used. The element MAY be present.
<file-formats>要素は、メディアの再生に必要なファイル形式のリストを提供します。この要素はメディアタイプを記述し、「media-formats」と名付けられた方がよいかもしれませんが、既存の実装により、「file-formats」という名前が使用されていることに注意してください。要素が存在してもかまいません。
The <file-formats> element has no attributes.
<file-formats>要素には属性はありません。
The <file-formats> element has a single child element:
<file-formats>要素には単一の子要素があります。
<required-format>: Has a single attribute, 'name', which provides the type of file format that is required. A valid value is a media type that, depending on its definition, can include additional parameters (e.g., [RFC6381]). The <required-format> element then has a further child element, <required-file-package>. The <required-file-package> element has a single attribute, 'required-file-package-name', which contains the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the file format support applies.
<required-format>：必要なファイル形式のタイプを提供する単一の属性 'name'があります。有効な値はメディアタイプであり、その定義に応じて、追加のパラメーターを含めることができます（[RFC6381]など）。 <required-format>要素には、さらに<required-file-package>という子要素があります。 <required-file-package>要素には、「required-file-package-name」という単一の属性があり、[RFC6230]のセクション13.1.1に準拠するMedia Control Channel Frameworkパッケージの名前が含まれています。ファイル形式のサポートが適用されます。
The <dtmf> element specifies the required methods to detect DTMF tones and to generate them. The element MAY be present.
<dtmf>要素は、DTMFトーンを検出して生成するために必要なメソッドを指定します。要素が存在してもかまいません。
The <dtmf> element has no attributes.
<dtmf>要素には属性はありません。
The <dtmf> element has zero or more of the following child elements:
<dtmf>要素には、次の子要素が0個以上含まれています。
<detect>: Indicates the required support for DTMF detection. The <detect> element has no attributes. The <detect> element has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF required and is a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (detecting tones as signals from the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<detect>：DTMF検出に必要なサポートを示します。 <detect>要素には属性はありません。 <detect>要素には、さらに<dtmf-type>という子要素があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 'name'属性は、必要なDTMFのタイプを提供し、 'RFC4733' [RFC4733]または 'Media'（オーディオストリームからの信号としてトーンを検出）を含む、大文字と小文字を区別しない文字列です。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
<generate>: Indicates the required support for DTMF generation. The <generate> element has no attributes. The <generate> element has a single child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF required and is a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (generating tones as signals in the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<generate>：DTMF生成に必要なサポートを示します。 <generate>要素には属性はありません。 <generate>要素には、単一の子要素<dtmf-type>があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 'name'属性は、必要なDTMFのタイプを提供し、 'RFC4733' [RFC4733]または 'Media'（オーディオストリームの信号としてトーンを生成する）を含む、大文字と小文字を区別しない文字列です。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
<passthrough>: Indicates the required support for passing DTMF through without re-encoding. The <passthrough> element has no attributes. The <passthrough> element then has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF required and is a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<passthrough>：再エンコードせずにDTMFを渡すために必要なサポートを示します。 <passthrough>要素には属性はありません。 <passthrough>要素には、さらに<dtmf-type>という子要素があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 'name'属性は、必要なDTMFのタイプを提供し、 'RFC4733' [RFC4733]または 'Media'（オーディオストリームを介して信号としてトーンを渡す）を含む、大文字と小文字を区別しない文字列です。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
The <tones> element provides requested tones that a Media Server must support for IVR. In particular, the request refers to both support for country codes (ISO 3166-1 [ISO.3166-1]) and requested functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present.
<tones>要素は、Media ServerがIVRをサポートする必要がある要求されたトーンを提供します。特に、要求は国コードのサポート（ISO 3166-1 [ISO.3166-1]）と要求された機能（ITU-T勧告Q.1950 [ITU-T.Q.1950]）の両方を参照しています。要素が存在してもかまいません。
The <tones> element has no attributes.
<tones>要素には属性はありません。
The <tones> element has zero or more of the following child elements:
<tones>要素には、0個以上の次の子要素があります。
<country-codes>: Describes the requested country codes in relation to tones. The <country-codes> element has no attributes. The <country-codes> element has one child element. The child element, <country-code>, requests a specific country code, compliant with the ISO 3166-1 [ISO.3166-1] specification. The <country-code> element has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], in which the tones from the specified country code are requested.
<country-codes>：トーンに関連して要求された国コードを説明します。 <country-codes>要素には属性はありません。 <country-codes>要素には1つの子要素があります。子要素<country-code>は、ISO 3166-1 [ISO.3166-1]仕様に準拠する特定の国コードを要求します。 <country-code>要素には、単一の属性「package」があります。属性「package」は、[RFC6230]のセクション13.1.1に準拠したMedia Control Channel Frameworkパッケージの名前を提供します。このパッケージでは、指定された国コードからのトーンが要求されます。
<h248-codes>: Describes the requested H.248 codes in relation to tones. The <h248-codes> element has no attributes. The <h248-codes> element has one child element. The child element, <h248-code>, requests a specific H.248 code, compliant with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification. The codes can be either specific (e.g., cg/dt to only report the Dial Tone from the Call Progress Tones package) or generic (e.g., cg/* to report all the tones from the Call Progress Tones package), using wildcards. The <h248-code> element has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], in which the specified codes are requested.
<h248-codes>：トーンに関連して要求されたH.248コードを記述します。 <h248-codes>要素には属性はありません。 <h248-codes>要素には1つの子要素があります。子要素<h248-code>は、ITU-T勧告Q.1950 [ITU-T.Q.1950]仕様に準拠した特定のH.248コードを要求します。コードは、ワイルドカードを使用して、特定のもの（たとえば、cg / dtでCall Progress Tonesパッケージからのダイヤルトーンのみを報告する）または一般的（たとえば、cg / *でCall Progress Tonesパッケージからすべてのトーンを報告する）のいずれかになります。 <h248-code>要素には、単一の属性「package」があります。属性 'package'は、[RFC6230]のセクション13.1.1に準拠したMedia Control Channel Frameworkパッケージの名前を提供し、指定されたコードが要求されます。
The <asr-tts> element requests information about the support for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) functionality in a Media Server. The functionality is requested by referring to the supported languages (using ISO 639-1 [ISO.639.2002] codes) in relation to both ASR and TTS. The <asr-tts> element has no attributes. The <asr-tts> element has zero or more of the following child elements:
<asr-tts>要素は、メディアサーバーでの自動音声認識（ASR）および音声合成（TTS）機能のサポートに関する情報を要求します。この機能は、ASRとTTSの両方に関して、サポートされている言語（ISO 639-1 [ISO.639.2002]コードを使用）を参照することによって要求されます。 <asr-tts>要素には属性はありません。 <asr-tts>要素には、0個以上の次の子要素があります。
<asr-support>: Describes the available languages for ASR. The <asr-support> element has no attributes. The <asr-support> element has one child element. The child element, <language>, requests that the Media Server supports ASR for a specific language. The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1 [ISO.639.2002] code of the supported language.
<asr-support>：ASRで使用可能な言語について説明します。 <asr-support>要素には属性はありません。 <asr-support>要素には1つの子要素があります。子要素<language>は、メディアサーバーが特定の言語のASRをサポートすることを要求します。 <language>要素には、単一の属性「xml：lang」があります。属性「xml：lang」には、サポートされている言語のISO 639-1 [ISO.639.2002]コードが含まれています。
<tts-support>: Describes the available languages for TTS. The <tts-support> element has no attributes. The <tts-support> element has one child element. The child element, <language>, requests that the Media Server supports TTS for a specific language. The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang' contains the ISO 639-1 [ISO.639.2002] code of the supported language.
<tts-support>：TTSで使用可能な言語について説明します。 <tts-support>要素には属性はありません。 <tts-support>要素には1つの子要素があります。子要素<language>は、メディアサーバーが特定の言語のTTSをサポートすることを要求します。 <language>要素には、単一の属性「xml：lang」があります。属性「xml：lang」には、サポートされている言語のISO 639-1 [ISO.639.2002]コードが含まれています。
The <vxml> element specifies if the Consumer client requires VoiceXML and, if so, which protocols are supported (e.g., via the control framework, RFC 4240 [RFC4240], or RFC 5552 [RFC5552]). The element MAY be present.
<vxml>要素は、コンシューマークライアントがVoiceXMLを必要とするかどうかを指定し、必要な場合は、どのプロトコルがサポートされているか（たとえば、制御フレームワーク、RFC 4240 [RFC4240]、またはRFC 5552 [RFC5552]を介して）。要素が存在してもかまいません。
The <vxml> element has a single child element:
<vxml>要素には単一の子要素があります。
<vxml-mode>: Has two attributes: 'package' and 'require'. The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the VXML support applies. The 'require' attribute specifies the type of VXML support required by the Consumer client (e.g., RFC 5552 [RFC5552], RFC 4240 [RFC4240], or IVR Package [RFC6231]), and valid values are case-insensitive RFC references (e.g., "rfc6231" to specify that the client requests support for VoiceXML as provided by the IVR Package [RFC6231]).
<vxml-mode>：「package」と「require」の2つの属性があります。 「package」属性は、VXMLサポートが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。 'require'属性は、コンシューマクライアントに必要なVXMLサポートのタイプ（たとえば、RFC 5552 [RFC5552]、RFC 4240 [RFC4240]、またはIVRパッケージ[RFC6231]）を指定し、有効な値は大文字と小文字を区別しないRFC参照（たとえば、 "rfc6231"。クライアントがIVRパッケージ[RFC6231]で提供されるVoiceXMLのサポートを要求することを指定します。
The presence of at least one <vxml> child element would indicate that the Consumer client requires VXML support as specified by the child element itself. An empty <vxml> element would otherwise indicate that the Consumer client does not require VXML support.
少なくとも1つの<vxml>子要素の存在は、コンシューマクライアントが子要素自体で指定されたVXMLサポートを必要とすることを示します。それ以外の場合、空の<vxml>要素は、コンシューマクライアントがVXMLサポートを必要としないことを示します。
The <location> element requests a civic location for an IVR Media Server. The request makes use of the Civic Address Schema standardized in RFC 5139 [RFC5139]. The element MAY be present. More precisely, this section is entirely optional and is implementation specific in its level of population.
<location>要素は、IVR Media Serverの都市の場所を要求します。このリクエストは、RFC 5139 [RFC5139]で標準化されたCivic Address Schemaを利用します。要素が存在してもかまいません。より正確には、このセクションは完全にオプションであり、その人口レベルでの実装固有です。
The <location> element has no attributes.
<location>要素には属性はありません。
The <location> element has a single child element:
<location>要素には単一の子要素があります：
<civicAddress>: Describes the civic address location of the requested Media Server, whose representation refers to Section 4 of RFC 5139 [RFC5139].
<civicAddress>：要求されたメディアサーバーの都市アドレスの場所を説明します。その表現はRFC 5139 [RFC5139]のセクション4を参照します。
The <encryption> element allows a Consumer client to request support for encrypting RTP media streams using RFC 3711 [RFC3711]. The element MAY be present. If the element is present, then the Media Server supports DTLS-SRTP [RFC5763].
<encryption>要素を使用すると、コンシューマークライアントはRFC 3711 [RFC3711]を使用したRTPメディアストリームの暗号化のサポートを要求できます。要素が存在してもかまいません。要素が存在する場合、メディアサーバーはDTLS-SRTP [RFC5763]をサポートします。
The <encryption> element has no attributes.
<encryption>要素には属性はありません。
The <encryption> element has no child elements.
<encryption>要素には子要素はありません。
The <application-data> element provides an arbitrary string of characters as IVR application-level data. This data is meant to only have meaning at the application-level logic and as such is not otherwise restricted by this specification. The set of allowed characters is the same as those in XML (viz., tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646.2012] (see also Section 2.2 of <http://www.w3.org/TR/xml/>)). The element MAY be present.
<application-data>要素は、IVRアプリケーションレベルのデータとして任意の文字列を提供します。このデータは、アプリケーションレベルのロジックでのみ意味を持つことを意図しているため、この仕様による制限はありません。許可される文字のセットは、XMLの文字と同じです（つまり、タブ、キャリッジリターン、ラインフィード、UnicodeおよびISO / IEC 10646 [ISO.10646.2012]の有効な文字）（<http：/のセクション2.2も参照） /www.w3.org/TR/xml/>））。要素が存在してもかまいません。
The <application-data> element has no attributes.
<application-data>要素には属性はありません。
The <application-data> element has no child elements.
<application-data>要素には子要素はありません。
The <max-prepared-duration> element indicates the amount of time required by the Consumer client representing media dialog preparation in the system before it is executed. The element MAY be present.
<max-prepared-duration>要素は、実行される前にシステムでメディアダイアログの準備を表すコンシューマークライアントが必要とする時間を示します。要素が存在してもかまいません。
The <max-prepared-duration> element has no attributes.
<max-prepared-duration>要素には属性はありません。
The <max-prepared-duration> element has a single child element:
<max-prepared-duration>要素には単一の子要素があります：
<max-time>: Has a single attribute, 'max-time-seconds', which provides the amount of time in seconds that a media dialog can be in the prepared state. The <max-time> element then has a further child element, <max-time-package>. The <max-time-package> element provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the time period applies.
<max-time>：「max-time-seconds」という単一の属性があり、メディアダイアログが準備された状態になることができる秒数を提供します。 <max-time>要素には、さらに<max-time-package>という子要素があります。 <max-time-package>要素は、期間が適用される[RFC6230]のセクション13.1.1に準拠するMedia Control Channel Frameworkパッケージの名前を提供します。
The <file-transfer-modes> element allows the Consumer client to specify which scheme names are required for file transfer to a Media Server for each Media Control Channel Framework package type. For example, does the Media Server support fetching media resources via HTTP, HTTPS, NFS, etc.? The element MAY be present.
<file-transfer-modes>要素を使用すると、コンシューマークライアントは、メディアコントロールチャネルフレームワークのパッケージタイプごとに、メディアサーバーへのファイル転送に必要なスキーム名を指定できます。たとえば、メディアサーバーは、HTTP、HTTPS、NFSなどを介したメディアリソースのフェッチをサポートしていますか？要素が存在してもかまいません。
The <file-transfer-modes> element has no attributes.
<file-transfer-modes>要素には属性はありません。
The <file-transfer-modes> element has a single child element:
<file-transfer-modes>要素には、単一の子要素があります。
<file-transfer-mode>: Has two attributes: 'name' and 'package'. The 'name' attribute provides the scheme name of the protocol required for fetching resources: valid values are case-insensitive scheme names (e.g., HTTP, HTTPS, NFS, etc.). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the scheme name applies.
<file-transfer-mode>：「name」と「package」の2つの属性があります。 'name'属性は、リソースのフェッチに必要なプロトコルのスキーム名を提供します。有効な値は、大文字と小文字を区別しないスキーム名です（HTTP、HTTPS、NFSなど）。 'package'属性は、スキーム名が適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
The same considerations relating to file transfer and live streaming are explained further in Section 5.1.5.15 and apply here as well.
ファイル転送とライブストリーミングに関連する同じ考慮事項は、セクション5.1.5.15でさらに説明され、ここでも適用されます。
The <mixerInfo> element provides information for general Consumer request information that is mixer specific. The following sub-sections describe the elements of the <mixerInfo> element: <mixers>, <file-formats>, <dtmf>, <tones>, <mixing-modes>, <application-data>, <location>, and <encryption>.
<mixerInfo>要素は、ミキサー固有の一般的なコンシューマーリクエスト情報の情報を提供します。次のサブセクションでは、<mixerInfo>要素の要素について説明します：<mixers>、<file-formats>、<dtmf>、<tones>、<mixing-modes>、<application-data>、<location>、および<暗号化>。
The <mixers> element provides information detailing the required mixed RTP sessions. The element MAY be present.
<mixers>要素は、必要な混合RTPセッションの詳細情報を提供します。要素が存在してもかまいません。
The <mixers> element has no attributes.
<mixers>要素には属性はありません。
The <mixers> element has a single child element:
<mixers>要素には単一の子要素があります。
<mix>: Describes the required mixed RTP sessions. The <mix> element has one attribute. The value of the attribute, 'users', is the number of participants required in the mix. The <mix> element has one child element. The child element, <rtp-codec>, contains the same information relating to RTP sessions as that defined in Section 5.1.5.3. The element MAY be present.
<mix>：必要な混合RTPセッションについて説明します。 <mix>要素には1つの属性があります。属性 'users'の値は、ミックスで必要な参加者の数です。 <mix>要素には1つの子要素があります。子要素<rtp-codec>には、セクション5.1.5.3で定義されたものと同じRTPセッションに関する情報が含まれています。要素が存在してもかまいません。
The <file-formats> element provides a list of file formats required by the Consumer client for the purpose of playing media to a mix. The element MAY be present.
<file-formats>要素は、メディアをミックスして再生する目的でコンシューマークライアントが必要とするファイルフォーマットのリストを提供します。要素が存在してもかまいません。
The <file-formats> element has no attributes.
<file-formats>要素には属性はありません。
The <file-formats> element has a single child element:
<file-formats>要素には単一の子要素があります。
<required-format>: Has a single attribute, 'name', which provides the type of file format supported. A valid value is a media type that, depending on its definition, can include additional parameters (e.g., [RFC6381]). The <required-format> element has a child element, <required-file-package>. The <required-file-package> element contains a single attribute, 'required-file-package-name', which contains the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the file format support applies.
<required-format>：サポートされているファイル形式のタイプを提供する単一の属性 'name'があります。有効な値はメディアタイプであり、その定義に応じて、追加のパラメーターを含めることができます（[RFC6381]など）。 <required-format>要素には、<required-file-package>という子要素があります。 <required-file-package>要素には、「required-file-package-name」という単一の属性が含まれています。これには、[RFC6230]のセクション13.1.1に準拠するMedia Control Channel Frameworkパッケージの名前が含まれ、ファイル形式のサポートが適用されます。
The <dtmf> element specifies the required methods to detect DTMF tones and to generate them in a mix. The element MAY be present.
<dtmf>要素は、DTMFトーンを検出し、それらを混合して生成するために必要なメソッドを指定します。要素が存在してもかまいません。
The <dtmf> element has no attributes.
<dtmf>要素には属性はありません。
The <dtmf> element has zero or more of the following child elements:
<dtmf>要素には、次の子要素が0個以上含まれています。
<detect>: Indicates the required support for DTMF detection. The <detect> element has no attributes. The <detect> element then has a further child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF being used and is a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (detecting tones as signals from the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<detect>：DTMF検出に必要なサポートを示します。 <detect>要素には属性はありません。 <detect>要素には、さらに<dtmf-type>という子要素があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 「name」属性は、使用されるDTMFのタイプを提供し、「RFC4733」[RFC4733]または「Media」（オーディオストリームからの信号としてトーンを検出）を含む、大文字と小文字を区別しない文字列です。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
<generate>: Indicates the required support for DTMF generation. The <generate> element has no attributes. The <generate> element has a single child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF being used and is a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (generating tones as signals in the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<generate>：DTMF生成に必要なサポートを示します。 <generate>要素には属性はありません。 <generate>要素には、単一の子要素<dtmf-type>があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 'name'属性は、使用されるDTMFのタイプを提供し、 'RFC4733' [RFC4733]または 'Media'（オーディオストリームの信号としてトーンを生成する）を含む、大文字と小文字を区別しない文字列です。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
<passthrough>: Indicates the required support for passing DTMF through without re-encoding. The <passthrough> element has no attributes. The <passthrough> element has a single child element, <dtmf-type>. The <dtmf-type> element has two attributes: 'name' and 'package'. The 'name' attribute provides the type of DTMF being used and is a case-insensitive string containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as signals through the audio stream). The 'package' attribute provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the DTMF type applies.
<passthrough>：再エンコードせずにDTMFを渡すために必要なサポートを示します。 <passthrough>要素には属性はありません。 <passthrough>要素には、単一の子要素<dtmf-type>があります。 <dtmf-type>要素には、「name」と「package」の2つの属性があります。 「name」属性は、使用されるDTMFのタイプを提供し、「RFC4733」[RFC4733]または「Media」（オーディオストリームを介して信号としてトーンを渡す）のいずれかを含む、大文字と小文字を区別しない文字列です。 'package'属性は、DTMFタイプが適用される、[RFC6230]のセクション13.1.1に準拠するメディアコントロールチャネルフレームワークパッケージの名前を提供します。
The <tones> element provides requested tones that a Media Server must support for a mix. In particular, the request refers to both support for country codes (ISO 3166-1 [ISO.3166-1]) and requested functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present.
<tones>要素は、メディアサーバーがミックスのためにサポートする必要がある要求されたトーンを提供します。特に、要求は国コードのサポート（ISO 3166-1 [ISO.3166-1]）と要求された機能（ITU-T勧告Q.1950 [ITU-T.Q.1950]）の両方を参照しています。要素が存在してもかまいません。
The <tones> element has no attributes.
<tones>要素には属性はありません。
The <tones> element has zero or more of the following child elements:
<tones>要素には、0個以上の次の子要素があります。
<country-codes>: Describes the requested country codes in relation to tones. The <country-codes> element has no attributes. The <country-codes> element has a single child element. The child element, <country-code>, requests a specific country code, compliant with the ISO 3166-1 [ISO.3166-1] specification. The <country-code> element has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the specified country code are requested.
<country-codes>：トーンに関連して要求された国コードを説明します。 <country-codes>要素には属性はありません。 <country-codes>要素には単一の子要素があります。子要素<country-code>は、ISO 3166-1 [ISO.3166-1]仕様に準拠する特定の国コードを要求します。 <country-code>要素には、単一の属性「package」があります。属性「package」は、指定された国コードからのトーンが要求される、関連するIANAレジストリの仕様（「msc-ivr / 1.0」など）に準拠したMedia Control Channel Frameworkパッケージの名前を提供します。
<h248-codes>: Describes the requested H.248 codes with respect to
tones. The <h248-codes> element has no attributes. The
<h248-codes> element has a single child element. The child
element, <h248-code>, requests a specific H.248 code, compliant
with the ITU-T Recommendation Q.1950 [ITU-T.Q.1950] specification.
The codes can be either specific (e.g., cg/dt to only report the
Dial Tone from the Call Progress Tones package) or generic (e.g.,
cg/* to report all the tones from the Call Progress Tones
package), using wildcards. The <h248-code> element has a single
attribute, 'package'. The attribute 'package' provides the name
of the Media Control Channel Framework package, compliant with
Section 13.1.1 of [RFC6230], in which the specified codes are
requested.
The <mixing-modes> element requests information relating to support for audio and video mixing, more specifically a list of supported algorithms to mix audio and a list of supported video presentation layouts. The element MAY be present.
<mixing-modes>要素は、オーディオとビデオのミキシングのサポートに関する情報、より具体的には、オーディオを混合するためにサポートされているアルゴリズムのリストと、サポートされているビデオプレゼンテーションレイアウトのリストを要求します。要素が存在してもかまいません。
The <mixing-modes> element has no attributes.
<mixing-modes>要素には属性はありません。
The <mixing-modes> element has zero or more of the following child elements:
<mixing-modes>要素には、次の子要素が0個以上含まれています。
<audio-mixing-modes>: Describes the requested algorithms for audio mixing. The <audio-mixing-modes> element has no attributes. The <audio-mixing-modes> element has one child element. The child element, <audio-mixing-mode>, contains a requested mixing algorithm. Valid values for the <audio-mixing-mode> element are algorithm names, e.g., 'nbest' and 'controller' as defined in [RFC6505]. The element has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the algorithm support is requested.
<audio-mixing-modes>：オーディオミキシングに必要なアルゴリズムについて説明します。 <audio-mixing-modes>要素には属性はありません。 <audio-mixing-modes>要素には1つの子要素があります。子要素<audio-mixing-mode>には、要求されたミキシングアルゴリズムが含まれています。 <audio-mixing-mode>要素の有効な値は、[RFC6505]で定義されている「nbest」や「controller」などのアルゴリズム名です。要素には、単一の属性「package」があります。属性「package」は、[RFC6230]のセクション13.1.1に準拠したMedia Control Channel Frameworkパッケージの名前を提供し、アルゴリズムのサポートが要求されます。
<video-mixing-modes>: Describes the requested video presentation layouts for video mixing. The <video-mixing-modes> element has two attributes: 'vas' and 'activespeakermix'. The 'vas' attribute is of type boolean with a value of 'true' indicating that the Consumer client requires automatic Voice Activated Switching. The 'activespeakermix' attribute is of type boolean with a value of 'true' indicating that the Consumer client requires an additional video stream for the loudest speaker participant without its contribution. The <video-mixing-modes> element has one child element. The child element, <video-mixing-mode>, contains the name of a specific video presentation layout. The name may refer to one of the predefined video layouts defined in the XCON conference information data model, or to non-XCON layouts as well, as long as they are appropriately prefixed. The <video-mixing-mode> element has a single attribute, 'package'. The attribute 'package' provides the name of the Media Control Channel Framework package, compliant with Section 13.1.1 of [RFC6230], for which the algorithm support is requested.
<video-mixing-modes>：ビデオミキシングのために要求されたビデオプレゼンテーションレイアウトについて説明します。 <video-mixing-modes>要素には、「vas」と「activespeakermix」の2つの属性があります。 「vas」属性はブール値タイプであり、値は「true」で、コンシューマクライアントが自動音声起動切り替えを必要とすることを示します。 「activespeakermix」属性はブール型であり、値は「true」で、コンシューマクライアントは、最大のスピーカー参加者に対して、その貢献なしに追加のビデオストリームを必要とすることを示します。 <video-mixing-modes>要素には1つの子要素があります。子要素<video-mixing-mode>には、特定のビデオプレゼンテーションレイアウトの名前が含まれています。名前は、適切にプレフィックスが付けられている限り、XCON会議情報データモデルで定義された事前定義されたビデオレイアウトの1つ、または非XCONレイアウトを指す場合があります。 <video-mixing-mode>要素には、単一の属性「package」があります。属性「package」は、[RFC6230]のセクション13.1.1に準拠したMedia Control Channel Frameworkパッケージの名前を提供し、アルゴリズムのサポートが要求されます。
The <application-data> element provides an arbitrary string of characters as mixer application-level data. This data is meant to only have meaning at the application-level logic and as such is not otherwise restricted by this specification. The set of allowed characters is the same as those in XML (viz., tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646.2012] (see also Section 2.2 of <http://www.w3.org/TR/xml/>)). The element MAY be present.
<application-data>要素は、ミキサーアプリケーションレベルのデータとして任意の文字列を提供します。このデータは、アプリケーションレベルのロジックでのみ意味を持つことを意図しているため、この仕様による制限はありません。許可される文字のセットは、XMLの文字と同じです（つまり、タブ、キャリッジリターン、ラインフィード、UnicodeおよびISO / IEC 10646 [ISO.10646.2012]の有効な文字）（<http：/のセクション2.2も参照） /www.w3.org/TR/xml/>））。要素が存在してもかまいません。
The <application-data> element has no attributes.
<application-data>要素には属性はありません。
The <application-data> element has no child elements.
<application-data>要素には子要素はありません。
The <location> element requests a civic location for a mixer Media Server. The request makes use of the Civic Address Schema standardized in RFC 5139 [RFC5139]. The element MAY be present. More precisely, this section is entirely optional, and it's implementation specific to fill it with just the details each implementer deems necessary for any optimization that may be needed.
<location>要素は、ミキサーメディアサーバーの都市の場所を要求します。このリクエストは、RFC 5139 [RFC5139]で標準化されたCivic Address Schemaを利用します。要素が存在してもかまいません。より正確には、このセクションは完全にオプションであり、各実装者が必要とする可能性のある最適化に必要であると見なす詳細のみを記入することは、実装固有です。
The <location> element has no attributes.
<location>要素には属性はありません。
The <location> element has a single child element:
<location>要素には単一の子要素があります：
<civicAddress>: Describes the civic address location of the requested Media Server, whose representation refers to Section 4 of RFC 5139 [RFC5139].
<civicAddress>：要求されたメディアサーバーの都市アドレスの場所を説明します。その表現はRFC 5139 [RFC5139]のセクション4を参照します。
The <encryption> element allows a Consumer client to request support for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. The element MAY be present. If the element is present, then the Media Server supports DTLS-SRTP [RFC5763].
<encryption>要素を使用すると、コンシューマクライアントは、RFC 3711 [RFC3711]を使用して混合RTPメディアストリームを暗号化するためのサポートを要求できます。要素が存在してもかまいません。要素が存在する場合、メディアサーバーはDTLS-SRTP [RFC5763]をサポートします。
The <encryption> element has no attributes.
<encryption>要素には属性はありません。
The <encryption> element has no child elements.
<encryption>要素には子要素はありません。
This section provides the element definitions for use in Consumer interface responses. The responses are carried in the <mediaResourceResponse> element.
このセクションでは、コンシューマインターフェイスの応答で使用する要素の定義を示します。応答は<mediaResourceResponse>要素で伝達されます。
The <mediaResourceResponse> element provides information for clients receiving response information from an external MRB entity.
<mediaResourceResponse>要素は、外部MRBエンティティから応答情報を受信するクライアントに情報を提供します。
The <mediaResourceResponse> element has two mandatory attributes: 'id' and 'status'. The 'id' attribute must contain the same value that the client provided in the 'id' attribute in the <mediaResourceRequest> to which the response is mapped. The 'status' attribute indicates the status code of the operation. The following status codes are defined for 'status':
<mediaResourceResponse>要素には、「id」と「status」の2つの必須属性があります。 「id」属性には、応答がマップされる<mediaResourceRequest>の「id」属性でクライアントが提供したのと同じ値が含まれている必要があります。 'status'属性は、操作のステータスコードを示します。以下のステータスコードが「ステータス」に定義されています。
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 400 | Syntax error |
| | |
| 405 | Wrong sequence number |
| | |
| 408 | Unable to find Resource |
| | |
| 409 | Unable to update Resource |
| | |
| 410 | Unable to remove Resource |
| | |
| 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+
Table 2: <mediaResourceResponse> Status Codes
If a new media resource request made by a client application has been accepted, the MRB MUST reply with a <mediaResourceResponse> with status code 200. The same rule applies whenever a request to update (action='update') or remove (action='remove') an existing transaction can be fulfilled by the MRB.
クライアントアプリケーションによって作成された新しいメディアリソース要求が受け入れられた場合、MRBは、ステータスコード200の<mediaResourceResponse>で応答する必要があります。更新（action = 'update'）または削除（action = 「削除」）既存のトランザクションは、MRBによって実行できます。
A media resource request, nevertheless, may fail for several reasons. In such a case, the status codes defined in Table 2 must be used instead. Specifically, if the MRB fails to handle a request due to a syntax error in the request itself (e.g., incorrect XML, violation of the schema constraints, or invalid values in any of the attributes/ elements), the MRB MUST reply with a <mediaResourceResponse> with status code 400. If a syntactically correct request fails because the request also includes any attribute/element the MRB doesn't understand, the MRB MUST reply with a <mediaResourceResponse> with status code 420. If a syntactically correct request fails because it contains a wrong sequence number, that is, a 'seq' value not consistent with the increment the MRB expects according to Section 5.2.3, the MRB MUST reply with a <mediaResourceResponse> with status code 405. If a syntactically correct request fails because the MRB couldn't find any Media Server able to fulfill the requirements presented by the Application Server in its request, the MRB MUST reply with a <mediaResourceResponse> with status code 408. If a syntactically correct request fails because the MRB couldn't update an existing request according to the new requirements presented by the Application Server in its request, the MRB MUST reply with a <mediaResourceResponse> with status code 409. If a syntactically correct request fails because the MRB couldn't remove an existing request and release the related resources as requested by the Application Server, the MRB MUST reply with a <mediaResourceResponse> with status code 410.
それにもかかわらず、メディアリソース要求はいくつかの理由で失敗する可能性があります。そのような場合は、表2で定義されているステータスコードを代わりに使用する必要があります。特に、リクエスト自体の構文エラー（たとえば、不正なXML、スキーマ制約の違反、または属性/要素の無効な値）が原因でMRBがリクエストを処理できない場合、MRBは< mediaResourceResponse>とステータスコード400。リクエストにMRBが理解できない属性/要素も含まれているために構文的に正しいリクエストが失敗した場合、MRBはステータスコード420の<mediaResourceResponse>で応答する必要があります。間違ったシーケンス番号が含まれている、つまり、セクション5.2.3に従ってMRBが期待する増分と一致しない「seq」値の場合、MRBはステータスコード405の<mediaResourceResponse>で応答する必要があります。構文的に正しいリクエストが失敗した場合MRBは、リクエストでアプリケーションサーバーによって提示された要件を満たすことができるMedia Serverを見つけることができなかったため、ステータスコード408の<mediaResourceResponse>で応答する必要があります。リクエストでアプリケーションサーバーによって提示された新しい要件に従ってMRBが既存のリクエストを更新できなかったため、正しいリクエストは失敗します。MRBは、ステータスコード409の<mediaResourceResponse>で応答する必要があります。MRBが原因で構文的に正しいリクエストが失敗した場合既存のリクエストを削除できず、アプリケーションサーバーからのリクエストに応じて関連リソースを解放できませんでした。MRBは、ステータスコード410の<mediaResourceResponse>で応答する必要があります。
Further details on status codes 409 and 410 are included in Section 5.2.3, where the leasing mechanism, along with its related scenarios, is described in more detail.
ステータスコード409および410の詳細については、セクション5.2.3に記載されています。リースメカニズムは、関連するシナリオとともに、より詳細に説明されています。
The <mediaResourceResponse> element has <response-session-info> as a child element. This element is used to describe the response of a Consumer interface query and is covered in the following sub-section.
<mediaResourceResponse>要素には、子要素として<response-session-info>があります。この要素は、コンシューマインターフェイスクエリの応答を説明するために使用され、次のサブセクションで説明されています。
The <response-session-info> element is included in Consumer responses. This applies to responses to both requests for new resources and requests to update an existing media resource session. The ability to change and remove an existing media resource session is described in more detail in Section 5.2.3. If the request was successful, the <mediaResourceResponse> MUST have one <response-session-info> child, which describes the media resource session addressed by the request. If the request was not successful, the <mediaResourceResponse> MUST NOT have a <response-session-info> child.
<response-session-info>要素は、コンシューマーレスポンスに含まれています。これは、新しいリソースの要求と既存のメディアリソースセッションの更新要求の両方に対する応答に適用されます。既存のメディアリソースセッションを変更および削除する機能については、セクション5.2.3で詳しく説明します。リクエストが成功した場合、<mediaResourceResponse>には、リクエストによってアドレス指定されたメディアリソースセッションを記述する1つの<response-session-info>子が必要です。リクエストが成功しなかった場合、<mediaResourceResponse>に<response-session-info>の子を含めることはできません。
The <response-session-info> element has no attributes.
<response-session-info>要素には属性はありません。
The <response-session-info> element has zero or more of the following child elements:
<response-session-info>要素には、次の子要素が0個以上含まれています。
<session-id>: A unique identifier that explicitly references an existing media resource session on the MRB. The identifier is included to update the existing session and is described in more detail in Section 5.2.3.
<session-id>：MRBの既存のメディアリソースセッションを明示的に参照する一意の識別子。識別子は既存のセッションを更新するために含まれており、セクション5.2.3でより詳細に説明されています。
<seq>: Used in association with the <session-id> element in a subsequent request to update an existing media resource session on an MRB. The <seq> number is incremented from its original value returned in response to the initial request for media resources. More information on its use is provided in Section 5.2.3.
<seq>：MRBの既存のメディアリソースセッションを更新する後続のリクエストで<session-id>要素と関連付けて使用されます。 <seq>番号は、メディアリソースの最初の要求に応答して返された元の値から増分されます。使用方法の詳細については、セクション5.2.3を参照してください。
<expires>: Includes the number of seconds that the media resources are reserved as part of this interaction. If the lease is not refreshed before expiry, the MRB will reclaim the resources and they will no longer be guaranteed. It is RECOMMENDED that a minimum value of 300 seconds be used for the value of the 'expires' attribute. It is also RECOMMENDED that a Consumer client refresh the lease at an interval that is not too close to the expiry time. A value of 80% of the timeout period could be used. For example, if the timeout period is 300 seconds, the Consumer client would refresh the transaction at 240 seconds. More information on its use is provided in Section 5.2.3.
<expires>：メディアリソースがこの対話の一部として予約される秒数が含まれます。リースが期限切れになる前に更新されない場合、MRBはリソースを再利用し、それらは保証されなくなります。 「expires」属性の値には、300秒の最小値を使用することをお勧めします。また、コンシューマクライアントは、有効期限に近すぎない間隔でリースを更新することをお勧めします。タイムアウト期間の80％の値を使用できます。たとえば、タイムアウト期間が300秒の場合、コンシューマクライアントは240秒でトランザクションを更新します。使用方法の詳細については、セクション5.2.3を参照してください。
<media-server-address>: Provides information to reach the Media Server handling the requested media resource. One or more instances of these elements may appear. The <media-server-address> element has a single attribute named 'uri', which supplies a SIP URI that reaches the specified Media Server. It also has three optional elements: <connection-id>, <ivr-sessions>, and <mixers>. The <ivr-sessions> and <mixers> elements are defined in Sections 5.2.5.1.2.1 and 5.2.5.1.3.1, respectively, and have the same meaning but are applied to individual Media Server instances as a subset of the overall resources reported in the <connection-id> element. If multiple Media Servers are assigned in an IAMM operation, exactly one <media-server-address> element, more specifically the Media Server that provided the media dialog or CFW response, will have a <connection-id> element. Additional information relating to the use of the <connection-id> element for media dialogs is included in Section 6.
<media-server-address>：要求されたメディアリソースを処理するメディアサーバーに到達するための情報を提供します。これらの要素の1つ以上のインスタンスが表示される場合があります。 <media-server-address>要素には、「uri」という名前の単一の属性があり、指定されたメディアサーバーに到達するSIP URIを提供します。また、<connection-id>、<ivr-sessions>、および<mixers>の3つのオプション要素もあります。 <ivr-sessions>および<mixers>要素はそれぞれセクション5.2.5.1.2.1および5.2.5.1.3.1で定義されており、同じ意味を持っていますが、報告された全体的なリソースのサブセットとして個々のMedia Serverインスタンスに適用されます<connection-id>要素内。 IAMM操作で複数のメディアサーバーが割り当てられている場合、1つの<media-server-address>要素、より具体的には、メディアダイアログまたはCFW応答を提供したメディアサーバーに<connection-id>要素があります。メディアダイアログでの<connection-id>要素の使用に関する追加情報は、セクション6に含まれています。
An entity acting as an In-line MRB can act in one of two roles for a request, as introduced in Section 4.2: the In-line Unaware MRB Mode (IUMM) of operation and the In-line Aware MRB Mode (IAMM) of operation. This section further describes IUMM.
インラインMRBとして機能するエンティティは、セクション4.2で紹介されているように、要求の2つの役割の1つで機能できます。操作のインライン非認識MRBモード（IUMM）と、インラインMRBモード（IAMM）の操作操作。このセクションでは、IUMMについてさらに説明します。
It should be noted that the introduction of an MRB entity into the network, as specified in this document, requires interfaces to be implemented by those requesting Media Server resources (for example, an Application Server). This applies when using the Consumer interface as discussed in Sections 5.2.1 (Query mode) and 5.2.2 (IAMM). An MRB entity can also act in a client-unaware mode when deployed into the network. This allows any SIP-compliant client entity, as defined by RFC 3261 [RFC3261] and its extensions, to send requests to an MRB that in turn will select an appropriate Media Server based on knowledge of Media Server resources it currently has available transparently to the client entity. Using an MRB in this mode allows for easy migration of current applications and services that are unaware of the MRB concept and would simply require a configuration change resulting in the MRB being set as a SIP outbound proxy for clients requiring media services.
このドキュメントで指定されているように、ネットワークにMRBエンティティを導入するには、メディアサーバーリソース（アプリケーションサーバーなど）を要求するユーザーがインターフェイスを実装する必要があることに注意してください。これは、セクション5.2.1（クエリモード）および5.2.2（IAMM）で説明したコンシューマーインターフェイスを使用する場合に適用されます。 MRBエンティティは、ネットワークに配置されたときにクライアント非認識モードで動作することもできます。これにより、RFC 3261 [RFC3261]とその拡張で定義されているSIP準拠のクライアントエンティティがMRBに要求を送信し、MRBが現在透過的に使用できるメディアサーバーリソースの知識に基づいて適切なメディアサーバーを選択することができます。クライアントエンティティ。このモードでMRBを使用すると、MRBの概念を認識していない現在のアプリケーションとサービスを簡単に移行でき、構成の変更が必要になるだけなので、MRBはメディアサービスを必要とするクライアントのSIPアウトバウンドプロキシとして設定されます。
With IUMM, the MRB may conclude that an assigned media resource is no longer needed when it receives a SIP BYE from the Application Server or Media Server that ends the SIP dialog that initiated the request.
IUMMを使用すると、MRBは、要求を開始したSIPダイアログを終了するアプリケーションサーバーまたはメディアサーバーからSIP BYEを受信すると、割り当てられたメディアリソースは不要であると結論付けることができます。
As with IAMM, in IUMM the SIP INVITE from the Application Server could convey the application/sdp payload to either set up a media dialog or a Control Framework Control Channel. In either case, in order to permit the Application Server to associate a media dialog with a Control Channel to the same Media Server, using the procedures of [RFC6230] Section 6, the MRB should be acting as a SIP proxy (and not a B2BUA). This allows the SIP URI of the targeted Media Server to be transparently passed back to the Application Server in the SIP response, resulting in a direct SIP dialog between the Application Server and the Media Server.
IAMMと同様に、IUMMでは、アプリケーションサーバーからのSIP INVITEは、アプリケーション/ sdpペイロードを伝達して、メディアダイアログまたはコントロールフレームワークコントロールチャネルをセットアップできます。どちらの場合でも、[RFC6230]セクション6の手順を使用して、アプリケーションサーバーがメディアダイアログをコントロールチャネルと同じメディアサーバーに関連付けることを許可するには、MRBがSIPプロキシとして機能している必要があります（B2BUAではない） ）。これにより、対象のメディアサーバーのSIP URIをSIP応答でアプリケーションサーバーに透過的に戻すことができ、アプリケーションサーバーとメディアサーバー間の直接のSIPダイアログが生成されます。
While IUMM has the least impact on legacy Application Servers, it also provides the least versatility. See Section 8.
IUMMはレガシーアプリケーションサーバーへの影響が最小ですが、汎用性も最も低くなります。セクション8を参照してください。
An MRB entity can act as a SIP Back-to-Back User Agent (B2BUA) or a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When an MRB acts as a B2BUA, issues can arise when using Media Control Channel packages such as the IVR [RFC6231] and mixer [RFC6505] packages. Specifically, the framework attribute 'connectionid' as provided in
MRBエンティティは、RFC 3261 [RFC3261]で定義されているように、SIPバックツーバックユーザーエージェント（B2BUA）またはSIPプロキシサーバーとして機能できます。 MRBがB2BUAとして機能する場合、IVR [RFC6231]やミキサー[RFC6505]パッケージなどのメディアコントロールチャネルパッケージを使用すると問題が発生する可能性があります。具体的には、以下で提供されるフレームワーク属性「connectionid」
Appendix A ("Common Package Components") of [RFC6230] uses a concatenation of the SIP dialog identifiers to be used for referencing SIP dialogs within the Media Control Channel. When a request traverses an MRB acting as a B2BUA, the SIP dialog identifiers change, and so the 'connectionid' cannot be used as intended due to this change. For this reason, when an MRB wishes to act as a SIP B2BUA when handling a request from an Application Server to set up a media dialog to a Media Server, it MUST include the optional <connection-id> element in a Consumer interface response with a value that provides the equivalent for the 'connectionid' ('Local Dialog Tag' + 'Remote Dialog Tag') for the far side of the B2BUA. If present, this value MUST be used as the value for the 'connectionid' in packages where the Common Package Components are used. The <connection-id> element MUST NOT be included in an HTTP Consumer interface response.
[RFC6230]の付録A（「共通パッケージコンポーネント」）は、メディアコントロールチャネル内のSIPダイアログを参照するために使用されるSIPダイアログ識別子の連結を使用します。リクエストがB2BUAとして機能するMRBを通過すると、SIPダイアログ識別子が変更されるため、この変更により「connectionid」を意図したとおりに使用できません。このため、MRBがアプリケーションサーバーからメディアサーバーへのメディアダイアログを設定する要求を処理するときにSIP B2BUAとして機能する場合は、オプションの<connection-id>要素をコンシューマーインターフェイスの応答に含める必要があります。 B2BUAの反対側の「connectionid」（「ローカルダイアログタグ」+「リモートダイアログタグ」）と同等の値を提供する値。存在する場合、この値は、共通パッケージコンポーネントが使用されるパッケージの「connectionid」の値として使用する必要があります。 <connection-id>要素は、HTTPコンシューマインターフェースの応答に含まれていてはなりません（MUST NOT）。
It is important to point out that although more Media Server instances may be returned in a Consumer response (i.e., the MRB has assigned more than one Media Server to a Consumer request to fulfill the Application Server requirements), in IAMM the MRB will only act as a B2BUA with a single Media Server. In this case, exactly one <media-server-address> element, describing the media dialog or CFW response, will have a <connection-id> element that will not be included in any additional <media-server-address> elements.
より多くのMedia Serverインスタンスがコンシューマーレスポンスで返される可能性がある（つまり、MRBが複数のMedia Serverをコンシューマーリクエストに割り当てて、アプリケーションサーバーの要件を満たす）場合でも、IAMMではMRBのみが機能することに注意することが重要です単一のMedia Serverを持つB2BUAとして。この場合、メディアダイアログまたはCFW応答を記述する1つの<media-server-address>要素には、追加の<media-server-address>要素に含まれない<connection-id>要素が含まれます。
An MRB implementation may operate multimodally with a collection of Application Server clients all sharing the same pool of media resources. That is, an MRB may be simultaneously operating in Query mode, IAMM, and IUMM. It knows in which mode to act on any particular request from a client, depending on the context of the request:
MRB実装は、すべて同じメディアリソースプールを共有するApplication Serverクライアントのコレクションでマルチモーダルに動作する場合があります。つまり、MRBはクエリモード、IAMM、およびIUMMで同時に動作している可能性があります。リクエストのコンテキストに応じて、クライアントからの特定のリクエストにどのモードで対処するかを認識します。
o If the received request is an HTTP POST message with application/ mrb-consumer+xml content, then the MRB processes it in Query mode.
o 受信したリクエストがapplication / mrb-consumer + xmlコンテンツを含むHTTP POSTメッセージである場合、MRBはそれをクエリモードで処理します。
o If the received request is a SIP INVITE with application/ mrb-consumer+xml content and application/sdp content, then the MRB processes it in IAMM.
o 受信した要求がapplication / mrb-consumer + xmlコンテンツとapplication / sdpコンテンツを含むSIP INVITEである場合、MRBはそれをIAMMで処理します。
o If the received request is a SIP INVITE without application/ mrb-consumer+xml content but with application/sdp content, then the MRB processes it in IUMM.
o 受信したリクエストがapplication / mrb-consumer + xmlコンテンツなしでapplication / sdpコンテンツ付きのSIP INVITEの場合、MRBはそれをIUMMで処理します。
At a high level, the possible Application Server MRB interactions can be distinguished by the following basic types:
高レベルでは、可能なApplication Server MRBの相互作用は、次の基本的なタイプによって区別できます。
a. Query mode - the client is requesting the assignment by the MRB of suitable Media Server resources;
a. クエリモード-クライアントはMRBによる適切なMedia Serverリソースの割り当てを要求しています。
b. IAMM/media dialog - the client is requesting the assignment by the MRB of suitable Media Server resources and the establishment of a media dialog to one of the Media Servers;
b. IAMM /メディアダイアログ-クライアントは、MRBによる適切なメディアサーバーリソースの割り当てと、メディアサーバーの1つへのメディアダイアログの確立を要求しています。
c. IAMM/Control Channel - the client is requesting the assignment by the MRB of suitable Media Server resources and the establishment of a CFW Control Channel to one of the Media Servers;
c. IAMM /制御チャネル-クライアントは、MRBによる適切なメディアサーバーリソースの割り当てと、メディアサーバーの1つへのCFW制御チャネルの確立を要求しています。
d. IUMM/media dialog - the client is requesting the establishment of a media dialog to a Media Server resource;
d. IUMM /メディアダイアログ-クライアントは、メディアサーバーリソースへのメディアダイアログの確立を要求しています。
e. IUMM/Control Channel - the client is requesting the establishment of a CFW Control Channel to a Media Server resource.
e. IUMM /制御チャネル-クライアントは、メディアサーバーリソースへのCFW制御チャネルの確立を要求しています。
Each type of interaction has advantages and disadvantages, where such considerations relate to the versatility of what the MRB can provide, technical aspects such as efficiency in different application scenarios, complexity, delay, use with legacy Application Servers, or use with the Media Control Channel Framework. Depending on the characteristics of a particular setting that an MRB is intended to support, some of the above interaction types may be more appropriate than others. This section provides a few observations on relative merits but is not intended to be exhaustive. Some constraints of a given interaction type may be subtle.
各タイプの相互作用には長所と短所があり、そのような考慮事項は、MRBが提供できる多様性、さまざまなアプリケーションシナリオでの効率、複雑さ、遅延、レガシーアプリケーションサーバーでの使用、またはメディアコントロールチャネルでの使用などの技術的側面に関連していますフレームワーク。 MRBがサポートすることを意図している特定の設定の特性に応じて、上記の相互作用タイプのいくつかは他よりも適切である場合があります。このセクションでは、相対的なメリットに関するいくつかの観察結果を示しますが、すべてを網羅することを意図したものではありません。特定の相互作用タイプの一部の制約は微妙な場合があります。
o Operation with other types of media control: Any of the types of interactions work with the mechanisms described in RFC 4240 [RFC4240] and RFC 5552 [RFC5552] where initial control instructions are conveyed in the SIP INVITE from the Application Server for the media dialog to the Media Server and subsequent instructions may be fetched using HTTP. Query mode (a), IAMM/ media dialog (b), and IUMM/media dialog (d) work with the Media Server Markup Language (MSML) as per RFC 5707 [RFC5707] or the Media Server Control Markup Language (MSCML) as per RFC 5022 [RFC5022].
o 他のタイプのメディア制御を使用した操作：RFC 4240 [RFC4240]およびRFC 5552 [RFC5552]で説明されているメカニズムを使用して、メディアダイアログ用のアプリケーションサーバーからSIP INVITEで初期制御命令が伝達されます。メディアサーバーと後続の命令は、HTTPを使用してフェッチできます。クエリモード（a）、IAMM /メディアダイアログ（b）、およびIUMM /メディアダイアログ（d）は、RFC 5707 [RFC5707]またはメディアサーバーコントロールマークアップ言語（MSCML）に従って、メディアサーバーマークアップ言語（MSML）で動作します。 RFC 5022 [RFC5022]に従います。
o As stated previously, IUMM has no interface impacts on an Application Server. When using IUMM, the Application Server does not specify the characteristics of the type of media resource it requires, as the <mediaResourceRequest> element is not passed to the MRB. For IUMM/media dialog (d), the MRB can deduce an appropriate media resource on a best-effort basis using information gleaned from examining information in the SIP INVITE. This includes the SDP information for the media dialog, or initial control information in the SIP Request-URI as per RFC 4240 [RFC4240]. With IUMM/Control Channel (e), there is even less information for the MRB to use.
o前述のとおり、IUMMはアプリケーションサーバーにインターフェイスの影響を与えません。 IUMMを使用する場合、<mediaResourceRequest>要素はMRBに渡されないため、アプリケーションサーバーは必要なメディアリソースのタイプの特性を指定しません。 IUMM /メディアダイアログ（d）の場合、MRBは、SIP INVITEでの情報の調査から収集した情報を使用して、ベストエフォートベースで適切なメディアリソースを推定できます。これには、メディアダイアログのSDP情報、またはRFC 4240 [RFC4240]によるSIP Request-URIの初期制御情報が含まれます。 IUMM /制御チャネル（e）を使用すると、MRBが使用する情報がさらに少なくなります。
o If using IUMM/Control Channel (e), the subsequent sending of the media dialog to the Media Server should not be done using IUMM/ media dialog. That is, the SIP signaling to send the media dialog to the selected Media Server must be directly between the Application Server and that Media Server, and not through the MRB. Unless resources can be confidentially identified, the MRB could send the media dialog to a different Media Server. Likewise, if using IUMM/media dialog (d), the subsequent establishment of a Control Channel should not be done with IUMM/Control Channel (e) unless definitive information is available.
o IUMM /コントロールチャネル（e）を使用する場合、メディアサーバーへのその後のメディアダイアログの送信は、IUMM /メディアダイアログを使用して行われるべきではありません。つまり、選択したメディアサーバーにメディアダイアログを送信するためのSIPシグナリングは、MRBを介してではなく、アプリケーションサーバーとそのメディアサーバーの間に直接存在する必要があります。リソースを機密で識別できない限り、MRBはメディアダイアログを別のメディアサーバーに送信できます。同様に、IUMM /メディアダイアログ（d）を使用する場合、決定的な情報が利用可能でない限り、制御チャネルのその後の確立はIUMM /制御チャネル（e）で行われるべきではありません。
o Query mode (a) and IAMM/Control Channel (c) lend themselves to requesting a pool of media resources (e.g., a number of IVR or conferencing ports) in advance of use and retaining use over a period of time, independent of whether there are media dialogs to those resources at any given moment, whereas the other types of interactions do not. This also applies to making a subsequent request to increase or decrease the amount of resources previously awarded.
o クエリモード（a）とIAMM /コントロールチャネル（c）は、使用前にメディアリソースのプール（たとえば、多数のIVRまたは会議ポート）を要求し、一定期間使用を維持します。他のタイプの相互作用はそうではないのに対し、任意の瞬間にそれらのリソースへのメディアダイアログです。これは、以前に付与されたリソースの量を増減するために後続のリクエストを行う場合にも適用されます。
o While Query mode (a) and IAMM/Control Channel (c) are the most versatile interaction types, the former is completely decoupled from the use or non-use of a Control Channel, whereas the latter requires the use of a Control Channel.
o クエリモード（a）とIAMM /制御チャネル（c）は最も用途の広い相互作用タイプですが、前者は制御チャネルの使用または非使用から完全に切り離されていますが、後者は制御チャネルを使用する必要があります。
o When Media Control Channel Framework Control Channels are to be used in conjunction with the use of an MRB, Query mode (a) would typically result in fewer such channels being established over time, as compared to IAMM/Control Channel (c). That is because the latter would involve setting up an additional Control Channel every time an Application Server has a new request for an MRB for media resources.
o メディアコントロールチャネルフレームワークコントロールチャネルをMRBの使用と組み合わせて使用する場合、クエリモード（a）では、IAMM /コントロールチャネル（c）と比較して、通常、このようなチャネルが時間の経過とともに確立されます。これは、後者の場合、アプリケーションサーバーがメディアリソースのMRBに対する新しいリクエストを送信するたびに、追加の制御チャネルを設定する必要があるためです。
This section provides examples of both the Publish and Consumer interfaces. Both the Query mode and In-line mode are addressed.
このセクションでは、パブリッシュインターフェイスとコンシューマインターフェイスの両方の例を示します。クエリモードとインラインモードの両方に対応しています。
Note that due to RFC formatting conventions, this section often splits HTTP, SIP/SDP, and CFW across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash, and its trailing CRLF and whitespace, would not appear in the actual protocol contents. Also note that the indentation of the XML content is only provided for readability: actual messages will follow strict XML syntax, which allows for but does not require indentation.
RFCのフォーマット規則により、このセクションでは、内容が72文字を超える行にHTTP、SIP / SDP、およびCFWが分割されることがよくあります。バックスラッシュ文字は、この行の折り返しが行われた場所を示します。このバックスラッシュ、およびその末尾のCRLFと空白は、実際のプロトコルコンテンツには表示されません。また、XMLコンテンツのインデントは読みやすくするためにのみ提供されていることに注意してください。実際のメッセージは厳密なXML構文に準拠しているため、インデントは可能ですが、必須ではありません。
The following example assumes that a Control Channel has been established and synced as described in the Media Control Channel Framework ([RFC6230]).
次の例では、メディア制御チャネルフレームワーク（[RFC6230]）で説明されているように、制御チャネルが確立および同期されていることを前提としています。
Figure 9 shows the subscription/notification mechanism the Publish interface is based on, as defined in Section 5.1. The MRB subscribes for information at the Media Server (message A1.), and the Media Server accepts the subscription (A2.). Notifications are triggered by the Media Server (B1.) and acknowledged by the MRB (B2.).
図9は、セクション5.1で定義されている、パブリッシュインターフェイスの基になるサブスクリプション/通知メカニズムを示しています。 MRBはメディアサーバーで情報をサブスクライブし（メッセージA1。）、メディアサーバーはサブスクリプションを受け入れます（A2。）。通知はメディアサーバー（B1。）によってトリガーされ、MRB（B2。）によって確認されます。
MRB MS
| |
| A1. CONTROL (MRB subscription) |
|--------------------------------------------->|
| A2. 200 OK |
|<---------------------------------------------|
| |
. .
. .
| |
| |--+ collect
| | | up-to-date
| |<-+ info
| B1. CONTROL (MRB notification) |
|<---------------------------------------------|
| B2. 200 OK |
|--------------------------------------------->|
| |
. .
. .
Figure 9: Publish Example: Sequence Diagram
図9：パブリッシュの例：シーケンス図
The rest of this section includes a full dump of the messages associated with the previous sequence diagram, specifically:
このセクションの残りの部分には、前のシーケンス図に関連するメッセージの完全なダンプが含まれています。具体的には次のとおりです。
1. the subscription (A1.), in an <mrbrequest> (CFW CONTROL);
1. サブスクリプション（A1。）、<mrbrequest>（CFW CONTROL）;
2. the Media Server accepting the subscription (A2.), in an <mrbresponse> (CFW 200);
2. <mrbresponse>（CFW 200）で、サブスクリプションを受け入れるメディアサーバー（A2）。
3. a notification (B1.), in an <mrbnotification> (CFW CONTROL);
3. <mrbnotification>（CFW CONTROL）の通知（B1）。
4. the ack to the notification (B2.), in a framework-level 200 message (CFW 200).
4. フレームワークレベルの200メッセージ（CFW 200）での通知へのack（B2。）。
A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 337
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest>
<subscription action="create" seqnumber="1" id="p0T65U">
<expires>600</expires>
<minfrequency>20</minfrequency>
<maxfrequency>20</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: 4226
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbnotification seqnumber="1" id="QQ6J3c">
<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:MS1@ms.example.net</media-server-address>
<encryption/>
</mrbnotification>
</mrbpublish>
B2. MRB -> MS (200 to CONTROL)
------------------------------
CFW 03fff52e7b7a 200
As specified in Section 5.2, the Consumer interface can be involved in two different modes: Query and In-line aware. When in Query mode, Consumer messages are transported in HTTP messages: an example of such an approach is presented in Section 9.2.1. When in In-line aware mode, messages are instead transported as part of SIP negotiations: considering that SIP negotiations may be related to either the creation of a Control Channel or to a User Agent Client (UAC) media dialog, two separate examples of such an approach are presented in Section 9.2.2.
セクション5.2で指定されているように、コンシューマインターフェイスは、クエリとインライン対応の2つの異なるモードに関与できます。クエリモードでは、コンシューマメッセージはHTTPメッセージで転送されます。このようなアプローチの例は、セクション9.2.1に示されています。インライン対応モードの場合、メッセージは代わりにSIPネゴシエーションの一部として転送されます。SIPネゴシエーションは、コントロールチャネルの作成またはユーザーエージェントクライアント（UAC）メディアダイアログのいずれかに関連している可能性があることを考慮して、その2つの例アプローチはセクション9.2.2に示されています。
The following example assumes that the interested Application Server already knows the HTTP URL where an MRB is listening for Consumer messages.
次の例では、関係するアプリケーションサーバーが、MRBがコンシューマーメッセージをリッスンしているHTTP URLをすでに知っていると想定しています。
Figure 10 shows the HTTP-based transaction between the Application Server (AS, as shown in the figure) and the MRB. The Application Server sends a Consumer request as payload of an HTTP POST message (1.), and the MRB provides an answer in an HTTP 200 OK message (2.). Specifically, as will be shown in the examples, the Application Server is interested in 100 IVR ports: the MRB finds two Media Servers that can satisfy the request (one providing 60 ports and the other providing 40 ports) and reports them to the Application Server.
図10は、アプリケーションサーバー（図に示されているAS）とMRBの間のHTTPベースのトランザクションを示しています。 Application Serverはコンシューマ要求をHTTP POSTメッセージのペイロードとして送信し（1。）、MRBはHTTP 200 OKメッセージで応答を提供します（2.）。具体的には、例に示すように、アプリケーションサーバーは100個のIVRポートに関心があります。MRBは、要求を満たす2つのメディアサーバーを見つけ（1つは60ポートを提供し、もう1つは40ポートを提供）、それらをアプリケーションサーバーに報告します。 。
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 first MS reported by MRB |
| |
. .
. .
Figure 10: Consumer Example (Query): Sequence Diagram
図10：消費者の例（クエリ）：シーケンス図
The rest of this section includes a full dump of the messages associated with the previous sequence diagram, specifically:
このセクションの残りの部分には、前のシーケンス図に関連するメッセージの完全なダンプが含まれています。具体的には次のとおりです。
1. the Consumer request (1.), in a <mediaResourceRequest> (HTTP POST, Content-Type 'application/mrb-consumer+xml');
1. <mediaResourceRequest>内のコンシューマーリクエスト（1.）（HTTP POST、Content-Type 'application / mrb-consumer + xml'）;
2. the Consumer response (2.), in a <mediaResourceResponse> (HTTP 200 OK, Content-Type 'application/mrb-consumer+xml').
2. <mediaResourceResponse>内のコンシューマー応答（2.）（HTTP 200 OK、Content-Type 'application / mrb-consumer + xml'）。
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.net: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.net: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="gh11x23v">
<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: 1133 Date: Mon, 12 Apr 2011 14:59:26 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 ：1133日付：2011年4月12日月曜日14:59:26 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="gh11x23v">
<response-session-info>
<session-id>5t3Y4IQ84gY1</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>
As the example shows, the request and response are associated by means of the 'id' attribute (id="gh11x23v"). The MRB has picked '9' as the random sequence number that needs to be incremented by the Application Server for the subsequent request associated with the same session.
例が示すように、リクエストとレスポンスは 'id'属性（id = "gh11x23v"）によって関連付けられます。 MRBは、同じセッションに関連付けられた後続の要求のためにアプリケーションサーバーがインクリメントする必要があるランダムシーケンス番号として「9」を選択しました。
The rest of the scenario is omitted for brevity. After having received the 'mediaResourceResponse', the Application Server has the URIs of two Media Servers able to fulfill its media requirements and can start a control dialog with one or both of them.
シナリオの残りは簡潔にするために省略されています。 「mediaResourceResponse」を受信した後、アプリケーションサーバーは、そのメディア要件を満たすことができる2つのメディアサーバーのURIを持ち、それらの一方または両方でコントロールダイアログを開始できます。
Two separate examples are presented for the IAMM case: in fact, IAMM can take advantage of two different approaches with respect to the SIP dialogs to be exploited to carry Consumer messages, i.e., i) a SIP control dialog to create a Control Channel, and ii) a UAC media dialog to attach to a Media Server. To make things clearer for the reader, the same Consumer request as the one presented in the Query mode will be sent, in order to clarify how the behavior of the involved parties may differ.
IAMMの場合の2つの個別の例を示します。実際、IAMMは、コンシューマーメッセージを運ぶために活用されるSIPダイアログに関して2つの異なるアプローチを利用できます。つまり、i）制御チャネルを作成するSIP制御ダイアログ、およびii）メディアサーバーに接続するためのUACメディアダイアログ。読者にわかりやすくするために、関係者の動作がどのように異なるかを明確にするために、クエリモードで提示されたものと同じコンシューマリクエストが送信されます。
The following example assumes that the interested Application Server already knows the SIP URI of an MRB.
次の例では、関係するアプリケーションサーバーがMRBのSIP URIをすでに認識していると想定しています。
Figure 11 shows the first approach, i.e., SIP-based transactions between the Application Server, the MRB, and one Media Server that the MRB chooses from the two that are allocated to fulfill the request. The diagram is more complex than before. This is basically a scenario envisaging the MRB as a B2BUA. The Application Server sends a SIP INVITE (1.) containing both a CFW-related SDP and a Consumer request (multipart body). The MRB sends a provisional response to the Application Server (2.) and starts working on the request. First of all, it makes use of the Consumer request from the Application Server to determine which Media Servers should be exploited. Once the right Media Servers have been chosen (MS1 and MS2 in the example), the MRB sends a new SIP INVITE (3.) to one of the Media Servers (MS1 in the example) by just including the SDP part of the original request. That Media Server negotiates this INVITE as specified in [RFC6230] (4., 5., 6.), providing the MRB with its own CFW-related SDP. The MRB replies to the original Application Server INVITE preparing a SIP 200 OK with another multipart body (7.): this multipart body includes the Consumer response used by the MRB to determine the right Media Servers and the SDP returned by the Media Server (MS1) in (5.). The Application Server finally acknowledges the 200 OK (8.), and can start a CFW connection towards that Media Server (MS1). Since the MRB provided the Application Server with two Media Server instances to fulfill its requirements, the Application Server can use the URI in the <media-server-address> element in the <mediaResourceResponse> that describes the other Media Server to establish a CFW channel with that Media Server (MS2) as well.
図11は、最初のアプローチ、つまり、アプリケーションサーバー、MRB、および要求を満たすために割り当てられた2つのメディアサーバーからMRBが選択する1つのメディアサーバー間のSIPベースのトランザクションを示しています。図は以前よりも複雑です。これは基本的に、MRBをB2BUAとして想定するシナリオです。アプリケーションサーバーは、CFW関連のSDPとコンシューマー要求（マルチパート本文）の両方を含むSIP INVITE（1.）を送信します。 MRBは暫定応答をアプリケーションサーバーに送信し（2.）、要求の処理を開始します。まず、アプリケーションサーバーからのコンシューマーリクエストを利用して、どのメディアサーバーを利用するかを決定します。適切なメディアサーバー（例ではMS1とMS2）が選択されると、MRBは元の要求のSDP部分を含めるだけで、新しいSIP INVITE（3.）をいずれかのメディアサーバー（例ではMS1）に送信します。 。そのメディアサーバーは、[RFC6230]（4、5、6）で指定されているようにこのINVITEをネゴシエートし、MRBに独自のCFW関連のSDPを提供します。 MRBは元のApplication Server INVITEに応答し、別のマルチパートボディでSIP 200 OKを準備します（7.）：このマルチパートボディには、MRBが使用するコンシューマー応答が含まれ、適切なメディアサーバーとメディアサーバー（MS1 ）（5.）アプリケーションサーバーは最終的に200 OK（8.）を確認し、そのメディアサーバー（MS1）へのCFW接続を開始できます。 MRBはアプリケーションサーバーに2つのMedia Serverインスタンスを提供して要件を満たすため、アプリケーションサーバーは、他のMedia Serverを記述する<mediaResourceResponse>の<media-server-address>要素のURIを使用して、CFWチャネルを確立できます。そのMedia Server（MS2）でも同様です。
Please note that to ease the reading of the protocol contents 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メッセージに挿入される実際の境界の代わりに、「multipart / mixed」ペイロードの境界が提供される場合は常に、単純な「= _Part」が使用されることに注意してください。
AS MRB MS1 MS2
| | | |
| 1. INVITE | | |
| (multipart/mixed) | | |
|---------------------->| | |
| 2. 100 (Trying) | | |
|<----------------------| | |
| |--+ Extract SDP and | |
| | | MRB payloads; handle | |
| |<-+ Consumer request to | |
| | pick MSs (MS1 and MS2) | |
| | | |
| | 3. INVITE | |
| | (only copy SDP from 1.) | |
| |-------------------------->| |
| | 4. 100 (Trying) | |
| |<--------------------------| |
| | |--+ Negotiate |
| | | | CFW Control |
| | |<-+ Channel |
| | 5. 200 OK | |
| |<--------------------------| |
| | 6. ACK | |
| |-------------------------->| |
| Prepare new +--| | |
| payload with | | | |
| SDP from MS and +->| | |
| Consumer reply | | |
| | | |
| 7. 200 OK | | |
| (multipart/mixed) | | |
|<----------------------| | |
| 8. ACK | | |
|---------------------->| | |
| | | |
|--+ Read Cons. reply | | |
| | and use SDP to | | |
|<-+ create CFW Chn. | | |
| | | |
| | |
| Create TCP CFW channel towards MS1 (if needed) | |
|-------------------------------------------------->| |
| | |
|<<############## TCP CONNECTION #################>>| |
| | |
| CFW SYNC | |
|++++++++++++++++++++++++++++++++++++++++++++++++++>| |
| | |
. . . .
. . . .
| | |
| Negotiate SIP control dialog with MS2 |
|<------------------------------------------------------------------>|
| Create TCP CFW channel towards MS2 as well (if needed) |
|------------------------------------------------------------------->|
| |
|<<######################## TCP CONNECTION ########################>>|
| |
| CFW SYNC |
|+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>|
| |
| | | |
. . . .
. . . .
Figure 11: Consumer Example (IAMM/Control Channel): Sequence Diagram
The rest of this section includes an almost full trace of the messages associated with the previous sequence diagram. Only the relevant SIP messages are shown (both the INVITEs and the 200 OKs), and only the relevant headers are preserved for brevity (Content-Type and multipart-related information). Specifically:
このセクションの残りの部分には、前のシーケンス図に関連するメッセージのほぼ完全なトレースが含まれています。関連するSIPメッセージのみが表示され（INVITEと200 OKの両方）、簡潔にするために関連するヘッダーのみが保持されます（コンテンツタイプとマルチパート関連情報）。具体的には：
1. the original INVITE (1.) containing both a CFW-related SDP (Connection-Oriented Media (COMEDIA) information to negotiate a new Control Channel) and a Consumer <mediaResourceRequest>;
1. 元のINVITE（1.）には、CFW関連のSDP（新しい制御チャネルをネゴシエートするための接続指向メディア（COMEDIA）情報）とコンシューマ<mediaResourceRequest>の両方が含まれています。
2. the INVITE sent by the MRB (acting as a B2BUA) to the Media Server (3.), containing only the CFW-related SDP from the original INVITE;
2. MRB（B2BUAとして機能）からメディアサーバーに送信されたINVITE（3.）。元のINVITEからのCFW関連のSDPのみが含まれます。
3. the 200 OK sent by the Media Server back to the MRB (5.) to complete the CFW-related negotiation (SDP only);
3. メディアサーバーからMRBに返された200 OK（5.）は、CFW関連のネゴシエーションを完了します（SDPのみ）。
4. the 200 OK sent by the MRB back to the Application Server in response to the original INVITE (7.), containing both the CFW-related information sent by the Media Server and a Consumer <mediaResourceRequest> documenting the MRB's decision to use that Media Server.
4. 元のINVITE（7.）に応じてMRBからアプリケーションサーバーに返される200 OK。メディアサーバーによって送信されるCFW関連情報と、そのメディアサーバーを使用するMRBの決定を文書化するコンシューマー<mediaResourceRequest>の両方が含まれます。 。
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
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
=_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="pz78hnq1">
<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
= _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
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
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
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0
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
a=ctrl-package:msc-mixer/1.0
a=ctrl-package:msc-ivr/1.0
a=ctrl-package:mrb-publish/1.0
a=ctrl-package:msc-example-pkg/1.0
=_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="pz78hnq1">
<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
= _Part
As the previous example illustrates, the only difference in the response that the MRB provides to the Application Server is in the 'connection-id' attribute that is added to the first allocated Media Server instance: this allows the Application Server to understand that the MRB has sent the CFW channel negotiation to that specific Media Server and that the connection-id to be used is the one provided. This will be described in more detail in the following section for the media dialog-based approach.
前の例が示すように、MRBがアプリケーションサーバーに提供する応答の唯一の違いは、最初に割り当てられたメディアサーバーインスタンスに追加される「connection-id」属性にあります。これにより、アプリケーションサーバーはMRBを理解できます。 CFWチャネルネゴシエーションをその特定のメディアサーバーに送信し、使用される接続IDが提供されたものである。これについては、メディアダイアログベースのアプローチの次のセクションで詳しく説明します。
The continuation of the scenario (the Application Server connecting to MS1 to start the Control Channel and the related SYNC message, the Application Server connecting to MS2 as well later on, all the media dialogs being attached to either Media Server) is omitted for brevity.
シナリオの続き（コントロールチャネルを開始するためにMS1に接続しているアプリケーションサーバーと関連するSYNCメッセージ、後でMS2に接続しているアプリケーションサーバー、いずれかのメディアサーバーに接続されているすべてのメディアダイアログ）は簡潔にするために省略されています。
The following example assumes that the interested Application Server already knows the SIP URI of an MRB.
次の例では、関係するアプリケーションサーバーがMRBのSIP URIをすでに認識していると想定しています。
Figure 12 shows the second approach, i.e., SIP-based transactions between a SIP client, the Application Server, the MRB, and the Media Server that the MRB chooses. The interaction is basically the same as previous examples (e.g., contents of the multipart body), but considering that a new party is involved in the communication, the diagram is slightly more complex than before. As before, the MRB acts as a B2BUA. A UAC sends a SIP INVITE to a SIP URI handled by the Application Server, since it is interested to its services (1.). The Application Server sends a provisional response (2.) and, since it doesn't have the resources yet, sends to the MRB a new SIP INVITE (3.) containing both the UAC media-related SDP and a Consumer request (multipart body). The MRB sends a provisional response to the Application Server (4.) and starts working on the request. First of all, it makes use of the Consumer request from the Application Server to determine which Media Servers should be chosen. Once the Media Server has been chosen, the MRB sends a new SIP INVITE to one of the Media Servers by including the SDP part of the original request (5.).
図12は、2番目のアプローチ、つまり、SIPクライアント、アプリケーションサーバー、MRB、およびMRBが選択するメディアサーバー間のSIPベースのトランザクションを示しています。相互作用は基本的に前の例と同じです（たとえば、マルチパート本体のコンテンツ）。ただし、新しいパーティが通信に関与していることを考えると、図は以前よりも少し複雑です。以前と同様に、MRBはB2BUAとして機能します。 UACはサービスに関心があるため、アプリケーションサーバーが処理するSIP URIにSIP INVITEを送信します（1.）。アプリケーションサーバーは暫定応答（2.）を送信し、まだリソースがないため、MRBにUACメディア関連のSDPとコンシューマーリクエスト（マルチパートボディ）の両方を含む新しいSIP INVITE（3.）を送信します。 ）。 MRBは暫定応答をアプリケーションサーバー（4.）に送信し、要求の処理を開始します。まず、アプリケーションサーバーからのコンシューマーリクエストを利用して、選択するメディアサーバーを決定します。メディアサーバーが選択されると、MRBは元のリクエストのSDP部分を含めることにより、新しいSIP INVITEをいずれかのメディアサーバーに送信します（5.）。
The Media Server negotiates this INVITE as specified in [RFC6230] (6., 7., 8.) to allocate the needed media resources to handle the new media dialog, eventually providing the MRB with its own media-related SDP. The MRB replies to the original Application Server INVITE preparing a SIP 200 OK with a multipart body (9.): this multipart body includes the Consumer response from the MRB indicating the chosen Media Servers and the SDP returned by the Media Server in (7.). The Application Server finally acknowledges the 200 OK (10.) and ends the scenario by eventually providing the UAC with the SDP it needs to set up the RTP channels with the chosen Media Server: a separate direct SIP control dialog may be initiated by the Application Server to the same Media Server in order to set up a Control Channel to manipulate the media dialog.
メディアサーバーは、[RFC6230]（6、7、8）で指定されているようにこのINVITEをネゴシエートして、新しいメディアダイアログを処理するために必要なメディアリソースを割り当て、最終的にMRBに独自のメディア関連SDPを提供します。 MRBは元のApplication Server INVITEに応答し、マルチパートボディ（9.）でSIP 200 OKを準備します。このマルチパートボディには、選択されたメディアサーバーと（7。 ）。アプリケーションサーバーは最終的に200 OK（10.）を確認し、最終的にUACに、選択したメディアサーバーでRTPチャネルをセットアップするために必要なSDPを提供することによってシナリオを終了します。アプリケーションによって、個別の直接SIP制御ダイアログが開始される場合があります。メディアダイアログを操作するためのコントロールチャネルを設定するために、サーバーを同じメディアサーバーに接続します。
As with the IAMM/Control Channel example in the prior section, this example has the MRB selecting Media Server resources across two Media Server instances. The convention could be that the MRB sent the SIP INVITE to the first Media Server in the list provided to the Application Server in the Consumer response information. For the sake of brevity, considerations related to connecting to the other Media Servers as well are omitted, since they have already been addressed in the previous section.
前のセクションのIAMM /制御チャネルの例と同様に、この例では、2つのMedia Serverインスタンス間でMRBがMedia Serverリソースを選択しています。コンベンションでは、MRBがコンシューマ応答情報でアプリケーションサーバーに提供されたリストの最初のメディアサーバーにSIP INVITEを送信した可能性があります。簡潔にするために、他のメディアサーバーへの接続に関する考慮事項についても、前のセクションで説明済みであるため省略します。
Please note that to ease the reading of the protocol contents, 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メッセージに挿入される実際の境界ではなく、「multipart / mixed」ペイロードの境界が提供される場合は常に、単純な「= _Part」が使用されることに注意してください。
UAC AS MRB MS
| | | |
| 1. INVITE | | |
| (media SDP) | | |
|-------------->| | |
| 2. 100 Trying | | |
|<--------------| | |
| | 3. INVITE | |
| | (multipart/mixed) | |
| |---------------------->| |
| | 4. 100 (Trying) | |
| |<----------------------| |
| | |--+ Extract SDP and |
| | | | MRB payloads; handle |
| | |<-+ Consumer request to |
| | | pick Media Servers |
| | | |
| | | 5. INVITE |
| | | (only copy SDP from 3.) |
| | |-------------------------->|
| | | 6. 100 (Trying) |
| | |<--------------------------|
| | | +--|
| | | Handle media dialog | |
| | | (connection-id) +->|
| | | |
| | | 7. 200 OK |
| | |<--------------------------|
| | | 8. ACK |
| | |-------------------------->|
| | Prepare new +--| |
| | payload with | | |
| | SDP from MS and +->| |
| | Consumer reply | |
| | | |
| | 9. 200 OK | |
| | (multipart/mixed) | |
| |<----------------------| |
| | 10. ACK | |
| |---------------------->| |
| | | |
| |--+ Read Cons. reply | |
| | | and send SDP | |
| |<-+ back to UAC | |
| 11. 200 OK | | |
|<--------------| | |
| 12. ACK | | |
|-------------->| | |
| | | |
|<<*************************** RTP *******************************>>|
| | | |
| |--+ Negotiate | |
| | | CFW channel | |
| |<-+ towards MS | |
| | (if needed) | |
. . . .
. . . .
| | | |
| | |
| | Create TCP CFW channel towards MS (if needed) |
| |-------------------------------------------------->|
| | |
| |<<############## TCP CONNECTION #################>>|
| | |
| | CFW SYNC |
| |++++++++++++++++++++++++++++++++++++++++++++++++++>|
| | |
. . . .
. . . .
Figure 12: Consumer Example (IAMM/Media Dialog): Sequence Diagram
The rest of this section includes a trace of the messages associated with the previous sequence diagram. Only the relevant SIP messages are shown (both the INVITEs and the 200 OKs), and only the relevant headers are preserved for brevity (Content-Type, From/To, and multipart-related information). Specifically:
このセクションの残りの部分には、前のシーケンス図に関連するメッセージのトレースが含まれています。関連するSIPメッセージのみが表示され（INVITEと200 OKの両方）、簡潔にするために関連するヘッダーのみが保持されます（Content-Type、From / To、およびマルチパート関連情報）。具体的には：
1. the original INVITE (1.) containing the media-related SDP sent by a UAC;
1. UACから送信されたメディア関連のSDPを含む元のINVITE（1）。
2. the INVITE sent by the AS to the MRB (3.), containing both the media-related SDP and a Consumer <mediaResourceRequest>;
2. ASからMRBに送信されたINVITE（3.）。メディア関連のSDPとコンシューマ<mediaResourceRequest>の両方を含みます。
3. the INVITE sent by the MRB (acting as a B2BUA) to the Media Server (5.), containing only the media-related SDP from the original INVITE;
3. MRB（B2BUAとして機能）からメディアサーバー（5.）に送信されたINVITE。元のINVITEからのメディア関連のSDPのみが含まれます。
4. the 200 OK sent by the Media Server back to the MRB (7.) to complete the media-related negotiation (SDP only);
4. メディア関連のネゴシエーションを完了するためにメディアサーバーからMRBに送信された200 OK（7.）（SDPのみ）。
5. the 200 OK sent by the MRB back to the Application Server in response to the original INVITE (9.), containing both the media-related information sent by the Media Server and a Consumer <mediaResourceRequest> documenting the MRB's decision to use that Media Server;
5. 元のINVITE（9.）に応答してMRBからアプリケーションサーバーに返される200 OK。メディアサーバーによって送信されるメディア関連情報と、そのメディアサーバーを使用するMRBの決定を文書化したコンシューマ<mediaResourceRequest>の両方が含まれます。 ;
6. the 200 OK sent by the Application Server back to the UAC to have it set up the RTP channel(s) with the Media Server (11.).
6. アプリケーションサーバーからUACに送り返された200 OKは、メディアサーバー（11.）とのRTPチャネルをセットアップするためのものです。
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）------------------------------------- [.. ]差出人：<sip：ApplicationServer@as.example.com>; tag = fd4fush5差出人：<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
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbconsumer version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-consumer">
<mediaResourceRequest id="ns56g1x0">
<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
= _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マルチパート/混合）------------------------------------- [。 。]差出人：<sip：ApplicationServer@as.example.com>; tag = fd4fush5宛先：<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
<?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="ns56g1x0">
<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
= _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
As the examples illustrate, as in the IAMM/Control Channel example, the MRB provides the Application Server with a <media-server-address> element in the Consumer response: the 'uri' attribute identifies the specific Media Server to which the MRB has sent the SDP media negotiation, and the 'connection-id' enables the Application Server to identify to the Media Server the dialog between the MRB and Media Server. This attribute is needed, since according to the framework specification [RFC6230] the connection-id is built out of the From/To tags of the dialog between the MRB and Media Server; since the MRB acts as a B2BUA in this scenario, without that attribute the Application Server does not know the relevant tags, thus preventing the CFW protocol from working as expected.
例が示すように、IAMM /制御チャネルの例のように、MRBはアプリケーションサーバーにコンシューマーレスポンスの<media-server-address>要素を提供します。'uri '属性は、MRBが持っている特定のメディアサーバーを識別します。 SDPメディアネゴシエーションを送信し、「connection-id」を使用すると、アプリケーションサーバーはメディアサーバーに対してMRBとメディアサーバー間のダイアログを識別できます。フレームワーク仕様[RFC6230]に従って、MRBとメディアサーバー間のダイアログのFrom / Toタグからconnection-idが構築されているため、この属性が必要です。このシナリオではMRBがB2BUAとして機能するため、その属性がないと、アプリケーションサーバーは関連するタグを認識しないため、CFWプロトコルが期待どおりに機能しません。
The continuation of the scenario (the Application Server connecting to the Media Server to start the Control Channel, the SYNC message, etc.) is omitted for brevity.
シナリオの続き（コントロールチャネルを開始するためにメディアサーバーに接続するアプリケーションサーバー、SYNCメッセージなど）は、簡潔にするために省略されています。
This section gives the XML Schema Definition [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the "application/mrb-publish+xml" format.
このセクションでは、「application / mrb-publish + xml」形式のXMLスキーマ定義[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028]を示します。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-publish"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-publish"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB package.
これは、IETF MediaCtrl MRBパッケージのスキーマです。
The schema namespace is urn:ietf:params:xml:ns:mrb-publish
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
スキーマのインポート
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the framework attributes for
conferenceid and connectionid.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the civicAddress specification
from RFC 5139.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
拡張コアタイプ
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (non-mixed) component types to
allow attributes from other namespaces.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!--
#####################################################
TOP-LEVEL ELEMENT: mrbpublish
トップレベルの要素：mrbpublish
#####################################################
-->
<xsd:complexType name="mrbpublishType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mrbrequest" />
<xsd:element ref="mrbresponse" />
<xsd:element ref="mrbnotification" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="version.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbpublish" type="mrbpublishType" />
<!--
#####################################################
mrbrequest TYPE
mrbrequestタイプ
#####################################################
-->
<!-- mrbrequest -->
<xsd:complexType name="mrbrequestType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="subscription" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbrequest" type="mrbrequestType" />
<!-- subscription -->
<xsd:complexType name="subscriptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="expires" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:element name="minfrequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:element name="maxfrequency" type="xsd:nonNegativeInteger"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="id.datatype" use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:attribute name="action" type="action.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="subscription" type="subscriptionType" />
<!--
#####################################################
mrbresponse TYPE
mrbresponseタイプ
#####################################################
-->
<!-- mrbresponse -->
<xsd:complexType name="mrbresponseType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="subscription" minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbresponse" type="mrbresponseType" />
<!--
#####################################################
mrbnotification TYPE
mrbnotification TYPE
#####################################################
-->
<!-- mrbnotification -->
<xsd:complexType name="mrbnotificationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="media-server-id"
type="subscriptionid.datatype"/>
<xsd:element ref="supported-packages" minOccurs="0" />
<xsd:element ref="active-rtp-sessions" minOccurs="0" />
<xsd:element ref="active-mixer-sessions" minOccurs="0" />
<xsd:element ref="non-active-rtp-sessions" minOccurs="0" />
<xsd:element ref="non-active-mixer-sessions" minOccurs="0" />
<xsd:element ref="media-server-status" minOccurs="0" />
<xsd:element ref="supported-codecs" minOccurs="0" />
<xsd:element ref="application-data" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="max-prepared-duration" minOccurs="0" />
<xsd:element ref="dtmf-support" minOccurs="0" />
<xsd:element ref="mixing-modes" minOccurs="0" />
<xsd:element ref="supported-tones" minOccurs="0" />
<xsd:element ref="file-transfer-modes" minOccurs="0" />
<xsd:element ref="asr-tts-support" minOccurs="0" />
<xsd:element ref="vxml-support" minOccurs="0" />
<xsd:element ref="media-server-location" minOccurs="0" />
<xsd:element ref="label" minOccurs="0" />
<xsd:element ref="media-server-address" minOccurs="0" />
<xsd:element ref="encryption" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="subscriptionid.datatype"
use="required" />
<xsd:attribute name="seqnumber" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbnotification" type="mrbnotificationType" />
<!-- supported-packages -->
<xsd:complexType name="supported-packagesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="package" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-packages" type="supported-packagesType"/>
<xsd:complexType name="packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="package" type="packageType" />
<!-- active-rtp-sessions -->
<xsd:complexType name="active-rtp-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-rtp-sessions" type="active-rtp-sessionsType"/>
<xsd:complexType name="rtp-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- active-mixer-sessions -->
<xsd:complexType name="active-mixer-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="active-mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-mixer-sessions"
type="active-mixer-sessionsType" />
<xsd:complexType name="active-mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attributeGroup ref="fw:framework-attributes" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-mix" type="active-mixType" />
<!-- non-active-rtp-sessions -->
<xsd:complexType name="non-active-rtp-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-rtp-sessions"
type="non-active-rtp-sessionsType" />
<!-- non-active-mixer-sessions -->
<xsd:complexType name="non-active-mixer-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="non-active-mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-mixer-sessions"
type="non-active-mixer-sessionsType" />
<xsd:complexType name="non-active-mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="available" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="non-active-mix" type="non-active-mixType" />
<!-- media-server-status -->
<xsd:element name="media-server-status" type="msstatus.datatype" />
<!-- supported-codecs -->
<xsd:complexType name="supported-codecsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-codec"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codecs" type="supported-codecsType" />
<xsd:complexType name="supported-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-codec-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codec" type="supported-codecType" />
<xsd:complexType name="supported-codec-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="supported-action" type="actions.datatype"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-codec-package"
type="supported-codec-packageType" />
<!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" />
<!-- file-formats -->
<xsd:complexType name="file-formatsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-format"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-formats" type="file-formatsType" />
<xsd:complexType name="supported-formatType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-file-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-format" type="supported-formatType" />
<xsd:element name="supported-file-package"
type="xsd:string" />
<!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-prepared-duration"
type="max-prepared-durationType" />
<xsd:complexType name="max-timeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="max-time-package" type="xsd:string" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-time" type="max-timeType" />
<!-- dtmf-support -->
<xsd:complexType name="dtmf-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="detect" />
<xsd:element ref="generate" />
<xsd:element ref="passthrough" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-support" type="dtmf-supportType" />
<xsd:complexType name="detectType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="detect" type="detectType" />
<xsd:complexType name="generateType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="passthrough" type="passthroughType" />
<xsd:complexType name="dtmf-typeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="dtmf.datatype" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" />
<!-- mixing-modes -->
<xsd:complexType name="mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="video-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="vas" type="boolean.datatype"
default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!-- supported-tones -->
<xsd:complexType name="supported-tonesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="supported-country-codes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="supported-h248-codes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-tones" type="supported-tonesType" />
<xsd:complexType name="supported-country-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-country-codes"
type="supported-country-codesType" />
<xsd:complexType name="country-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="supported-h248-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="supported-h248-codes"
type="supported-h248-codesType" />
<xsd:complexType name="h248-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" />
<!-- file-transfer-modes -->
<xsd:complexType name="file-transfer-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="file-transfer-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-transfer-modes"
type="file-transfer-modesType" />
<xsd:complexType name="file-transfer-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="transfermode.datatype"
use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-transfer-mode" type="file-transfer-modeType" />
<!-- asr-tts-support -->
<xsd:complexType name="asr-tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="asr-support"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="tts-support"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-tts-support" type="asr-tts-supportType" />
<xsd:complexType name="asr-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-support" type="asr-supportType" />
<xsd:complexType name="tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tts-support" type="tts-supportType" />
<xsd:complexType name="languageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute ref="xml:lang" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="language" type="languageType" />
<!-- media-server-location -->
<xsd:complexType name="media-server-locationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="civicAddress" type="ca:civicAddress"
minOccurs="1" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="media-server-location"
type="media-server-locationType" />
<!-- vxml-support -->
<xsd:complexType name="vxml-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-support" type="vxml-supportType" />
<xsd:complexType name="vxml-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="support" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- label -->
<xsd:element name="label" type="label.datatype" />
<!-- media-server-address -->
<xsd:element name="media-server-address" type="xsd:anyURI" />
<!-- encryption -->
<xsd:complexType name="encryptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="encryption" type="encryptionType" />
<!--
####################################################
DATATYPES
データ型
####################################################
-->
<xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="id.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="msstatus.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="active" />
<xsd:enumeration value="deactivated" />
<xsd:enumeration value="unavailable" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="create" />
<xsd:enumeration value="update" />
<xsd:enumeration value="remove" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="actions.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="encoding" />
<xsd:enumeration value="decoding" />
<xsd:enumeration value="passthrough" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:string" />
</xsd:simpleType>
<xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="transfermode.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="subscriptionid.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
</xsd:schema>
This section gives the XML Schema Definition [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the "application/mrb-consumer+xml" format.
このセクションでは、「application / mrb-consumer + xml」形式のXMLスキーマ定義[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028]を示します。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:mrb-consumer"
elementFormDefault="qualified" blockDefault="#all"
xmlns="urn:ietf:params:xml:ns:mrb-consumer"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl MRB 1.0
This is the schema of the IETF MediaCtrl MRB Consumer interface.
これは、IETF MediaCtrl MRBコンシューマインターフェイスのスキーマです。
The schema namespace is urn:ietf:params:xml:ns:mrb-consumer
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
スキーマのインポート
#############################################################
-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the XML attributes for
xml:base, xml:lang, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the civicAddress specification
from RFC 5139.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
拡張コアタイプ
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (non-mixed) component types to
allow attributes from other namespaces.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!--
#####################################################
TOP-LEVEL ELEMENT: mrbconsumer
トップレベルの要素：mrbconsumer
#####################################################
-->
<xsd:complexType name="mrbconsumerType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="mediaResourceRequest" />
<xsd:element ref="mediaResourceResponse" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="version.datatype"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mrbconsumer" type="mrbconsumerType" />
<!--
#####################################################
mediaResourceRequest TYPE
mediaResourceRequest TYPE
#####################################################
-->
<!-- mediaResourceRequest -->
<xsd:complexType name="mediaResourceRequestType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="generalInfo" minOccurs="0" />
<xsd:element ref="ivrInfo" minOccurs="0" />
<xsd:element ref="mixerInfo" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mediaResourceRequest"
type="mediaResourceRequestType" />
<!--
#####################################################
generalInfo TYPE
generalInfo TYPE
#####################################################
-->
<!-- generalInfo -->
<xsd:complexType name="generalInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="session-info" minOccurs="0" />
<xsd:element ref="packages" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generalInfo" type="generalInfoType" />
<!-- session-info -->
<xsd:complexType name="session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="action" type="action.datatype"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="session-info" type="session-infoType" />
<!-- packages -->
<xsd:complexType name="packagesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="package" type="xsd:string" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="packages" type="packagesType"/>
<!--
#####################################################
ivrInfo TYPE
ivrInfoタイプ
#####################################################
-->
<!-- ivrInfo -->
<xsd:complexType name="ivrInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="ivr-sessions" minOccurs="0" />
<xsd:element ref="file-formats" minOccurs="0" />
<xsd:element ref="dtmf-type" minOccurs="0" />
<xsd:element ref="tones" minOccurs="0" />
<xsd:element ref="asr-tts" minOccurs="0" />
<xsd:element ref="vxml" minOccurs="0" />
<xsd:element ref="location" minOccurs="0" />
<xsd:element ref="encryption" minOccurs="0" />
<xsd:element ref="application-data" minOccurs="0" />
<xsd:element ref="max-prepared-duration" minOccurs="0" />
<xsd:element ref="file-transfer-modes" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ivrInfo" type="ivrInfoType" />
<!--
#####################################################
mixerInfo TYPE
ミキサ情報タイプ
#####################################################
-->
<!-- mixerInfo -->
<xsd:complexType name="mixerInfoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="mixers" minOccurs="0"/>
<xsd:element ref="file-formats" minOccurs="0"/>
<xsd:element ref="dtmf-type" minOccurs="0"/>
<xsd:element ref="tones" minOccurs="0"/>
<xsd:element ref="mixing-modes" minOccurs="0"/>
<xsd:element ref="application-data" minOccurs="0"/>
<xsd:element ref="location" minOccurs="0"/>
<xsd:element ref="encryption" minOccurs="0"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixerInfo" type="mixerInfoType" />
<!--
#####################################################
mediaResourceResponse TYPE
mediaResourceResponse TYPE
#####################################################
-->
<!-- mediaResourceResponse -->
<xsd:complexType name="mediaResourceResponseType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="response-session-info" minOccurs="0" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string"
use="required" />
<xsd:attribute name="status" type="status.datatype"
use="required" />
<xsd:attribute name="reason" type="xsd:string" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mediaResourceResponse"
type="mediaResourceResponseType" />
<!--
####################################################
ELEMENTS
ELEMENTS
####################################################
-->
<!-- response-session-info -->
<xsd:complexType name="response-session-infoType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="session-id" type="id.datatype"/>
<xsd:element name="seq" type="xsd:nonNegativeInteger"/>
<xsd:element name="expires" type="xsd:nonNegativeInteger"/>
<xsd:element ref="media-server-address"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="response-session-info"
type="response-session-infoType" />
<!-- media-server-address -->
<xsd:complexType name="media-server-addressTYPE">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="connection-id" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element ref="ivr-sessions" minOccurs="0"/>
<xsd:element ref="mixers" minOccurs="0"/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="uri" type="xsd:anyURI" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="media-server-address"
type="media-server-addressTYPE" />
<!-- ivr-sessions -->
<xsd:complexType name="ivr-sessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ivr-sessions" type="ivr-sessionsType" />
<xsd:complexType name="rtp-codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="decoding" type="xsd:nonNegativeInteger" />
<xsd:element name="encoding" type="xsd:nonNegativeInteger" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="rtp-codec" type="rtp-codecType" />
<!-- file-formats -->
<xsd:complexType name="file-formatsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="required-format"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-formats" type="file-formatsType" />
<xsd:complexType name="required-formatType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="required-file-package"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="required-format" type="required-formatType" />
<xsd:complexType name="required-file-packageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="required-file-package-name" type="xsd:string"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="required-file-package"
type="required-file-packageType" />
<!-- dtmf-type -->
<xsd:complexType name="dtmfType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="detect" />
<xsd:element ref="generate" />
<xsd:element ref="passthrough" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf" type="dtmfType" />
<xsd:complexType name="detectType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="detect" type="detectType" />
<xsd:complexType name="generateType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="generate" type="generateType" />
<xsd:complexType name="passthroughType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="dtmf-type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="passthrough" type="passthroughType" />
<xsd:complexType name="dtmf-typeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="dtmf.datatype" use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="dtmf-type" type="dtmf-typeType" />
<!-- tones -->
<xsd:complexType name="required-tonesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-codes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="h248-codes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tones" type="required-tonesType" />
<xsd:complexType name="required-country-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="country-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="country-codes"
type="required-country-codesType" />
<xsd:complexType name="country-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="country-code" type="country-codeType" />
<xsd:complexType name="required-h248-codesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="h248-code"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="h248-codes"
type="required-h248-codesType" />
<xsd:complexType name="h248-codeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="h248-code" type="h248-codeType" />
<!-- asr-tts -->
<xsd:complexType name="asr-ttsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="asr-support"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="tts-support"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-tts" type="asr-ttsType" />
<xsd:complexType name="asr-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="asr-support" type="asr-supportType" />
<xsd:complexType name="tts-supportType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="language"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="tts-support" type="tts-supportType" />
<xsd:complexType name="languageType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute ref="xml:lang" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="language" type="languageType" />
<!-- vxml -->
<xsd:complexType name="vxmlType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="vxml-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml" type="vxmlType" />
<xsd:complexType name="vxml-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:attribute name="require" type="vxml.datatype" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="vxml-mode" type="vxml-modeType" />
<!-- location -->
<xsd:complexType name="locationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="ca:civicAddress"
minOccurs="1" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="location" type="locationType" />
<!-- encryption -->
<xsd:complexType name="encryptionType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="encryption" type="encryptionType" />
<!-- application-data -->
<xsd:element name="application-data" type="appdata.datatype" />
<!-- max-prepared-duration -->
<xsd:complexType name="max-prepared-durationType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="max-time" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-prepared-duration"
type="max-prepared-durationType" />
<xsd:complexType name="max-timeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element name="max-time-package" type="xsd:string" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="max-time-seconds" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="max-time" type="max-timeType" />
<!-- file-transfer-modes -->
<xsd:complexType name="file-transfer-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="file-transfer-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-transfer-modes"
type="file-transfer-modesType" />
<xsd:complexType name="file-transfer-modeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="transfermode.datatype"
use="required" />
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="file-transfer-mode" type="file-transfer-modeType" />
<!-- mixers -->
<xsd:complexType name="mixerssessionsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="mix" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixers" type="mixerssessionsType" />
<xsd:complexType name="mixType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="rtp-codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="users" type="xsd:nonNegativeInteger"
use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mix" type="mixType" />
<!-- mixing-modes -->
<xsd:complexType name="mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="video-mixing-modes"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="mixing-modes" type="mixing-modesType" />
<xsd:complexType name="audio-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="audio-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="audio-mixing-modes" type="audio-mixing-modesType" />
<xsd:complexType name="audio-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="audio-mixing-mode" type="audio-mixing-modeType" />
<xsd:complexType name="video-mixing-modesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="video-mixing-mode"
minOccurs="0" maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="vas" type="boolean.datatype"
default="false" />
<xsd:attribute name="activespeakermix" type="boolean.datatype"
default="false" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="video-mixing-modes" type="video-mixing-modesType" />
<xsd:complexType name="video-mixing-modeType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="package" type="xsd:string" use="required" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="video-mixing-mode" type="video-mixing-modeType" />
<!--
####################################################
DATATYPES
データ型
####################################################
-->
<xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="id.datatype">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="[0-9][0-9][0-9]" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="transfermode.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="action.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="remove" />
<xsd:enumeration value="update" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="dtmf.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="vxml.datatype">
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>
<xsd:simpleType name="appdata.datatype">
<xsd:restriction base="xsd:string" />
</xsd:simpleType>
</xsd:schema>
The MRB network entity has two primary interfaces -- Publish and Consumer -- that carry sensitive information and must therefore be appropriately protected and secured.
The MRB network entity has two primary interfaces -- Publish and Consumer -- that carry sensitive information and must therefore be appropriately protected and secured.
The Publish interface, as defined in and described in Section 5.1, uses the Media Control Channel Framework [RFC6230] as a mechanism to connect an MRB to a Media Server. It is very important that the communication between the MRB and the Media Server is secured: a malicious entity may change or even delete subscriptions to a Media Server, thus affecting the view the MRB has of the resources actually available on a Media Server, leading it to incorrect selection when media resources are being requested by an Application Server. A malicious entity may even manipulate available resources on a Media Server, for example, to make the MRB think no resources are available at all. Considering that the Publish interface is a CFW Control Package, the same security considerations included in the Media Control Channel Framework specification apply here to protect interactions between an MRB and a Media Server.
The Publish interface, as defined in and described in Section 5.1, uses the Media Control Channel Framework [RFC6230] as a mechanism to connect an MRB to a Media Server. It is very important that the communication between the MRB and the Media Server is secured: a malicious entity may change or even delete subscriptions to a Media Server, thus affecting the view the MRB has of the resources actually available on a Media Server, leading it to incorrect selection when media resources are being requested by an Application Server. A malicious entity may even manipulate available resources on a Media Server, for example, to make the MRB think no resources are available at all. Considering that the Publish interface is a CFW Control Package, the same security considerations included in the Media Control Channel Framework specification apply here to protect interactions between an MRB and a Media Server.
The Publish interface also allows a Media Server, as explained in Section 5.1.5.18, to provide more or less accurate information about its geographic location, should Application Servers be interested in such details when looking for services at an MRB. While the usage of this information is entirely optional and the level of detail to be provided is implementation specific, it is important to draw attention to the potential security issues that the disclosure of such addresses may introduce. As such, it is important to make sure MRB implementations don't disclose this information as is to interested Application Servers but only exploit those addresses as part of computation algorithms to pick the most adequate resources Application Servers may be looking for.
The Publish interface also allows a Media Server, as explained in Section 5.1.5.18, to provide more or less accurate information about its geographic location, should Application Servers be interested in such details when looking for services at an MRB. While the usage of this information is entirely optional and the level of detail to be provided is implementation specific, it is important to draw attention to the potential security issues that the disclosure of such addresses may introduce. As such, it is important to make sure MRB implementations don't disclose this information as is to interested Application Servers but only exploit those addresses as part of computation algorithms to pick the most adequate resources Application Servers may be looking for.
The Consumer interface, as defined in and described in Section 5.2, conceives transactions based on a session ID. These transactions may be transported either by means of HTTP messages or SIP dialogs. This means that malicious users could be able to disrupt or manipulate an MRB session should they have access to the above-mentioned session ID or replicate it somehow: for instance, a malicious entity could modify an existing session between an Application Server and the MRB, e.g., requesting less resources than originally requested to cause media dialogs to be rejected by the Application Server, or requesting many more resources instead to try and lock as many of (if not all) the resources an MRB can provide, thus making them unavailable to other legitimate Application Servers in subsequent requests. In order to prevent this, it is strongly advised that MRB implementations generate session identifiers that are very hard to replicate, in order to minimize the chances that malicious users could gain access to valid identifiers by just guessing or by means of brute-force attacks. It is very important, of course, to also secure the way that these identifiers are transported by the involved parties, in both requests and responses, in order to prevent network attackers from intercepting Consumer messages and having access to session IDs. The Consumer interface uses either the Hypertext Transfer Protocol (HTTP) or the Session Initiation Protocol (SIP) as the mechanism for clients to connect to an MRB to request media resources. In the case where HTTP is used, any binding using the Consumer interface MUST be capable of being transacted over Transport Layer Security (TLS), as described in RFC 2818 [RFC2818]. In the case where SIP is used, the same security considerations included in the Media Control Channel Framework specification apply here to protect interactions between a client requesting media resources and an MRB.
The Consumer interface, as defined in and described in Section 5.2, conceives transactions based on a session ID. These transactions may be transported either by means of HTTP messages or SIP dialogs. This means that malicious users could be able to disrupt or manipulate an MRB session should they have access to the above-mentioned session ID or replicate it somehow: for instance, a malicious entity could modify an existing session between an Application Server and the MRB, e.g., requesting less resources than originally requested to cause media dialogs to be rejected by the Application Server, or requesting many more resources instead to try and lock as many of (if not all) the resources an MRB can provide, thus making them unavailable to other legitimate Application Servers in subsequent requests. In order to prevent this, it is strongly advised that MRB implementations generate session identifiers that are very hard to replicate, in order to minimize the chances that malicious users could gain access to valid identifiers by just guessing or by means of brute-force attacks. It is very important, of course, to also secure the way that these identifiers are transported by the involved parties, in both requests and responses, in order to prevent network attackers from intercepting Consumer messages and having access to session IDs. The Consumer interface uses either the Hypertext Transfer Protocol (HTTP) or the Session Initiation Protocol (SIP) as the mechanism for clients to connect to an MRB to request media resources. In the case where HTTP is used, any binding using the Consumer interface MUST be capable of being transacted over Transport Layer Security (TLS), as described in RFC 2818 [RFC2818]. In the case where SIP is used, the same security considerations included in the Media Control Channel Framework specification apply here to protect interactions between a client requesting media resources and an MRB.
Should a valid session ID be compromised somehow (that is, intercepted or just guessed by a malicious user), as a further means to prevent disruption the Consumer interface also prescribes the use of a sequence number in its transactions. This sequence number is to be increased after each successful transaction, starting from a first value randomly generated by the MRB when the session is first created, and it must match in every request/response. While this adds complexity to the protocol (implementations must pay attention to those sequence numbers, since wrong values will cause "Wrong sequence number" errors and the failure of the related requests), it is an important added value for security. In fact, considering that different transactions related to the same session could be transported in different, unrelated HTTP messages (or SIP INVITEs in cases where the In-line mode is being used), this sequence number protection prevents the chances of session replication or disruption, especially in cases where the session ID has been compromised: that is, it should make it harder for malicious users to manipulate or remove a session for which they have obtained the session ID. It is strongly advised that the MRB doesn't choose 1 as the first sequence number for a new session but rather picks a random value to start from. The reaction to transactions that are out of sequence is left to MRB implementations: a related error code is available, but implementations may decide to enforce further limitations or actions upon the receipt of too many failed attempts in a row or of what looks like blatant attempts to guess what the current, valid sequence number is.
Should a valid session ID be compromised somehow (that is, intercepted or just guessed by a malicious user), as a further means to prevent disruption the Consumer interface also prescribes the use of a sequence number in its transactions. This sequence number is to be increased after each successful transaction, starting from a first value randomly generated by the MRB when the session is first created, and it must match in every request/response. While this adds complexity to the protocol (implementations must pay attention to those sequence numbers, since wrong values will cause "Wrong sequence number" errors and the failure of the related requests), it is an important added value for security. In fact, considering that different transactions related to the same session could be transported in different, unrelated HTTP messages (or SIP INVITEs in cases where the In-line mode is being used), this sequence number protection prevents the chances of session replication or disruption, especially in cases where the session ID has been compromised: that is, it should make it harder for malicious users to manipulate or remove a session for which they have obtained the session ID. It is strongly advised that the MRB doesn't choose 1 as the first sequence number for a new session but rather picks a random value to start from. The reaction to transactions that are out of sequence is left to MRB implementations: a related error code is available, but implementations may decide to enforce further limitations or actions upon the receipt of too many failed attempts in a row or of what looks like blatant attempts to guess what the current, valid sequence number is.
It is also worth noting that in In-line mode (both IAMM and IUMM) the MRB may act as a Back-to-Back User Agent (B2BUA). This means that when acting as a B2BUA the MRB may modify SIP bodies: it is the case, for instance, for the IAMM handling multipart/mixed payloads. This impacts the ability to use any SIP security feature that protects the body (e.g., RFC 4474 [RFC4474], S/MIME, etc.), unless the MRB acts as a mediator for the security association. This should be taken into account when implementing an MRB compliant with this specification.
It is also worth noting that in In-line mode (both IAMM and IUMM) the MRB may act as a Back-to-Back User Agent (B2BUA). This means that when acting as a B2BUA the MRB may modify SIP bodies: it is the case, for instance, for the IAMM handling multipart/mixed payloads. This impacts the ability to use any SIP security feature that protects the body (e.g., RFC 4474 [RFC4474], S/MIME, etc.), unless the MRB acts as a mediator for the security association. This should be taken into account when implementing an MRB compliant with this specification.
Both the Publishing interface and Consumer interface may address the location of a Media Server: the Publishing interface may be used to inform the MRB where a Media Server is located (approximately or precisely), and the Consumer interface may be used to ask for a Media Server located somewhere in a particular region (e.g., a conference bridge close to San Francisco). Both Media Server and MRB implementers need to take this into account when deciding whether or not to make this location information available, and if so how many bits of information really need to be made available for brokering purposes.
Both the Publishing interface and Consumer interface may address the location of a Media Server: the Publishing interface may be used to inform the MRB where a Media Server is located (approximately or precisely), and the Consumer interface may be used to ask for a Media Server located somewhere in a particular region (e.g., a conference bridge close to San Francisco). Both Media Server and MRB implementers need to take this into account when deciding whether or not to make this location information available, and if so how many bits of information really need to be made available for brokering purposes.
It is worthwhile to cover authorization issues related to this specification. Neither the Publishing interface nor the Consumer interface provides an explicit means for implementing authentication, i.e., they do not contain specific protocol interactions to ensure that authorized Application Servers can make use of the services provided by an MRB instance. Considering that both interfaces are transported using well-established protocols (HTTP, SIP, CFW), support for such functionality can be expressed by means of the authentication mechanisms provided by the protocols themselves. Therefore, any MRB-aware entity (Application Servers, Media Servers, MRBs themselves) MUST support HTTP and SIP Digest access authentication. The usage of such Digest access authentications is recommended and not mandatory, which means MRB-aware entities MAY exploit it in deployment.
It is worthwhile to cover authorization issues related to this specification. Neither the Publishing interface nor the Consumer interface provides an explicit means for implementing authentication, i.e., they do not contain specific protocol interactions to ensure that authorized Application Servers can make use of the services provided by an MRB instance. Considering that both interfaces are transported using well-established protocols (HTTP, SIP, CFW), support for such functionality can be expressed by means of the authentication mechanisms provided by the protocols themselves. Therefore, any MRB-aware entity (Application Servers, Media Servers, MRBs themselves) MUST support HTTP and SIP Digest access authentication. The usage of such Digest access authentications is recommended and not mandatory, which means MRB-aware entities MAY exploit it in deployment.
An MRB may want to enforce further constraints on the interactions between an Application Server/Media Server and an MRB. For example, it may choose to only accept requests associated with a specific session ID from the IP address that originated the first request or may just make use of pre-shared certificates to assess the identity of legitimate Application Servers and/or Media Servers.
An MRB may want to enforce further constraints on the interactions between an Application Server/Media Server and an MRB. For example, it may choose to only accept requests associated with a specific session ID from the IP address that originated the first request or may just make use of pre-shared certificates to assess the identity of legitimate Application Servers and/or Media Servers.
There are several IANA considerations associated with this specification.
There are several IANA considerations associated with this specification.
This section registers a new Media Control Channel Framework package, per the instructions in Section 13.1 of [RFC6230].
This section registers a new Media Control Channel Framework package, per the instructions in Section 13.1 of [RFC6230].
Package Name: mrb-publish/1.0
Package Name: mrb-publish/1.0
Published Specification(s): RFC 6917
Published Specification(s): RFC 6917
Person and email address to contact for further information: IETF MediaCtrl working group (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
Person and email address to contact for further information: IETF MediaCtrl working group (mediactrl@ietf.org), Chris Boulton (chris@ns-technologies.com).
To: application
To: application
Subject: Registration of media type application/mrb-publish+xml
Type name: application
Type name: application
Subtype name: mrb-publish+xml
Subtype name: mrb-publish+xml
Required parameters: none
Required parameters: none
Optional parameters: Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023].
オプションのパラメーター：RFC 3023 [RFC3023]で指定されているapplication / xmlのcharsetパラメーターと同じです。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 12 of RFC 6917.
セキュリティに関する考慮事項：RFC 3023 [RFC3023]のセクション10とRFC 6917のセクション12を参照してください。
Interoperability considerations: none.
Interoperability considerations: none.
Published specification: Section 10 of RFC 6917.
公開された仕様：RFC 6917のセクション10。
Applications that use this media type: This media type is used to support a Media Resource Broker (MRB) entity.
Applications that use this media type: This media type is used to support a Media Resource Broker (MRB) entity.
Additional Information:
追加情報：
Magic Number: None
Magic Number: None
File Extension: .xdf
File Extension: .xdf
Macintosh file type code: "TEXT"
Macintosh file type code: "TEXT"
Person and email address to contact for further information: Chris Boulton (chris@ns-technologies.com).
詳細について連絡する人と電子メールアドレス：Chris Boulton（chris@ns-technologies.com）。
Intended usage: COMMON
Intended usage: COMMON
Author/Change controller: The IETF.
Author/Change controller: The IETF.
To: application
宛先：アプリケーション
Subject: Registration of media type application/mrb-consumer+xml
Type name: application
タイプ名：アプリケーション
Subtype name: mrb-consumer+xml
サブタイプ名：mrb-consumer + xml
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023].
Optional parameters: Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
エンコーディングに関する考慮事項：RFC 3023 [RFC3023]で指定されているapplication / xmlのエンコーディングに関する考慮事項と同じです。
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 12 of RFC 6917.
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 12 of RFC 6917.
Interoperability considerations: none.
相互運用性に関する考慮事項：なし。
Published specification: Section 11 of RFC 6917.
Published specification: Section 11 of RFC 6917.
Applications that use this media type: This media type is used to support a Media Resource Broker (MRB) entity.
Applications that use this media type: This media type is used to support a Media Resource Broker (MRB) entity.
Additional Information:
Additional Information:
Magic Number: None
Magic Number: None
File Extension: .xdf
ファイル拡張子：.xdf
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「TEXT」
Person and email address to contact for further information: Chris Boulton (chris@ns-technologies.com).
詳細について連絡する人と電子メールアドレス：Chris Boulton（chris@ns-technologies.com）。
Intended usage: COMMON
Intended usage: COMMON
Author/Change controller: The IETF.
Author/Change controller: The IETF.
IANA has registered the URN "urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish". The schema of the XML namespace named urn:ietf:params:xml:ns:mrb-publish is in Section 10.
IANA has registered the URN "urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish". The schema of the XML namespace named urn:ietf:params:xml:ns:mrb-publish is in Section 10.
IANA has registered the URN "urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer". The schema of the XML namespace named urn:ietf:params:xml:ns:mrb-consumer is in Section 11.
IANAは、URN "urn：ietf：params：xml：ns：mrb-consumer"をID "mrb-consumer"で登録しました。 urn：ietf：params：xml：ns：mrb-consumerという名前のXML名前空間のスキーマは、セクション11にあります。
IANA has registered the schema for mrb-publish:
IANAはmrb-publishのスキーマを登録しました。
URI: urn:ietf:params:xml:schema:mrb-publish
ID: mrb-publish
ID：mrb-publish
Filename: mrb-publish
ファイル名：mrb-publish
Registrant Contact: IETF MediaCtrl working group (mediactrl@ietf.org)
登録者の連絡先：IETF MediaCtrlワーキンググループ（mediactrl@ietf.org）
Schema: The XML for the schema is in Section 10 of this document.
スキーマ：スキーマのXMLは、このドキュメントのセクション10にあります。
Please register the schema for mrb-consumer:
mrb-consumerのスキーマを登録してください：
URI: urn:ietf:params:xml:schema:mrb-consumer
ID: mrb-consumer
ID：mrb-consumer
Filename: mrb-consumer
ファイル名：mrb-consumer
Registrant Contact: IETF MediaCtrl working group (mediactrl@ietf.org)
Registrant Contact: IETF MediaCtrl working group (mediactrl@ietf.org)
Schema: The XML for the schema is in Section 11 of this document.
スキーマ：スキーマのXMLは、このドキュメントのセクション11にあります。
The authors would like to thank the members of the Publish Interface design team, who provided valuable input into this document. The design team consisted of Adnan Saleem, Michael Trank, Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also like to thank John Dally, Bob Epley, Simon Romano, Henry Lum, Christian Groves, and Jonathan Lennox for input into this specification.
著者は、このドキュメントに貴重な情報を提供してくれたPublish Interfaceデザインチームのメンバーに感謝します。設計チームは、アドナン・サリーム、マイケル・トランク、ビクター・ポールサミー、マーティン・ドリー、およびスコット・マクグラシャンで構成されていました。著者は、この仕様への入力についてジョン・ダリー、ボブ・エプリー、サイモン・ロマーノ、ヘンリー・ラム、クリスチャン・グローブス、およびジョナサン・レノックスにも感謝します。
Ben Campbell carried out the RAI expert review on an early version of this specification and provided a great deal of invaluable input.
Ben Campbellは、この仕様の初期バージョンについてRAIの専門家によるレビューを実施し、非常に貴重な情報を数多く提供しました。
[ISO.10646.2012] International Organization for Standardization, "Information technology -- Universal Coded Character Set (UCS)", ISO Standard 10646, 2012.
[ISO.10646.2012]国際標準化機構、「情報技術-ユニバーサルコード化文字セット（UCS）」、ISO標準10646、2012。
[ISO.3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard 3166-1:2006, 2006.
[ISO.3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard 3166-1:2006, 2006.
[ISO.639.2002] International Organization for Standardization, "Codes for the representation of names of languages -- Part 1: Alpha-2 code", ISO Standard 639, 2002.
[ISO.639.2002]国際標準化機構、「言語の名前を表すためのコード-パート1：Alpha-2コード」、ISO標準639、2002。
[ITU-T.Q.1950] International Telecommunication Union, "Bearer independent call bearer control protocol", ITU-T Recommendation Q.1950, December 2002.
[ITU-T.Q.1950]国際電気通信連合、「ベアラ独立コールベアラ制御プロトコル」、ITU-T勧告Q.1950、2002年12月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[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：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、J。、「セッション開始プロトコル（SIP）UPDATEメソッド」、RFC 3311、2002年10月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010.
[RFC5763] Fischl、J.、Tschofenig、H。、およびE. Rescorla、「Datagram Transport Layer Security（DTLS）を使用したセキュアなリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク」、RFC 5763、2010年5月。
[W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-xmlschema-2-20041028] Biron、P.およびA. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、World Wide Web Consortium Recommendation REC-xmlschema-2-20041028、2004年10月、<http： //www.w3.org/TR/2004/REC-xmlschema-2-20041028>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]バーガー、E。、ヴァンダイク、J。、およびA.スピッツァー、「SIPを使用した基本的なネットワークメディアサービス」、RFC 4240、2005年12月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、2006年8月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733] Schulzrinne、H。およびT. Taylor、「DTMFディジット、テレフォニートーン、およびテレフォニーシグナルのRTPペイロード」、RFC 4733、2006年12月。
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
[RFC5167]ドリー、M。およびR.でも、「Media Server Control Protocol Requirements」、RFC 5167、2008年3月。
[RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media Services", RFC 5552, May 2009.
[RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media Services", RFC 5552, May 2009.
[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月。
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup Language (MSML)", RFC 5707, February 2010.
[RFC5707] Saleem、A.、Xin、Y。、およびG. Sharratt、「Media Server Markup Language（MSML）」、RFC 5707、2010年2月。
[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, May 2011.
[RFC6230]ボウルトン、C。、メランチュク、T。、およびS.マグラスハン、「Media Control Channel Framework」、RFC 6230、2011年5月。
[RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", RFC 6231, May 2011.
[RFC6231] McGlashan、S.、Melanchuk、T。、およびC. Boulton、「メディアコントロールチャネルフレームワーク用のインタラクティブ音声応答（IVR）制御パッケージ」、RFC 6231、2011年5月。
[RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types", RFC 6381, August 2011.
[RFC6381] Gellens、R.、Singer、D。、およびP. Frojdh、「「コーデック」および「プロファイル」パラメータの「バケット」メディアタイプ」、RFC 6381、2011年8月。
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012.
[RFC6501] Novo、O.、Camarillo、G.、Morgan、D。、およびJ. Urpalainen、「集中会議（XCON）の会議情報データモデル」、RFC 6501、2012年3月。
[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月。
Authors' Addresses
著者のアドレス
Chris Boulton NS-Technologies
クリス・ボールトンNSテクノロジーズ
EMail: chris@ns-technologies.com
Lorenzo Miniero Meetecho Via Carlo Poerio 89 Napoli 80100 Italy
Lorenzo Miniero Meetecho Via Carlo Poerio 89ナポリ80100イタリア
EMail: lorenzo@meetecho.com
Gary Munson AT&T 200 Laurel Avenue South Middletown, New Jersey 07748 USA
Gary Munson AT＆T 200 Laurel Avenue South Middletown、New Jersey 07748 USA
EMail: gamunson@gmail.com