Network Working Group J. Van Dyke
Request for Comments: 5022 Cantata Technology, Inc.
Obsoletes: 4722 E. Burger, Ed.
Category: Informational BEA Systems, Inc.
A. Spitzer
Bluesocket Inc.
September 2007
Media Server Control Markup Language (MSCML) and Protocol
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
Abstract
抽象
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.
メディアサーバ制御マークアップ言語（MSCML）は、高度な会議や対話型音声応答（IVR）機能を提供するために、SIPと一緒に使用するマークアップ言語です。デバイスレベルの制御モデルとは対照的に、MSCMLは、アプリケーションレベルの制御モデルを提示します。このプロトコルの1つの用途は、IETF SIP会議フレームワークにおける会議フォーカスとミキサとの間の通信のためのものです。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. MSCML Approach ..................................................5
3. Use of SIP Request Methods ......................................6
4. MSCML Design ....................................................8
4.1. Transaction Model ..........................................8
4.2. XML Usage ..................................................9
4.2.1. MSCML Time Values ...................................9
5. Advanced Conferencing ..........................................10
5.1. Conference Model ..........................................10
5.2. Configure Conference Request <configure_conference> .......11
5.3. Configure Leg Request <configure_leg> .....................13
5.4. Terminating a Conference ..................................14
5.5. Conference Manipulation ...................................15
5.6. Video Conferencing ........................................16
5.7. Conference Events .........................................17
5.8. Conferencing with Personalized Mixes ......................18
5.8.1. MSCML Elements and Attributes for
Personalized Mixes .................................19
5.8.2. Example Usage of Personalized Mixes ................20
6. Interactive Voice Response (IVR) ...............................23
6.1. Specifying Prompt Content .................................24
6.1.1. Use of the Prompt Element ..........................24
6.2. Multimedia Processing for IVR .............................30
6.3. Playing Announcements <play> ..............................31
6.4. Prompt and Collect <playcollect> ..........................32
6.4.1. Control of Digit Buffering and Barge-In ............33
6.4.2. Mapping DTMF Keys to Special Functions .............33
6.4.3. Collection Timers ..................................35
6.4.4. Logging Caller DTMF Input ..........................36
6.4.5. Specifying DTMF Grammars ...........................36
6.4.6. Playcollect Response ...............................37
6.4.7. Playcollect Example ................................38
6.5. Prompt and Record <playrecord> ............................38
6.5.1. Prompt Phase .......................................38
6.5.2. Record Phase .......................................39
6.5.3. Playrecord Example .................................41
6.6. Stop Request <stop> .......................................42
7. Call Leg Events ................................................43
7.1. Keypress Events ...........................................43
7.1.1. Keypress Subscription Examples .....................45
7.1.2. Keypress Notification Examples .....................45
7.2. Signal Events .............................................46
7.2.1. Signal Event Examples ..............................47
8. Managing Content <managecontent> ...............................48
8.1. Managecontent Example .....................................50
9. Fax Processing .................................................51
9.1. Recording a Fax <faxrecord> ...............................51
9.2. Sending a Fax <faxplay> ...................................53
10. MSCML Response Attributes and Elements ........................56
10.1. Mechanism ................................................56
10.2. Base <response> Attributes ...............................56
10.3. Response Attributes and Elements for <configure_leg> .....57
10.4. Response Attributes and Elements for <play> ..............57
10.4.1. Reporting Content Retrieval Errors ...............58
10.5. Response Attributes and Elements for <playcollect> .......59
10.6. Response Attributes and Elements for <playrecord> ........60
10.7. Response Attributes and Elements for <managecontent> .....61
10.8. Response Attributes and Elements for <faxplay>
and <faxrecord> ..........................................61
11. Formal Syntax .................................................62
11.1. Schema ...................................................62
12. IANA Considerations ...........................................73
12.1. IANA Registration of MIME Media Type application/
mediaservercontrol+xml ...................................73
13. Security Considerations .......................................74
14. References ....................................................75
14.1. Normative References .....................................75
14.2. Informative References ...................................76
Appendix A. Regex Grammar Syntax .................................78
Appendix B. Contributors .........................................79
Appendix C. Acknowledgements .....................................79
This document describes the Media Server Control Markup Language (MSCML) and its usage. It describes payloads that one can send to a media server using standard SIP INVITE and INFO methods and the capabilities these payloads implement. RFC 4240 [2] describes media server SIP URI formats.
この文書では、メディアサーバ制御マークアップ言語（MSCML）とその使用方法について説明します。これは、1つのINVITE標準SIPを使用してINFO方法およびこれらのペイロードが実装機能メディアサーバに送信できるペイロードを説明します。 RFC 4240 [2]メディアサーバSIP URIフォーマットを記述する。
Prior to MSCML, there was not a standard way to deliver SIP-based enhanced conferencing. Basic SIP constructs, such as those described in RFC 4240 [2], serve simple n-way conferencing well. The SIP URI provides a natural mechanism for identifying a specific SIP conference, while INVITE and BYE methods elegantly implement conference join and leave semantics. However, enhanced conferencing applications also require features such as sizing and resizing, in-conference IVR operations (e.g., recording and playing participant names to the full conference), and conference event reporting. MSCML payloads within standard SIP methods realize these features.
MSCMLに先立ち、SIPベースの高度な会議を実現するための標準的な方法はありませんでした。そのようなRFC 4240に記載されているような基本的なSIP構築物は、[2]、よく簡単n-ウェイ会議を果たします。 INVITEながらSIP URIは、特定のSIP会議を識別するための自然なメカニズムを提供し、BYEメソッドは、エレガントな会議参加及び残すセマンティクスを実装します。ただし、強化された会議アプリケーションはまた、サイズ調整やサイズ変更などの機能を必要とし、中会議IVR操作が（例えば、記録およびフル会議に参加者名を演奏）、および会議イベントが報告します。標準のSIPメソッド内MSCMLペイロードは、これらの機能を実現します。
The structure and approach of MSCML satisfy the requirements set out in RFC 4353 [10]. In particular, MSCML serves as the interface between the conference server or focus and a centralized conference mixer. In this case, a media server has the role of the conference mixer.
MSCMLの構造及び手法は、RFC 4353 [10]に記載された要件を満たします。特に、MSCMLは、会議サーバまたは焦点と集中会議ミキサーとの間のインターフェースとして機能します。この場合、メディアサーバは、会議ミキサーの役割を担っています。
There are two broad classes of MSCML functionality. The first class includes primitives for advanced conferencing, such as conference configuration, participant leg manipulation, and conference event reporting. The second class comprises primitives for interactive voice response (IVR). These include collecting DTMF digits and playing and recording multimedia content.
MSCML機能の二つの広いクラスがあります。最初のクラスは、会議の設定、参加者の足操作、および会議イベントのレポートなどの高度な会議のためのプリミティブを、含まれています。第二のクラスは、対話型音声応答（IVR）のためのプリミティブを含みます。これらは、DTMFディジットを収集し、マルチメディアコンテンツを再生し、記録しています。
MSCML fills the need for IVR and conference control with requests and responses over a SIP transport. VoiceXML [11] fills the need for IVR with requests and responses over a HTTP transport. This enables developers to use whatever model fits their needs best.
MSCMLは、SIPトランスポート上の要求と応答でIVR、会議コントロールの必要性を満たします。 VoiceXMLは、[11]はHTTPトランスポート上の要求と応答とのIVRの必要性を満たします。これは、最高の自分のニーズに合ったどんなモデルを使用する開発者を可能にします。
In general, a media server offers services to SIP UACs, such as Application Servers, Feature Servers, and Media Gateway Controllers. See the IPCC Reference Architecture [12] for definitions of these terms. It is unlikely, but not prohibited, for end-user SIP UACs to have a direct signaling relationship with a media server. The term "client" is used in this document to refer generically to an entity that interacts with the media server using SIP and MSCML.
一般的には、メディアサーバは、アプリケーションサーバ、フィーチャーサーバー、およびメディアゲートウェイコントローラとして、SIP求めるUACにサービスを提供しています。これらの用語の定義については、IPCCのリファレンスアーキテクチャ[12]を参照してください。エンドユーザーSIP求めるUACは、メディアサーバーとの直接のシグナリング関係を持っていることは、ほとんどありませんが、禁止されていません。用語「クライアント」は、SIPとMSCMLを使用してメディアサーバーと対話するエンティティを包括的に参照するために、このドキュメントで使用されています。
The media server fulfills the role of the Media Resource Function (MRF) in the IP Multimedia Subsystem (IMS) [13] as described by 3GPP. MSCML and RFC 4240 [2], upon which MSCML builds, are specifically focused on the Media resource (Mr) interface which supports interactions between application logic and the MRF.
メディアサーバーは、3GPPによって記載されているように、IPマルチメディアサブシステム（IMS）[13]でメディアリソース機能（MRF）の役割を果たす。 MSCML及びRFC 4240 [2]、MSCMLビルドその上には、具体的には、アプリケーションロジックとMRFとの間の相互作用をサポートするメディアリソース（MR）インターフェイスに焦点を当てています。
This document describes a working framework and protocol with which there is considerable implementation experience. Application developers and service providers have created several MSCML-based services since the availability of the initial version in 2001. This experience is highly relevant to the ongoing work of the IETF, particularly the SIP [26], SIPPING [27], MMUSIC [28], and XCON [29] work groups, the IMS [30] work in 3GPP, and the CCXML work in the Voice Browser Work Group of the W3C.
この文書では、かなりの実装経験があると協力の枠組みとプロトコルについて説明します。アプリケーション開発者やサービスプロバイダーは、この経験は、[27]、MMUSIC [28を飲み、IETF、特にSIP [26]の進行中の作業に非常に関連性がある2001年に最初のバージョンの可用性以来、いくつかのMSCMLベースのサービスを作成しました]、およびXCON [29]はグループの仕事、IMS [30]は、3GPPでの作業、およびW3Cの音声ブラウザワーキンググループでCCXML作業。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
It is critically important to emphasize that the goal of MSCML is to provide an application interface that follows the SIP, HTTP, and XML development paradigm to foster easier and more rapid application deployment. This goal is reflected in MSCML in two ways.
MSCMLの目標は、より簡単に、より迅速なアプリケーション展開を促進するためにSIP、HTTP、およびXML開発パラダイムを以下のアプリケーション・インターフェースを提供することであることを強調することが非常に重要です。この目標は、2つの方法でMSCMLに反映されています。
First, the programming model is that of peer to peer rather than master-slave. Importantly, this allows the media server to be used simultaneously for multiple applications rather than be tied to a single point of control. It also enables standard SIP mechanisms to be used for media server location and load balancing.
まず、プログラミング・モデルではなく、マスタースレーブよりピアツーピアのものです。重要なことに、これは、メディアサーバが複数のアプリケーションのために同時に使用されるよりもむしろ単一の制御ポイントに接続することが可能となります。また、メディアサーバーの場所と負荷分散のために使用される標準のSIPメカニズムを可能にします。
Second, MSCML defines constructs and primitives that are meaningful at the application level to ensure that programmers are not distracted by unnecessary complexity. For example, the mixing resource operates on constructs such as conferences and call participants rather than directly on individual media streams.
第二に、MSCMLはプログラマが不必要に複雑に気を取られていないことを保証するために、アプリケーション・レベルで意味のある構築物およびプリミティブを定義します。例えば、混合リソースは、個々のメディアストリーム上の会議通話の参加者ではなく、直接的に構築上で動作します。
The MSCML paradigm is important to the developer community, in that developers and operators conceptually write applications about calls, conferences, and call legs. For the majority of developers and applications this approach significantly simplifies and speeds development.
開発者とオペレータが概念的に呼び出し、会議に関するアプリケーションを作成し、足を呼び出すことでMSCMLパラダイムは、開発者コミュニティにとって重要です。開発者と大多数のアプリケーションでは、このアプローチは、大幅に簡素化し、開発をスピードアップします。
As mentioned above, MSCML payloads may be carried in either SIP INVITE or INFO requests. The initial INVITE, which creates an enhanced conference, MAY include an MSCML payload. A subsequent INVITE to the same Request-URI joins a participant leg to the conference. This INVITE MAY include an MSCML payload. The initial INVITE that establishes an IVR session MUST NOT include an MSCML payload. The client sends all mid-call MSCML payloads for conferencing and IVR via SIP INFO requests.
上述したように、MSCMLペイロードは、SIP INVITEまたはINFO要求のいずれかで行うことができます。初期はMSCMLペイロードを含み、強化された会議を作成する、INVITE。それ以降は、同じ要求URIにINVITE会議に参加者の足を結合します。このINVITEはMSCMLペイロードを含むかもしれません。初期には、それがMSCMLペイロードを含んではいけませんIVRセッションを確立INVITE。クライアントは、SIP INFOリクエストを経由して会議やIVRのためのすべてのミッド呼び出すMSCMLペイロードを送信します。
SIP INVITE requests that contain both MSCML and Session Description Protocol (SDP) body parts are used frequently in conferencing scenarios. Therefore, the media server MUST support message bodies with the MIME type "multipart/mixed" in SIP INVITE requests.
会議のシナリオで頻繁に使用されているMSCMLとセッション記述プロトコル（SDP）身体の部分の両方を含む要求を、SIP INVITE。したがって、メディアサーバは、MIMEタイプとメッセージ本文をサポートしなければならない「マルチパート/混合」SIPにおけるINVITE要求。
The media server transports MSCML responses in the final response to the SIP INVITE containing the matching MSCML request or in a SIP INFO message. The only allowable final response to a SIP INFO containing a message body is a 200 OK, per RFC 2976 [3]. Therefore, if the client sends the MSCML request via SIP INFO, the media server responds with the MSCML response in a separate INFO request. In general, these responses are asynchronous in nature and require a separate transaction due to timing considerations.
メディアサーバは、SIPに最終応答におけるMSCML応答が一致MSCML要求またはSIP INFOメッセージ内を含むINVITEを搬送します。メッセージ本体を含むSIP INFOにのみ許容される最終的な応答は、RFC 2976あたり、200 OKである[3]。クライアントは、SIP INFO経由MSCML要求を送信した場合そのため、メディアサーバは、独立したINFO要求におけるMSCML応答で応答します。一般的に、これらの応答は、本質的に非同期であり、原因タイミングの考慮事項に別のトランザクションが必要です。
There has been considerable debate on the use of the SIP INFO method for any purpose. Our experience is that MSCML would not have been possible without it. At the time the first MSCML specification was published, the first SIP Event Notification draft had just been submitted as an individual submission. At that time, there was no mechanism to link SUBSCRIBE/NOTIFY to an existing dialog. This prevented its use in MSCML, since all events occurred in an INVITE-established dialog. And while SUBSCRIBE/NOTIFY was well suited for reporting conference events, its semantics seemed inappropriate for modifying a participant leg or conference setting where the only "event" was the success or failure of the request. Lastly, since SIP INFO was an established RFC, most SIP stack implementations supported it at that time. We had few, if any, interoperability issues as a result.
任意の目的のためにSIP INFOメソッドの使用にかなりの議論がありました。私たちの経験はMSCMLはそれなしでは不可能でしたということです。最初のMSCML仕様が公開された時点では、最初のSIPイベント通知案は、単に個々の服従として提出されていました。その際、既存のダイアログにSUBSCRIBE / NOTIFYリンクするメカニズムはありませんでした。これは、すべてのイベントがINVITE確立ダイアログで発生したことから、MSCMLにおけるその使用を防止しました。 SUBSCRIBE / NOTIFYは会議イベントを報告するのに適しせながら、その意味は、唯一の「イベント」は、要求の成功または失敗した参加者の足や会議の設定を変更するには不適切なように見えました。 SIP INFOが確立RFCだったので最後に、ほとんどのSIPスタックの実装では、その時点で、それを支持しました。私たちは、結果として、もしあれば、相互運用性の問題をいくつか持っていました。
More recent developments have provided additional reasons why SUBSCRIBE/NOTIFY is not appropriate for use in MSCML. Use of SUBSCRIBE presents two problems. The first is semantic. The purpose of SUBSCRIBE is to register interest in User Agent state. However, using SUBSCRIBE for MSCML results in the SUBSCRIBE modifying the User Agent state. The second reason SUBSCRIBE is not appropriate is because MSCML is inherently call based. The association of a SIP dialog with a call leg means MSCML can be incredibly straightforward.
より最近の開発は、SUBSCRIBE / NOTIFYがMSCMLでの使用に適していないその他の理由を提供しています。 SUBSCRIBEの使用は二つの問題を提示しています。最初は、意味です。 SUBSCRIBEの目的は、ユーザーエージェントの状態への関心を登録することです。しかし、SUBSCRIBEユーザエージェント状態を変更することでMSCML結果のSUBSCRIBE使用。 MSCMLがベースの、本質的に呼び出しているので、SUBSCRIBEが適切でない第2の理由はあります。コールレッグを持つSIPダイアログの関連はMSCMLは非常に簡単にできることを意味します。
For example, if one used SUBSCRIBE or other SIP method to send commands about some context, one must identify that context somehow. Relating commands to the SIP dialog they arrive on defines the context for free. Moreover, it is conceptually easy for the developer. Using NOTIFY to transport MSCML responses is also not appropriate, as the NOTIFY would be in response to an implicit subscription. The SIP and SIPPING lists have discussed the dangers of implicit subscription.
1つのSUBSCRIBE使用したり、他のSIP方法は、いくつかの状況について、コマンドを送信した場合、1は何とかそのコンテキストを識別する必要があります。彼らは自由のためのコンテキストを定義するに到着したSIPダイアログにコマンドを関係します。また、開発者のための概念的に簡単です。暗黙のサブスクリプションに応じだろうNOTIFYとしてMSCML応答を輸送するNOTIFY使用すると、また、適切ではありません。 SIPおよびSIPPINGリストは、暗黙的なサブスクリプションの危険性を議論してきました。
In order to guarantee interoperability with this specification, as well as with SIP User Agents that are unaware of MSCML, SIP UACs that wish to use MSCML services MUST specify a service indicator that supports MSCML in the initial INVITE. RFC 4240 [2] defines the service indicator "conf", which MUST be used for MSCML conferencing applications. The service indicator "ivr" MUST be used for MSCML interactive voice response applications. In this specification, only "conf" and "ivr" are described.
この仕様との相互運用性を保証するだけでなく、最初のINVITEにMSCMLをサポートするサービスインジケータを指定しなければならないMSCMLサービスを使用したいMSCML、SIP求めるUACを知らないSIPユーザーエージェントとするために。 RFC 4240 [2] MSCML会議アプリケーションのために使用しなければならないサービスインジケータ「CONF」を定義します。サービスインジケータ「IVRは」MSCML対話型音声応答アプリケーションを使用しなければなりません。この仕様では、唯一の「CONF」と「IVR」が記述されています。
The media server MUST support moving the call between services through sending the media server a BYE on the existing dialog and establishing a new dialog with an INVITE to the desired service. Media servers SHOULD support moving between services without requiring modification of the previously established SDP parameters. This is achieved by sending a re-INVITE on the existing dialog in which the Request-URI is modified to specify the new service desired by the client. This eliminates the need for the client to send an INVITE to the caller or gateway to establish new SDP parameters.
メディアサーバは、メディアサーバに既存のダイアログ上でBYEを送信し、所望のサービスにINVITEで新しいダイアログを確立してサービス間の通話を動かすサポートしなければなりません。メディアサーバは、以前に確立されたSDPパラメータの変更を必要とせずに、サービス間での移動をサポートすべきです。これは、要求URIは、クライアントが希望する新しいサービスを指定するように変更されている既存のダイアログ上で再INVITEを送信することにより達成されます。これは、新しいSDPパラメータを確立するために、発信者またはゲートウェイにINVITEを送信するためのクライアントのための必要がなくなります。
The media server, as a SIP UAS, MUST respond appropriately to an INVITE that contains an MSCML body. If MSCML is not supported, the media server MUST generate a 415 final response and include a list of the supported content types in the response per RFC 3261 [4]. The media server MUST also advertise its support of MSCML in responses to OPTIONS requests, by including "application/mediaservercontrol+xml" as a supported content type in an Accept header. This alleviates the major issues with using INFO for the transport of application data; namely, the User Agent's proper interpretation of what is, by design, an opaque message request.
メディアサーバは、SIP UASとして、それはMSCML本体が含まれているINVITEに適切に対応しなければなりません。 MSCMLがサポートされていない場合、メディアサーバ415の最終的な応答を生成して、[4] RFC 3261あたりの応答でサポートされているコンテンツタイプのリストを含まなければなりません。メディアサーバーは、Acceptヘッダーでサポートされているコンテンツタイプとして「アプリケーション/ mediaservercontrol + XML」を含むことによって、OPTIONS要求への応答にMSCMLのサポートをアドバタイズする必要があります。これは、アプリケーションデータの輸送のためのINFOを使用して、主要な問題を軽減します。すなわち、設計、不透明なメッセージ要求によって、何であるかのユーザーエージェントの適切な解釈。
To avoid undue complexity, MSCML establishes two rules regarding its usage. The first is that only one MSCML body may be present in a SIP request. The second is that each MSCML body may contain only one request or response. This greatly simplifies transaction management. MSCML syntax does provide for the unique identification of multiple requests in a single body part. However, this is not supported in this specification.
過度の複雑さを避けるために、MSCMLは、その使用に関する2つのルールを確立します。最初は一MSCML本体がSIPリクエスト中に存在してもよいということです。第二は、各MSCML本体が唯一のリクエストまたはレスポンスを含んでいてもよいということです。これは非常にトランザクション管理を簡素化します。 MSCML構文は、単一の身体の部分で複数の要求を一意に識別するために提供しません。しかし、これは、この仕様ではサポートされていません。
Per the guidelines of RFC 3470 [14], MSCML bodies MUST be well formed and valid.
RFC 3470 [14]のガイドラインごとに、MSCML体がうまく形成され、有効でなければなりません。
MSCML is a direct request-response protocol. There are no provisional responses, only final responses. A request may, however, result in multiple notifications. For example, a request for active talker reports will result in a notification for each speaker set. This maps to the three major element trees for MSCML: <request>, <response>, and <notification>.
MSCMLは直接要求 - 応答プロトコルです。何の暫定応答、唯一の最後の応答がありません。要求は、しかし、複数の通知をもたらすことができます。例えば、アクティブな話し手レポートの要求は、各スピーカーのセットのための通知になります。 <要求>、<応答>、および<通知>：これはMSCMLのための3つの主要な要素の木にマッピングされます。
Figure 1 shows a request body. Depending on the command, one can send the request in an INVITE or an INFO. Figure 2 shows a response body. The SIP INFO method transports response bodies. Figure 3 shows a notification body. The SIP INFO method transports notifications.
図1は、要求本体を示しています。コマンドに応じて、1つは、INVITEまたはINFOにリクエストを送信することができます。図2は、レスポンスボディを示します。 SIP INFOメソッドは、レスポンスボディを運びます。図3は、通知体を示します。 SIP INFOメソッドは、通知を転送します。
<?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> ... request body ... </request> </MediaServerControl>
<？xml version = "1.0" エンコード= "UTF-8"？> <MediaServerControlバージョン= "1.0"> <要求> ...リクエストボディ... </リクエスト> </ MediaServerControl>
Figure 1: MSCML Request Format
図1：MSCML要求フォーマット
<?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <response> ... response body ... </response> </MediaServerControl>
<？xml version = "1.0" エンコード= "UTF-8"？> <MediaServerControlバージョン= "1.0"> <応答> ...レスポンスボディ... </レスポンス> </ MediaServerControl>
Figure 2: MSCML Response Format
図2：MSCML回答フォーマット
<?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <notification> ... notification body ... </notification> </MediaServerControl>
<？xml version = "1.0" エンコード= "UTF-8"？> <MediaServerControlバージョン= "1.0"> <通知> ...通知本体... </通知> </ MediaServerControl>
Figure 3: MSCML Notification Format
図3：MSCML通知のフォーマット
MSCML requests MAY include a client-defined ID attribute for the purposes of matching requests and responses. The values used for these IDs need only be unique within the scope of the dialog in which the requests are issued.
MSCML要求が一致する要求と応答の目的のために、クライアントに定義されたID属性を含むかもしれません。これらのIDのために使用される値は、唯一の要求が発行されているダイアログの範囲内で一意である必要があります。
In the philosophy of XML as a text-based description language, and not as a programming language, MSCML makes the choice of many attribute values for readability by a human. Thus, many attributes that would often be "boolean" instead take "yes" or "no" values. For example, what does 'report="false"' or 'report="1"' mean? However, 'report="yes"' is clearer: I want a report. Some programmers prefer the precision of a boolean. To satisfy both styles, MSCML defines an XML type, "yesnoType", that takes on the values "yes" and "no" as well as "true", "false", "1", and "0".
テキストベースの記述言語としてXMLの哲学ではなく、プログラミング言語として、MSCMLは人間が読みやすくするために、多くの属性値の選択を行います。このように、多くの場合、「ブール」だろう多くの属性ではなく、「はい」または「いいえ」の値をとります。例えば、何ん「報告書は= 『false』を」または「レポート= 『1』」意味ですか？しかし、「報告書は= 『yes』と」明確である：私はレポートをしたいです。一部のプログラマーは、ブール値の精度を好みます。両方のスタイルを満たすために、MSCMLは「はい」値をとるXML型、「yesnoType」を、定義し、「いいえ」だけでなく、「真」「偽」、「1」、「0」。
Many attributes in the MSCML schema have default values. In order to limit demands on the XML parser, MSCML applies these values at the protocol, not XML, level. The MSCML schema documents these defaults as XML annotations to the appropriate attribute.
MSCMLスキーマ内の多くの属性は、デフォルト値があります。 XMLパーサの要求を制限するために、MSCMLプロトコルではなく、XML、レベルでこれらの値を適用します。 MSCMLスキーマは、適切な属性へのXML注釈としてこれらのデフォルトを説明します。
For clarity, time values in MSCML are based on the time designations described in the Cascading Style Sheets level 2 (CSS2) Specification [15]. Their format consists of a number immediately followed by an optional time unit identifier of the following form:
明確にするために、MSCMLの時間値は、カスケーディングスタイルシートレベル2（CSS2）仕様[15]に記載の時間指定に基づいています。それらのフォーマットは、直ちに次の形式の任意の時間単位識別子が続く数で構成されています。
ms: milliseconds (default) s: seconds
MS：ミリ秒（デフォルト）S：秒
If no time unit identifier is present, the value MUST be interpreted as being in milliseconds. As extensions to [15] MSCML allows the string values "immediate" and "infinite", which have special meaning for certain timers.
何時間単位識別子が存在しない場合、値はミリ秒であると解釈されなければなりません。 MSCML [15]の拡張機能として、特定のタイマーのための特別な意味を持っている、文字列値「即時」と「無限」ことができます。
The advanced conferencing model is a star controller model, with both signaling and media directed to a central location. Figure 4 depicts a typical signaling relationship between end users' UACs, a conference application server, and a media server.
高度会議モデルは、中央位置に向けシグナリングおよびメディアの両方とスター・コントローラ・モデルです。図4は、エンドユーザの求めるUACの間の典型的なシグナリング関係、会議アプリケーションサーバ、およびメディアサーバを示しています。
RFC 4353 [10] describes this model. The application server is an instantiation of the conference focus. The media server is an instantiation of the media mixer. Note that user-level constructs, such as event notifications, are in the purview of the application server. This is why, for example, the media server sends active talker reports using MSCML notifications, while the application server would instead use the conference package [16] for individual notifications to SIP user agents. Note that we do not recommend the use of the conference package for media server to application server notifications because none of the filtering and membership information is available at the media server.
RFC 4353 [10]は、このモデルを説明しています。アプリケーションサーバは、会議の焦点のインスタンス化したものです。メディアサーバは、メディアミキサーのインスタンス化したものです。そのようなイベント通知としてユーザーレベルの構築物は、アプリケーションサーバの範囲内にあることに留意されたいです。アプリケーションサーバではなく、SIPユーザエージェントに個別通知のための会議パッケージ[16]を使用しながら、例えば、メディアサーバは、MSCML通知を使用して、アクティブな話し手レポートを送信する理由、これがあります。フィルタリングと会員情報のどれもがメディアサーバーで利用可能ではありませんので、我々は、アプリケーション・サーバーの通知にメディアサーバーの会議パッケージの使用を推奨しないことに注意してください。
+-------+
| UAC 1 |---\ Public URI +-------------+
+-------+ \ _____________| Application |
/ / | Server | Not shown:
+-------+ / / +-------------+ RTP flows directly
| UAC 2 |---/ / | Private between UACs and
+-------+ / | URI media server
. / +--------------+
: / | |
+-------+ / | Media Server |
| UAC n |---/ | |
+-------+ +--------------+
Figure 4: Conference Model
図4：会議モデル
Each UAC sends an INVITE to a Public Conference URI. Presumably, the client publishes this URI, or it is an ad hoc URI. In any event, the client generates a Private URI, following the rules specified by RFC 4240 [2]. That is, the URI is of the following form:
各UACは、公共の会議URIにINVITEを送信します。おそらく、クライアントは、このURIを公開する、またはそれはアドホックなURIです。いずれにしても、クライアントは、RFC 4240で指定された規則に従って、プライベートURIを生成する[2]。つまり、URIの形式は、次のとおりです：
sip:conf=UniqueID@ms.example.net
SIP：conf=UniqueID@ms.example.net
where UniqueID is a unique conference identifier and ms.example.net is the host name or IP address of the media server. There is nothing to prevent the UACs from contacting the media server directly. However, one would expect the owner of the media server to restrict who can use its resources.
一意IDは、ユニークな会議識別子であり、ms.example.netは、メディアサーバのホスト名またはIPアドレスです。直接メディアサーバとの接触から求めるUACを防ぐためには何もありません。しかし、一つは、メディアサーバーの所有者がそのリソースを使用できるユーザーを制限することが期待されます。
As for basic conferencing, described by RFC 4240 [2], the first INVITE to the media server with a UniqueID creates a conference. However, in advanced conferencing, the first INVITE MAY include a MSCML <configure_conference> payload rather than the SDP of a conference participant. The <configure_conference> payload conveys extended session parameters (e.g., number of participants) that SDP does not readily express, but the media server must know to allocate the appropriate resources.
一意IDは、会議を作成すると、RFC 4240によって説明した基本的な会議、[2]と同様に、最初は、メディアサーバにINVITE。しかし、先進的な会議では、INVITE最初はMSCML <configure_conference>ペイロードではなく、会議参加者のSDPを含むかもしれません。 <configure_conference>ペイロードは、拡張セッションパラメータを搬送する（例えば、参加者の数）SDPを容易に発現していないが、メディアサーバが適切なリソースを割り当てるために知らなければならないこと。
When the conference is created by sending an INVITE containing a MSCML <configure_conference> payload, the resulting SIP dialog is termed the "Conference Control Leg." This leg has several useful properties. The lifetime of the conference is the same as that of its control leg. This ensures that the conference remains in existence even if all participant legs leave or have not yet arrived. In addition, when the client terminates the Conference Control Leg, the media server automatically terminates all participant legs. The Conference Control Leg is also used for play or record operations to/from the entire conference and for active talker notifications. Full conference media operations and active talker report subscriptions MUST be executed on the Conference Control Leg.
会議はMSCML <configure_conference>ペイロードを含むINVITEを送信することにより作成されると、結果のSIPダイアログは、「会議コントロール脚」と呼ばれます。この足は、いくつかの有用な性質を持っています。会議の寿命は、その制御脚のと同じです。これは、すべての参加者の足が去るか、まだ到着していない場合でも、会議が存在して維持されます。クライアントは、会議コントロール脚を終了するときに加えて、メディアサーバは、自動的にすべての参加者の足を終了します。会議コントロール脚も/全体会議から、アクティブな話者通知のに再生や録音操作に使用されます。完全な会議メディア操作およびアクティブトーカーレポートサブスクリプションは、会議制御レグ上で実行されなければなりません。
Creation of a Conference Control Leg is RECOMMENDED because full advanced conferencing capabilities are not available without it. Clients MUST establish the Conference Control Leg in the initial INVITE that creates the conference; it cannot be created later.
フル高度な会議機能はそれをせずに利用できませんので、会議コントロール脚の作成をお勧めします。クライアントは、それが会議を作成する最初のINVITEに会議コントロール脚を確立する必要があります。それは後で作成することができません。
Once the client has created the conference with or without the Conference Control Leg, participants can be joined to the conference. This is achieved by the client's directing an INVITE to the Private Conference URI for each participant. Using the example conference URI given above, this would be sip:conf=UniqueID@ms.example.net.
クライアントは、会議コントロール脚の有無にかかわらず会議を作成した後は、参加者が会議に参加することができます。これは、クライアントのは、各参加者の非公開会議URIにINVITEを向けることによって達成されます。 conf=UniqueID@ms.example.net：上記の例の会議URIを使用して、これは、SIPだろう。
The <configure_conference> request has two attributes that control the resources the media server sets aside for the conference. These are described in the list below.
<configure_conference>リクエストは、メディアサーバが会議のために取って設定したリソースを制御する2つの属性があります。これらは、以下のリストに記載されています。
Attributes of <configure_conference>:
<configure_conference>の属性：
o reservedtalkers - optional (see note), no default value: The maximum number of talker legs allocated for the conference. Note: required when establishing the Conference Control Leg but optional in subsequent <configure_conference> requests.
Oのreservedtalkers - オプション（注を参照）、デフォルト値なし：会議のために割り当てられた話者の脚の最大数。注意：会議コントロール脚を確立する際に必要ですが、その後の<configure_conference>要求ではオプション。
o reserveconfmedia - optional, default value "yes": Controls allocation of resources to enable playing or recording to or from the entire conference.
O reserveconfmedia - オプション、デフォルト値は「はい」：全体会議にまたはから再生または記録を可能にするためにリソースの割り当てを制御します。
When the reservedtalkers+1st INVITE arrives at the media server, the media server SHOULD generate a 486 Busy Here response. Failure to send a 486 response to this condition can cause the media server to oversubscribe its resources.
reservedtalkers +第一は、INVITEがメディアサーバーに到着すると、メディアサーバは、ここでビジー486応答を生成する必要があります。この条件に486応答を送信に失敗すると、メディアサーバーがそのリソースをオーバーサブスクライブすることがあります。
NOTE: It would be symmetric to have a reservedlisteners parameter. However, the practical limitation on the media server is the number of talkers for a mixer to monitor. In either case, the client regulates who gets into the conference by either proxying the INVITEs from the user agent clients or metering to whom it gives the conference URI.
注：reservedlistenersパラメータを持っている対称だろう。しかしながら、メディアサーバ上の実際的な制限は、監視するためのミキサー話者の数です。いずれの場合も、クライアントはそれが会議URIを与える誰にユーザエージェントクライアントや計量からのINVITEをプロキシのいずれかによって、会議に誰が規制します。
For example, to create a conference with up to 120 active talkers and the ability to play audio into the conference or record portions or all of the conference full mix, the client specifies both attributes, as shown in Figure 6.
図6に示すように、例えば、最大120アクティブトーカー、会議または記録部分や会議、フルミックスのすべてにオーディオを再生する機能を持つ会議を作成するために、クライアントは、両方の属性を指定します。
<?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <configure_conference reservedtalkers="120" reserveconfmedia="yes"/> </request> </MediaServerControl>
<？xml version = "1.0" エンコード= "UTF-8"？> <MediaServerControlバージョン= "1.0"> <要求> <configure_conference reservedtalkers = "120" reserveconfmedia = "YES" /> </リクエスト> </ MediaServerControl>
Figure 6: 120 Speaker MSCML Example
図6：120スピーカーMSCML例
In addition to these attributes, a <configure_conference> request MAY contain a child <subscribe> element. The <subscribe> element is used to request notifications for conference-wide active talker events. Detailed information regarding active talker events is contained in Section 5.7.
これらの属性に加えて、<configure_conference>要求は要素を<購読>子を含むかもしれません。 <サブスクライブ>要素は、会議全体のアクティブな話し手イベントの通知を要求するために使用されます。アクティブな話し手イベントに関する詳細な情報は、5.7節に含まれています。
The client MUST include a <configure_conference> request in the initial INVITE which establishes the conference when creating the Conference Control Leg. The client server MUST issue asynchronous commands, such as <play>, separately (i.e., in INFO messages) to avoid ambiguous responses.
クライアントは、初期における<configure_conference>要求会議コントロール脚を作成するときに会議を確立するINVITEを含まなければなりません。クライアント・サーバは、あいまいな応答を避けるために、別々に、このような<遊び>などの非同期コマンドを、（すなわち、INFOメッセージで）発行しなければなりません。
Media operations on the Conference Control leg are performed internally, no external RTP streams are involved. Accordingly, the media server does not expect RTP on the Conference Control Leg. Therefore, the client MUST send either no SDP or hold SDP in the INVITE request containing a <configure_conference> payload. The media server MUST treat SDP with all media lines set to "inactive" or with connection addresses set to 0.0.0.0 (for backwards compatibility) as hold SDP.
会議コントロール脚のメディア操作は内部、外部RTPストリームが関与していないされて実行されます。したがって、メディアサーバは、会議コントロール脚の上にRTPを期待していません。したがって、クライアントがないかSDPを送信しないか、または<configure_conference>ペイロードを含むINVITE要求にSDPを保持しなければなりません。メディアサーバは、保留SDPとして「非アクティブ」またはとの接続アドレスが（後方互換性のため）0.0.0.0に設定して設定されたすべてのメディアラインにSDPを扱わなければなりません。
The media server sends a response when it has finished processing the <configure_conference> request. The format of the <configure_conference> response is detailed in Section 10.2.
メディアサーバは、それが<configure_conference>要求の処理を完了した応答を送信します。 <configure_conference>レスポンスのフォーマットは、10.2節で詳述されます。
Conference legs have a number of properties the client can modify. These are set using the <configure_leg> request. This request has the attributes described in the list below.
会議の足は、クライアントが変更できるプロパティの数を持っています。これらは、<configure_leg>要求を使用して設定されています。この要求は、以下のリストで説明する属性を持っています。
Attributes of <configure_leg>:
<configure_leg>の属性：
o type - optional, default value "talker": Consider this leg's audio for inclusion in the output mix. Alternative is "listener".
Oタイプ - オプション、デフォルト値「話し手」：出力ミックスに含めるため、この区間のオーディオを考えてみましょう。代替は「リスナー」です。
o dtmfclamp - optional, default value "yes": Remove detected DTMF digits from the input audio.
O dtmfclamp - 任意のデフォルト値「はい」：入力オーディオから検出されたDTMFディジットを削除します。
o toneclamp - optional, default value "yes": Remove tones from the input audio. Tones include call progress tones and the like.
O toneclamp - 任意のデフォルト値「はい」：入力オーディオからトーンを削除します。トーンは、コールプログレストーンなどが挙げられます。
o mixmode - optional, default value "full": Be a candidate for the full mix. Alternatives are "mute", to disallow media in the mix, "parked", to disconnect the leg's media streams from the conference for IVR operations, "preferred", to give this stream preferential selection in the mix (i.e., even if not loudest talker, include media, if present, from this leg in the mix), and "private", which enables personalized mixes.
OをMixMode - オプション、デフォルト値「完全に」：フルミックスの候補となります。代替は、IVR操作のための会議から足のメディアストリームを切断するために、「パーク」、ミックスにメディアを禁止するために、「ミュート」が、「好ましい」、ミックスの中で、このストリームに優先的に選択を与えるために（すなわち、たとえない最大音量話者が、メディアを含め、存在する場合、パーソナライズされたミックスを可能にし、このミックスで足）、および「プライベート」、から。
In addition to these attributes, there are four child elements defined for <configure_leg>. These are <inputgain>, <outputgain>, <configure_team>, and <subscribe>.
これらの属性に加えて、<configure_leg>のために定義された4つの子要素があります。これらは、<inputgain>、<outputgain>、<configure_team>であり、<購読します>。
The first two, <inputgain> and <outputgain>, modify the gain applied to the input and output audio streams, respectively. These may contain <auto>, to use automatic gain control (AGC) or <fixed>. The <auto> element has the attributes "startlevel", "targetlevel", and "silencethreshold". All the parameters are in dB. The <fixed> element has the attribute "level", which is in dB. The default for both <inputgain> and <outputgain> is <fixed>. The media server MAY silently cap <inputgain> or <outputgain> requests that exceed the gain limits imposed by the platform.
最初の二つ、<inputgain>と<outputgain>、それぞれ、入力および出力オーディオストリームに適用されるゲインを変更します。これらは、<自動>を含むことができる自動利得制御（AGC）を使用するか、<固定します>。 <自動>要素は、属性 "startlevel"、 "targetlevel"、および "silencethreshold" を持っています。すべてのパラメータはdBです。 <固定>要素はdBである属性「レベル」を有します。両方の<inputgain>と<outputgain>のデフォルトは、<固定>されます。メディアサーバは静かにプラットホームによって課された利得限界を超え<inputgain>または<outputgain>要求をキャップMAY。
Clients most commonly manipulate only the input gain for a conference leg and rely on the mixer to set an optimum output gain based on the inputs currently in the mix. However, as described above, MSCML does allow for manipulation of the output gain as well. Some of the IVR commands, such as <play>, enable control of the output gain for content playback operations. The interaction of conference output gain and IVR playback gain controls is described in Section 6.1.1. Note that <inputgain> and <outputgain> settings apply only to conference legs and do not apply to IVR sessions.
クライアントは、最も一般的に会議脚のための唯一の入力ゲインを操作し、現在はミックスの入力に基づいて、最適な出力ゲインを設定するためにミキサーに依存しています。しかし、上述したように、MSCMLは同様に、出力ゲインの操作を可能にしません。こうした<遊び>などのIVRコマンドのいくつかは、コンテンツの再生操作用の出力ゲインの制御を可能にします。会議の出力ゲインとIVR再生利得制御の相互作用は、セクション6.1.1に記載されています。なお、<inputgain>と<outputgain>の設定は、脚を会議にのみ適用され、IVRセッションには適用されません。
The <configure_team> element is used to create and manipulate groups for personalized mixes. Details of personalized mixes are discussed in Section 5.8.
<configure_team>要素は、パーソナライズされたミックスのためのグループを作成し、操作するために使用されます。パーソナライズされたミックスの詳細は、5.8節で議論されています。
The <subscribe> element is used to request notifications for call leg related events, such as asynchronous DTMF digit reports. Detailed information regarding call leg events is discussed in Section 7.
<サブスクライブ>要素は、このような非同期のDTMFディジットレポートなどのコールレッグ関連のイベントのための通知を要求するために使用されます。コールレッグのイベントに関する詳細な情報は7章で説明されています。
If the default parameters are acceptable for the leg the client wishes to enter into the conference, then a normal SIP INVITE, with no MSCML body, is sufficient. However, if the client wishes to modify one or more of the parameters, the client can include a MSCML body in addition to the SDP body.
デフォルトパラメータは、クライアントが会議に入ることを希望し、脚のために許容される場合は、通常のSIPはありませんMSCML本体と、INVITE、十分です。クライアントは、1つまたは複数のパラメータを変更したい場合は、クライアントは、SDP本体に加えて、MSCMLボディを含めることができます。
The client can modify the conference leg parameters during the conference by issuing a SIP INFO on the dialog representing the conference leg. Of course, the client cannot modify SDP in an INFO message.
クライアントは、会議脚を表し、ダイアログ上でSIP INFOを発行することにより、会議中に会議脚のパラメータを変更することができます。もちろん、クライアントはINFOメッセージでSDPを変更することはできません。
The media server sends a response when it has finished processing the <configure_leg> request. The format of the <configure_leg> response is detailed in Section 10.3.
メディアサーバは、それが<configure_leg>要求の処理を完了した応答を送信します。 <configure_leg>レスポンスのフォーマットは、セクション10.3に詳述されています。
To remove a leg from the conference, the client issues a SIP BYE request on the selected dialog representing the conference leg.
会議から足を削除するには、クライアントは、会議脚を表し選択ダイアログ上のSIP BYE要求を発行します。
The client can terminate all legs in a conference by issuing a SIP BYE request on the Conference Control Leg. If one or more participants are still in the conference when the media server receives a SIP BYE request on the Conference Control Leg, the media server issues SIP BYE requests on all remaining conference legs to ensure cleanup of the legs.
クライアントは、会議コントロール脚のSIP BYEリクエストを発行することにより、会議のすべての足を終了することができます。 1人以上の参加者が会議に残っている場合は、メディアサーバは、会議コントロール脚の上にSIP BYE要求を受信したとき、メディアサーバは、脚のクリーンアップを確実にするために、残りのすべての会議の足にSIP BYE要求を発行します。
The media server returns a 200 OK to the SIP BYE request as it sends BYE requests to the other legs. This is because we cannot issue a provisional response to a non-INVITE request, yet the teardown of the other legs may exceed the retransmission timer limits of the original request. While the conference is being cleaned up, the media server MUST reject any new INVITEs to the terminated conference with a 486 Busy Here response. This response indicates that the specified conference cannot accept any new members, pending deletion.
それは他の足にBYE要求を送信してメディアサーバは、SIP BYE要求に対する200 OKを返します。私たちは非INVITEリクエストに対する暫定応答を発行することはできません、まだ他の脚のティアダウンが元の要求の再送信タイマーの限界を超える可能性があるためです。会議がクリーンアップされている間、メディアサーバは、486ここでビジー応答で終了した会議への新しい招待拒絶しなければなりません。この応答は、指定された会議が削除を保留中の、任意の新しいメンバーを受け入れることができないことを示しています。
Once the conference has begun, the client can manipulate the conference as a whole or a particular participant leg by issuing commands on the associated SIP dialog. For example, by sending MSCML requests on the Conference Control Leg the client can request that the media server record the conference, play a prompt to the conference, or request reports on active talker events. Similarly, the client may mute a participant leg, configure a personalized mix or request reports for call leg events, such as DTMF keypresses.
会議が始まった後は、クライアントが関連付けられているSIPダイアログでコマンドを発行することにより、全体として会議や特定の参加者の足を操作することができます。例えば、会議コントロール脚のMSCML要求を送信することにより、クライアントは、メディアサーバレコードの会議は、アクティブな話し手イベントの会議、または要求レポートにプロンプトを再生することを要求することができます。同様に、クライアントは、参加者の足をミュートなどのDTMFキー押下などのコールレッグのイベントのためのパーソナライズされたミックスや要求レポートを設定することができます。
Figure 7 shows an example of an MSCML command that plays a prompt to all conference participants.
図7は、すべての会議参加者にプロンプトを再生MSCMLコマンドの例を示します。
<?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <play> <prompt> <audio url="http://prompts.example.net/en_US/welcome.au"/> </prompt> </play> </request> </MediaServerControl>
<？xml version = "1.0" エンコード= "UTF-8"？> <MediaServerControlバージョン= "1.0"> <要求> <遊ぶ> <プロンプト> <オーディオURL = "http://prompts.example.net/en_US /welcome.au "/> </プロンプト> </遊ぶ> </リクエスト> </ MediaServerControl>
Figure 7: Full Conference Audio Command - Play
図7：フルカンファレンスオーディオコマンド - プレイ
A client can modify a leg by issuing an INFO on the dialog associated with the participant leg. For example, Figure 8 mutes a conference leg.
クライアントは、参加者の足に関連したダイアログのINFOを発行することにより、脚を変更することができます。例えば、図8は、会議脚をミュートします。
<?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <configure_leg mixmode="mute"/> </request> </MediaServerControl>
<？xml version = "1.0" エンコード= "UTF-8"？> <MediaServerControlバージョン= "1.0"> <要求> <configure_legをMixMode = "ミュート" /> </リクエスト> </ MediaServerControl>
Figure 8: Sample Change Leg Command
図8：サンプルの変更脚コマンド
In Figure 7, we saw a request to play a prompt to the entire conference. The client can also request to play a prompt to an individual call leg. In that case, the MSCML request is issued within the SIP dialog of the desired conference participant.
図7では、我々は全体会議にプロンプトを再生するための要求を見ました。また、クライアントは、個々のコールレッグにプロンプトを再生することを要求することができます。その場合には、MSCML要求は、所望の会議参加者のSIPダイアログ内で発行されます。
Section 6 describes the interactive voice response (IVR) services offered by MSCML. If an IVR command arrives on the control channel, it takes effect on the whole conference. This is a mechanism for playing prompts to the entire conference (e.g., announcing new participants). If an IVR command arrives on an individual leg, it only affects that leg. This is a mechanism for interacting with users, such as the creation of "waiting rooms", allowing a user to mute themselves using key presses, allowing a moderator to out-dial, etc.
第6節はMSCMLが提供する対話型音声応答（IVR）サービスについて説明します。 IVRコマンドは制御チャネルに到達した場合、それは全体会議で有効になります。これは、（例えば、新しい参加者を発表する）の全体会議にプロンプトを再生するためのメカニズムです。 IVRコマンドは、個々の足に到達した場合には、それだけでその足に影響を与えます。これは、など、そのような「待合室」の創設など、ユーザーと対話するユーザは、キーの押下を使用して自分自身をミュートすることができ、モデレータがアウトダイヤルすることを可能にするための仕組みであります
A participant leg MUST be configured with mixmode="parked" prior to the issuance of any IVR commands with prompt content ('prompturl' attribute or <prompt> element). Parking the leg isolates the participant's input and output media from the conference and allows use of those streams for playing and recording purposes. However, the mixmode has no effect if just digit collection or recording is desired. <playcollect> and <playrecord> requests without prompt content MAY be sent on participant legs without setting mixmode="parked".
参加者の脚=前プロンプトコンテンツ（「prompturl」属性または<プロンプト>要素）を有する任意のIVRコマンドの発行に「駐車」をMixModeを設定する必要があります。駐車場は、脚が会議から参加者の入力および出力メディアを分離し、演奏や録音の目的のためにそれらのストリームを使用することができます。しかし、をMixModeは単に数字収集や記録が所望される場合には効果がありません。 <playcollect>と<playrecord>プロンプトコンテンツのない要求は=は「パーク」をMixModeを設定せずに、参加者の足の上で送信されてもよいです。
MSCML-controlled advanced conferences, as well as RFC 4240 [2] controlled basic conferences, implicitly support video conferencing in the form of video switching. In video switching, the video stream of the loudest talker (with some hysteresis) is sent to all participants other than that talker. The loudest talker receives the video stream from the immediately prior loudest talker.
MSCML制御高度会議、ならびにRFC 4240 [2]の制御の基本的な会議、暗黙映像切替の形でビデオ会議をサポートします。ビデオスイッチングでは、（いくつかのヒステリシス付き）最大音量話し手のビデオストリームは、その話者以外のすべての参加者に送信されます。最大音量話し手は、直前の最大音量話し手からのビデオストリームを受信します。
Media servers MUST ensure that participants receive video media compatible with their session. For example, a participant who has established an H.263 video stream will not receive video from another participant employing H.264 media. Media servers SHOULD implement video transcoding to minimize media incompatibilities between participants.
メディアサーバーは、参加者が自分のセッションに対応したビデオメディアを受け取ることを保証しなければなりません。例えば、H.263ビデオストリームを確立している参加者は、H.264メディアを採用し、他の参加者からのビデオを受信しません。メディアサーバーは、参加者間でメディアの非互換性を最小限にするためにビデオトランスコーディングを実装する必要があります。
The media server MUST switch video streams only when it receives a refresh video frame. A refresh frame contains all the video information required to decode that frame (i.e., there is no dependency on data from previous video frames).
それはリフレッシュビデオ・フレームを受信した場合にのみ、メディア・サーバは、ビデオストリームを切り替える必要があります。リフレッシュフレームは、そのフレームを復号するために必要なすべてのビデオ情報（すなわち、前のビデオフレームからのデータには依存関係が存在しない）を含みます。
Refresh frames are large and generally sent infrequently to conserve network bandwidth. The media server MUST implement standard mechanisms to request that the new loudest talker's video encoder transmits a refresh frame to ensure that video can be switched quickly.
リフレッシュフレームが大きく、一般的にネットワーク帯域幅を節約するために、まれに送られます。メディアサーバーは、新しい最も騒々しい話者のビデオエンコーダは、そのビデオを素早く切り替えることができることを確認するためにリフレッシュフレームを送信することを要求するための標準的なメカニズムを実装しなければなりません。
A client can subscribe for periodic active talker event reports that indicate which participants are included in the conference mix. As these are conference-level events, the subscription and notifications are sent on the Conference Control Leg.
クライアントは、会議ミックスに含まれている参加者を示す定期的なアクティブな話し手イベントレポートのために購読することができます。これらは、会議レベルのイベントであるため、サブスクリプションと通知が会議制御レグに送信されます。
Media servers MAY impose limits on the minimum interval for active talker reports for performance reasons. If the client request is below the imposed minimum, the media server SHOULD set the interval to the minimum value supported. To limit unnecessary notification traffic, the media server SHOULD NOT send a report if the active talker information for the conference has not changed during the reporting interval.
メディアサーバーは、パフォーマンス上の理由から、アクティブな話し手レポートの最小間隔に制限を課すことができます。クライアント要求が課さ最小値を下回った場合は、メディアサーバがサポートされる最小値に間隔を設定する必要があります。会議のアクティブな話者情報は、報告期間中に変更されていない場合は、不要な通知トラフィックを制限するには、メディアサーバは、レポートを送るべきではありません。
A request for an active talker report is in Figure 9. The active talker report enumerates the current call legs in the mix.
アクティブな話し手レポートの要求は、アクティブな話し手レポートはミックスで、現在のコールレッグを列挙し、図9にあります。
<?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <configure_conference> <subscribe> <events> <activetalkers report="yes" interval="60s"/> </events> </subscribe> </configure_conference> </request> </MediaServerControl>
<？xml version = "1.0" エンコード= "UTF-8"？> <MediaServerControlバージョン= "1.0"> <要求>が<configure_conference> <サブスクライブ> <イベント> <activetalkersレポート= "yes" の間隔= "60年代" / > </イベント> </サブスクライブ> </ configure_conference> </リクエスト> </ MediaServerControl>
Figure 9: Active Talker Request
図9：アクティブトーカーリクエスト
Event notifications are sent in SIP INFO messages. Figure 10 shows an example of a report.
イベント通知は、SIP INFOメッセージで送信されます。図10は、レポートの例を示しています。
<?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <notification> <conference uniqueid="ab34h76z" numtalkers="47"> <activetalkers> <talker callid="myhost4sn123"/> <talker callid="myhost2sn456"/> <talker callid="myhost12sn78"/> </activetalkers> </conference> </notification> </MediaServerControl>
<activetalkers> <話し手callid = "myhost4sn123 <numtalkers = "47" "ab34h76z" 会議一意ID =>の<？xml version = "1.0" エンコード= "UTF-8"？> <MediaServerControlバージョン= "1.0"> <通知> "/> <話者callid =" myhost2sn456 "/> <話者callid =" myhost12sn78" /> </ activetalkers> </会議> </通知> </ MediaServerControl>
Figure 10: Active Talker Event Example
図10：アクティブトーカーイベント例
The value of the "callid" attribute in the <talker> element corresponds to the value of the SIP Call-ID header of the associated dialog. This enables the client to associate the active talker with a specific participant leg.
<話し手>要素の「callid」属性の値は、関連するダイアログのSIPコールIDヘッダの値に相当します。これは、特定の参加者の足でアクティブな話し手を関連付けるためにクライアントを可能にします。
MSCML enables clients to create personalized mixes through the <configure_team> element for scenarios where the standard mixmode settings do not provide sufficient control. The <configure_team> element is a child of <configure_leg>.
MSCMLは標準をMixModeの設定が十分な制御を提供していないシナリオについて<configure_team>要素を通してパーソナライズミックスを作成するためにクライアントを可能にします。 <configure_team>要素は、<configure_leg>の子です。
To create personalized mixes, the client has to identify the relationships among the participants. This is accomplished by manipulating two MSCML objects. These objects are:
パーソナライズされたミックスを作成するには、クライアントは、参加者間の関係を識別しなければなりません。これは、2つのMSCMLオブジェクトを操作することによって達成されます。これらのオブジェクトは、次のとおりです。
1. The list of team members (<teammate> elements), set using <configure_team>
1.チームのメンバー（<チームメイト>要素）のリスト、使って設定<configure_team>
The media server uses the values of these objects to determine which audio inputs to combine for output to the participant. In a normal conference, each participant hears the conference mix minus their own input if they are part of the mixed output. The team list enables the client to specify other participants that the leg can hear in addition to the normal mixed output. Note that personalized mix settings apply only to audio media and do not affect video switching.
メディアサーバは、オーディオ入力を参加者に出力するために結合するかを決定するためにこれらのオブジェクトの値を使用しています。彼らは混合出力の一部である場合、通常の会議では、各参加者は、会議ミックスマイナス自身の入力を聞きます。チームのリストは、脚が通常の混合出力に加えて、聞くことができ、他の参加者を指定するためにクライアントを可能にします。パーソナライズされたミックス設定がオーディオメディアにのみ適用され、ビデオ・スイッチングには影響を与えないことに注意してください。
Team relationships are implicitly symmetric. If the client sets participant A as a team member of participant B, then the media server automatically sets participant B as a team member for A.
チームの関係は、暗黙的に対称です。クライアントが参加者Bのチームの一員として参加者Aを設定した場合は、メディアサーバーは自動的にAのチームメンバーとして参加者Bを設定し、
The id attribute set through <configure_leg> is used to identify the various participants. A unique ID MUST be assigned to each participant included in a personalized mix. The IDs used MUST be unique within the scope of the conference in which they appear.
<configure_leg>を通じて設定id属性は、様々な参加者を識別するために使用されます。ユニークIDは、パーソナライズされたミックスに含まれる各参加者に割り当てる必要があります。使用されるIDは、彼らが表示されている会議の範囲内で一意でなければなりません。
By itself, the team list only defines those participants that the leg can hear. The mixmode attribute of each team member determines whether to include their audio input in the personalized mix. If the client sets the teammate's mixmode to private, then it is part of the mix. If the mixmode is set to any other value, it is not.
それ自体で、チームのリストには、脚を聞くことができ、これらの参加者を定義します。各チームメンバーのをMixMode属性は、パーソナライズされたミックスでのオーディオ入力を含めるかどうかを決定します。クライアントがプライベートにチームメイトのをMixModeを設定した場合、それはミックスの一部です。 MixModeは、他の値に設定されている場合は、そうではありません。
Control of personalized mixes rely on two major MSCML elements:
パーソナライズされたミックスのコントロールは、2つの主要なMSCML要素に依存しています：
1. <configure_leg>, using the mixmode attribute setting mixmode="private"
1. <configure_leg>、をMixMode設定をMixMode属性を使用して= "プライベート"
The <configure_team> element allows the user to make the participants members of a team within a specific conference. It is a child of the <configure_leg> parent element.
<configure_team>要素は、ユーザーが特定の会議内のチームの参加メンバーを行うことができます。それは<configure_leg>親要素の子です。
The client sends the <configure_team> element in a <configure_leg> request in either a SIP INVITE or SIP INFO.
クライアントは、SIP INVITEまたはSIP INFOのいずれかで、<configure_leg>要求で<configure_team>要素を送信します。
o In an INVITE, to join a participant whose properties differ from the properties established for the conference as a whole.
INVITE中のO、その特性が全体として会議のために確立された特性とは異なる参加者に参加します。
o In an INFO, to change the properties for an existing leg.
O INFOでは、既存の足のプロパティを変更します。
The two attributes of the configure_team element are "id" and "action". The id attribute MUST contain the unique ID of the leg being modified, as set in the original <configure_leg> request. The action attribute can take on the values "add", "delete", "query", and "set". The default value is "query". This attribute allows the user to modify the team list. Table 1 describes the actions that can be performed on the team list.
configure_team要素の2つの属性が「ID」と「アクション」です。 id属性は、元の<configure_leg>要求で設定され、変更されて脚の固有IDを含まなければなりません。 action属性は、「削除」、「追加」「クエリ」の値をとると、「設定」することができます。デフォルト値は「クエリ」です。この属性は、ユーザーがチームのリストを変更することができます。表1は、チームのリストに対して実行できるアクションについて説明します。
+--------+----------------------------------------------------------+
| Action | Description |
+--------+----------------------------------------------------------+
| add | Adds a teammate to the mix. |
| delete | Deletes a teammate from the mix. |
| query | Returns the teammate list to the requestor. This is the |
| | default value. |
| set | Creates a team list when followed by <teammate id="n"> |
| | and also removes all the teammates from the team list |
| | for example, when the creator (originator) of the team |
| | list on that specific conference leg wants to remove all |
| | of the teammates from the team. If the set operation |
| | removes all teammates from a participant, that |
| | participant hears the full conference mix. |
+--------+----------------------------------------------------------+
Table 1: Configure Team Actions
表1：設定チームのアクション
A common use of personalized mixing is to support coaching of one participant by another. The coaching scenario includes three participants: 1. The Supervisor, who coaches the agent. 2. The Agent, who interacts with the customer. 3. The Customer, who interacts with the agent.
パーソナライズされた混合の一般的な用途は別である参加者の指導をサポートすることです。 1.スーパーバイザー、コーチエージェント：コーチングシナリオは3人の参加者が含まれています。顧客と対話2.ザ・エージェント、。 3.エージェントと対話する顧客、。
Table 2 illustrates the details of the coached conference topology.
表2は、コーチの会議トポロジの詳細を示しています。
+-------------+------------+------------+---------+-----------------+
| Participant | ID | Team | Mixmode | Hears |
| | | Members | | |
+-------------+------------+------------+---------+-----------------+
| Supervisor | supervisor | Agent | Private | customer + |
| | | | | agent |
| Agent | agent | Supervisor | Full | customer + |
| | | | | supervisor |
| Customer | customer | none | Full | agent |
+-------------+------------+------------+---------+-----------------+
Table 2: Coached Conference Example
表2：指導会議の例
To create this topology, the client performs the following actions:
このトポロジを作成するには、クライアントは次のアクションを実行します。
1. The client joins each leg to the conference, being certain to include a unique ID in the <configure_leg> request. The leg ID needs to be unique only within the scope of the conference to which it belongs.
1.クライアントは、<configure_leg>リクエストでユニークなIDを含めて、特定のこと、会議に各脚を結合します。レッグIDは、それが属する会議の範囲内で一意である必要があります。
2. The client configures the teammate list and mixmode of each participant, as required.
2.必要に応じてクライアントは、各参加者の味方リストとをMixModeを設定します。
Both actions (steps 1 and 2) may be combined in a single MSCML request. The following sections detail these actions and their corresponding MSCML payloads.
両方のアクションは、（1ステップと、2）単一MSCML要求で組み合わせることができます。次のセクションで詳しくこれらのアクションとそれに対応するMSCMLペイロード。
Before joining any participants, the client must create the conference by sending a SIP INVITE that contains an MSCML <configure_conference> request with a unique conference identifier.
すべての参加者に参加する前に、クライアントはそれがユニークな会議識別子を持つMSCML <configure_conference>要求を含むINVITE SIPを送信することによって、会議を作成する必要があります。
Join the coach leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to supervisor and its mixmode to private.
会議にコーチ脚に参加して、SIPは、<configure_leg>要求を含むINVITEを送信することによって、所望の特性を設定します。 <configure_leg>要素には、スーパーバイザーや民間へのをMixModeに足の一意のIDを設定します。
The corresponding MSCML request is as follows.
次のように対応するMSCML要求があります。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg id="supervisor" mixmode="private"/> </request> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <configure_leg ID = "スーパーバイザー" をMixMode = "プライベート" /> </リクエスト> </ MediaServerControl>
Figure 11: Join Coach Request
図11：コーチリクエストに参加
Note that the client cannot configure the teammate list for the coach yet, as there are no other participants in the conference. One must join a participant to the conference before one can add it as a teammate for another leg.
会議には、他の参加者が存在しないとして、クライアントはまだコーチのためのチームメイトのリストを設定できないことに注意してください。 1が別の脚のためのチームメイトとして追加することができます前に、一つは、会議に参加者を参加させる必要があります。
Join the agent leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to "agent" and sets the supervisor as a team member of the agent. Because team member relationships are symmetric, this action also adds the agent as a team member for the coach.
会議にエージェント脚に参加して、SIPは、<configure_leg>要求を含むINVITEを送信することによって、所望の特性を設定します。 <configure_leg>要素は、「エージェント」に、脚の一意のIDを設定し、エージェントのチームメンバーとして監督を設定します。チームメンバーの関係は対称であるため、このアクションはまた、コーチのためのチームメンバーとしてエージェントを追加します。
The corresponding MSCML request is as follows. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg id="agent"> <configure_team action="set"> <teammate id="supervisor"/> </configure_team> </configure_leg> </request> </MediaServerControl>
次のように対応するMSCML要求があります。 <？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <configure_leg ID = "エージェント"> <configure_teamアクション= "設定"> <味方のid = "スーパーバイザー" /> </ configure_team> </ configure_leg> </リクエスト> </ MediaServerControl>
Figure 12: Join Agent Request
図12：エージェントのリクエストに参加
Because the desired mixmode for this leg is full, which is the default value, there is no need to set it explicitly.
このレッグの希望をMixModeは、デフォルト値である、フルであるため、明示的に設定する必要はありません。
Join the client leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element simply sets the leg's unique ID to "customer". The media server does not need further configuration because the desired mixmode, full, is the default and the customer has no team members.
会議にクライアント脚に参加して、SIPは、<configure_leg>要求を含むINVITEを送信することによって、所望の特性を設定します。 <configure_leg>要素は、単に「顧客」に足の一意のIDを設定します。フル希望をMixModeは、デフォルトで、顧客が何チームメンバーを持っていないため、メディア・サーバーは、追加の設定は必要ありません。
The corresponding MSCML request is as follows. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg id="customer"/> </request> </MediaServerControl>
次のように対応するMSCML要求があります。 <？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <configure_leg ID = "顧客" /> </リクエスト> </ MediaServerControl>
Figure 13: Join Client Request
図13：クライアント要求に参加
Strictly speaking, it is not a requirement that the client give the customer leg a unique ID because it will not be a team member. However, when using coached conferencing, we RECOMMEND that one assign a unique ID to each leg in the initial INVITE request. Assigning a unique ID eliminates the need to set it later by sending a SIP INFO if one later desires personalized mixing for the customer leg.
厳密に言えば、それはチームメンバーではありませんので、クライアントは、顧客の足に一意のIDを与えることは必須ではありません。コーチ会議を使用している場合しかし、我々は1つが、最初のINVITE要求内の各脚に固有のIDを割り当てることをお勧めします。ユニークなIDを割り当てると、1人の以降の欲望は、顧客の足のために混合パーソナライズされた場合は、SIP INFOを送信することで、後でそれを設定する必要がなくなります。
The conference is now in the desired configuration, shown previously in Table 2.
会議は、表2に先に示した所望の構成になりました。
In the IVR model, the media server acts as a media-processing proxy for the UAC. This is particularly useful when the UAC is a media gateway or other device with limited media processing capability.
IVRモデルでは、メディア・サーバは、UACのメディア処理プロキシとして働きます。 UACは、限られたメディア処理機能を持つメディアゲートウェイまたは他のデバイスである場合に特に有用です。
The typical use case for MSCML is when there is an application server that is the MSCML client. The client can use the SIP Service URI concept (RFC 3087) to initiate a service. The client then uses RFC 4240 [2] to initiate a MSCML session on a media server. These relationships are shown in Figure 14.
MSCMLクライアントであるアプリケーション・サーバがある場合MSCMLのための典型的な使用ケースがあります。クライアントは、サービスを開始するために、SIPサービスURIの概念（RFC 3087）を使用することができます。次に、クライアントは、RFC 4240 [2]メディアサーバー上のMSCMLセッションを開始するために使用しています。これらの関係は、図14に示されています。
SIP +--------------+
Service URI | Application |
/----------------| Server |
/(e.g., RFC 3087) +--------------+
/ | MSCML
/ SIP | Session
/ +--------------+
+-----+/ RTP | |
| UAC |======================| Media Server |
+-----+ | |
+--------------+
Figure 14: IVR Model
図14：IVRモデル
The IVR service supports basic Interactive Voice Response functions, playing announcements, collecting DTMF digits, and recording, based on Media Server Control Markup Language (MSCML) directives added to the message body of a SIP request. The major MSCML IVR requests are <play>, <playcollect>, and <playrecord>.
IVRサービスは、SIPリクエストのメッセージボディに追加メディアサーバ制御マークアップ言語（MSCML）ディレクティブに基づいて、DTMFディジット、および記録を収集し、アナウンスメントを演奏し、基本的な対話型音声応答機能をサポートしています。主要なMSCML IVR要求は、<遊び>、<playcollect>であり、<playrecord>。
Multifunction media servers MUST use the URI conventions described in RFC 4240 [2]. The service indicator for MSCML IVR MUST be set to "ivr", as shown in the following example:
多機能メディアサーバは、RFC 4240で説明URIの規則を使用しなければならない[2]。次の例に示すように、MSCML IVRのサービスインジケータは、「IVR」に設定する必要があります。
sip:ivr@ms.example.net
SIP：ivr@ms.example.net
The VoiceXML IVR service indicator is "dialog". This service indicator MUST NOT be used for any other interactive voice response control mechanism.
VoiceXMLのIVRサービスインジケータは「ダイアログ」です。このサービスインジケータは、他の対話型音声応答制御機構のために使用してはいけません。
The media server MUST accept MSCML IVR payloads in INFO requests and MUST NOT accept MSCML IVR payloads in the initial or subsequent INVITEs. The INFO method reduces certain timing issues that occur with INVITEs and requires less processing on both the client and media server.
メディアサーバは、INFO要求でMSCML IVRペイロードを受け入れなければならないし、初期または後続のINVITEでMSCML IVRペイロードを受け入れてはいけません。 INFOメソッドは、のINVITEで発生する特定のタイミングの問題を低減し、クライアントとメディアサーバーの両方で以下の処理が必要です。
The media server notifies the client that the command has completed through a <response> message containing final status information and associated data such as collected DTMF digits.
メディアサーバは、コマンドは、収集されたDTMFディジットとして最終的なステータス情報および関連データを含む<応答>メッセージを介して完了したクライアントに通知します。
The media server does not queue IVR requests. If the media server receives a new IVR request while another is in progress, the media server stops the first operation and it carries out the new request. The media server generates a <response> message for the first request and returns any data collected up to that point. If a client wishes to stop a request in progress but does not wish to initiate another operation, it issues a <stop> request. This also causes the media server to generate a <response> message.
メディアサーバは、IVR要求をキューに入れていません。他の進行中にメディアサーバーが新しいIVR要求を受信した場合、メディアサーバは、第1の動作を停止し、それが新しい要求を行います。メディアサーバは、最初の要求に対する<応答>メッセージを生成し、その時点までに収集されたデータを返します。クライアントは、進行中の要求を停止することを希望するが、別の操作を開始することを希望しない場合は、<停止>要求を発行します。また、これは、<応答>メッセージを生成するメディアサーバーが発生します。
The media server treats a SIP re-INVITE that modifies the established SDP parameters as an implicit <stop> request. Examples of such SDP modifications include receiving hold SDP or removing an audio or video stream. When this occurs, the media server immediately terminates the running <play>, <playcollect>, or <playrecord> request and sends a <response> indicating "reason=stopped".
メディアサーバは、再INVITEそれは暗黙の<停止>要求として確立されたSDPパラメータを変更するSIPを扱います。そのようなSDP修飾の例は、ホールドSDPを受信し、またはオーディオまたはビデオストリームを除去することを含みます。これが発生すると、「停止=理由」を、メディアサーバは、すぐに実行されている<遊び>、<playcollect>、または<playrecord>要求を終了して示す<応答>を送信します。
The MSCML IVR requests support two methods of specifying content to be delivered to the user. These are the <prompt> element and the prompturl attribute. Clients MUST NOT utilize both methods in a single IVR request. Clients SHOULD use the more flexible <prompt> mechanism. Use of the prompturl attribute is deprecated and may not be supported in future MSCML versions.
MSCML IVR要求は、ユーザに配信するコンテンツを指定する2つのメソッドをサポートしています。これらは、<プロンプト>要素とprompturl属性です。クライアントは、単一のIVR要求の両方の方法を利用してはなりません。クライアントは、より柔軟な<迅速な>メカニズムを使用すべきです。 prompturl属性の使用は推奨されず、将来のMSCMLバージョンではサポートされない場合があります。
The <prompt> element MAY be included in the body of a <play>, <playcollect>, or <playrecord> request to specify a prompt sequence to be delivered to the caller. The prompt sequence consists of one or more references to physical content files, spoken variables, or dynamic URLs that return a sub-sequence of files or variables. In addition, the <prompt> element has several attributes that control playback of the included content. These are described in the list below.
<プロンプト>要素は、発信者に配信されるプロンプト順序を指定するには、<遊び>、<playcollect>、または<playrecord>リクエストのボディに含まれるかもしれません。プロンプトのシーケンスは、物理的なコンテンツファイル、話変数、またはファイルまたは変数のサブシーケンスを返す動的URLへの1つまたは複数の参照で構成されています。また、<プロンプト>要素が含まれたコンテンツの再生を制御するいくつかの属性を有します。これらは、以下のリストに記載されています。
Attributes of <prompt>:
<プロンプト>の属性：
o baseurl - optional, no default value: For notational convenience, as well as reducing the MSCML payload size, the "baseurl" attribute is used to specify a base URL that is prepended to any other URLs in the sequence that are not fully qualified.
O BASEURL - オプションで、デフォルトなし値：表記の便宜上、同様にMSCMLペイロードサイズを小さくするために、「BASEURL」属性は、完全修飾されていないシーケンスの任意の他のURLの先頭に追加されたベースURLを指定するために使用されます。
o delay - optional, default value "0": The "delay" attribute to the prompt element specifies the time to pause between repetitions of the <prompt> sequence. It has no effect on the first iteration of the sequence. Expressed as a time value (Section 4.2.1) from 0 onwards.
Oの遅延 - オプション、デフォルト値「0」：プロンプト要素に「遅延」属性は、<>プロンプトシーケンスの繰り返しの間に一時停止する時間を指定します。これは、シーケンスの最初の繰り返しには影響を与えません。以降0から時間値（セクション4.2.1）のように表します。
o duration - optional, default value "infinite": The "duration" attribute to the prompt element controls the maximum amount of time that may elapse while the media server repeats the sequence. This allows the client to set an upper bound on the length of play. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite". "Immediate" directs the media server to end play immediately, whereas "infinite" indicates that the media server imposes no limit.
期間O - オプション、デフォルト値「無限」：プロンプト要素への「期間」属性は、メディアサーバがシーケンスを繰り返しながら経過して時間の最大量を制御します。これは、クライアントが遊びの長さに上限を設定することができます。以降は1msから時間値（4.2.1項）、または文字列「即時」と「無限」と表現。 「無限」は、メディアサーバが制限を課していないことを示しているのに対し、「即時」、すぐにプレイを終了するには、メディアサーバーに指示します。
o gain - optional, default value "0": Sets the absolute gain to be applied to the content contained in <prompt>. The value of this attribute is specified in units of dB. The media server MAY silently cap values that exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content contained in <prompt> has been completed.
Oゲイン - 任意のデフォルト値「0」<プロンプト>に含まれるコンテンツに適用される絶対的な利得が設定します。この属性の値はデシベル単位で指定します。メディアサーバは静かにプラットホームによって課された利得限界を超えた値をキャップMAY。 <プロンプト>に含まれるコンテンツの再生が終了したときにレベルが元の値に戻ります。
o gaindelta - optional, default value "0": Sets the relative gain to be applied to the content contained in <prompt>. The value of this attribute is specified in units of dB. The media server MAY silently cap values which exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content contained in <prompt> has been completed.
O gaindelta - 任意のデフォルト値「0」<プロンプト>に含まれるコンテンツに適用される相対利得を設定します。この属性の値はデシベル単位で指定します。メディアサーバは静かにプラットホームによって課された利得限界を超えた値をキャップMAY。 <プロンプト>に含まれるコンテンツの再生が終了したときにレベルが元の値に戻ります。
o rate - optional, default value "0": Specifies the absolute playback rate of the content relative to normal as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content contained in <prompt> has been completed.
Oレート - 任意のデフォルト値「0」が正のパーセンテージ（速い）または負のパーセンテージ（遅い）のいずれかとして正常にコンテンツの相対的な絶対的な再生速度を指定します。許可またはサイレント許容最小値以下の最大上記レートを設定しようとする任意の値が最大または最小にレートを設定します。 <プロンプト>に含まれるコンテンツの再生が終了したときに速度が元の値に戻ります。
o ratedelta - optional, default value "0": Specifies the playback rate of the content relative to it's current rate as either a positive percentage (faster) or negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content contained in <prompt> has completed.
O ratedelta - オプション、デフォルト値「0」は：それへのコンテンツの相対的な再生速度を指定する正の割合（速い）か負の割合（遅い）のどちらかとして現在のレートです。許可またはサイレント許容最小値以下の最大上記レートを設定しようとする任意の値が最大または最小にレートを設定します。 <プロンプト>に含まれるコンテンツの再生が完了したときに速度が元の値に戻ります。
o locale - optional, no default value: Specifies the language and country variant used for resolving spoken variables. The language is defined as a two-letter code per ISO 639. The country variant is also defined as a two-letter code per ISO 3166. These codes are concatenated with a single underscore (%x5F) character.
Oロケール - オプションで、デフォルトなし値：話の変数を解決するために使用される言語と国バリアントを指定します。言語は、国変異体はまた、これらのコードは、単一の下線（％x5F）文字で連結されているISO 3166ごとに2文字のコードとして定義されているISO 639ごとに2文字のコードとして定義されます。
o offset - optional, default value "0": A time value (Section 4.2.1) which specifies the time from the beginning of the sequence at which play is to begin. Offset only applies to the first repetition; subsequent repetitions begin play at offset 0. Allowable values are positive time values from 0 onwards. When the sequence consists of multiple content files, the offset may select any point in the sequence. If the offset value is greater than the total time of the sequence, it will "wrap" to the beginning and continue from there until the media server reaches the specified offset.
Oオフセット - オプション、デフォルト値「0」：プレイを開始するされたシーケンスの先頭からの時間を指定する時間値（セクション4.2.1を）。最初の繰り返しのみに適用されるオフセット。以降、0から正の時間値を0許容値をオフセットしている時に、後続の繰り返しは、プレイを始めます。シーケンスは、複数のコンテンツファイルで構成されている場合、オフセットは、シーケンス内の任意のポイントを選択することができます。オフセット値は、シーケンスの合計時間よりも大きい場合、それは最初に「ラップ」し、メディアサーバーが指定されたオフセットに達するまで、そこから継続します。
o repeat - optional, default value "1": The "repeat" attribute to the prompt element controls the number of times the media server plays the sequence in the <prompt> element. Allowable values are integers from 0 on and the string "infinite", which indicates that repetition should occur indefinitely. For example, "repeat=2" means that the sequence will be played twice, and "repeat=0", which is allowed, means that the sequence is not played.
Oリピート - オプション、デフォルト値「1」：「リピート」属性は、プロンプト要素にメディアサーバは<プロンプト>要素のシーケンスを果たしている回数を制御します。許容値は、繰り返しが無限に起こるべきであることを示していると、文字列「無限」、上の0からの整数です。例えば、「リピート= 2」は、配列が二回演奏され、許可されている「リピート= 0」は、シーケンスが再生されないことを意味していることを意味します。
o stoponerror - optional, default value "no": Controls media server handling and reporting of errors encountered when retrieving remote content. If set to "yes", content play will end if a fetch error occurs, and the response will contain details regarding the failure. If set to "no", the media server will silently move on to the next URL in the sequence if a fetch failure occurs.
O STOPONERROR - オプション、デフォルト値は「いいえ」：リモートコンテンツを取得する際に発生したエラーのメディアサーバの処理およびレポートを制御します。設定した場合は「はい」、フェッチエラーが発生した場合は、コンテンツの再生が終了し、応答が失敗に関する詳細が含まれます。 「なし」に設定した場合、フェッチ障害が発生した場合、メディアサーバは静かにシーケンス内の次のURLに移動します。
Clients MUST NOT include both 'gain' and 'gaindelta' attributes within a single <prompt> element.
クライアントは、「ゲイン」と「gaindelta」一<プロンプト>要素内の属性の両方を含めることはできません。
When the client explicitly controls the output gain on a conference leg, as described in Section 5.3, the 'gain' and 'gaindelta' attributes SHOULD interact with the conference leg output gain settings in the following manner.
クライアントが明示的に5.3節で説明したように会議脚の出力利得を制御すると、「ゲイン」とは、「gaindeltaの属性は、次のように会議脚の出力ゲイン設定と対話すべきです。
o Conference leg output gain set to <fixed>: The operation of the 'gain' and 'gaindelta' attributes are unchanged. However, the baseline gain value before any playback changes are applied is the value specified for the conference leg.
Oカンファレンス脚出力ゲインを設定し、<固定>：「ゲイン」と「gaindeltaの属性が変更されていないの動作。しかし、ベースラインのゲイン値任意の再生変更が適用される前に、会議脚に指定された値です。
o Conference leg output gain set to <auto>: When playback gain controls are used, the automatic gain control settings for the leg are suspended for the duration of the playback operation. The operation of the 'gain' and 'gaindelta' attributes are unchanged. The automatic gain control settings are reinstated when playback has finished.
O会議レッグ出力ゲインに設定<自動>：再生利得制御が使用される場合、脚のための自動利得制御設定は、再生動作の期間中に懸濁させます。 「ゲイン」と「gaindeltaの属性の動作が変更されません。再生が終了したときに自動利得制御設定が復元されます。
Media servers SHOULD support rate controls for content. However, media servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <prompt> element.
メディアサーバーは、コンテンツのレートコントロールをサポートする必要があります。コンテンツの制限は、要求を光栄にすることはできません場合は、メディアサーバは静かにレート変更要求を無視するかもしれません。クライアントは「率」と「ratedelta」一<プロンプト>要素内の属性の両方を含めることはできません。
Figure 16 shows a sample prompt block.
図16は、試料プロンプトブロックを示しています。
<prompt stoponerror="yes" baseurl="file:////var/mediaserver/prompts/" locale="en_US" offset="0" gain="0" rate="0" delay="0" duration="infinite" repeat="1"> <audio url="num_dialed.raw" encoding="ulaw"/> <variable type="dig" subtype="ndn" value="3014170700"/> <audio url="num_invalid.wav"/> <audio url="please_check.wav"/> </prompt>
<プロンプトSTOPONERROR = "yes" をBASEURL = "ファイル：//// VAR / MediaServerの/プロンプト/" ロケール= "en_USの" オフセット= "0"、ゲイン= "0" 率= "0" 遅延= "0" 期間= "無限" 繰り返す= "1"> <オーディオURL = "num_dialed.raw" エンコード= "ULAW" /> <変数タイプ= "掘る" サブタイプ= "NDN" 値= "3014170700" /> <オーディオURL = "num_invalid .WAV "/> <オーディオURL =" please_check.wav "/> </プロンプト>
Figure 16: Prompt Block Example
図16：プロンプトのブロックの例
Clients compose prompt sequences using the <audio> and <variable> elements. An <audio> element MAY refer to content that contains audio, video, or both; the generic name is preserved for backwards compatibility. The <audio> element has the attributes described in the list below.
クライアントは、<オーディオ>と<変数>要素を使用して、プロンプトのシーケンスを構成します。 <オーディオ>要素は、オーディオ、ビデオ、またはその両方が含まれているコンテンツを参照してもよいです。一般名は、後方互換性のために保存されます。 <オーディオ>要素は、以下のリストで説明する属性を持っています。
Attributes of <audio>:
<オーディオ>の属性：
o url - required, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. If the URL is not fully qualified and a "baseurl" attribute was set, the value of the "baseurl" attribute will be prepended to this value to generate the target URL.
O URL - 必要なしデフォルト値：コンテンツのURLを取得して再生します。スキームのURLまたは「http：//」または「https：//で」スキームURL：ターゲットは、ローカルまたはリモート（NFS）「//ファイル」であってもよいです。 URLは、完全修飾されていない場合や、「BASEURL」属性が設定された、「BASEURL」属性の値は、ターゲットURLを生成するには、この値の前に追加されます。
o encoding - optional, default value "ulaw": Specifies the content encoding for file formats that are not self-describing (e.g., .WAV). Allowable values are "ulaw", "alaw", and "msgsm". This attribute only affects "file://" scheme URLs.
Oエンコード - 任意のデフォルト値「ULAW」は：自己記述（例えば、.WAV）でないファイル形式のコンテンツのエンコーディングを指定します。許容値は、 "ULAW"、 "ALAW"、および "msgsm" です。スキームのURL：この属性は、「//ファイルを」影響を与えます。
o gain - optional, default value "0": Sets the absolute gain to be applied to the content URL. The value of this attribute is specified in units of dB. The media server MAY silently cap values that exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content URL has been completed.
Oゲイン - オプション、デフォルト値「0」：コンテンツのURLに適用される絶対的なゲインを設定します。この属性の値はデシベル単位で指定します。メディアサーバは静かにプラットホームによって課された利得限界を超えた値をキャップMAY。コンテンツURLの再生が完成したとき、レベルは元の値に戻ります。
o gaindelta - optional, default value "0": Sets the relative gain to be applied to the content URL. The value of this attribute is specified in units of dB. The media server MAY silently cap values that exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content URL has been completed.
O gaindelta - オプション、デフォルト値「0」：コンテンツのURLに適用される相対利得を設定します。この属性の値はデシベル単位で指定します。メディアサーバは静かにプラットホームによって課された利得限界を超えた値をキャップMAY。コンテンツURLの再生が完成したとき、レベルは元の値に戻ります。
o rate - optional, default value "0": Specifies the absolute playback rate of the content relative to normal as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content URL has been completed.
Oレート - 任意のデフォルト値「0」が正のパーセンテージ（速い）または負のパーセンテージ（遅い）のいずれかとして正常にコンテンツの相対的な絶対的な再生速度を指定します。許可またはサイレント許容最小値以下の最大上記レートを設定しようとする任意の値が最大または最小にレートを設定します。コンテンツURLの再生が完成したとき、レートは元の値に戻ります。
o ratedelta - optional, default value "0": Specifies the playback rate of the content relative to it's current rate as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content URL has been completed.
O ratedelta - オプション、デフォルト値「0」は：それへのコンテンツの相対的な再生速度を指定する正の割合（速い）か負の割合（遅い）のどちらかとして現在のレートです。許可またはサイレント許容最小値以下の最大上記レートを設定しようとする任意の値が最大または最小にレートを設定します。コンテンツURLの再生が完成したとき、レートは元の値に戻ります。
Clients MUST NOT include both 'gain' and 'gaindelta' attributes within a single <audio> element.
クライアントは、「ゲイン」と「gaindelta」一<オーディオ>要素内の属性の両方を含めることはできません。
When the client explicitly controls the output gain on a conference leg, as described in Section 5.3, the 'gain' and 'gaindelta' attributes SHOULD interact with the conference leg output gain settings in the following manner.
クライアントが明示的に5.3節で説明したように会議脚の出力利得を制御すると、「ゲイン」とは、「gaindeltaの属性は、次のように会議脚の出力ゲイン設定と対話すべきです。
o Conference leg output gain set to <fixed>: The operation of the 'gain' and 'gaindelta' attributes are unchanged. However, the baseline gain value before any playback changes are applied is the value specified for the conference leg.
Oカンファレンス脚出力ゲインを設定し、<固定>：「ゲイン」と「gaindeltaの属性が変更されていないの動作。しかし、ベースラインのゲイン値任意の再生変更が適用される前に、会議脚に指定された値です。
o Conference leg output gain set to <auto>: When playback gain controls are used, the automatic gain control settings for the leg are suspended for the duration of the playback operation. The operation of the 'gain' and 'gaindelta' attributes are unchanged. The automatic gain control settings are reinstated when playback has finished.
O会議レッグ出力ゲインに設定<自動>：再生利得制御が使用される場合、脚のための自動利得制御設定は、再生動作の期間中に懸濁させます。 「ゲイン」と「gaindeltaの属性の動作が変更されません。再生が終了したときに自動利得制御設定が復元されます。
Media servers SHOULD support rate controls for content. However, media servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <audio> element.
メディアサーバーは、コンテンツのレートコントロールをサポートする必要があります。コンテンツの制限は、要求を光栄にすることはできません場合は、メディアサーバは静かにレート変更要求を無視するかもしれません。クライアントは「率」と「ratedelta」一<オーディオ>要素内の属性の両方を含めることはできません。
Media servers MUST support local and remote (NFS) "file://" scheme URLs and "http://" and "https://" scheme URLs for content retrieval.
メディアサーバーは、ローカルおよびリモート（NFS）「ファイル：//」をサポートしなければならないスキームのURLと「のhttp：//」や「https：//で」コンテンツ検索のためのスキームのURL。
NOTE: The provisioning of NFS mount points and their mapping to the "file://" schema is purely a local matter at the media server.
注：NFSのプロビジョニングは、ポイントをマウントし、「ファイル：//」へのマッピングスキーマは純粋にメディアサーバーでローカルの問題です。
MSCML also supports "http://" and "https://" scheme URLS that return a list of physical URLs using the "text/uri-list" MIME type. This facility provides flexibility for applications to dynamically generate prompt sequences at execution time and enables separation of this function from the client and media server.
そして、「https：//で」「uriテキスト/リスト」MIMEタイプを使用して物理的なURLのリストを返す仕組みのURL：MSCMLも「// HTTP」をサポートしています。この機能は、動的に実行時にプロンプトシーケンスを生成し、クライアントとメディアサーバーからこの機能の分離を可能にするアプリケーションのための柔軟性を提供します。
Spoken variables are specified using the <variable> element. This element has the attributes described in the list below. MSCML's spoken variables are based on those described in Audio Server Protocol [17].
話された変数は、<variable>要素を使用して指定されています。この要素は、以下のリストで説明する属性を持っています。 MSCMLの話された変数は、オーディオサーバプロトコル[17]に記載されたものに基づいています。
Attributes of <variable>:
<変数>の属性：
o type - required, no default value: Specifies the major type format of the spoken variable to be played. Allowable values are "dat" (date), "dig" (digit), "dur" (duration), "mth" (month), "mny" (money), "num" (number), "sil" (silence), "str" (string), "tme" (time), and "wkd" (weekday).
Oタイプ - 必要なしデフォルト値：話さ変数の主要な種類のフォーマットが再生されるように指定します。許容値は、 "DAT"（日付）は、 "掘る"（数字）、 "DUR"（継続）、 "m番目"（月）、 "MNY"（金）、 "NUM"（数）、 "SIL"（沈黙）、 "STR"（文字列）、 "TME"（時間）、および "WKD"（平日）。
o subtype - optional, no default value: Specifies the minor type format of the spoken variable to be played. Allowable values depend on the value of the corresponding "type" attribute. Possible values are "mdy", "ymd", and "dmy" for dates, "t12" and "t24" for times, "gen", "ndn", "crd", and "ord" for digits, and "USD" for money.
Oサブタイプ - オプションで、デフォルトなし値：話さ変数のマイナータイプのフォーマットが再生できるように指定します。許容値は、対応する「タイプ」属性の値に依存します。可能な値は "MDY"、 "YMD"、および時刻の日付のための "DMY"、 "T12" と "T24"、 "GEN"、 "NDN"、 "CRD"、および数字のための "ORD"、および「USDです" お金のために。
o value - required, no default value: A string that will be interpreted based on the formatting information specified in the "type" and "subtype" attributes and the "locale" attribute of the parent <prompt> element to render the spoken variable.
O値 - 必要なしデフォルト値：「タイプ」と「サブタイプ」に指定されたフォーマット情報に基づいて解釈される文字列の属性と親の「ロケール」属性<プロンプト>要素は、変数話さレンダリングします。
If the "locale" attribute was not specified in <prompt>, the media server SHOULD make a selection based on platform configuration. If the precise "locale" requested cannot be honored, the media server SHOULD select the closest match based on the available content.
「ロケール」属性は、<プロンプト>で指定されていない場合は、メディアサーバは、プラットフォーム構成に基づいて選択を行う必要があります。要求された正確な「ロケールは」光栄することができない場合は、メディアサーバは、利用可能なコンテンツに基づいて最も近いものを選択する必要があります。
IVR applications normally require specialized prompt content that is authored by the application provider. To deliver a quality user interaction, the specialized prompts and spoken variables must be generated by the same speaker. Since the media server inherently supports multiple simultaneous applications, it is extremely difficult to provision all the necessary application prompts and matching spoken variable content locally on the media server. Therefore, we STRONGLY RECOMMEND that clients employ the dynamic URL mechanism described earlier to generate spoken variables using an external web server that returns "text/uri-list" content.
IVRアプリケーションは、通常、アプリケーションプロバイダによって作成された専門のプロンプトコンテンツを必要としています。品質のユーザーとの対話を実現するには、専門的なプロンプトと話された変数は、同じ話者によって生成されなければなりません。メディアサーバは、本質的に同時に複数のアプリケーションをサポートしているので、それがメディアサーバー上でローカル変数の内容を話され、必要なすべてのアプリケーションのプロンプトとマッチング提供することは極めて困難です。したがって、私たちは強く、クライアントが「uriテキスト/リスト」内容を返す外部Webサーバーを使用して話された変数を生成するために、先に説明した動的URLメカニズムを採用することをお勧めします。
MSCML IVR requests implicitly support multimedia content. Multimedia capabilities are controlled by the audio and video media negotiated for the dialog and the content specified by the client for play and record operations. If the content specified for delivery contains both audio and video tracks and the dialog has audio and video streams, both tracks are streamed to the caller. Likewise, if the dialog has both audio and video streams and the content format specified supports both (e.g., .3gp files) the media server records both streams to the file.
MSCML IVR要求は、暗黙的にマルチメディアコンテンツをサポートしています。マルチメディア機能は、ダイアログと再生および録音操作のために、クライアントによって指定されたコンテンツのために交渉し、オーディオとビデオのメディアによって制御されています。配信のために指定されたコンテンツは、オーディオとビデオの両方のトラックが含まれていると、ダイアログは、オーディオおよびビデオストリームを持っている場合は、両方のトラックは、呼び出し側にストリーミングされています。同様に、ダイアログは、メディアサーバレコードのオーディオおよびビデオストリームとコンテンツフォーマット指定の両方をサポート（例えば、.3GPファイル）の両方を持って、両方のファイルにストリーム場合。
If there is a mismatch between the real time media and specified content, the media server MUST play or record the appropriate content tracks rather than failing the request. For example, if the client has requested playback of content with audio and video tracks but only audio media has been established for the dialog, the media server should play the audio track. If the dialog has both audio and video media but the content is audio-only, the media server MAY stream a pre-provisioned video track to the caller. Media servers SHOULD implement video transcoding functions to minimize incompatibilities between real time media and content.
リアルタイムメディアと指定されたコンテンツとの間に不一致がある場合は、メディアサーバは、再生したり、要求を失敗よりも、適切なコンテンツのトラックを、むしろ記録しなければなりません。例えば、クライアントは、オーディオとビデオトラックとコンテンツの再生を要求したが、音声のみのメディアは、ダイアログのために確立されている場合は、メディアサーバは、オーディオトラックを再生しなければなりません。ダイアログがオーディオとビデオの両方のメディアを持っていますが、コンテンツがある場合は音声のみ、メディアサーバは、発信者への事前プロビジョニングビデオトラックをストリーミングするかもしれません。メディアサーバーは、リアルタイムメディアとコンテンツの間の非互換性を最小限に抑えるためにビデオトランスコーディング機能を実装する必要があります。
The media server MUST begin recording video media only when it receives a refresh video frame. A refresh frame contains all the video information required to decode that frame (i.e., there is no dependency on data from previous video frames). Refresh frames are large and generally sent infrequently to conserve network bandwidth. The media server MUST implement standard mechanisms to request that the caller (video encoder) transmit a refresh frame to ensure video recording begins quickly. The media server MUST begin recording the audio track immediately while waiting to receive the video refresh frame.
メディアサーバは、それがリフレッシュビデオフレームを受信した場合にのみ、映像メディアの記録を開始しなければなりません。リフレッシュフレームは、そのフレームを復号するために必要なすべてのビデオ情報（すなわち、前のビデオフレームからのデータには依存関係が存在しない）を含みます。リフレッシュフレームが大きく、一般的にネットワーク帯域幅を節約するために、まれに送られます。メディアサーバは、発信者（ビデオエンコーダ）は、録画がすぐに始まる確実にするために、リフレッシュフレームを送信することを要求するために、標準的なメカニズムを実装しなければなりません。メディアサーバは、ビデオ・リフレッシュフレームを受け取るために待っている間に、すぐにオーディオトラックの記録を開始しなければなりません。
The client issues a <play> request to play an announcement without interruption and with no digit collection. One use, for example, is to announce the name of a new participant to the entire conference. The <play> request has the attributes described in the list below.
クライアントは、中断することなくなし桁のコレクションで発表を再生するには、<遊び>要求を発行します。 1つの用途は、例えば、全体会議に新しい参加者の名前を発表することです。 <遊び>の要求は、以下のリストで説明する属性を持っています。
Attributes of <play>:
<遊び>の属性：
o id - optional, no default value: Specifies a client-defined ID for purposes of matching requests and responses.
OのID - オプションで、デフォルトなし値：一致する要求と応答の目的のために、クライアントに定義されたIDを指定します。
o offset - optional, default value "0": Specifies the time from the beginning of the URL specified in the 'prompturl' attribute at which play will begin. Expressed as a time value (Section 4.2.1) from 0 onwards. If the offset value is greater than the total time of the content, it will "wrap" to the beginning and continue from there until the media server reaches the specified offset. NOTE: Use of this attribute is deprecated.
Oオフセット - オプション、デフォルト値は「0」：プレイが開始される「prompturl」属性で指定されたURLの先頭からの時間を指定します。以降0から時間値（セクション4.2.1）のように表します。オフセット値は、コンテンツの総時間よりも大きい場合、それは最初に「ラップ」し、メディアサーバーが指定されたオフセットに達するまで、そこから継続します。注：この属性の使用は推奨されません。
o promptencoding - optional, no default value: Specifies the content encoding for file formats that are not self-describing (e.g., .WAV). Allowable values are "ulaw", "alaw", and "msgsm". This attribute only affects "file://" scheme URLs. NOTE: Use of this attribute is deprecated.
O promptencoding - オプション、デフォルト値は：自己記述（例えば、.WAV）でないファイル形式のコンテンツのエンコーディングを指定しません。許容値は、 "ULAW"、 "ALAW"、および "msgsm" です。スキームのURL：この属性は、「//ファイルを」影響を与えます。注：この属性の使用は推奨されません。
o prompturl - optional, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
O prompturl - オプションで、デフォルトなし値：コンテンツのURLを取得して再生すること。スキームのURLまたは「http：//」または「https：//で」スキームURL：ターゲットは、ローカルまたはリモート（NFS）「//ファイル」であってもよいです。注：この属性の使用は推奨されません。
The <play> request has one child element defined, <prompt>. Use of <prompt> is described in Section 6.1.1.
<遊び>要求は1つのつの子要素定義され、<>プロンプトを持っています。 <プロンプト>の使用は、セクション6.1.1に記載されています。
The client MUST NOT use both the <prompt> element and "prompturl" attribute in a single request. As previously discussed, the "prompturl" attribute is supported for backwards compatibility with older MSCML applications, but its use is deprecated. The more flexible <prompt> element SHOULD be used instead.
クライアントは、単一のリクエストで、<プロンプト>要素と「prompturl」属性の両方を使用してはなりません。前述したように、「prompturl」属性は、古いMSCMLアプリケーションとの後方互換性のためにサポートされていますが、その使用は推奨されません。より柔軟<プロンプト>要素を代わりに使用してください。
The following play request (Figure 17) example shows the delivery of a complex prompt sequence consisting of content accessed via NFS and spoken variables.
次の再生要求（図17）は、例えばNFSと話さ変数を介してアクセスされるコンテンツからなる複合プロンプトシーケンスの送達を示します。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <play id="332985001"> <prompt stoponerror="yes" baseurl="file:////var/mediaserver/prompts/" locale="en_US" offset="0" gain="0" rate="0" delay="0" duration="infinite" repeat="1"> <audio url="num_dialed.raw" encoding="ulaw"/> <variable type="dig" subtype="ndn" value="3014170700"/> <audio url="num_invalid.wav"/> <audio url="please_check.wav"/> </prompt> </play> </request> </MediaServerControl>
<？xmlのバージョン= "1.0"> <MediaServerControlバージョン= "1.0"> <要求> <遊ぶのid = "332985001"> <プロンプトSTOPONERROR = "yes" をBASEURL = "ファイル：//// VAR / MediaServerの/プロンプト0 "ゲイン= "0" 速度 "0" 遅延= "0" の期間= "無限" リピート= "1"> <オーディオURL = "num_dialed.raw "=オフセット" / "ロケール=" en_USの" エンコーディング=" ULAW "/> <変数の型="「サブタイプ= "NDN掘る" 値を= "3014170700" /> <オーディオURL = "num_invalid.wav" /> <オーディオURL = "please_check.wav" /> </プロンプト> <再生/> </リクエスト> </ MediaServerControl>
Figure 17: <Play> Request Example
図17：要求の例<再生>を
When the announcement has finished playing, the media server sends a <response> payload to the client in a SIP INFO message. Details regarding the format of <play> responses are provided in Section 10.4.
発表の再生が終了したとき、メディアサーバは、SIP INFOメッセージでクライアントに<応答>ペイロードを送信します。 <遊び>のフォーマットに関する詳細は、応答は10.4で提供されています。
The client issues a <playcollect> request to play an announcement (optional) and collect digits. The <playcollect> request is executed in two phases, prompt and collect. If the client specifies prompt content to be played, using the <prompt> element or prompturl attribute, the media server plays the content before starting the collection phase. If no prompt content is specified, the collect phase begins immediately.
クライアントが発表（別売）を再生し、ディジットを収集するために、<playcollect>要求を発行します。 <playcollect>要求プロンプト、二段階で実行され、収集されます。クライアントが再生するプロンプトコンテンツを指定した場合、<プロンプト>要素またはprompturl属性を使用して、メディアサーバは、収集フェーズを開始する前に、コンテンツを再生します。何のプロンプトコンテンツが指定されていない場合は、収集フェーズはすぐに開始されます。
The basic attributes of <playcollect> are the same as those of <play>, which were described in Section 6.3. In addition to these basic attributes, <playcollect> defines others which control digit buffering and barge-in behavior, collection timers, special purpose DTMF key functions, and logging of user DTMF input. Each functional category and its attributes are described below.
<playcollect>の基本的な属性は、セクション6.3で説明された、<遊び>のものと同じです。これらの基本的な属性に加えて、<playcollect>は、桁バッファリングとはしけ-での動作、収集タイマー、特別な目的のDTMFキー機能、およびユーザーのDTMF入力のログを制御他人を定義します。各機能カテゴリとその属性は、以下に記載されています。
Whenever the media server is processing a call that specifies an MSCML service (i.e., "conf" and "ivr"), the media server continuously looks for DTMF digits and places them in a quarantine buffer. The quarantine buffer is examined when a <playcollect> request is received. The media server compares any previously buffered digits for barge-in, and to look for matches with DTMF grammars or special purpose keys. This provides the type-ahead behavior for menu traversal and other types of IVR interactions.
メディアサーバがMSCMLサービス（すなわち、「CONF」と「IVR」）を指定するコールを処理しているときはいつでも、メディアサーバは、継続的にDTMF数字を探し、隔離バッファに配置します。 <playcollect>要求を受信したときに隔離バッファが検査されます。メディアサーバは、バージ・インのために以前にバッファリングされた数字を比較し、DTMF文法や特殊目的のキーとの一致を見て。これは、メニュートラバーサルおよびIVR相互作用の他のタイプのための先行入力動作を提供します。
Attributes for Control of Digit Buffering and Barge-In:
桁のバッファリングとバージ-Inのコントロールのための属性：
o cleardigits - optional, default value "no": Specifies whether previous user input should be considered or ignored for barge-in purposes and DTMF matching. When it is set to "yes", any previously buffered digits are removed, so prior user input is ignored. If it is set to "no", previously buffered digits will be considered. If "cleardigits" is set to "no" and barge-in is enabled, previously buffered digits will immediately terminate the prompt phase. In this case, the prompt is not played, and digit collection begins immediately.
O cleardigits - オプション、デフォルト値「いいえ」：以前のユーザー入力が考慮さやはしけインの目的とDTMFマッチングのために無視するかどうかを指定します。それが「はい」に設定されている場合は、任意の以前にバッファリングされたケタが削除され、その前にユーザーの入力は無視されます。それは「なし」に設定されている場合は、以前にバッファリングされたケタが考慮されます。 「cleardigits」は「いいえ」に設定され、バージ・インが有効になっている場合は、以前にバッファリングされたケタはすぐに迅速なフェーズを終了します。この場合、プロンプトが演奏し、数字収集がすぐに開始されていません。
o barge - optional, default value "yes": Specifies whether user input will barge the prompt and force transition to the collect phase. When it is set to "yes", a DTMF input will barge the prompt. When it is set to "no", the prompt phase cannot be barged, and any user input during the prompt is placed in the quarantine buffer for inspection during the collect phase. Note that if the "barge" attribute is set to "no", the "cleardigits" attribute implicitly has a value of "yes". This ensures that the media server does not leave DTMF input that occurred prior to the current collection in the quarantine buffer after the request is completed.
Oのはしけ - オプション、デフォルト値は「はい」：ユーザーの入力が収集フェーズへの迅速かつ力の移行を割り込むかどうかを指定します。それが「はい」に設定されている場合は、DTMF入力はプロンプトを割り込むだろう。それは「NO」に設定されている場合、プロンプト相が割り込まできず、プロンプト中の任意のユーザ入力が収集フェーズ中に検査用隔離バッファに置かれます。 「はしけ」属性が「なし」に設定されている場合は、「cleardigits」属性が暗黙のうちに「はい」の値を持っていることに注意してください。これは、メディアサーバは、要求が完了した後に隔離バッファにおける現在のコレクションに先立って発生したDTMF入力を残さないことを保証します。
The client can define mappings between DTMF digits and special functions. The media server invokes the special function if the associated DTMF digit is detected. MSCML has two attributes that define mappings that affect termination of the collect phase. These attributes are described in the list below.
クライアントは、DTMF数字と特殊な機能間のマッピングを定義することができます。関連するDTMFディジットが検出された場合、メディアサーバは、特殊な関数を呼び出します。 MSCMLは、収集フェーズの終了に影響を与えるのマッピングを定義する2つの属性があります。これらの属性は、以下のリストに記載されています。
DTMF Key Mappings for <playcollect>:
<playcollect>のためのDTMFキーマッピング：
o escapekey - optional, default value "*": Specifies a DTMF key that indicates that the user wishes to terminate the current operation without saving any input collected to that point. Detection of the mapped DTMF key terminates the request immediately and generates a response.
O escapekey - オプション、デフォルト値の「*」：ユーザーがその時点までに収集したすべての入力を保存せずに現在の操作を終了したいことを示しているDTMFキーを指定します。マッピングされたDTMFキーの検出は、直ちに要求を終了し、応答を生成します。
o returnkey - optional, default value "#": Specifies a DTMF key that indicates that the user has completed input and wants to return all collected digits to the client. When the media server detects the returnkey, it immediately terminates collection and returns the collected digits to the client in the <response> message.
O returnkey - オプション、デフォルト値「＃」はユーザが入力を完了し、クライアントに収集されたすべての数字を返すように望んでいることを示しているDTMFキーを指定します。メディアサーバーがreturnkeyを検出すると、それはすぐにコレクションを終了し、<応答>メッセージでクライアントに収集した数字を返します。
MSCML defines three additional mappings to enable video cassette recorder (VCR) type controls while playing a prompt sequence. Media servers SHOULD support VCR controls. However, if the media server does not support VCR controls, it MUST silently ignore DTMF inputs mapped to VCR functions and complete the <playcollect> request. The VCR control attributes are described in the list below.
MSCMLは、ビデオカセットレコーダー（VCR）をイネーブルプロンプトシーケンスを再生しながらコントロールを入力するための3つの追加のマッピングを定義します。メディアサーバーは、VCRのコントロールをサポートする必要があります。メディアサーバーは、VCRコントロールをサポートしていない場合しかし、それは静かにVCR機能にマッピングされたDTMF入力を無視して、<playcollect>要求を完了する必要があります。 VCR制御属性は、以下のリストに記載されています。
Attributes for VCR Controls:
VCRコントロールの属性：
o skipinterval - optional, default value "6s": The "skipinterval" attribute indicates how far the media server should skip backwards or forwards when the rewind key (rwkey) or fast forward key (ffkey) is pressed, specified as a time value (Section 4.2.1).
O skipinterval - オプション、デフォルト値「6S」：「skipinterval」属性が時間値として指定し、巻き戻しキー（rwkey）または早送りキー（ffkey）が押されたとき、メディアサーバは、前後にスキップするべきか遠くを示しています（ 4.2.1項）。
o ffkey - optional, no default value: The "ffkey" attribute maps a DTMF key to a fast forward operation equal to the value of the "skipinterval" attribute.
O ffkey - オプション、デフォルト値なし：「ffkey」属性は、「skipinterval」属性の値に等しい早送り動作にDTMFキーをマッピングします。
o rwkey - optional, no default value: The "rwkey" attribute maps a DTMF key to a rewind action equal to the value of the "skipinterval" attribute.
rwkey O - オプション、デフォルト値なし：「rwkey」属性は「skipinterval」属性の値に等しい巻き戻しアクションへのDTMFキーをマッピングします。
Clients MUST NOT map the same DTMF digit to both the "rwkey" and "ffkey" attributes in a single <playcollect> request.
クライアントは、単一の<playcollect>リクエストの属性「rwkey」と「ffkey」の両方に同じDTMFディジットをマッピングしてはなりません。
VCR control operations are bounded by the beginning and end of the prompt sequence. A rewind action that moves the offset before the beginning of the sequence results in playback starting at the beginning of the sequence (i.e., offset=0). A fast forward action that moves the offset past the end of the sequence results in the media server's treating the sequence as complete.
VCR制御操作は、プロンプトシーケンスの最初と最後で囲まれています。配列の先頭から再生のシーケンス結果の開始前に、オフセット移動する巻き戻し動作（すなわち、= 0をオフセット）。メディアサーバーの完全なよう順序を治療する際のシーケンス結果の最後を超えてオフセット移動早送りアクション。
MSCML defines several timer attributes that control how long the media server waits for digits in the input sequence. All timer settings are time values (Section 4.2.1). The list below describes these attributes and their use.
MSCMLは、メディアサーバーが入力シーケンスの桁を待機する時間を制御するいくつかのタイマー属性を定義します。すべてのタイマー設定は、時間の値（セクション4.2.1）です。以下のリストは、これらの属性とその使用について説明します。
Collection Timer Attributes:
コレクションタイマー属性：
o firstdigittimer - optional, default value "5000ms": Specifies how long the media server waits for the initial DTMF input before terminating the collection. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately whereas "infinite" indicates that the timer will never fire.
firstdigittimer O - オプション、デフォルト値「5000msは」：コレクションを終了する前に、最初のDTMF入力のためのメディアサーバがどれくらい長い間の待機を指定します。 「即時」以降は1msまたは文字列から時間値（セクション4.2.1）のように表す「無限。」値「即時」を「無限」は、タイマーが起動しないことを示しているのに対し、タイマーがすぐに発動すべきであることを示しています。
o interdigittimer - optional, default value "2000ms": Specifies how long the media server waits between DTMF inputs. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately, whereas "infinite" indicates that the timer will never fire.
O interdigittimer - オプション、デフォルト値は「2000ミリ秒」：DTMF入力間のどのくらいのメディアサーバーの待機を指定します。 「即時」以降は1msまたは文字列から時間値（セクション4.2.1）のように表す「無限。」 「無限」は、タイマーが起動しないことを示しているのに対し、値「即時」には、タイマーがすぐに発動すべきであることを示しています。
o extradigittimer - optional, default value "1000ms": Specifies how long the media server waits for additional user input after the specified number of digits has been collected. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately, whereas "infinite" indicates that the timer will never fire.
O extradigittimer - オプション、デフォルト値は「1000ミリ秒」：指定した桁数が収集された後に追加のユーザ入力のためのメディアサーバがどれくらい長い間の待機を指定します。 「即時」以降は1msまたは文字列から時間値（セクション4.2.1）のように表す「無限。」 「無限」は、タイマーが起動しないことを示しているのに対し、値「即時」には、タイマーがすぐに発動すべきであることを示しています。
o interdigitcriticaltimer - optional, defaults to the value of the interdigittimer attribute: Specifies how long the media server waits after a grammar has been matched for a subsequent digit that may cause a longer match. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" results in "shortest match first" behavior, whereas "infinite" means to wait indefinitely for additional input. If not explicitly specified otherwise, this attribute is set to the value of the 'interdigittimer' attribute.
O interdigitcriticaltimer - interdigittimer属性の値オプション、デフォルト：文法は長い試合を引き起こす可能性があり、その後の数字に一致した後にどのくらいのメディアサーバーが待機指定します。 「即時」以降は1msまたは文字列から時間値（セクション4.2.1）のように表す「無限。」値「無限」に対し、「第一の最短マッチ」行動の「即時」の結果は、追加の入力を無制限に待つことを意味します。明示的に指定されていない場合、この属性は「interdigittimer」属性の値に設定されています。
The extradigittimer setting enables the "returnkey" input to be associated with the current collection. For example, if maxdigits is set to 3 and returnkey is set to #, the user may enter either "x#", "xx#", or "xxx#", where x represents a DTMF digit.
extradigittimerの設定は、現在のコレクションに関連付けられる「returnkey」の入力を可能にします。 maxdigitsが3に設定され、returnkeyは＃に設定されている場合、xはDTMFディジットを表し、例えば、ユーザは、「X位」、「○○＃」、または「XXX位」のいずれかを入力することができます。
If the media server detects the "returnkey" pattern during the "extradigit" interval, the media server returns the collected digits to the client and removes the "returnkey" from the digit buffer.
メディアサーバーが「extradigit」期間中に「returnkey」パターンを検出した場合、メディアサーバーは、クライアントに収集した数字を返し、桁バッファから「returnkey」を削除します。
If this were not the case, the example would return "xxx" to the client and leave the terminating "#" in the digit buffer. At the next <playcollect> request, the media server would process the '#'. This might result in the termination of the following prompt, which is clearly not what the user intended.
これがそうでないならば、例では、桁バッファに「＃」をクライアントに「XXX」を返し、終了を残すでしょう。次の<playcollect>要求では、メディアサーバは、「＃」を処理します。これは、ユーザーが意図したもの明らかにされていない、次のプロンプトが終了する可能性があります。
The extradigittimer has no effect unless returnkey has been set.
returnkeyが設定されていない限り、extradigittimerは効果がありません。
Standard SIP mechanisms, such as those discussed in Security Considerations (Section 14), protect MSCML protocol exchanges and the information they contain. These protections do not apply to data captured in media server log files. In general, media server logging is platform specific and therefore is not covered by this specification. However, one aspect of logging, the capture of sensitive information (such as personal identification numbers or credit card numbers), is relevant. The media server has no means to determine whether the DTMF input it receives may be sensitive, as that is in the purview of the client. Recognizing this, MSCML includes a per-request mechanism to suppress logging of captured DTMF to be enabled by clients as needed.
このようなセキュリティ上の考慮事項（セクション14）で説明したもののような標準的なSIPメカニズムは、MSCMLプロトコル交換及びそれらが含む情報を保護します。これらの保護は、メディアサーバーのログファイルにキャプチャされたデータには適用されません。一般的には、メディアサーバーのログには、プラットフォーム固有のものですので、この仕様でカバーされていません。しかし、ログの一の態様では、（例えば、個人識別番号またはクレジットカード番号のような）機密情報の取得は、関連しています。メディアサーバは、クライアントの範囲内にあるように、それが受信DTMF入力は、感受性であり得るかどうかを決定する手段を持ちません。これを認識し、MSCMLは、必要に応じて、クライアントで有効にするために捕獲さDTMFの伐採を抑制するために、要求ごとの機構を備えています。
The "maskdigits" attribute controls whether detected DTMF digits appear in the log output. Clients use this attribute when the media server collects sensitive information that should not be accessible through the log files.
「maskdigits」属性が検出されたDTMFディジットは、ログ出力に表示されるかどうかを制御します。メディアサーバがログファイルを介してアクセスすべきではない機密情報を収集するとき、クライアントは、この属性を使用します。
Maskdigits Attribute:
Maskdigitsは属性：
o maskdigits - optional, default value "no": Controls whether user DTMF inputs are captured in media server log files. The possible values for this attribute are "yes" and "no".
O maskdigits - オプション、デフォルト値「いいえ」：ユーザーのDTMF入力は、メディアサーバのログファイルにキャプチャされているかどうかを制御します。この属性に指定可能な値は「はい」と「いいえ」です。
MSCML supports four methods for specifying DTMF grammars: the "maxdigits" attribute, which provides a simple mechanism for collecting any number of digits up to the maximum, regular expressions, MGCP [5] digit maps, and H.248.1 [6] digit maps. A media server MUST support the maxdigits and regular expression methods for specifying DTMF grammars and SHOULD support MGCP and H.248.1 methods. A client MUST NOT mix DTMF grammar types in a single <playcollect> request.
[6]ケタ地図を最大値までの桁の任意の数を収集するための単純な機構を提供します「maxdigits」属性、正規表現、MGCP [5]桁のマップ、およびH.248.1：MSCMLはDTMF文法を指定するための4つの方法をサポートしています。メディアサーバは、DTMF文法を指定するためのmaxdigitsと正規表現の方法をサポートしなければならないし、MGCPとH.248.1メソッドをサポートする必要があります。クライアントは、単一の<playcollect>リクエストでDTMF文法の種類を混ぜてはなりません。
Following is a description of the "maxdigits" attribute.
以下は、「maxdigits」属性の説明です。
Maxdigits Attribute:
Maxdigits属性：
o maxdigits - optional, no default value: Specifies the maximum number of DTMF digits to be collected.
O maxdigits - オプションで、デフォルトなし値：収集するDTMFの最大桁数を指定します。
The <pattern> element specifies a digit pattern or patterns for the media server to look for. This element may contain three different child elements that specify the type of DTMF grammar used in the expression. The <pattern> element has no attributes.
<パターン>要素は、探すためにメディアサーバーの桁または複数のパターンを指定します。この要素は、式で使用DTMF文法の種類を指定する3つの異なる子要素を含んでいてもよいです。 <パターン>要素には属性はありません。
<regex> Use regular expressions to define DTMF patterns to match. The complete regular expression syntax used in MSCML is described in Appendix A.
<正規表現>と一致するようにDTMFパターンを定義する正規表現を使用してください。 MSCMLで使用される完全な正規表現の構文は、付録Aに記載されています
<mgcpdigitmap> Use digit maps as specified in MGCP [5].
MGCP [5]で指定された<mgcpdigitmap>桁のマップを使用します。
<megacodigitmap> Use digit maps as specified in H.248.1 [6].
H.248.1 [6]に指定されている<megacodigitmap>桁のマップを使用します。
At least one <regex> element MUST be present in <pattern> when regex grammars are used. Multiple <regex> elements MAY be present. When <mgcpdigitmap> or <megacodigitmap> grammars are used, <pattern> MUST contain only one grammar element.
少なくとも一つの<正規表現>要素は、正規表現の文法が使用されている<パターン>に存在していなければなりません。複数の<正規表現>要素が存在してもよいです。 <mgcpdigitmap>または<megacodigitmap>文法が使用される場合、<パターン>は一つだけの文法要素を含まなければなりません。
The DTMF grammar elements <regex>, <mgcpdigitmap>, and <megacodigitmap> have the attributes described in the list below.
DTMF文法要素<正規表現>、<mgcpdigitmap>、および<megacodigitmap>以下のリストで説明する属性を持っています。
Attributes of DTMF Grammar Elements:
DTMF文法要素の属性：
o value - required, no default value: Specifies a string representing a DTMF grammar matching the parent element type (e.g., regex). Regex values represent a single DTMF grammar. MGCP and MEGACO digit maps allow multiple grammars to be described in a single string.
O値が - 必要なしデフォルト値：親要素のタイプ（例えば、正規表現）と一致DTMF文法を表す文字列を指定します。正規表現の値は、単一のDTMF文法を表します。 MGCPとMEGACO桁マップは複数の文法は、単一の文字列で記述することができます。
o name - optional, no default value: Associates a client defined name for the grammar that is sent back in the <playcollect> response. This attribute is most useful with regex type grammars as each grammar element can have a unique name.
名○ - オプション、デフォルト値は<playcollect>応答で返送された文法のためのクライアント定義名を関連付けません。各文法要素は固有の名前を持つことができますので、この属性は、正規表現型文法と最も有用です。
When the <playcollect> has finished, the media server sends a <response> payload to the client in a SIP INFO message.
<playcollect>が終了したとき、メディアサーバは、SIP INFOメッセージでクライアントに<応答>ペイロードを送信します。
Details of the <playcollect> response are described in Section 10.5.
<playcollect>応答の詳細は、セクション10.5で説明されています。
The following <playcollect> request (Figure 18) example depicts use of the "maxdigits" attribute to control digit collection.
次の<playcollect>要求（図18）の例では、ディジット収集を制御する「maxdigits」属性の使用を示します。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <playcollect id="332986004" maxdigits="6" firstdigittimer="10000" interdigittimer="5000" extradigittimer="1000" interdigitcriticaltimer="1000" returnkey="#" escapekey="*" cleardigits="no" barge="yes" maskdigits="no"> <prompt baseurl="http://www.example.com/prompts/"> <audio url="generic/en_US/enter_pin.wav"/> </prompt> </playcollect> </request> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <playcollect ID = "332986004" maxdigits = "6" firstdigittimer = "10000" interdigittimer = "5000" extradigittimer = "1000" interdigitcriticaltimer = "1000" returnkey = "＃" escapekey = "*" cleardigits = "いいえ" はしけ= "yes" をmaskdigits = "いいえ"> <プロンプトBASEURL = "http://www.example.com/prompts/"> <オーディオURL = "ジェネリック/ en_USの/ enter_pin.wav" /> </プロンプト> </ playcollect> </リクエスト> </ MediaServerControl>
Figure 18: <Playcollect> Request Example Using the Maxdigits Attribute
図18：Maxdigits属性を使用した<Playcollect>リクエストの例
The <playrecord> request directs the media server to convert and possibly to transcode the RTP payloads it receives and store them to the specified URL using the requested content codec(s) and file format. This request proceeds in two phases; prompt and record.
<playrecord>要求が変換すると、おそらくそれが受信RTPペイロードをトランスコードし、要求されたコンテンツのコーデック（複数可）およびファイル形式を使用して指定されたURLにそれらを格納するメディアサーバーを指示します。この要求は、2つのフェーズに進めます。プロンプトとレコード。
The <playrecord> request shares the basic attributes of <play> and <playcollect> as described in Section 6.3. MSCML also defines other attributes that control the behavior of the prompt and recording phases. These phases and the attributes that control them are described in the text and tables below.
<playrecord>リクエスト株式6.3節で説明したように、<遊び>と<playcollect>の基本的な属性。 MSCMLも迅速かつ記録相の動作を制御する他の属性を定義します。これらのフェーズと、それらを制御する属性は、テキストと以下の表で説明されています。
The presence or absence of a "prompturl" attribute or child <prompt> element controls whether a prompt is played before recording begins. As previously noted, use of the "prompturl" attribute is deprecated, and clients SHOULD use <prompt> instead.
記録を開始する前にプロンプトが再生されているかどうかを「prompturl」属性または子の<迅速な>要素のコントロールの存在または不在。先に述べたように、「prompturl」の使用属性は廃止され、クライアントは<プロンプト>の代わりに使用すべきです。
When the client requests that the media server prompt the caller before recording audio, <playrecord> has two stages. The first is equivalent to a <playcollect> operation. The client may set the prompt phase to be interruptible by DTMF input (barge) and may specify an escape key that will terminate the <playrecord> request before the recording phase begins.
クライアントは、メディアサーバがオーディオを録音する前に、発信者を促していることを要求すると、<playrecord> 2つの段階があります。最初は、<playcollect>動作と同等です。クライアントは、DTMF入力（はしけ）で中断するプロンプト位相を設定することができ、記録フェーズが始まる前に<playrecord>要求を終了しますエスケープキーを指定することもできます。
The list below describes the attributes of <playrecord> that specify the behavior of the prompt phase of the request.
以下のリストは、要求の迅速なフェーズの動作を指定する<playrecord>の属性について説明します。
Playrecord Attributes for the Prompt Phase:
Playrecordは、迅速なフェーズの属性：
o barge - optional, default value "yes": Specifies whether user input will barge the prompt and force transition to the record phase. When it is set to "yes", a DTMF input will barge the prompt. When it is set to "no", the prompt phase cannot be barged, and any user input during the prompt is placed in the quarantine buffer for inspection during the collect phase. Note that if the "barge" attribute is set to "no", the "cleardigits" attribute implicitly has a value of "yes". This ensures that the media server does not leave DTMF input that occurred prior to the current collection in the quarantine buffer after the request completes.
Oはしけ - オプション、デフォルト値は「はい」：ユーザーの入力がレコード相への迅速かつ力の移行を割り込むかどうかを指定します。それが「はい」に設定されている場合は、DTMF入力はプロンプトを割り込むだろう。それは「NO」に設定されている場合、プロンプト相が割り込まできず、プロンプト中の任意のユーザ入力が収集フェーズ中に検査用隔離バッファに置かれます。 「はしけ」属性が「なし」に設定されている場合は、「cleardigits」属性が暗黙のうちに「はい」の値を持っていることに注意してください。これは、メディアサーバはリクエストが完了した後、隔離バッファにおける現在のコレクションに先立って発生したDTMF入力を残さないことを保証します。
o cleardigits - optional, default value "no": Specifies whether previous user input should be considered or ignored for barge-in purposes. When it is set to "yes", any previously buffered digits are removed, so prior user input is ignored. If it is set to "no", previously buffered digits will be considered. If "cleardigits" is set to "no" and barge-in is enabled, previously buffered digits will terminate the prompt phase immediately. In this case, the prompt is not played, and recording begins immediately.
O cleardigits - オプション、デフォルト値「いいえ」：以前のユーザー入力が考慮さやはしけインの目的のために無視するかどうかを指定します。それが「はい」に設定されている場合は、任意の以前にバッファリングされたケタが削除され、その前にユーザーの入力は無視されます。それは「なし」に設定されている場合は、以前にバッファリングされたケタが考慮されます。 「cleardigits」は「いいえ」に設定され、バージ・インが有効になっている場合は、以前にバッファリングされたケタはすぐに迅速なフェーズを終了します。この場合、プロンプトが演奏し、録音がすぐに開始されていません。
o escapekey - optional, default value "*": Specifies a DTMF key that indicates the user wishes to terminate the current operation without saving any input recorded to that point. Detection of the mapped DTMF key terminates the request immediately and generates a response.
O escapekey - オプション、デフォルト値の「*」：ユーザーがその時点で記録された入力を保存せずに現在の操作を終了したい示しDTMFキーを指定します。マッピングされたDTMFキーの検出は、直ちに要求を終了し、応答を生成します。
Detection of the escape key generates a response message, and the operation returns immediately. If the user presses any other keys and if the prompt is interruptible (barge="yes"), then the play stops immediately, and the recording phase begins.
エスケープキーの検出は、応答メッセージを生成し、動作が即座に返します。ユーザーが任意の他のキーを押した場合と、プロンプトが（はしけ=「yes」を）中断された場合、その後のプレイはすぐに停止し、記録フェーズが開始されます。
If the request proceeds to the recording phase, the media server discards any digits from the collect phase from the quarantine buffer to eliminate unintended termination of the recording. The following attributes control recording behavior.
要求は、記録相に移行した場合、メディアサーバは、隔離バッファから収集相から任意の数字が記録の意図しない終了を排除するために破棄する。以下の属性は、行動の記録を制御します。
Playrecord Attributes for the Record Phase: o recurl - required, no default value: Specifies the target URL for the recorded content.
Playrecordは、録音フェーズの属性：再カール○ - 必要な、デフォルト値なし：記録されたコンテンツのターゲットURLを指定します。
o recencoding - optional, default value "ulaw": Specifies the encoding of the recorded content if it cannot be inferred from the recurl. Possible values are "ulaw", "alaw", and "msgsm."
O recencoding - オプション、デフォルト値「ULAWは」：それは再カールから推測できない場合、録画されたコンテンツのエンコーディングを指定します。可能な値は "ULAW"、 "ALAW"、とある "msgsm。"
o mode - optional, default value "overwrite": Specifies whether the recording should overwrite or be appended to the target URL. Allowable values are "overwrite" and "append."
Oモード - オプション、デフォルト値「上書き」：記録を上書きするか、ターゲットURLに付加することかどうかを指定します。許容値は、「上書き」と「付加します。」
o duration - optional, default value "infinite": Specifies the maximum allowable duration for the recording. Expressed as a time value (Section 4.2.1) from 1 onwards or the strings "immediate" and "infinite." The value "immediate" indicates that recording will end immediately, whereas "infinite" indicates recording should continue indefinitely. If the maximum duration is reached, the <playrecord> request will terminate and generate a response.
Oデュレーション - オプション、デフォルト値「無限に」：記録のための最大許容時間を指定します。以降1または文字列「即時」から時間値（セクション4.2.1）のように表す「無限。」 「無限」記録を無期限に継続する必要があることを示し、一方、「即時」の値は、記録が即座に終了することを示しています。最大持続時間に達した場合、<playrecord>要求が終了して応答を生成します。
o beep - optional, default value "yes": Specifies whether a beep should be played to the caller immediately prior to the start of the recording phase. Allowable values are "yes" and "no."
Oビープ音 - オプション、デフォルト値は「はい」：ビープ音が直前に記録フェーズの開始に発信者に対して再生されるかどうかを指定します。許容値は「ノー」である。「はい」と
o initsilence - optional, default value "3000ms": Specifies how long to wait for initial speech input before terminating (canceling) the recording. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately, whereas "infinite" directs the media server to wait indefinitely.
O initsilence - オプション、デフォルト値「3000ms」：記録を（キャンセル）終了する前に、最初の音声入力を待機する時間を指定します。 「即時」以降は1msまたは文字列から時間値（セクション4.2.1）のように表す「無限。」 「即時」の値は「無限」無期限に待機するメディアサーバーを指示し、一方、タイマーは、すぐに発火すべきであることを示しています。
o endsilence - optional, default value "4000ms": Specifies how long the media server waits after speech has ended to stop the recording. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." When set to "infinite", the recording will continue indefinitely after speech has ended and will only terminate due to a DTMF keypress or because the input has reached the maximum desired duration.
O endsilence - オプション、デフォルト値は「4000ms」：音声は録音を停止し終了した後にどのくらいのメディアサーバーが待機指定します。 「即時」以降は1msまたは文字列から時間値（セクション4.2.1）のように表す「無限。」 「無限」に設定すると、録音音声が終了した後に無期限に続けるのみによるDTMFキー押下や、入力が所望の最大持続時間に達したために終了します。
o recstopmask - optional, default value "0123456789ABCD#*": Specifies a list of individual DTMF characters that, if detected, will cause the recording to be terminated. To ensure that the input of a specific key does not cause the recording to stop, remove the DTMF key from the list.
O recstopmask - オプション、デフォルト値「0123456789ABCD＃*」：、検出された場合、記録が終了することになります個々のDTMF文字のリストを指定します。特定のキーの入力が録音を停止させることがないように、リストからDTMFキーを削除します。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバーは、ローカルおよびリモート（NFS）「ファイル：//」をサポートしなければならないスキームのURLを「再カール」属性で。 <managecontent>（8節）要求を介して間接的スキームのURL：と "// https" の：MSCMLは "// HTTP" をサポートしています。
The media server buffers and returns any digits collected in the prompt phase, with the exception of those contained in the "recstopmask" attribute, in the response.
メディアサーバのバッファと応答で「recstopmask」属性に含まれているものを除いて、迅速なフェーズで収集した任意の数字を返します。
The media server compares digits detected during the recording phase to the digits specified in the "recstopmask" to determine whether they indicate a recording termination request.
メディアサーバは、それらが、記録終了要求を示すかどうかを決定するために、「recstopmask」で指定された桁数に記録フェーズ中に検出された数字を比較します。
The media server ignores digits not present in the recstopmask and passes them into the recording. If DTMF input terminates the recording, the media server returns the collected digit to the client in the <response>.
メディアサーバは、recstopmaskに存在しない数字を無視し、記録にそれらを渡します。 DTMF入力が録音を終了した場合、メディアサーバは<応答>でクライアントに収集した数字を返します。
Once recording has begun, the media server writes the received media to the specified recurl URL no matter what DTMF events the media server detects. It is the responsibility of the client to examine the DTMF input returned in the <response> message to determine whether the audio file should be saved or deleted and, potentially, re-recorded.
記録が開始されると、メディアサーバーに関係なく、メディアサーバーが検出したものをDTMFイベント指定の再カールのURLに受信したメディアを書き込みません。オーディオファイルが再記録し、潜在的に、保存または削除とすべきかどうかを判断するために、<応答>メッセージで返さDTMF入力を調べるために、クライアントの責任です。
If the endsilence timer expires, the media server trims the end of the recorded audio by an amount equal to the value of the "endsilence" attribute.
endsilenceタイマーが満了した場合は、メディアサーバは、「endsilence」属性の値に等しい量によって記録された音声の最後をトリミング。
When the recording is finished, the media server generates a <response> message and sends it to the client in a SIP INFO message. Details of the <playrecord> response are described in Section 10.6.
記録が終了すると、メディアサーバは<応答>メッセージを生成し、SIP INFOメッセージでクライアントに送信します。 <playrecord>応答の詳細は、10.6節で説明されています。
The recording example (Figure 19) plays a prompt and records it to the destination specified in the "recurl" attribute encoded as MS-GSM in wave format.
記録例（図19）はプロンプトを再生し、WAVE形式でMS-GSMとしてエンコード「再カール」属性で指定された宛先にそれを記録します。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <playrecord id="5556123" recurl="file:////nfs.example.com/rec/name.wav" recencoding="msgsm" initsilence="5000" endsilence="3000" duration="30000" barge="yes" beep="yes" mode="overwrite" cleardigits="no" escapekey="*" recstopmask="0123456789#*"> <prompt> <audio url="http://www.example.com/prompts/recordname.wav"/> </prompt> </playrecord> </request> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <playrecord ID = "5556123" 再カール= "ファイル：////nfs.example.com/rec/name.wav" recencoding = "msgsm" initsilence = "5000" endsilence = "3000" 期間= "30000" はしけ= "yes" とビープ= "yes" のモード= cleardigitsを "上書き" = "no" をescapekey = "*" recstopmask = "0123456789＃* "> <プロンプト> <オーディオURL =" http://www.example.com/prompts/recordname.wav "/> </プロンプト> </ playrecord> </リクエスト> </ MediaServerControl>
Figure 19: Recording Example
図19：記録例
The client issues a <stop> request when the objective is to stop a request in progress and not to initiate another operation. This request generates a <response> message from the media server.
クライアントは、目的が進行中の要求を停止し、別の操作を開始することではありません。<停止>要求を発行します。この要求は、メディアサーバから<応答>メッセージを生成します。
The only attribute is id, which is optional.
唯一の属性はオプションでID、です。
The client-defined request id correlates the asynchronous response with its original request and echoes back to the client in the media server's response.
クライアント定義要求IDは、元の要求と非同期の応答を相関させ、メディアサーバの応答でクライアントにエコーバック。
The following MSCML payload (Figure 20) depicts an example <stop> request.
以下MSCMLペイロード（図20）は、例えば、<停止>要求を示しています。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <stop id="4578903"/> </request> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <停止ID = "4578903" /> </リクエスト> </ MediaServerControl>
Figure 20: Stop Example
図20：ストップ例
The format of a response to a <stop> request is detailed in Section 10.2.
<停止>要求に対する応答のフォーマットは、セクション10.2に詳述されています。
As discussed previously, the media server treats a SIP re-INVITE that modifies the established SDP parameters as an implicit <stop> request. Examples of such SDP modifications include receiving hold SDP or removing an audio or video stream. When this occurs, the media server immediately terminates the running <play>, <playcollect>, or <playrecord> request and sends a <response> indicating "reason=stopped".
前述したように、メディアサーバは、再INVITEそれは暗黙の<停止>要求として確立されたSDPパラメータを変更するSIPを扱います。そのようなSDP修飾の例は、ホールドSDPを受信し、またはオーディオまたはビデオストリームを除去することを含みます。これが発生すると、「停止=理由」を、メディアサーバは、すぐに実行されている<遊び>、<playcollect>、または<playrecord>要求を終了して示す<応答>を送信します。
MSCML defines event notifications that are scoped to a specific SIP dialog or call leg. These events allow a client to be notified of individual, asynchronous DTMF keypresses, as well as of various call progress signals. The subscription, event detection, and notifications for call leg events occur in the same SIP dialog. This is different from the conference level active talker events described earlier. The subscription and notifications for active talker events occur on the conference control leg, but the actual event detection occurs on one or more participant legs.
MSCMLは、特定のSIPダイアログまたはコールレッグにスコープされているイベント通知を定義します。これらのイベントは、クライアントがさまざまなコールプログレス信号のと同様に、個々の、非同期のDTMFキー押下を通知することを可能にします。サブスクリプション、イベント検出、およびコールレッグイベントの通知は、同じSIPダイアログで起こります。これは、前述の会議レベルアクティブな話し手イベントとは異なります。アクティブな話し手イベントのサブスクリプションと通知は、会議コントロール脚に発生しますが、実際のイベントの検出は、一つ以上の参加者の足で発生します。
Subscriptions for call leg events are made by sending an MSCML <configure_leg> request on the desired SIP dialog. Call leg events may be used with the MSCML conferencing or IVR services. When used with the IVR service, the <configure_leg> request SHOULD NOT include any conference-related attributes. The media server MUST ignore these if present. Call leg event subscriptions MUST NOT be made on the conference control leg, since it has no actual RTP media to process for event detection. The media server MUST reject a <configure_leg> request sent on the conference control leg.
コールレッグイベントのサブスクリプションは、所望のSIPダイアログにMSCML <configure_leg>要求を送信することで作られています。コールレッグのイベントがMSCML会議やIVRサービスで使用することができます。 IVRサービスで使用する場合、<configure_leg>要求が任意の会議に関連する属性を含めるべきではありません。存在する場合、メディアサーバーはこれらを無視しなければなりません。それはイベント検出のために処理するために、実際のRTPメディアを持っていないのでコールレッグイベントサブスクリプションは、会議コントロール脚の上に作られてはなりません。メディアサーバは、会議コントロール脚の上に送られた<configure_leg>要求を拒絶しなければなりません。
The <configure_leg> request contains the child elements <subscribe> and <events>. The <events> element may contain two child elements that control subscriptions to call leg events. These are <keypress> and <signal>. A <configure_leg> request MUST contain at most one <keypress> element but MAY contain multiple <signal> elements that request notification of different call progress events.
<configure_leg>リクエストは子要素<購読>と<イベント>が含まれています。 <イベント>要素は、脚のイベントを呼び出すためにサブスクリプションを制御する2人の子要素が含まれていてもよいです。これらは、<キー入力>及び<信号>です。 <configure_leg>要求は多くても1つの<キー操作>要素に含まれなければならないが、異なるコールプログレスイベントの通知を要求する複数の<信号>要素を含んでいてもよいです。
Keypress events are used when the client wishes to receive notifications of individual DTMF events that are not tied to a specific <playcollect> request. One use of this facility is to monitor conference legs for DTMF inputs that require application intervention; for example, to notify the moderator that the caller wishes to speak. Keypress events are also used when the application desires complete control of grammars and timing constraints.
キー押下イベントは、クライアントが特定の<playcollect>要求に縛られていない個々のDTMFイベントの通知を受信したいときに使用されています。この施設の用途の1つは、アプリケーションの介入を必要とDTMF入力のための会議脚を監視することです。たとえば、呼び出し元が話したいモデレータに通知します。キープレスイベントは、アプリケーションが文法やタイミング制約の完全な制御を希望する場合に使用されています。
When used in a subscription context, the <keypress> element has two attributes, 'report' and 'maskdigits', which are detailed in the list below.
サブスクリプションの文脈で使用される場合、<キー操作>要素は、以下のリストで詳述されている2つの属性、「レポート」と「maskdigits」を持っています。
Keypress Subscription Attributes:
キー押下購読属性：
o report - required, no default value: Possible values are 'standard', 'long', 'both', and 'none'. 'Standard' means that detected digits should be reported. 'Long' means that long digits should be reported. 'Long' digits are defined as a single key press held down for more than one second, or two distinct key presses (a "double") of the same digit that occur within two seconds of each other with no other intervening digits. 'Both' means that both 'standard' and 'long' digit events should be reported. As a 'long' digit consists of one or more "normal" digits, a single long duration key press will generate one standard event and one 'long' event. A "double" will produce two standard events and one 'long' event. 'None' means that no keypress events should be reported; it disables keypress event reporting if enabled.
O報告 - 必要なしデフォルト値：可能な値は、「標準」、「長い」、「両方」、および「なし」を。 「標準」は検出された数字が報告されるべきであることを意味しています。 「ロング」は、長い数字が報告されるべきであることを意味しています。 「ロング」の数字はない他の介在の数字でお互いの2秒以内に起こる同じ桁の1秒以上押し続ける単一のキーを押し、または二つの異なるキーを押す（「ダブル」）として定義されます。 「どちらも、」両方の「標準」と「長い」桁の事象が報告されるべきであることを意味しています。 「長い」の数字が1つまたは複数の「ノーマル」の数字で構成されていたように、単一の長い期間のキーを押して、一つの標準イベントと1「長い」イベントを生成します。 「ダブル」は、2つの標準的なイベントと1「長い」イベントを生成します。 「なし」にはキー押下イベントが報告されてはならないことを意味しません。それが有効な場合の報告keypressイベントを無効にします。
o maskdigits - optional, default value "no": Controls whether user DTMF inputs are captured in media server log files. The possible values for this attribute are "yes" and "no".
O maskdigits - オプション、デフォルト値「いいえ」：ユーザーのDTMF入力は、メディアサーバのログファイルにキャプチャされているかどうかを制御します。この属性に指定可能な値は「はい」と「いいえ」です。
The media server sends an MSCML response to the subscription immediately upon receiving the request. Notifications are sent to the client when the specified events are detected.
メディアサーバは、直ちに要求を受信すると、サブスクリプションへのMSCML応答を送信します。指定されたイベントが検出されたときに通知がクライアントに送信されます。
When used in a notification context, the <keypress> element has several attributes that are used to convey details of the event that was detected. It also contains a child element, <status>, that provides information on any MSCML request that was in progress when the event occurred. The details of these notification attributes are described in the list below.
通知文脈で使用される場合、<キー押下>要素は、検出されたイベントの詳細を伝えるために使用されるいくつかの属性を有します。また、イベントが発生したときに進行していた任意のMSCML要求に関する情報を提供し、子要素、<状態>を、含まれています。これらの通知の属性の詳細は、以下のリストに記載されています。
Keypress Notification Attributes:
キー押下通知属性：
o digit - required, no default value: Specifies the DTMF digit detected. Possible values are [0-9], [A-D], '#', or '*'.
O桁 - 必要なしデフォルト値：検出されたDTMFディジットを指定します。可能な値は、[0-9]、[A-D]、 '＃'、または '*'。
o length - required, no default value: Specifies the duration class of the DTMF input. Possible values are 'standard' or 'long'.
Oの長さ - 必要なしデフォルト値：DTMF入力の持続クラスを指定します。可能な値は「標準」または「長い」です。
o method - required, no default value: Specifies the keypress detection method that generated the notification. Possible values are 'standard', 'long', and 'double'.
Oの方法 - 必要なしデフォルト値：通知を生成したキー押下検出方法を指定します。可能な値は、「標準」「長い」、および「ダブル」です。
o interdigittime - required, no default value: Specifies the elapsed time, as a time value (Section 4.2.1), between the current event detection and the previous one.
O interdigittime - 必要に応じて、デフォルト値は、現在のイベントの検出及び前の間、時間の値（セクション4.2.1）のように、経過時間を指定していません。
The following examples of MSCML payloads depict a subscription for standard keypress events and disabling keypress reporting.
MSCMLペイロードの次の例は、標準のキー押下イベントと無効化キープレス・レポートのサブスクリプションを示しています。
Figure 21 shows a subscription for standard keypress events.
図21は、標準のキー押下イベントのサブスクリプションを示しています。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg> <subscribe> <events> <keypress report="standard"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <configure_leg> <サブスクライブ> <イベント> <キープレスレポート= "標準" /> </イベント> </サブスクライブ> </ configure_leg > </リクエスト> </ MediaServerControl>
Figure 21: Standard Digit Events Subscription
図21：標準桁イベントサブスクリプション
Figure 22 shows a client disabling keypress event notifications.
図22は、キープレスイベント通知を無効にするクライアントを示しています。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg> <subscribe> <events> <keypress report="none"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <configure_leg> <サブスクライブ> <イベント> <キープレスレポート= "なし" /> </イベント> </サブスクライブ> </ configure_leg > </リクエスト> </ MediaServerControl>
Figure 22: Disabling Keypress Event Reporting
図22：キー押下イベントレポートを無効にします
The following MSCML payloads depict keypress event notifications caused by various types of DTMF input.
以下のMSCMLペイロードはDTMF入力の様々な種類に起因するキープレスイベント通知を示しています。
Figure 23 shows a notification generated by the detection of a standard "4" DTMF digit. In this example, this is the first digit detected. Thus, the 'interdigittime' attribute has a value of '0'.
図23は、標準の「4」のDTMFディジットの検出によって生成された通知を示しています。この例では、検出された最初の桁です。このように、「interdigittime」属性が「0」の値を持ちます。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <notification> <keypress digit="4" length="standard" method="standard" interdigittime="0"> <status command="play" duration="10"/> </keypress> </notification> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <通知> <キープレス桁= "4" 長さ= "標準" メソッド= "標準" interdigittime = "0"> <statusコマンド= "プレイ"持続時間=" 10" /> </キー押下> </通知> </ MediaServerControl>
Figure 23: Standard Keypress Notification
図23：標準的なキー押下通知
Figure 24 shows a notification generated by detection of a long pound (#).
図24は、長いシャープ（＃）の検出によって生成された通知を示しています。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <notification> <keypress digit="#" length="long" method="long" interdigittime="200"> <status command="idle" duration="4"/> </keypress> </notification> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <通知> <キープレス桁= "＃" 長さ= "長い" メソッド= "長い" interdigittime = "200"> <statusコマンド= "アイドル"持続時間=" 4" /> </キー押下> </通知> </ MediaServerControl>
Figure 24: Long Keypress Notification
図24：ロングキー押下通知
MSCML supports notification of certain call progress tones through the <signal> element. When used in a subscription context, the <signal> element has two attributes, 'type' and 'report', and no child elements. These attributes are detailed in the list below.
MSCMLは<信号>要素を通じて、特定の呼出音の通知をサポートしています。サブスクリプションの文脈で使用される場合、<信号>要素には次の2つの属性、「タイプ」と「レポート」、およびなし子要素を持っています。これらの属性は、以下のリストに詳述されています。
Signal Subscription Attributes:
信号購読属性：
o report - required, no default value: Controls whether the specified signal is reported. Possible values are 'yes' and 'no'. When set to 'yes', the media server invokes the required signal detection code and reports detected events. When it is set to 'no', the media server disables the associated signal detection code and does not report events.
Oレポート - 必要なしデフォルト値：指定された信号が報告されているかどうかを制御します。可能な値は「はい」と「いいえ」です。 「はい」に設定すると、メディアサーバは、必要な信号検出用コードを呼び出し、レポートには、イベントを検出しました。それは「NO」に設定されている場合は、メディアサーバは、関連する信号検出コードを無効にし、イベントを報告しません。
o type - required, no default value: Specifies the type of call progress signal to detect. Possible values are 'busy', 'ring', 'CED', 'CNG', and '400', which correspond to busy tone, ring tone, fax CED, fax CNG, and 400 Hz tone, respectively.
Oタイプ - 必要なしデフォルト値：検出するために、コールプログレス信号の種類を指定します。可能な値は、それぞれ、CNGをファックス、CEDファックス、「ビジー」、「リング」、「CED」、「CNG」、及び「400」、ビジートーンに対応し、リングトーンであり、400 Hzのトーン。
NOTE: The details of media server provisioning required to support country-specific variants of 'busy' and 'ring' is not covered by this specification.
注：「忙しい」と「リング」の国固有のバリアントをサポートするために必要なメディアサーバーのプロビジョニングの詳細は、この仕様でカバーされていません。
As stated previously, a single <configure_leg> request MAY contain multiple <signal> elements that request notification of different call progress tones. A single <configure_leg> request SHOULD NOT contain multiple <signal> elements that have the same 'type' attribute value. If the media server receives such a request, it SHOULD honor the last element specifying that type that appears in the request.
先に述べたように、単一の<configure_leg>要求は、異なる呼出音の通知を要求する複数の<信号>要素を含んでいてもよいです。単一の<configure_leg>要求が同じ「タイプ」属性の値を持つ複数の<信号>要素を含めることはできません。メディアサーバがそのような要求を受信した場合、その要求に表示されるタイプを指定する最後の要素を尊重すべきです。
The media server generates an immediate response to the <configure_leg> subscription request and sends notifications when the specified signals are detected. A single notification is sent as soon as the specified signal has been reliably detected. If the signal persists continuously, additional notifications will not be sent. If the signal is interrupted and then resumes, additional notifications will be sent.
メディアサーバは<configure_leg>サブスクリプション要求に即座に応答を生成し、指定された信号が検出されたときに通知を送信します。単一の通知は、すぐに指定された信号を確実に検出されたとして送信されます。信号が継続的に解消されない場合は、追加の通知が送信されません。信号が中断し、その後再開された場合は、追加の通知が送信されます。
Signal notifications have a single attribute, "type", as described in the list below.
以下のリストで説明したように信号通知は、単一の属性、「タイプ」を持っています。
Signal Notification Attribute:
シグナル通知属性：
o type - required, no default value: Specifies the type of call progress signal that was detected. Possible values are 'busy', 'ring', 'CED', 'CNG', and '400', which correspond to busy tone, ring tone, fax CED, fax CNG, and 400 Hz tone, respectively.
Oタイプ - 必要なしデフォルト値：検出されたコールプログレス信号の種類を指定します。可能な値は、それぞれ、CNGをファックス、CEDファックス、「ビジー」、「リング」、「CED」、「CNG」、及び「400」、ビジートーンに対応し、リングトーンであり、400 Hzのトーン。
The following MSCML payloads show a signal event subscription (Figure 25) and notification (Figure 26).
以下MSCMLペイロードは信号イベントサブスクリプション（図25）と通知（図26）を示します。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg> <subscribe> <events> <signal type="busy" report="yes"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <configure_leg> <サブスクライブ> <イベント> <信号タイプ= "忙しい" レポート= "はい" /> </イベント> </サブスクライブ> </ configure_leg> </リクエスト> </ MediaServerControl>
Figure 25: Signal Event Subscription
図25：信号イベント・サブスクリプション
<?xml version="1.0"?> <MediaServerControl version="1.0"> <notification> <signal type="busy"/> </notification> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <通知> <信号タイプ= "忙しい" /> </通知> </ MediaServerControl>
Figure 26: Signal Event Notification
図26：信号イベント通知
MSCML uses the <managecontent> request to move recorded content from the media server to remote locations using the HTTP protocol. This is a store-and-forward model, which requires the completion of local temporary recording before the media server can send it to the web server. This facility is useful in applications such as voice messaging, where a message may be reviewed by the caller prior to being committed to persistent storage.
MSCMLは、HTTPプロトコルを使用して、遠隔地へのメディアサーバから記録されたコンテンツを移動する<managecontent>要求を使用します。これは、メディアサーバーがWebサーバーに送信する前に、ローカルの一時記録を完了する必要がストアアンドフォワードモデル、です。この機能は、このようなメッセージが前永続ストレージにコミットされることに、発信者によって審査される音声メッセージ、などのアプリケーションに有用です。
The <managecontent> request contains no child elements and has the attributes described in the list below.
<managecontent>要求には、子要素を含まず、以下のリストで説明する属性を持っています。
Managecontent Attributes:
Managecontent属性：
o src - required, no default value: Specifies the local source URL of the content. The URL scheme MUST be "file://".
OのSRC - 必要なしデフォルト値：コンテンツのローカルソースURLを指定します。 URLスキームは「：//ファイル」でなければなりません。
o dest - required (see note), no default value: Specifies the destination URL. The URL scheme MUST be "http://". Note: If the selected action is 'delete', this attribute is optional; otherwise it is required.
OのDEST - 必要は（注を参照）、デフォルト値は：先のURLを指定していません。 URLスキームは "http：//" にでなければなりません。注意：選択したアクションが「削除」である場合、この属性はオプションです。それ以外の場合は必要です。
o action - optional, default value "move": Specifies the operation for the media server to execute. Values can be either 'move' or 'delete'. The 'delete' action operates on the local source file. After a successful move or delete, the media server deletes the source file from its local storage. If the request is unsuccessful, the source file is not deleted, which gives the client complete control of the retry strategy.
Oアクション - オプション、デフォルト値「の動きは、」：実行するメディアサーバーの操作を指定します。値は、「移動」または「削除」のいずれかとすることができます。 「削除」アクションは、ローカルのソースファイル上で動作します。成功した移動または削除した後、メディアサーバは、そのローカルストレージからソースファイルを削除します。要求が失敗した場合、ソースファイルが再試行戦略のクライアントの完全な制御を与える、削除されません。
o httpmethod - optional, default value "post": HTTP protocol method for the media server to use in the HTTP request. The only values are 'post' or 'put'.
O HTTPMETHOD - オプション、デフォルト値「ポスト」：メディアサーバーのHTTPプロトコルメソッドは、HTTPリクエストで使用します。唯一の値は、「ポスト」または「置く」です。
o name - required (see note), no default value: Specifies the field name for the content in the form when using the 'post' method. This is not to be confused with the "src" or "dest" attributes. Note: This attribute is required when the "htttpmethod" has the value "post" and is optional otherwise.
名○ - 必要（注を参照）、デフォルト値は「ポスト」メソッドを使用するときに、フォームのコンテンツのためのフィールド名を指定します。これは、「SRC」または「DEST」属性と混同してはなりません。注：「htttpmethod」値「ポスト」を持っているし、そうでない場合は、オプションである場合は、この属性が必要です。
o fetchtimeout - optional, default value "10000ms": Specifies the maximum time allowed for the transfer to complete. Expressed as a time value (Section 4.2.1) from 1ms onwards.
O fetchtimeout - オプション、デフォルト値「10000msは」：完了するために転送するために許可される最大時間を指定します。 1msの以降から時間値（セクション4.2.1）のように表します。
o mimetype - required (see note), no default value: Specifies the MIME type that the media server will use for the content transfer. If it is not provided, the media server MUST try to infer it from the content file extension based on a platform specific mapping table. A non-normative, example mapping table is shown in Table 3. To avoid ambiguity, we RECOMMEND that clients explicitly set this attribute. Note: If the MIME type of the content cannot be inferred from the file extension, this attribute is required.
MIMEタイプO - 必要（注を参照）、デフォルト値は：メディアサーバーがコンテンツの転送に使用することがMIMEタイプを指定します。それが提供されていない場合は、メディアサーバは、プラットフォーム固有のマッピングテーブルに基づいて、コンテンツファイルの拡張子からそれを推測しようとする必要があります。非規範的、例マッピングテーブルあいまいさを避けるために、表3に示されている、私たちは、クライアントが明示的にこの属性を設定することをお勧めします。注意：コンテンツのMIMEタイプはファイルの拡張子から推測することができない場合は、この属性は必須です。
Table 3 shows common audio and video MIME types and possible file extension mappings.
表3は、一般的なオーディオおよびビデオのMIMEタイプと可能なファイル拡張子のマッピングを示しています。
+-----------+--------------------+
| Extension | MIME Type |
+-----------+--------------------+
| alaw | audio/x-alaw-basic |
| ulaw | audio/basic |
| msgsm | audio/ms-gsm |
| wav | audio/x-wav |
| tif | image/tiff |
| tiff | image/tiff |
| mov | video/quicktime |
| qt | video/quicktime |
| 3gp | video/3gpp |
| 3gpp | video/3gpp |
+-----------+--------------------+
Table 3: Example File Extension to MIME Type Mappings
表3：MIMEタイプのマッピングに例のファイルの拡張子
<Managecontent> is purely a transport operation; the underlying content is not changed by it. Therefore clients MUST ensure that the source and destination file name extensions and MIME types are the same. Failure to do so could result in content that is unreadable.
<Managecontent>は純粋搬送動作です。基礎となるコンテンツは、それによって変更されません。したがって、クライアントは、送信元と送信先のファイル名の拡張子とMIMEタイプが同じであることを保証しなければなりません。これを怠ると、読めないコンテンツにつながる可能性があります。
The ability to move or delete any local file presents a potential risk to the security of the media server system. For this reason, we STRONGLY RECOMMEND that implementers limit local file system access when using <managecontent>. For example, we encourage limiting access as based on file ownership and/or specific directories.
任意のローカルファイルを移動または削除する機能は、メディアサーバシステムのセキュリティに対する潜在的なリスクを提示します。このような理由から、私たちは強く、<managecontent>を使用した場合、実装は、ローカルファイルシステムへのアクセスを制限することをお勧めします。例えば、我々は、ファイルの所有権および/または特定のディレクトリに基づいてアクセスを制限奨励します。
The following is an example (Figure 27) showing a local file on the media server being transferred to an HTTP URL using the "put" method. The client sends the following request.
以下は、「置く」方法を使用してHTTP URLに転送されているメディアサーバー上のローカルファイルを示す例（図27）です。クライアントは、次の要求を送信します。
<?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <managecontent id="102" src="file:////var/mediaserver/rec/6A5GH49B.ulaw" dest="http://www.example.com/recordings/myrecording.ulaw" mimetype="audio/basic" action="move" httpmethod="put" fetchtimeout="5000"/> </request> </MediaServerControl>
<？xml version = "1.0"？> <MediaServerControlバージョン= "1.0"> <要求> <managecontent ID = "102" SRC = "ファイル：////var/mediaserver/rec/6A5GH49B.ulaw" DEST =」 http://www.example.com/recordings/myrecording.ulaw」MIMEタイプ= "オーディオ/基本的な" アクション= "移動" HTTPMETHOD = "置く" fetchtimeout = "5000" /> </リクエスト> </ MediaServerControl>
Figure 27: Managecontent Example
図27：Managecontent例
Note that the client can change the temporary file name assigned by the media server as part of this operation as shown.
示すように、クライアントは、この操作の一環として、メディアサーバによって割り当てられた一時ファイル名を変更することができることに注意してください。
If the request is ambiguous, the media server MUST return a status code of "400" and text "Bad Request." If the media server is unable to execute a syntactically correct and unambiguous request, it MUST return a "500" status code with the text "Server Error." For example, the local file system access restrictions may prevent deletion of the specified file. In this case, the "reason" attribute in the response conveys additional details on the server error that occurred. If there is a network or remote server error, the media server provides detailed error information in the <error_info> element contained in the media server response. Additional information regarding <managecontent> responses is provided in Section 10.7.
要求があいまいな場合は、メディアサーバーは、「400」のステータスコードとテキスト返さなければならない「不正な要求を。」メディアサーバが構文的に正しいと明確な要求を実行することができない場合は、テキストと「500」のステータスコードを返さなければならない「サーバーエラーが発生しました。」たとえば、ローカルファイルシステムへのアクセス制限は、指定されたファイルの削除を防止することができます。この場合、応答で「理由」属性が発生したサーバーエラーに関する詳細を伝えます。ネットワークまたはリモート・サーバ・エラーがある場合、メディアサーバは、メディアサーバの応答に含まれる<ERROR_INFO>要素内の詳細なエラー情報を提供します。 <managecontent>回答に関する追加情報は、セクション10.7で提供されます。
The <faxrecord> request directs the media server to process a fax in answer mode. The reason for a request separate from <playrecord> is that the media server needs to know to process the T.30 [18] or T.38 [19] fax protocols.
<faxrecord>要求には応答モードでファックスを処理するメディアサーバーを指示します。別の要求の理由<playrecord>メディアサーバがT.30 [18]又はT.38 [19]ファックスプロトコルを処理するために知っておく必要があることです。
The <faxrecord> request has multiple attributes and one child element, <prompt>. Its attributes are described in the list below.
<faxrecord>要求には、複数の属性と1つのつの子要素、<>プロンプトを持っています。その属性は、以下のリストに記載されています。
Attributes of <faxrecord>:
<faxrecord>の属性：
o lclid - optional, default value "" (the empty string): A string that identifies the called station.
O lclid - 任意のデフォルト値は「」（空文字列）と呼ばれるステーションを識別する文字列。
o prompturl - optional, no default value: The URL of the fax content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
O prompturl - オプションで、デフォルトなし値：ファックスコンテンツのURLを取得して再生すること。スキームのURLまたは「http：//」または「https：//で」スキームURL：ターゲットは、ローカルまたはリモート（NFS）「//ファイル」であってもよいです。注：この属性の使用は推奨されません。
o promptencoding - optional, no default value: Specifies the content encoding for files that do not have a 'tif' or 'tiff' extension. The only allowable value is 'tiff'. This attribute only affects "file://" scheme URLs. NOTE: Use of this attribute is deprecated.
O promptencoding - オプション、デフォルト値は：「TIF」または「TIFF」の拡張子を持っていないファイルのコンテンツのエンコーディングを指定します。唯一の許容値は「いさかい」です。スキームのURL：この属性は、「//ファイルを」影響を与えます。注：この属性の使用は推奨されません。
o recurl - optional, no default value: Specifies the target URL for the recorded content.
O再カール - オプションで、デフォルトなし値：録画されたコンテンツのターゲットURLを指定します。
o rmtid - optional, no default value: Specifies the calling station identifier of the remote terminal. If present, the media server
Oのrmtid - オプションで、デフォルトなし値：リモート端末の発呼局識別子を指定します。存在する場合、メディアサーバー
MUST reject transactions with the remote terminal if the remote terminal's identifier does not match the value of 'rmtid'.
遠隔端末の識別子が「rmtid」の値と一致しない場合、リモート端末との取引を拒絶しなければなりません。
Clients SHOULD use the more flexible <prompt> mechanism for specifying fax content. Use of the 'prompturl' attribute is deprecated and may not be supported in future MSCML versions. The <prompt> element is described in Section 6.1.1. A <prompt> element sent in a <faxrecord> request MUST NOT contain <variable> elements.
クライアントは、ファックスコンテンツを指定するためのより柔軟な<迅速な>メカニズムを使用すべきです。 「prompturl」属性の使用が廃止されており、将来のMSCMLバージョンではサポートされない場合があります。 <プロンプト>要素は、セクション6.1.1に記載されています。 <faxrecord>要求で送信された<プロンプト>要素は、<変数>要素を含めることはできません。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバーは、ローカルおよびリモート（NFS）「ファイル：//」をサポートしなければならないスキームのURLを「再カール」属性で。 <managecontent>（8節）要求を介して間接的スキームのURL：と "// https" の：MSCMLは "// HTTP" をサポートしています。
The <faxrecord> request operates in one of three modes: receive, poll, and turnaround poll. The combination of <prompt> or 'prompturl' attribute and 'recurl' attribute define the mode. Table 4 describes these modes in detail. The 'prompt' column in the table has the value 'yes' if the request has either a <prompt> element or a 'prompturl' attribute.
受信、アンケート、およびターンアラウンド投票：<faxrecord>要求には3つのモードのいずれかで動作します。 <プロンプト>や「prompturl」属性と「再カール」の組み合わせは、モードを定義する属性。表4は、詳細にこれらのモードについて説明します。リクエストは<プロンプト>要素や「prompturl」属性のいずれかを持っている場合、テーブルの「プロンプト」欄には、「はい」の値を持ちます。
+--------+--------+---------+---------------------------------------+
| prompt | recurl | Mode | Operation |
+--------+--------+---------+---------------------------------------+
| no | no | Invalid | Request fails. |
| no | yes | Receive | Record the fax to the target URL |
| | | | specified in 'recurl'. |
| yes | no | Poll | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute. If there is a 'rmtid', it |
| | | | MUST match the remote terminal's |
| | | | identifier, or the request will fail. |
| yes | yes | TP | Turnaround Poll (TP) mode. If the |
| | | | remote terminal wishes to transmit, |
| | | | the media server records the fax to |
| | | | the target URL specified in 'recurl'. |
| | | | If the remote terminal wishes to |
| | | | receive, the media server sends the |
| | | | fax from the source URL contained in |
| | | | <prompt> or 'prompturl'. If there is |
| | | | a 'rmtid', it MUST match remote |
| | | | terminal's identifier, or the send |
| | | | request will fail. A receive |
| | | | operation will still succeed, |
| | | | however. |
+--------+--------+---------+---------------------------------------+
Table 4: Fax Receive Modes
表4：モードの受信ファックス
In receive mode, the media server receives the fax and writes the fax data to the target URL specified by the 'recurl' attribute.
受信モードでは、メディアサーバは、FAXを受信して、「再カール」属性で指定されたターゲットURLにファックスデータを書き込みます。
In poll mode, the media server sends a fax, but as a polled (called) device.
ポーリングモードでは、メディアサーバは、ファックスを送信しますが、ポーリング（と呼ばれる）デバイスとして。
In turnaround poll mode, the media server will record a fax that the remote machine sends. If the remote machine requests a transmission, then the media server will send the fax.
ターンアラウンド・ポーリングモードでは、メディア・サーバは、リモートマシンが送信したファクスを記録します。リモートマシンが送信を要求した場合、その後、メディアサーバは、FAXを送信します。
When transmitting a fax, the media server will advertise that it can receive faxes in the DIS message. Likewise, when receiving a fax, the media server will advertise that it can send faxes in the DIS message.
ファックスを送信する場合、メディアサーバは、DISメッセージでファックスを受信できることをアドバタイズします。ファックスを受信したとき同様に、メディアサーバは、DISメッセージでファックスを送信できることをアドバタイズします。
The media server MUST flush any quarantined digits when it receives a <faxrecord> request.
それは<faxrecord>要求を受信したとき、メディアサーバは、任意の隔離された数字をフラッシュする必要があります。
The <faxplay> request directs the media server to process a fax in originate mode. The reason for a request separate from <play> is that the media server needs to know to process the T.30 [18] or T.38 [19] fax protocols.
<faxplay>要求が発信モードでファックスを処理するメディアサーバーを指示します。要求は、<遊び>とは別の理由は、メディアサーバーがT.30 [18]またはT.38 [19]のファックスプロトコルを処理するために知っておく必要があるということです。
The <faxplay> request has multiple attributes and one child element, <prompt>. Its attributes are described in the list below.
<faxplay>要求には、複数の属性と1つのつの子要素、<>プロンプトを持っています。その属性は、以下のリストに記載されています。
Attributes of <faxplay>:
<faxplay>の属性：
o lclid - optional, default value "" (the empty string): A string that identifies the called station.
O lclid - 任意のデフォルト値は「」（空文字列）と呼ばれるステーションを識別する文字列。
o prompturl - optional, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
O prompturl - オプションで、デフォルトなし値：コンテンツのURLを取得して再生すること。スキームのURLまたは「http：//」または「https：//で」スキームURL：ターゲットは、ローカルまたはリモート（NFS）「//ファイル」であってもよいです。注：この属性の使用は推奨されません。
o promptencoding - optional, no default value: Specifies the content encoding for files that do not have a 'tif' or 'tiff' extension. The only allowable value is 'tiff'. This attribute only affects "file://" scheme URLs. NOTE: Use of this attribute is deprecated.
O promptencoding - オプション、デフォルト値は：「TIF」または「TIFF」の拡張子を持っていないファイルのコンテンツのエンコーディングを指定します。唯一の許容値は「いさかい」です。スキームのURL：この属性は、「//ファイルを」影響を与えます。注：この属性の使用は推奨されません。
o recurl - optional, no default value: Specifies the target URL for the recorded content.
O再カール - オプションで、デフォルトなし値：録画されたコンテンツのターゲットURLを指定します。
o rmtid - optional, no default value: Specifies the calling station identifier of the remote terminal. If present, the media server
Oのrmtid - オプションで、デフォルトなし値：リモート端末の発呼局識別子を指定します。存在する場合、メディアサーバー
MUST reject transactions with the remote terminal if the remote terminal's identifier does not match the value of 'rmtid'.
遠隔端末の識別子が「rmtid」の値と一致しない場合、リモート端末との取引を拒絶しなければなりません。
Clients SHOULD use the more flexible <prompt> mechanism for specifying fax content. Use of the 'prompturl' attribute is deprecated and may not be supported in future MSCML versions. The <prompt> element is described in Section 6.1.1. A <prompt> element sent in a <faxrecord> request MUST NOT contain <variable> elements.
クライアントは、ファックスコンテンツを指定するためのより柔軟な<迅速な>メカニズムを使用すべきです。 「prompturl」属性の使用が廃止されており、将来のMSCMLバージョンではサポートされない場合があります。 <プロンプト>要素は、セクション6.1.1に記載されています。 <faxrecord>要求で送信された<プロンプト>要素は、<変数>要素を含めることはできません。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバーは、ローカルおよびリモート（NFS）「ファイル：//」をサポートしなければならないスキームのURLを「再カール」属性で。 <managecontent>（8節）要求を介して間接的スキームのURL：と "// https" の：MSCMLは "// HTTP" をサポートしています。
The <faxplay> request operates in one of three modes: send, remote poll, and turnaround poll. The combination of <prompt> or 'prompturl' attribute and 'recurl' attribute define the mode. Table 5 describes these modes in detail. The 'prompt' column in the table has the value 'yes' if the request has either a <prompt> element or a 'prompturl' attribute.
送信、リモート世論調査、およびターンアラウンド投票：<faxplay>要求には3つのモードのいずれかで動作します。 <プロンプト>や「prompturl」属性と「再カール」の組み合わせは、モードを定義する属性。表5は、詳細にこれらのモードについて説明します。リクエストは<プロンプト>要素や「prompturl」属性のいずれかを持っている場合、テーブルの「プロンプト」欄には、「はい」の値を持ちます。
+--------+--------+---------+---------------------------------------+
| prompt | recurl | Mode | Operation |
+--------+--------+---------+---------------------------------------+
| no | no | Invalid | Request fails. |
| yes | no | Send | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute. If there is a 'rmtid', it |
| | | | MUST match the remote terminal's |
| | | | identifier, or the request will fail. |
| no | yes | Poll | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute, assuming the remote |
| | | | terminal specifies it can receive a |
| | | | fax in its DIS message. If the remote |
| | | | terminal does not support reverse |
| | | | polling, the request will fail. If |
| | | | 'rmtid' is specified, it MUST match |
| | | | remote terminal's identifier, or the |
| | | | request will fail. |
| yes | yes | TP | Turnaround Poll (TP) mode. If the |
| | | | remote terminal wishes to transmit, |
| | | | the media server records the fax to |
| | | | the target URL specified in 'recurl'. |
| | | | If the remote terminal wishes to |
| | | | receive, the media server sends the |
| | | | fax from the source URL contained in |
| | | | <prompt> or 'prompturl'. If there is |
| | | | a 'rmtid', it MUST match remote |
| | | | terminal's identifier, or the send |
| | | | request will fail. A receive |
| | | | operation will still succeed, |
| | | | however. |
+--------+--------+---------+---------------------------------------+
Table 5: Fax Send Modes
表5：ファックスモードを送ります
In send mode, the media server sends the fax.
送信モードでは、メディアサーバは、ファックスを送信します。
In remote poll mode, the client places a call on behalf of the media server. The media server requests a fax transmission from the remote fax terminal.
リモートポーリングモードでは、クライアントは、メディアサーバに代わって電話をかけます。メディアサーバーは、リモートファックス端末からのファックス送信を要求します。
In turnaround poll mode, the media server will record a fax that the remote machine sends. If the remote machine requests a transmission, then the media server will send the fax.
ターンアラウンド・ポーリングモードでは、メディア・サーバは、リモートマシンが送信したファクスを記録します。リモートマシンが送信を要求した場合、その後、メディアサーバは、FAXを送信します。
When transmitting a fax, the media server will advertise that it can receive faxes in the DIS message. Likewise, when receiving a fax, the media server will advertise that it can send faxes in the DIS message.
ファックスを送信する場合、メディアサーバは、DISメッセージでファックスを受信できることをアドバタイズします。ファックスを受信したとき同様に、メディアサーバは、DISメッセージでファックスを送信できることをアドバタイズします。
The media server MUST flush any quarantined digits when it receives a <faxplay> request.
それは<faxplay>要求を受信したとき、メディアサーバは、任意の隔離された数字をフラッシュする必要があります。
The media server acknowledges receipt of a client MSCML request sent in a SIP INVITE by sending a response of either 200 OK or 415 Bad Media Type. The media server responds with 415 when the SIP request contains a content type other than "application/sdp" or "application/ mediaservercontrol+xml".
メディアサーバは、SIPに送信されたクライアントMSCML要求の受信を確認200 OKまたは415バート・メディアタイプのいずれかの応答を送信することにより、INVITE。メディアサーバは、SIP要求は「アプリケーション/ SDP」または「アプリケーション/ mediaservercontrol + XML」以外のコンテンツタイプが含まれている場合、415で応答します。
The media server acknowledges receipt of a client MSCML request sent in a SIP INFO with a 200 OK or 415 Bad Media Type. The media server responds with 415 if the INFO request contains a content type other than "application/mediaservercontrol+xml".
メディアサーバはOK 200または415不良メディアタイプでSIP INFOに送信されたクライアントMSCML要求の受信を確認します。 INFO要求は「アプリケーション/ mediaservercontrol + XML」以外のコンテンツタイプが含まれている場合は、メディアサーバーが415で応答します。
The media server transports the MSCML <response> message in a SIP INFO request.
メディアサーバは、SIP INFO要求におけるMSCML <応答>メッセージを転送します。
If there is an error in the request or the media server cannot complete the request, the media server sends the <response> message very shortly after receiving the request. If the request is able to proceed, the <response> contains final status information as described below.
要求または要求を完了することができないメディアサーバーでエラーが発生した場合は、メディアサーバは要求を受信した後に非常にすぐに<応答>メッセージを送信します。要求は、<応答>を続行することが可能である場合、以下に記載されるように、最終的なステータス情報を含みます。
All MSCML responses have the basic attributes defined in the list below.
すべてのMSCML応答は以下のリストで定義された基本的な属性を持っています。
Basic MSCML Response Attributes:
基本MSCML応答属性：
o id - optional, no default value: Echoes the client-defined ID contained in the request.
O ID - オプション、デフォルト値は：要求に含まれるクライアント定義IDをエコーません。
o request - required, no default value: Specifies the MSCML request type that generated the response. Allowable values are "configure_conference", "configure_leg", "play", "playcollect", "playrecord", "stop", "faxplay", "faxrecord", and "managecontent".
O要求 - 必要なしデフォルト値：応答を生成MSCML要求タイプを指定します。許容値は、 "configure_conference"、 "configure_leg"、 "遊び"、 "playcollect"、 "playrecord"、 "停止"、 "faxplay"、 "faxrecord"、および "managecontent" です。
o code - required, no default value: The final status code for the request. MSCML uses a subset of the status classes defined in RFC 3261 [4]. In MSCML, 2XX responses indicate success, 4XX responses indicate client error, and 5XX responses indicate an error on the media server. There are no 1XX, 3XX, or 6XX status codes in MSCML.
Oコード - 必要なしデフォルト値：リクエストの最終ステータスコード。 MSCML [4] RFC 3261で定義されたステータス・クラスのサブセットを使用します。 MSCMLでは、2xx応答が成功を示し、4XX応答はクライアントのエラーを示し、および5XX応答は、メディアサーバー上のエラーを示しています。 MSCMLには1XX、3XX、または6XXステータスコードはありません。
o text - required, no default value: The human readable reason phrase associated with the status code.
Oテキスト - 必要なしデフォルト値：ステータスコードに関連付けられている人間が読める理由フレーズ。
Responses to <configure_conference> and <stop> requests contain only the attributes above. MSCML responses to other requests MAY contain additional request-specific attributes and elements. These are described in the following sections.
<configure_conference>と<停止>への応答は、要求は、上記の属性のみが含まれています。他の要求へのMSCML応答は、追加のリクエスト固有の属性と要素を含んでいてもよいです。これらは以下のセクションで説明されています。
Responses to <configure_leg> requests have only the base response attributes defined in Section 10.2. However, when the request contains a <configure_team> element, the response includes a <team> element describing the teammate configuration for that leg. The attributes of the <team> element are shown in the list below.
<configure_leg>要求に対する応答は、セクション10.2で定義されている唯一のベース応答属性を持っています。リクエストが<configure_team>要素が含まれている場合しかし、応答はその足のためにチームメイトの構成を説明する<チーム>要素を含んでいます。 <チーム>要素の属性は、以下のリストに示されています。
Attributes of <team>:
<チーム>の属性：
o id - required, no default value: The client-defined unique identifier for the conference leg.
OのID - 必要なしデフォルト値：会議レッグのクライアントに定義された一意の識別子。
o numteam - required, no default value: The number of team members for the leg.
Oのnumteam - 必要なしデフォルト値：レッグのチームメンバーの数。
Additional information on each team member is conveyed by child <teammate> elements contained within <team>. Each teammate is represented by a single element in the list. The <teammate> element has a single attribute, as described below.
各チームメンバーの追加情報は、子<チームメイト> <チーム>内に含まれる要素によって搬送されます。それぞれのチームメイトは、リスト内の単一の要素によって表されます。後述のように、<チームメイト>要素は、単一の属性を持っています。
Attributes of <teammate>:
<チームメイト>の属性：
o id - required, no default value: The client-defined unique identifier for the teammate leg.
OのID - 必要なしデフォルト値：味方の足のためにクライアントに定義された一意の識別子。
In addition to the base response attributes defined in Section 10.2, responses to <play> requests have the additional attributes described in the list below.
10.2節で定義されたベース応答属性に加えて、<遊び>の要求に対する応答は、以下のリストで説明した追加の属性を持っています。
MSCML Response Attributes for <play>:
MSCML応答は、<遊び>の属性：
o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received, and "EOF", indicating that the end of the specified sequence of URLs was reached.
O理由 - オプションで、デフォルトなし値：すぐに完了していないリクエストの場合、「理由は」属性は、コマンドが完了した理由に関する追加情報を伝えます。可能な値は、明示的または暗黙的な<停止>要求が受信されたことを示す、「停止」、および「EOF」、URLの特定の配列の終わりに達したことを示しています。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout.
O o。o playduration - 必要である、なしデフォルト値：時間値（セクション4.2.1）関連するコンテンツ再生の持続時間を返します。
o playoffset - required, no default value: A time value (Section 4.2.1) that returns the time offset into the specified content sequence where play was terminated. If the initial "offset" value in the sequence was "0", then "playduration" and "playoffset" are equal. However, if the initial offset had some other value, "playoffset" serves as a bookmark for the client to resume play in a subsequent request.
O playoffset - 必要なしデフォルト値：時間値（4.2.1項）のプレイが終了した指定されたコンテンツシーケンスへのオフセット時間を返します。シーケンス内の最初の「オフセット」値は「0」であった場合は、「playduration」および「playoffset」が等しいです。しかし、初期オフセットは、他のいくつかの値を持っていた場合は、「playoffsetは」後続の要求でプレーを再開するためのクライアントのためのブックマークとして機能します。
If the associated request set "stoponerror=yes" in <prompt> and an error occurred while retrieving the specified content the response will include an <error_info> element detailing the problem. This element contains the response information received from the remote content server. The <error_info> element has the attributes described in the list below.
指定されたコンテンツを取得しているときに<>プロンプトとエラーに関連する要求セット「STOPONERROR = YES」が発生した場合の応答は、問題を詳述<ERROR_INFO>要素が含まれます。この要素は、リモートコンテンツサーバーから受信した応答情報が含まれています。 <ERROR_INFO>要素は、以下のリストで説明する属性を持っています。
Attributes of <error_info>:
<ERROR_INFO>の属性：
o code - required, no default value: The status code returned by the remote content server. For example, a web server might return 404 to indicate that the requested content was not found.
Oコード - 必要な、デフォルト値なし：リモートコンテンツサーバから返されたステータスコード。例えば、ウェブサーバは、要求されたコンテンツが見つからなかったことを示すために404を返すことがあります。
o text - required, no default value: The human-readable reason phrase returned by the remote content server. For example, the reason phrase "Not Found" would be returned if the requested content was not found.
Oテキスト - 必要なしデフォルト値：リモートコンテンツサーバから返された、人間が読み取り可能な理由フレーズ。要求されたコンテンツが見つからなかった場合たとえば、「見つかりません」理由句が返されます。
o context - required, no default value: Contains the content URL that was being fetched when the retrieval error occurred. This enables the client to know precisely which URL in a sequence caused the problem.
Oコンテキスト - 必要な、デフォルト値は：検索エラーが発生したときにフェッチされたコンテンツのURLが含まれていません。これは、クライアントが問題の原因となったシーケンスが正確にどのURLを知ることができます。
An <error_info> element MAY be present in the response to any request that contains a child <prompt> element.
<ERROR_INFO>要素は、子<プロンプト>要素が含まれているすべての要求に応答中に存在することができます。
In addition to the base response attributes defined in Section 10.2, responses to <playcollect> requests have the additional attributes described in the list below.
10.2節で定義されたベース応答属性に加えて、<playcollect>要求への応答は以下のリストで説明した追加の属性を持っています。
MSCML Response Attributes for <playcollect>:
MSCML応答は、<playcollect>の属性：
o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "match", meaning that a DTMF grammar was matched; "timeout", indicating that no DTMF input was received before one of the collection timers expired; and "returnkey" or "escapekey", meaning the DTMF digit mapped to that key was detected and the return key or escape key terminated the operation, respectively.
O理由 - オプションで、デフォルトなし値：すぐに完了していないリクエストの場合、「理由は」属性は、コマンドが完了した理由に関する追加情報を伝えます。可能な値は明示的または暗黙的な<停止>要求が受信されたことを示す、「停止」されています。 DTMF文法がマッチしたことを意味する「マッチ」、。収集タイマーの期限が切れる前に何DTMF入力が受信されなかったことを示す「タイムアウト」、。そして「returnkey」または「escapekey」、そのキーにマッピングされたDTMFディジットが検出された意味とリターンキーまたはキーを逃れるには、それぞれ、操作を終了しました。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout. If the caller barged the prompt, this value will reflect the play duration up to that event.
O o。o playduration - 必要である、なしデフォルト値：時間値（セクション4.2.1）関連するコンテンツ再生の持続時間を返します。発信者がプロンプトに割り込ま場合、この値はそのイベントまでのプレイ時間を反映します。
o playoffset - required, no default value: A time value (Section 4.2.1) that returns the time offset into the specified content sequence where play was terminated. If the initial "offset" value in the sequence was "0", then "playduration" and "playoffset" are equal. However, if the initial offset had some other value, "playoffset" serves as a bookmark for the client to resume play in a subsequent request. If the caller barged the prompt this value will reflect the time offset at which barge-in occurred.
O playoffset - 必要なしデフォルト値：時間値（4.2.1項）のプレイが終了した指定されたコンテンツシーケンスへのオフセット時間を返します。シーケンス内の最初の「オフセット」値は「0」であった場合は、「playduration」および「playoffset」が等しいです。しかし、初期オフセットは、他のいくつかの値を持っていた場合は、「playoffsetは」後続の要求でプレーを再開するためのクライアントのためのブックマークとして機能します。発信者がプロンプトに割り込ま場合、この値は、バージ・インが発生した時刻オフセットを反映します。
o digits - required, no default value: Contains the collected DTMF input characters. If no DTMF input was collected, this attribute is set to the empty string ("").
O桁 - 必要な、デフォルト値は：収集したDTMF入力文字が含まれていません。何のDTMF入力が収集されなかった場合は、この属性は空の文字列（「」）に設定されています。
o name - required (see note), no default value: The client-defined name of the DTMF grammar that was matched. Note: This attribute is required if the "name" attribute was set in the matching DTMF grammar.
O名 - 必要（注を参照）、デフォルト値なし：マッチしたDTMF文法のクライアント定義名。注意：「名前」属性が一致するDTMF文法に設定された場合、この属性は必須です。
Responses to <playcollect> requests MAY include an <error_info> element, as described in Section 10.4.1.
第10.4.1項で説明したように、<playcollect>要求への応答は、<ERROR_INFO>要素を含んでいてもよいです。
In addition to the base response attributes defined in Section 10.2, responses to <playrecord> requests have the additional attributes described in the list below.
10.2節で定義されたベース応答属性に加えて、<playrecord>要求への応答は以下のリストで説明した追加の属性を持っています。
o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "digit", meaning that a DTMF digit was detected and that the prompt phase was barged; "init_silence", meaning the recording terminated because of no input; "end_silence", meaning that the recording was terminated because the "endsilence" timer elapsed; "max_duration", indicating that the maximum time for the recording was reached; "escapekey", indicating that the DTMF input mapped to "escapekey" was detected, thus terminating the recording; and "error", indicating a general operation failure.
O理由 - オプションで、デフォルトなし値：すぐに完了していないリクエストの場合、「理由は」属性は、コマンドが完了した理由に関する追加情報を伝えます。可能な値は明示的または暗黙的な<停止>要求が受信されたことを示す、「停止」されています。 「数字」、DTMFディジットを検出したことを意味し、プロンプト相を割り込まれたこと。ないため、入力の終了記録を意味する「init_silence」、。 「endsilence」タイマーが経過しているため記録が終了したことを意味する「end_silence」、。記録のための最大時間に達したことを示す「MAX_DURATION」; 「escapekey」にマッピングされたDTMF入力がこうして記録を終了、検出されたことを示す「escapekey」;一般的な動作不良を示すと、「エラー」、。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout. If the caller barged the prompt, this value will reflect the play duration up to that event.
O o。o playduration - 必要である、なしデフォルト値：時間値（セクション4.2.1）関連するコンテンツ再生の持続時間を返します。発信者がプロンプトに割り込ま場合、この値はそのイベントまでのプレイ時間を反映します。
o playoffset - required, no default value: A time value (Section 4.2.1) that returns the time offset into the specified content sequence where play was terminated. If the initial "offset" value in the sequence was "0", then "playduration" and "playoffset" are equal. However, if the initial offset had some other value, "playoffset" serves as a bookmark for the client to resume play in a subsequent request. If the caller barged the prompt this value will reflect the time offset at which barge-in occurred.
O playoffset - 必要なしデフォルト値：時間値（4.2.1項）のプレイが終了した指定されたコンテンツシーケンスへのオフセット時間を返します。シーケンス内の最初の「オフセット」値は「0」であった場合は、「playduration」および「playoffset」が等しいです。しかし、初期オフセットは、他のいくつかの値を持っていた場合は、「playoffsetは」後続の要求でプレーを再開するためのクライアントのためのブックマークとして機能します。発信者がプロンプトに割り込ま場合、この値は、バージ・インが発生した時刻オフセットを反映します。
o digits - required, no default value: Contains the DTMF digit that terminated the recording. If no DTMF input was detected, this attribute is set to the empty string ("").
O桁 - 必要な、デフォルト値なし：録画を終了DTMFディジットが含まれています。何のDTMF入力が検出されなかった場合は、この属性は空の文字列（「」）に設定されています。
o reclength - required, no default value: The length of the recorded content, in bytes.
O reclength - 必要なしデフォルト値：記録されたコンテンツの長さは、バイトです。
o recduration - required, no default value: A time value (Section 4.2.1) indicating the elapsed duration of the recording.
入出力recduration - 必要なしデフォルト値：記録の経過時間を示す時間値（セクション4.2.1）。
Responses to <playrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
第10.4.1項で説明したように、<playrecord>要求への応答は、<ERROR_INFO>要素を含んでいてもよいです。
Responses to <managecontent> requests have only the base response attributes defined in Section 10.2. If a content transfer error occurs while executing the request the response will also contain an <error_info> element as described in Section 10.4.1.
<managecontent>要求に対する応答は、セクション10.2で定義されている唯一のベース応答属性を持っています。リクエストの実行中にコンテンツ転送エラーが発生した場合、セクション10.4.1に記載されているように、応答はまた、<ERROR_INFO>要素を含むであろう。
In addition to the base response attributes defined in Section 10.2, responses to <faxplay> and <faxrecord> requests have the additional attributes described in the list below.
<faxplay>と<faxrecord>要求に基本応答セクション10.2で定義された属性、回答に加えて、以下のリストで説明した追加の属性を持っています。
o reason - required, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "complete", indicating successful completion, even if there were bad lines or minor negotiation problems (e.g., a DCN was received); "disconnect", meaning that the session was disconnected; and "notfax", indicating that no DIS or DCS was received on the connection.
O理由 - 必要な、デフォルト値は：すぐに完了していないリクエストの場合、「理由」属性は、コマンドが完了した理由に関する追加情報を伝えていません。可能な値は明示的または暗黙的な<停止>要求が受信されたことを示す、「停止」されています。不良行またはマイナーネゴシエーションの問題（例えば、DCNを受信した）があったとしても、正常に完了したことを示し、「完了」。セッションが切断されたことを意味する「切断」、。何DISまたはDCSが接続上で受信されなかったことを示すと「notfax」。
o pages_received - required (see note), no default value: Indicates the number of fax pages received. Note: This attribute is required if any pages were received.
受信したFAXページの数を示していない：必要（注を参照）、デフォルト値は - O pages_received。注意：任意のページが受信された場合、この属性は必須です。
o pages_sent - required (see note), no default value: Indicates the number of fax pages sent. Note: This attribute is required if any pages were sent.
O pages_sent - 必要は（注を参照）、デフォルト値：送信されたファックス・ページの数を示していません。注意：任意のページが送られた場合、この属性は必須です。
o faxcode - required, no default value: The value of the "faxcode" attribute is the binary-or of the bit patterns defined in Table 6.
O faxcode - 必要なしデフォルト値は「faxcode」属性の値は、バイナリまたは表6で定義されたビットパターンです。
+------+--------------------------------------+
| Mask | description |
+------+--------------------------------------+
| 0 | Operation Failed |
| 1 | Operation Succeeded |
| 2 | Partial Success |
| 4 | Image received and placed in recurl |
| 8 | Image sent from specified source URL |
| 16 | rmtid did not match |
| 32 | Error reading source URL |
| 64 | Error writing recurl |
| 128 | Negotiation failure on send phase |
| 256 | Negotiation failure on receive phase |
| 512 | Reserved |
| 1024 | Irrecoverable IP packet loss |
| 2048 | Line errors in received image |
+------+--------------------------------------+
Table 6: Faxcode Mask
表6：Faxcodeマスク
Responses to <faxplay> and <faxrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
第10.4.1項で説明したように、<faxplay>と<faxrecord>要求への応答は、<ERROR_INFO>要素を含んでいてもよいです。
The following syntax specification uses XML Schema as described in XML [7].
XML [7]に記載のように、次の構文仕様は、XMLスキーマを使用します。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="MediaServerControl"> <xs:complexType> <xs:choice> <xs:element name="request"> <xs:complexType> <xs:choice> <xs:element name="configure_conference" type="configure_conferenceRequestType"/> <xs:element name="configure_leg" type="configure_legRequestType"/> <xs:element name="play" type="playRequestType"/> <xs:element name="playcollect" type="playcollectRequestType"/> <xs:element name="playrecord" type="playrecordRequestType"/>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：XSの= "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格"> <XS：要素名前= "MediaServerControl"> <XS：complexTypeの> <XS：選択> <XS：要素名= "要求"> <XS：complexTypeの> <XS：選択> <XS：要素名= "configure_conference" タイプ= "configure_conferenceRequestType" /> <XS：要素名= "configure_leg" タイプ= "configure_legRequestType" /> <XS：要素名= "遊ぶ" タイプ= "playRequestType" /> <XS：要素名= "playcollect" タイプ= "playcollectRequestType" /> <XS：要素名= "playrecord" タイプ= "playrecordRequestType" />
<xs:element name="managecontent" type="managecontentRequestType"/> <xs:element name="faxplay" type="faxRequestType"/> <xs:element name="faxrecord" type="faxRequestType"/> <xs:element name="stop" type="stopRequestType"/> </xs:choice> </xs:complexType> </xs:element> <xs:element name="response" type="responseType"/> <xs:element name="notification"> <xs:complexType> <xs:choice> <xs:element name="conference" type="conferenceNotificationType"/> <xs:element name="keypress" type="keypressNotificationType"/> <xs:element name="signal" type="signalNotificationType"/> </xs:choice> </xs:complexType> </xs:element> </xs:choice> <xs:attribute name="version" use="required"/> </xs:complexType> </xs:element> <!-- Definitions for base and concrete MSCML requests --> <!-- and embedded types. --> <xs:complexType name="base_requestType" abstract="true"> <xs:attribute name="id" type="xs:string"/> </xs:complexType> <xs:complexType name="playRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="prompt" type="promptType" minOccurs="0"/> </xs:sequence> <xs:attribute name="prompturl" type="xs:string"/> <xs:attribute name="offset" type="xs:string"/> <xs:attribute name="promptencoding" type="xs:string"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="configure_conferenceRequestType"> <xs:complexContent> <xs:extension base="base_requestType">
<XS：要素名= "managecontent" タイプ= "managecontentRequestType" /> <XS：要素名= "faxplay" タイプ= "faxRequestType" /> <XS：要素名= "faxrecord" タイプ= "faxRequestType" /> <XS ：要素名= "停止" タイプ= "stopRequestType" /> </ XS：選択> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "レスポンス" タイプ= "responseType" /> <XS ：要素名= "通知"> <XS：complexTypeの> <XS：選択> <XS：要素名= "会議" タイプ= "conferenceNotificationType" /> <XS：要素名= "キー入力" タイプ= "keypressNotificationType" /> <XS：要素名= "信号" タイプ= "signalNotificationType" /> </ XS：選択> </ XS：complexTypeの> </ XS：要素> </ XS：選択> <XS：属性名= "バージョン" を使用= "必須" /> </ XS：complexTypeの> </ XS：要素> < - > < - - と組み込みタイプのベースとコンクリートMSCML要求の定義！！。 - > <XS：complexTypeの名= "base_requestType" 抽象= "真"> <XS：属性名= "ID" タイプ= "XS：文字列" /> </ XS：complexTypeの> <XS：complexTypeの名= "playRequestType "> <XS：complexContentを> <XS：拡張ベース=" base_requestType "> <XS：配列> <XS：要素名=" プロンプト」タイプ= "promptType" のminOccurs = "0" /> </ XS：配列> < XS：属性名= "prompturl" タイプ= "XS：文字列" /> <XS：属性名= "オフセット" タイプ= "XS：文字列" /> <XS：属性名= "promptencoding" タイプ= "XS：文字列"/> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名前=" configure_conferenceRequestType "> <XS：complexContentを> <XS：増設ベース=" base_requestType ">
<xs:sequence> <xs:element name="subscribe" type="conference_eventsubscriptionType" minOccurs="0"/> </xs:sequence> <xs:attribute name="reservedtalkers" type="xs:positiveInteger"/> <xs:attribute name="reserveconfmedia" type="yesnoType" default="yes"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="configure_legRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="inputgain" type="gainType" minOccurs="0"/> <xs:element name="outputgain" type="gainType" minOccurs="0"/> <xs:element name="configure_team" type="configure_teamType" minOccurs="0"/> <xs:element name="subscribe" type="leg_eventsubscriptionType" minOccurs="0"/> </xs:sequence> <xs:attribute name="type"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="talker"/> <xs:enumeration value="listener"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="mixmode"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="full"/> <xs:enumeration value="mute"/> <xs:enumeration value="preferred"/> <xs:enumeration value="parked"/> <xs:enumeration value="private"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="dtmfclamp" type="yesnoType"/> <xs:attribute name="toneclamp" type="yesnoType"/> </xs:extension> </xs:complexContent> </xs:complexType>
<XS：シーケンス> <XS：要素名=タイプ= "conference_eventsubscriptionType" minOccurs属性を "購読" = "0" /> </ XS：シーケンス> <XS：属性名は= "reservedtalkers" タイプ= "XS：POSITIVEINTEGER" /> <XS：属性名= "reserveconfmedia" タイプ= "yesnoType" デフォルト= "はい" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名= "configure_legRequestType"> < XS：complexContentを> <XS：拡張ベース= "base_requestType"> <XS：配列> <XS：要素名= "inputgain" タイプ= "gainType" のminOccurs = "0" /> <XS：要素名= "outputgain" タイプ= "gainType" のminOccurs = "0" /> <XS：要素名= "configure_team" タイプ= "configure_teamType" のminOccurs = "0" /> <XS：要素名= "加入" タイプ= "leg_eventsubscriptionType" のminOccurs = "0 "/> </ XS：配列> <XS：属性名=" タイプ "> <XS：単純> <XS：制限ベース=" XS：NMTOKEN "> <XS：列挙値=" トーカー "/> <XS：列挙値= "リスナー" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "をMixMode"> <XS：単純> <XS：制限ベース= "XS： NMTOKEN "> <XS ：列挙値= "フル" /> <XS：列挙値= "ミュート" /> <XS：列挙値= "好ましい" /> <XS：列挙値= "駐車" /> <XS：列挙値= "プライベート"/> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名=" dtmfclamp "タイプ= "yesnoType"/> <XS：属性名= "toneclamp" タイプ=" yesnoType 「/> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの>
<xs:complexType name="configure_teamType"> <xs:sequence> <xs:element name="teammate" type="teammateType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string"/> <xs:attribute name="action" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="add"/> <xs:enumeration value="delete"/> <xs:enumeration value="query"/> <xs:enumeration value="set"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="teammateType"> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="playcollectRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="prompt" type="promptType" minOccurs="0"/> <xs:element name="pattern" type="dtmfGrammarType" minOccurs="0"/> </xs:sequence> <xs:attribute name="prompturl" type="xs:string"/> <xs:attribute name="offset" type="xs:string"/> <xs:attribute name="barge" type="yesnoType" default="yes"/> <xs:attribute name="promptencoding" type="xs:string"/> <xs:attribute name="cleardigits" type="yesnoType" default="no"/> <xs:attribute name="maxdigits" type="xs:string"/> <xs:attribute name="firstdigittimer" type="xs:string" default="5000ms"/> <xs:attribute name="interdigittimer" type="xs:string" default="2000ms"/> <xs:attribute name="extradigittimer" type="xs:string" default="1000ms"/> <xs:attribute name="interdigitcriticaltimer" type="xs:string"/> <xs:attribute name="skipinterval" type="xs:string" default="6s"/> <xs:attribute name="ffkey" type="DTMFkeyType"/> <xs:attribute name="rwkey" type="DTMFkeyType"/>
<XS：complexTypeの名前= "configure_teamType"> <XS：配列> <XS：要素名= "味方" タイプ= "teammateType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS：名前= "ID" 属性タイプ= "XS：文字列が" /> <XS：属性名= "アクションが" 使用は= "必要"> <XS：単純> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "追加" /> <XS：列挙値= "削除" /> <XS：列挙値= "クエリ" /> <XS：列挙値= "設定" /> </ XS：制限> </ XS ：単純> </ XS：属性> </ XS：complexTypeの> <XS：complexTypeの名前= "teammateType"> <XS：属性名= "ID" タイプ= "XS：文字列" 使用= / /> < "必要" XS：complexTypeの> <XS：complexTypeの名前= "playcollectRequestType"> <XS：complexContentを> <XS：増設ベース= "base_requestType"> <XS：配列> <XS：要素名= "プロンプト" タイプ= "promptType" のminOccurs = "0" /> <XS：要素名= "パターン" タイプ= "dtmfGrammarType" のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名= "prompturl" タイプ= "XS：文字列" /> <XS：属性名= "オフセット" タイプ= "XS：文字列" /> <XS：属性名= "はしけ" タイプ= "yesnoTy PE」デフォルト= "はい" /> <XS：属性名= "promptencoding" タイプ= "XS：文字列" /> <XS：属性名= "cleardigits" タイプ= "yesnoType" デフォルト= "なし" /> <XS ：属性名= "maxdigits" タイプ= "XS：文字列" /> <XS：属性名= "firstdigittimer" タイプ= "XS：文字列" デフォルト= "5000ms" /> <XS：属性名= "interdigittimer" タイプ= "XS：文字列" デフォルト= "2000ミリ秒" /> <XS：属性名= "extradigittimer" タイプ= "XS：文字列" デフォルト= "1000msの" /> <XS：属性名= "interdigitcriticaltimer" タイプ= "XS：文字列"/> <XS：属性名=" skipinterval "タイプ= "XS：文字列" デフォルト= "6S"/> <XS：属性名= "ffkey" タイプ= "DTMFkeyType"/> <XS：属性名=" rwkey "タイプ=" DTMFkeyType "/>
<xs:attribute name="returnkey" type="DTMFkeyType" default="#"/> <xs:attribute name="escapekey" type="DTMFkeyType" default="*"/> <xs:attribute name="maskdigits" type="yesnoType" default="no"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="playrecordRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="prompt" type="promptType" minOccurs="0"/> </xs:sequence> <xs:attribute name="prompturl" type="xs:string"/> <xs:attribute name="promptencoding" type="xs:string"/> <xs:attribute name="offset" type="xs:string" default="0"/> <xs:attribute name="barge" type="yesnoType" default="yes"/> <xs:attribute name="cleardigits" type="yesnoType" default="no"/> <xs:attribute name="escapekey" type="xs:string" default="*"/> <xs:attribute name="recurl" type="xs:string" use="required"/> <xs:attribute name="mode" default="overwrite"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="append"/> <xs:enumeration value="overwrite"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="recencoding" type="xs:string"/> <xs:attribute name="initsilence" type="xs:string"/> <xs:attribute name="endsilence" type="xs:string"/> <xs:attribute name="duration" type="xs:string"/> <xs:attribute name="beep" type="yesnoType" default="yes"/> <xs:attribute name="recstopmask" type="xs:string" default="01234567890*#"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="managecontentRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:attribute name="fetchtimeout" type="xs:string" default="10000"/> <xs:attribute name="mimetype" type="xs:string"/>
<XS：属性名= "returnkey" タイプ= "DTMFkeyType" デフォルト= "＃" /> <XS：属性名= "escapekey" タイプ= "DTMFkeyType" デフォルト= "*" /> <XS：属性名= "maskdigits "タイプ=" yesnoType」デフォルト= "なし" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名= "playrecordRequestType"> <XS：complexContentを> <XS：拡張基地= "base_requestType"> <XS：配列> <XS：要素名= "プロンプト" タイプ= "promptType" のminOccurs = "0" /> </ XS：配列> <XS：属性名= "prompturl" タイプ=」 XS：文字列 "/> <XS：属性名=" promptencoding」タイプ= "XS：文字列" /> <XS：属性名= "オフセット" タイプ= "XS：文字列" デフォルト= "0" /> <XS：属性名= "はしけ" タイプ= "yesnoType" デフォルト= "はい" /> <XS：属性名= "cleardigits" タイプ= "yesnoType" デフォルト= "なし" /> <XS：属性名= "escapekey" タイプ= "XS：文字列" デフォルト= "*" /> <XS：属性名= "再カール" タイプ= "XS：文字列" 使用= "必要" /> <XS：属性名= "モード" デフォルト= "上書き"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "追加" /> <XS：列挙値= /> </ XS "上書き"：制限> </ XS：単純> </ XS：属性> <XS：属性名は= "recencoding" タイプ= "XS：文字列" /> <XS：属性名=」 initsilence」タイプ= "XS：文字列" /> <XS：属性名= "endsilence" タイプ= "XS：文字列" /> <XS：属性名= "継続" タイプ= "XS：文字列" /> <XS：属性名= "recstopmask" タイプ= "XS：：文字列" デフォルト= "01234567890 *＃" /> </ XS：拡張> <名前= "ビープ音" タイプ= "yesnoType" デフォルト= "はい" /> <XS属性/ XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名= "managecontentRequestType"> <XS：complexContentを> <XS：増設ベース= "base_requestType"> <XS：属性名= "fetchtimeout" タイプ= "XS：文字列」デフォルト= "10000" /> <XS：属性名= "MIMEタイプ" タイプ= "XS：文字列" />
<xs:attribute name="name" type="xs:string"/> <xs:attribute name="httpmethod"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="put"/> <xs:enumeration value="post"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="action"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="move"/> <xs:enumeration value="delete"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="dest" type="xs:string"/> <xs:attribute name="src" type="xs:string" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="stopRequestType"> <xs:complexContent> <xs:extension base="base_requestType"/> </xs:complexContent> </xs:complexType> <xs:complexType name="faxRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="prompt" type="promptType" minOccurs="0"/> </xs:sequence> <xs:attribute name="lclid" type="xs:string"/> <xs:attribute name="prompturl" type="xs:string"/> <xs:attribute name="recurl" type="xs:string"/> <xs:attribute name="rmtid" type="xs:string"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="dtmfGrammarType"> <xs:choice> <xs:element name="regex" type="dtmfPatternType" maxOccurs="unbounded"/> <xs:element name="mgcpdigitmap" type="dtmfPatternType"/> <xs:element name="megacodigitmap" type="dtmfPatternType"/> </xs:choice> </xs:complexType>
<XS：属性名= "名前" タイプ= "XS：文字列" /> <XS：属性名= "HTTPMETHOD"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= XS /> < "置く"：列挙値= "ポスト" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "アクション"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "移動" /> <XS：列挙値= "削除" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "DEST" タイプ= "XS：文字列" /> <XS：属性名= "SRC" タイプ= "XS：文字列" 使用= "必須" /> </ XS：拡張> < / XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名前= "stopRequestType"> <XS：complexContentを> <XS：増設ベース= "base_requestType" /> </ XS：complexContentを> </ XS：complexTypeの> < XS：complexTypeの名前= "faxRequestType"> <XS：complexContentを> <XS：増設ベース= "base_requestType"> <XS：配列> <XS：要素名= "プロンプト" タイプ= "promptType" のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名= "lclid" タイプ= "XS：文字列" /> <XS：属性名= "prompturl" TY PE = "XS：文字列" /> <XS：属性名= "再カール" タイプ= "XS：文字列" /> <XS：属性名= "rmtid" タイプ= "XS：文字列" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名= "dtmfGrammarType"> <XS：選択> <XS：要素名= "正規表現" タイプ= "dtmfPatternType" のmaxOccurs = "無制限" /> < XS：要素名= "mgcpdigitmap" タイプ= "dtmfPatternType" /> <XS：要素名= "megacodigitmap" タイプ= "dtmfPatternType" /> </ XS：選択> </ XS：complexTypeの>
<xs:complexType name="dtmfPatternType"> <xs:attribute name="value" type="xs:string" use="required"/> <xs:attribute name="name" type="xs:string"/> </xs:complexType> <!-- Definitions for base and concrete MSCML responses --> <!-- and embedded types. --> <xs:complexType name="base_responseType" abstract="true"> <xs:attribute name="request" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="configure_conference"/> <xs:enumeration value="configure_leg"/> <xs:enumeration value="play"/> <xs:enumeration value="playcollect"/> <xs:enumeration value="playrecord"/> <xs:enumeration value="managecontent"/> <xs:enumeration value="faxplay"/> <xs:enumeration value="faxrecord"/> <xs:enumeration value="stop"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="id" type="xs:string"/> <xs:attribute name="code" type="xs:string" use="required"/> <xs:attribute name="text" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="responseType"> <xs:complexContent> <xs:extension base="base_responseType"> <xs:sequence> <xs:element name="error_info" type="stoponerrorResponseType" minOccurs="0"/> <xs:element name="team" type="configure_teamResponseType" minOccurs="0"/> </xs:sequence> <xs:attribute name="reason" type="xs:string"/> <xs:attribute name="reclength" type="xs:string"/> <xs:attribute name="recduration" type="xs:string"/> <xs:attribute name="digits" type="xs:string"/> <xs:attribute name="name" type="xs:string"/> <xs:attribute name="playduration" type="xs:string"/> <xs:attribute name="playoffset" type="xs:string"/> <xs:attribute name="faxcode" type="xs:string"/> <xs:attribute name="pages_sent" type="xs:string"/> <xs:attribute name="pages_recv" type="xs:string"/> </xs:extension> </xs:complexContent> </xs:complexType>
<XS：complexTypeの名前= "dtmfPatternType"> <XS：属性名= "値" タイプ= "XS：文字列" 使用= "必要" /> <XS：属性名= "名前" タイプ= "XS：文字列" / > </ XS：complexTypeの> < - ベースの定義と具体的なMSCML応答 - > < - と組み込みタイプ！！。 - > <XS：complexTypeの名= "base_responseTypeは" 抽象= "真"> <XS：属性名= "要求" の使用は= "必要"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "configure_conference" /> <XS：列挙値= "configure_leg" /> <XS：列挙値= "遊ぶ" /> <XS：列挙値= "playcollect" /> <XS：列挙値= "playrecord" /> <XS：列挙値= "managecontent" /> <XS：列挙値= "faxplay" /> <XS：列挙値= "faxrecord" /> <XS：列挙値= "ストップ" /> < / XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "ID" タイプ= "XS：文字列" /> <XS：属性名= "コード" タイプ= "XS：列"：=属性名/> <XS" テキスト」タイプ= "XSを：必要な "=を使用" string" を使用する= "必要" /> </ XS：complexTypeの> <XS：complexTypeの名= "responseType"> <XS： complexContentを> <XS：拡張ベース= "base_responseType"> <XS：シーケンス> <XS：要素名= "ERROR_INFO" タイプ= "stoponerrorResponseType" のminOccurs = "0" /> <XS：要素名= "チーム" タイプ=」 configure_teamResponseType」のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名= "理由" タイプ= "XS：文字列" /> <XS：属性名= "reclength" タイプ= "XS：文字列" /> <XS：属性名= "recduration" タイプ= "XS：文字列 "/> <XS：属性名=" 数字」タイプ= "XS：文字列" /> <XS：属性名= "名前" タイプ= "XS：文字列" /> <XS：属性名= "playduration" タイプ= "XS：文字列" /> <XS：属性名= "playoffset" タイプ= "XS：文字列" /> <XS：属性名= "faxcode" タイプ= "XS：文字列" /> <XS：属性名= "pages_sent" タイプ= "XS：文字列" /> <XS：属性名= "pages_recv" タイプ= "XS：文字列" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの>
<xs:complexType name="stoponerrorResponseType"> <xs:attribute name="code" type="xs:string" use="required"/> <xs:attribute name="text" type="xs:string" use="required"/> <xs:attribute name="context" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="configure_teamResponseType"> <xs:sequence> <xs:element name="teammate" type="teammateType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="numteam" type="xs:integer" use="required"/> </xs:complexType> <!-- Definitions for MSCML event subscriptions and --> <!-- embedded types --> <xs:complexType name="conference_eventsubscriptionType"> <xs:sequence> <xs:element name="events"> <xs:complexType> <xs:sequence> <xs:element name="activetalkers" type="activetalkersSubscriptionType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="activetalkersSubscriptionType"> <xs:attribute name="report" type="yesnoType" use="required"/> <xs:attribute name="interval" type="xs:string" default="60s"/> </xs:complexType> <xs:complexType name="leg_eventsubscriptionType"> <xs:sequence> <xs:element name="events"> <xs:complexType> <xs:sequence> <xs:element name="keypress" type="keypressSubscriptionType" minOccurs="0" maxOccurs="1"/> <xs:element name="signal" type="signalSubscriptionType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="keypressSubscriptionType"> <xs:attribute name="report" use="required">
<XS：complexTypeの名前= "stoponerrorResponseType"> <XS：属性名= "コード" タイプ= "XS：文字列" 使用= "必須" /> <XS：属性名= "テキスト" タイプ= "XS：文字列" 使用= "必須" /> <XS：属性名= "文脈" タイプ= "XS：文字列" 使用= "必須" /> </ XS：complexTypeの> <XS：complexTypeの名= "configure_teamResponseType"> <XS：シーケンス> <XS：要素名= "味方" タイプ= "teammateType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS：属性名= "ID" タイプ= "XS：文字列" 使用= "必須" /> <XS：属性名は= "numteam" タイプ= "XS：整数" 使用= "必須" /> </ XS：！complexTypeの> < - MSCMLイベントサブスクリプションの定義と - > <！ - - 組み込みタイプ - > <XS：complexTypeの名は= "conference_eventsubscriptionType"> <XS：シーケンス> <XS：要素名= "イベント"> <XS：complexTypeの> <XS：シーケンス> <XS：要素名= "activetalkers"シーケンス> </ XS：：complexTypeの> </ XS：要素> </ XS：シーケンス> </ XS：complexTypeの> <XS：complexTypeの名= "activetalkersSubscriptionType"> <XS = "activetalkersSubscriptionType" /> </ XSを入力します。属性名=「レポート」TYP E = "yesnoType" 使用= "必須" /> <XS：属性名= "間隔" タイプ= "XS：文字列" デフォルト= "60年代" /> </ XS：complexTypeの> <XS：complexTypeの名前は= "leg_eventsubscriptionType" > <XS：配列> <XS：要素名= "イベント"> <XS：complexTypeの> <XS：配列> <XS：要素名= "キー押下" タイプ= "keypressSubscriptionType" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素名= "信号" タイプ= "signalSubscriptionType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：complexTypeの> </ XS：要素> </ XS：シーケンス> </ XS：complexTypeの> <XS：complexTypeの名= "keypressSubscriptionType"> <XS：属性名= "レポート" 利用= "必要">
<xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="standard"/> <xs:enumeration value="long"/> <xs:enumeration value="both"/> <xs:enumeration value="none"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="maskdigits" type="yesnoType" default="no"/> </xs:complexType> <xs:complexType name="signalSubscriptionType"> <xs:attribute name="type" type="xs:NMTOKEN" use="required"/> <xs:attribute name="report" type="yesnoType" use="required"/> </xs:complexType> <!-- Definitions for MSCML event notifications and --> <!-- embedded types. --> <xs:complexType name="conferenceNotificationType"> <xs:sequence> <xs:element name="activetalkers" type="activetalkersNotificationType" minOccurs="0"/> </xs:sequence> <xs:attribute name="uniqueid" type="xs:string" use="required"/> <xs:attribute name="numtalkers" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="activetalkersNotificationType"> <xs:sequence minOccurs="0"> <xs:element name="talker" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="callid" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="keypressNotificationType"> <xs:sequence> <xs:element name="status" type="statusType"/> </xs:sequence> <xs:attribute name="digit" type="DTMFkeyType" use="required"/> <xs:attribute name="length" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="standard"/> <xs:enumeration value="long"/> </xs:restriction> </xs:simpleType>
<XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "標準" /> <XS：列挙値= "長い" /> <XS：列挙値= "双方" /> <XS：列挙値= "なし" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "maskdigits" タイプ= "yesnoType" デフォルト= "なし" /> </ XS：complexTypeの> <XS：complexTypeの名前= "signalSubscriptionType"> <XS：属性名= "タイプ" タイプ= "XS：NMTOKEN" 使用= "必要" /> <XS：属性名= "レポート" タイプ= "yesnoType" 使用= "必須" /> </ XS：complexTypeの> < - MSCMLイベント通知の定義と - > < - 組み込みタイプ！！。 - > <XS：complexTypeの名前= "conferenceNotificationType"> <XS：シーケンス> <XS：要素名= "activetalkers" タイプ= "activetalkersNotificationType" のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名属性名= "numtalkers" タイプ= "XS：：文字列" = "uniqueidの" タイプ= "XS：文字列" = /> <XS "必要" 使用=使用 "必要" /> </ XS：complexTypeの> <XS： complexTypeの名前= "activetalkersNotificationType"> <XS：シーケンスのminOccurs = "0"> <XS：要素名= "話し手" のmaxOccurs = "無制限"> <XS：complexTypeの> <XS：属性名= "callid" タイプ= "XS ：文字列」使用= "必須" /> </ XS：complexTypeの> </ XS：要素> </ XS：シーケンス> </ XS：complexTypeの> <XS：complexTypeの名は= "keypressNotificationType"> <XS：シーケンス> < XS：要素名= "ステータス" タイプ= "statusType" /> </ XS：シーケンス> <XS：属性名= "数字" タイプ= "DTMFkeyType" 使用= "必要" /> <XS：属性名= "長さ"使用は=" 必要 "> <XS：単純> <XS：制限ベース=" XS：NMTOKEN "> <XS：列挙値=" 標準 "/> <XS：列挙値=" 長い "/> </ XS：制限> </ XS：単純>
</xs:attribute> <xs:attribute name="method" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="standard"/> <xs:enumeration value="long"/> <xs:enumeration value="double"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="interdigittime" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="statusType"> <xs:attribute name="command" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="idle"/> <xs:enumeration value="play"/> <xs:enumeration value="collect"/> <xs:enumeration value="record"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="duration" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="signalNotificationType"> <xs:attribute name="type" use="required" fixed="busy"/> </xs:complexType> <!-- Definitions for miscellaneous embedded, helper data types --> <xs:complexType name="promptType"> <xs:choice maxOccurs="unbounded"> <xs:element name="audio" type="promptcontentType"/> <xs:element name="variable" type="spokenvariableType"/> </xs:choice> <xs:attribute name="locale" type="xs:string"/> <xs:attribute name="baseurl" type="xs:string"/> <xs:attribute name="stoponerror" type="yesnoType" default="no"/> <xs:attribute name="gain" type="xs:string" default="0"/> <xs:attribute name="gaindelta" type="xs:string" default="0"/> <xs:attribute name="rate" type="xs:string" default="0"/> <xs:attribute name="ratedelta" type="xs:string" default="0"/> <xs:attribute name="repeat" type="xs:string" default="1"/> <xs:attribute name="duration" type="xs:string" default="infinite"/> <xs:attribute name="offset" type="xs:string" default="0"/> <xs:attribute name="delay" type="xs:string" default="0"/> </xs:complexType>
</ XS：属性> <XS：属性名= "方法" の使用は= "必要"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "標準" /> < XS：列挙値= "長い" /> <XS：列挙値= "ダブル" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "interdigittime" タイプ= "XS：文字列" 使用は= "必要" /> </ XS：complexTypeの> <XS：complexTypeの名= "statusType"> <XS：単純> <XS：属性名= "コマンド" 使用は=> <XS "必要" ：制限ベース= "XS：文字列"> <XS：列挙値= "アイドル" /> <XS：列挙値= "再生" /> <XS：列挙値= "収集" /> <XS：列挙値=」記録 "/> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名=" 継続」タイプ= "XS：文字列" 使用= "必要" /> </ XS：complexTypeの！埋め込まれた雑多の定義、ヘルパーデータタイプ - のcomplexType> <：> <XS：complexTypeの名前= "signalNotificationType"> <XS：属性名= "タイプ" の使用を=固定= "忙しい" /> </ XSを "必須" - > <XS：complexTypeの名= "promptType"> <XS：選択肢のmaxOccurs = "無制限"> <X S：要素名= "オーディオ" タイプ= "promptcontentType" /> <XS：要素名= "変数" タイプ= "spokenvariableType" /> </ XS：選択> <XS：属性名= "ロケール" タイプ= "XS ：文字列 "/> <XS：属性名=" BASEURL」タイプ= "XS：文字列" /> <XS：属性名= "STOPONERROR" タイプ= "yesnoType" デフォルト= "なし" /> <XS：属性名= "ゲイン" タイプ= "XS：文字列" デフォルト= "0" /> <XS：属性名= "gaindelta" タイプ= "XS：文字列" デフォルト= "0" /> <XS：属性名= "率" タイプ= "XS：文字列" デフォルト= "0" /> <XS：属性名= "ratedelta" タイプ= "XS：文字列" デフォルト= "0" /> <XS：属性名= "繰り返し" タイプ= "XS：文字列」デフォルト= "1" /> <XS：属性名= "継続" タイプ= "XS：文字列" デフォルト= "無限" /> <XS：属性名= "オフセット" タイプ= "XS：文字列" デフォルト= "0" /> <XS：属性名= "遅延" タイプ= "XS：文字列" デフォルト= "0" /> </ XS：complexTypeの>
<xs:complexType name="promptcontentType"> <xs:attribute name="url" type="xs:string" use="required"/> <xs:attribute name="encoding" type="xs:string"/> <xs:attribute name="gain" type="xs:string" default="0"/> <xs:attribute name="gaindelta" type="xs:string" default="0"/> <xs:attribute name="rate" type="xs:string" default="0"/> <xs:attribute name="ratedelta" type="xs:string" default="0"/> </xs:complexType> <xs:complexType name="spokenvariableType"> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="dat"/> <xs:enumeration value="dig"/> <xs:enumeration value="dur"/> <xs:enumeration value="mth"/> <xs:enumeration value="mny"/> <xs:enumeration value="num"/> <xs:enumeration value="sil"/> <xs:enumeration value="str"/> <xs:enumeration value="tme"/> <xs:enumeration value="wkd"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="subtype"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="mdy"/> <xs:enumeration value="dmy"/> <xs:enumeration value="ymd"/> <xs:enumeration value="ndn"/> <xs:enumeration value="t12"/> <xs:enumeration value="t24"/> <xs:enumeration value="USD"/> <xs:enumeration value="gen"/> <xs:enumeration value="ndn"/> <xs:enumeration value="crd"/> <xs:enumeration value="ord"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="value" type="xs:string" use="required"/> </xs:complexType> <xs:simpleType name="yesnoType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/>
<XS：complexTypeの名前= "promptcontentType">属性名= "エンコーディング" タイプ= "XS：：文字列" <XS <XS：：属性名= "URL" タイプ= "XS文字列" 使用は= / "必要"> / > <XS：属性名= "ゲイン" タイプ= "XS：文字列" デフォルト= "0" /> <XS：属性名= "gaindelta" タイプ= "XS：文字列" デフォルト= "0" /> <XS：デフォルト= "0" /> <XS：属性名= "ratedelta" タイプ= "XS：文字列" デフォルト= "0" /> </ XS：：名= "率" タイプ= "文字列XS" 属性のcomplexType> < XS：complexTypeの名前= "spokenvariableType"> <XS：属性名= "タイプ" の使用は= "必要"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "DAT" /> <XS：列挙値= "掘る" /> <XS：列挙値= "DUR" /> <XS：列挙値= "m番目の" /> <XS：列挙値= "MNY" /> <XS：列挙値= "NUM" /> <XS：列挙値= "SIL" /> <XS：列挙値= "STR" /> <XS：列挙値= "TME" /> <XS：列挙値= "WKD" / > </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "サブタイプ"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "MDY "/> <XS：列挙値=" DMY "/> <XS：列挙値=" YMD "/> <XS：列挙値=" NDN "/> <XS：列挙値=" T12" /> <XS：列挙値= "T24" /> <XS：列挙値= "USD" /> <XS：列挙値= "GEN" /> <XS：列挙値= "NDN" /> <XS：列挙値= "CRD" /> <XS：列挙値= "ORD" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "値" タイプ= "XS：文字列" 使用=」必要な "/> </ XS：complexTypeの> <XS：単純型名=" yesnoType "> <XS：制限ベース=" XS：NMTOKEN "> <XS：列挙値=" はい "/> <XS：列挙値="なし "/>
<xs:enumeration value="1"/> <xs:enumeration value="0"/> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="DTMFkeyType"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]"/> <xs:pattern value="[A-D]"/> <xs:pattern value="[a-d]"/> <xs:pattern value="#"/> <xs:pattern value="\*"/> </xs:restriction> </xs:simpleType> <xs:complexType name="gainType"> <xs:choice> <xs:element name="auto" type="autogainType"/> <xs:element name="fixed" type="fixedgainType"/> </xs:choice> </xs:complexType> <xs:complexType name="autogainType"> <xs:attribute name="startlevel" type="xs:string"/> <xs:attribute name="targetlevel" type="xs:string"/> <xs:attribute name="silencethreshold" type="xs:string"/> </xs:complexType> <xs:complexType name="fixedgainType"> <xs:attribute name="level" type="xs:string"/> </xs:complexType> </xs:schema>
<XS：列挙値= "1" /> <XS：列挙値= "0" /> <XS：列挙値= "TRUE" /> <XS：列挙値= "偽" /> </ XS：制限> </ XS：単純> <XS：simpleTypeの名前= "DTMFkeyType"> <XS：制限ベース= "XS：文字列"> <XS：パターン値= "[0-9]" /> <XS：パターン値=」 [AD] "/> <XS：パターン値=" [AD] "/> <XS：パターン値=" ＃ "/> <XS：パターン値=" \ * "/> </ XS：制限> </ XS：単純> <XS：complexTypeの名前= "gainType"> <XS：選択> <XS：要素名= "自動" タイプ= "autogainType" /> <XS：要素名= "固定" タイプ= "fixedgainType" / > </ XS：選択> </ XS：complexTypeの> <XS：complexTypeの名前= "autogainType"> <XS：属性名= "startlevel" タイプ= "XS：文字列" /> <XS：属性名= "targetlevel"タイプ= "XS：文字列" /> <XS：属性名= "silencethreshold" タイプ= "XS：文字列" /> </ XS：complexTypeの> <XS：complexTypeの名= "fixedgainType"> <XS：属性名=」レベル」TYPE = "XS：文字列" /> </ XS：complexTypeの> </ XS：スキーマ>
12.1. IANA Registration of MIME Media Type application/ mediaservercontrol+xml
12.1. MIMEメディアタイプアプリケーション/ mediaservercontrol + XMLのIANA登録
MIME media type name: application
MIME subtype name: mediaservercontrol+xml
Required parameters: none
Optional parameters: charset
charset This parameter has identical semantics to the charset parameter of the "application/xml" media type, as specified in XML Media Types [8].
XMLのメディアタイプに指定されている。このパラメータは、「アプリケーション/ xmlの」メディアタイプのcharsetパラメータと同じ意味を持つ文字セット[8]。
Encoding considerations: See RFC 3023 [8]. Interoperability considerations: See RFC 2023 [8] and RFC 5022. Published specification: RFC 5022
エンコードの考慮事項：RFC 3023を参照してください。[8]。相互運用性の考慮事項：RFC 5022：RFC 2023 [8]およびRFC 5022公開された仕様を参照してください
Applications that use this media type: Multimedia, enhanced conferencing and interactive applications. Personal and email address for further information: eburger@cantata.com [31] Intended usage: COMMON
マルチメディア、強化会議やインタラクティブなアプリケーション：このメディアタイプを使用するアプリケーション。詳しくは、個人やメールアドレス：eburger@cantata.com [31]意図している用法：COMMON
Because media flows through a media server in a conference, the media server itself MUST protect the integrity, confidentiality, and security of the sessions. It should not be possible for a conference participant, on her own behalf, to be able to "tap in" to another conference without proper authorization.
メディアは会議でメディアサーバーを介して流れるため、メディアサーバ自体はセッションの完全性、機密性、およびセキュリティを保護する必要があります。これは、適切な許可を持たずに、別の会議に「水道」ことができるように、彼女自身に代わって、会議参加者のために可能にすべきではありません。
Because conferencing is a high-value application, the media server SHOULD implement appropriate security measures. This includes, but is not limited to, access lists for application servers. That is, the media server only allows a select list of application or proxy servers to create conferences, to invite participants to sessions, etc. Note that the mechanisms for such security, like private networks, shared certificates, MAC white/black lists, are beyond the scope of this document.
会議は、付加価値の高いアプリケーションであるため、メディアサーバは、適切なセキュリティ対策を実装する必要があります。これには、アプリケーションサーバー用のアクセスリストが、これらに限定されません。つまり、メディアサーバは、プライベートネットワークのようなセキュリティのためのメカニズム、共有証明書、MACのブラック/ホワイトリストは、あることに注意してくださいなど、セッションに参加者を招待し、会議を作成するために、アプリケーションまたはプロキシサーバの選択リストを可能にこのドキュメントの範囲を超えて。
Security concerns are one important reason MSCML limits requests with conference scope to a separate control leg per conference. MSCML uses the simple, proven, Internet-scale security model of SIP to determine if a client is who they say they are (authentication) and if they are allowed to create and manipulate a conference. However, the security model to enable a control leg to manipulate arbitrary conferences on the media server is extremely difficult. Not only would one need to authenticate and authorize the basic conference primitives, but privacy considerations require policies for one client to access another client's conferences, even if the two clients are on the same host. For example, if the media server allowed any control leg to control any conference, an authorized but unrelated client could maliciously attach itself to an existing session and record or tap the conversation without the participant's knowledge or consent.
セキュリティ上の懸念は、会議ごとに別々の制御脚に会議スコープの一つの重要な理由のMSCML制限を要求しています。 MSCMLは、クライアントは、彼らが（認証）であり、彼らは会議を作成し、操作を許可されている場合は本人であるかどうかを判断するためにSIPの簡単な、実績のある、インターネット規模のセキュリティモデルを使用しています。しかし、メディアサーバー上で任意の会議を操作するための制御脚を有効にするには、セキュリティモデルは非常に困難です。一つは、基本的な会議プリミティブを認証および認可する必要がありますが、プライバシーの考慮事項が2つのクライアントが同じホスト上にある場合でも、別のクライアントの会議にアクセスするためのクライアントのポリシーを必要とするだけでなく。例えば、任意の制御脚は任意の会議を制御するために許可されたメディアサーバー場合は、許可されたが、無関係なクライアントは、悪意を持って、既存のセッションおよび記録に自分自身を添付することができたり、参加者の知識や同意なしに会話をタップします。
Participants give implicit authorization to their applications by virtue of the INVITE to the application. However, there is no trust, explicit or implicit, between the users of one service and a distinct client of another service.
参加者は、アプリケーションにINVITEのおかげで自分のアプリケーションへの暗黙的な許可を与えます。しかし、一つのサービスのユーザーと他のサービスの個別のクライアントの間で明示的または暗黙的な信頼関係は、ありません。
All MSCML messages are sent within an INVITE-created SIP dialog. As a result, it would be difficult for an entity other than the original requestor to interfere with an established MSCML session, as this would require detailed information on the dialog state. This allows multiple applications to utilize the resources of a single media server simultaneously without interfering with one another.
すべてのMSCMLメッセージは、INVITEが作成したSIPダイアログ内で送信されます。これは、対話状態に関する詳細な情報を必要とする結果として、それは、確立されたMSCMLセッションを妨害するために、元の要求者以外のエンティティのために困難であろう。これは、複数のアプリケーションが同時にお互いに干渉することなく、単一のメディア・サーバのリソースを利用することができます。
Because of the sensitive nature of collected data, such as credit card numbers or other identifying information, the media server MUST support sips: and TLS. Clients, who presumably know the value of the information they collect, as well as the privacy expectations of their users, are free to use clear text signaling or encrypted secure signaling, depending on the application's needs. Likewise, the media server SHOULD support Secure Realtime Transport Protocol (SRTP) [9]. Again, the clients are free to negotiate the appropriate level of media security.
TLS：ので、クレジットカード番号やその他の識別情報として収集されたデータの機密性のため、メディアサーバは、SIPをサポートしなければなりません。おそらく、彼らが収集した情報の価値、並びにその利用者のプライバシーの期待を知っているクライアントは、アプリケーションのニーズに応じて、クリアテキストのシグナリングまたは暗号化されたセキュアシグナリングを自由に使用できます。同様に、メディアサーバは、SRTP（Secure Realtime Transport Protocol）をサポートすべきである[9]。ここでも、クライアントは、メディアセキュリティの適切なレベルを交渉するのは自由です。
The media management facilities of MSCML, such as the <managecontent> (Section 8) request, assume a trust relationship between the media server and file server. This scenario is similar to the one addressed by URLAUTH [20]. Namely, the media server is acting on behalf of a given user, yet the media server does not have credentials for that user. One might be tempted to use the user:pass facility of the HTTP URI to offer per-user security, but that also requires that the media server be secure, as the media server would need to know the user credentials in a form that is easily compromised (clear text passwords).
こうした<managecontent>（8節）要求としてMSCMLのメディア管理機能は、メディアサーバとファイルサーバ間の信頼関係を前提としています。このシナリオでは、URLAUTH [20]によって対処ものと同様です。すなわち、メディアサーバは、特定のユーザーに代わって行動している、まだメディアサーバーは、そのユーザーの資格情報を持っていません。一つは、ユーザーを使用するように誘惑される可能性があります：ユーザごとのセキュリティを提供するためにHTTP URIのパス機能を、それはまた、メディアサーバーが簡単である形式でユーザーの資格情報を知っておく必要があるだろうとして、メディアサーバは、安全であることが必要です妥協（クリアテキストのパスワード）。
The IETF is investigating methods for providing per-user or per-instance authorization of third-party http writing, as is needed for other protocols as well, such as WEBDAV [21]. However, until that work is completed, media server implementations MUST be prepared to authenticate themselves to file and web servers using appropriate authentication means. At a minimum, the media server MUST support HTTPS basic authentication. Implementers should note that the media server will need to respond appropriately to whatever authentication mechanism the file server requires.
IETFは、WEBDAV [21]と同様に他のプロトコルに必要とされるように、サード・パーティのHTTP書き込みのユーザごと、またはインスタンスごとの認証を提供するための方法を、調査しています。その作業が完了するまでは、メディアサーバの実装は、適切な認証手段を使用してファイルサーバーやWebために自分自身を認証するために準備しなければなりません。最低でも、メディアサーバは、HTTPS基本認証をサポートしなければなりません。実装者は、メディアサーバがファイルサーバが必要とするものは何でも認証メカニズムに適切に対応する必要があることに注意しなければなりません。
As this is an XML markup, all the security considerations of RFC 3023 [8] apply.
これはXMLマークアップ、RFC 3023のすべてのセキュリティ上の考慮事項であるとして、[8]適用されます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[2]バーガー、E.、ヴァン・ダイク、J.、およびA.スピッツァー、 "SIPを使用した基本的なネットワークメディアサービス"、RFC 4240、2005年12月。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[5] "Network call signalling protocol for the delivery of time-critical services over cable television networks using cable modems", ITU-T J.162, March 2001.
[5]、ITU-T J.162、2001年3月「ネットワークコールがケーブルモデムを使用して、ケーブルテレビネットワーク上のタイムクリティカルなサービスの提供のためのシグナリングプロトコル」。
[6] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[6]グローブ、C.、パンタレオ、M.、アンダーソン、T.、およびT.テイラー、 "ゲートウェイ制御プロトコルバージョン1"、RFC 3525、2003年6月。
[7] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.
[7]トンプソン、H.、ブナ、D.、マロニー、M.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、W3C REC REC-XMLSCHEMA-1から20010502、2001年5月。
[8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[8]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[9] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[10] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[10]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[11] Carter, J., Danielsen, P., Hunt, A., Ferrans, J., Lucas, B., Porter, B., Rehor, K., Tryphonas, S., McGlashan, S., and D. Burnett, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C REC REC-voicexml20-20040316, March 2004.
[11]カーター、J.、Danielsen、P.、ハント、A.、Ferrans、J.、ルーカス、B.、ポーター、B.、Rehor、K.、Tryphonas、S.、McGlashan、S.、およびD 。バーネット、 "音声拡張マークアップ言語（VoiceXMLの）バージョン2.0"、W3C REC REC-voicexml20-20040316、2004年3月。
[12] International Packet Communications Consortium, "IPCC Reference Architecture V2", June 2002.
[12]国際パケット通信コンソーシアム、 "IPCCリファレンスアーキテクチャV2"、2002年6月。
[13] European Telecommunications Standards Institute, "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 23.228 version 7.2.0 Release 7)", December 2005.
[13]欧州電気通信標準化協会、 "デジタルセルラー通信システム（フェーズ2+）;汎用移動通信システム（UMTS）、IPマルチメディアサブシステム（IMS）;ステージ2（3GPP TS 23.228バージョン7.2.0リリース7）"、12月2005。
[14] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[14]ホレンベック、S.、ローズ、M.、およびL. Masinter、 "IETFプロトコル内で拡張マークアップ言語（XML）の使用のためのガイドライン"、BCP 70、RFC 3470、2003年1月。
[15] Jacobs, I., Lie, H., Bos, B., and C. Lilley, "Cascading Style Sheets, level 2 (CSS2) Specification", W3C REC REC-CSS2- 19980512, May 1998.
[15]ジェイコブス、I.、リー、H.、BOS、B.、およびC.リリー、 "カスケーディングスタイルシート、レベル2（CSS2）仕様"、W3C REC REC-CSS2- 19980512、1998年5月。
[16] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[16]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、RFC 4575、2006年8月。
[17] Cable Television Laboratories, Inc., "Audio Server Protocol", January 2005.
[17]ケーブルテレビラボラトリーズ社、「オーディオサーバプロトコル」、2005年1月。
[18] "Procedures for document facsimile transmission in the general switched telephone network", Recommendation T.30, April 1999.
[18]、勧告T.30、1999年4月「一般に文書のファクシミリ送信のための手順は、交換電話網」。
[19] "Procedures for real-time Group 3 facsimile communication over IP networks", Recommendation T.38, March 2002.
[19]、勧告T.38、2002年3月「IPネットワーク上のリアルタイムグループ3ファクシミリ通信のための手順」。
[20] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[20]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - URLAUTH拡張"、RFC 4467、2006年5月。
[21] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[21] Dusseault、L.、エド。、RFC 4918、2007年6月 "Web分散オーサリングとバージョン管理（WebDAV）のためのHTTP拡張機能"。
[22] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: Base Definitions, Chapter 9", IEEE Standard 1003.1, June 2001.
[22]電気電子技術者協会、 "情報技術 - ポータブルオペレーティングシステムインタフェース（POSIX） - パート1：基本の定義は、第9章" IEEE標準1003.1、2001年6月。
[23] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[23]バーガー、E.およびM.ドリー、 "Aセッション開始プロトコル（SIP）キーを押して刺激のためのイベントパッケージ（KPML）"、RFC 4730、2006年11月。
[24] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[24] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[25] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol", Work in Progress, February 2007.
[25]キャンベル、B.、エド。、マーイ、R.、エド。、およびC.ジェニングス、エド。、 "メッセージセッションリレープロトコル"、進歩、2007年2月での作業。
URIs
URI
[26] <http://www.ietf.org/html.charters/sip-charter.html>
「２６」 ＜ｈっｔｐ：／／ｗっｗ。いえｔｆ。おｒｇ／ｈｔｍｌ。ちゃｒてｒｓ／しｐーちゃｒてｒ。ｈｔｍｌ＞
[27] <http://www.ietf.org/html.charters/sipping-charter.html>
「２７」 ＜ｈっｔｐ：／／ｗっｗ。いえｔｆ。おｒｇ／ｈｔｍｌ。ちゃｒてｒｓ／しっぴんｇーちゃｒてｒ。ｈｔｍｌ＞
[28] <http://www.ietf.org/html.charters/mmusic.html>
「２８」 ＜ｈっｔｐ：／／ｗっｗ。いえｔｆ。おｒｇ／ｈｔｍｌ。ちゃｒてｒｓ／っむしｃ。ｈｔｍｌ＞
[29] <http://www.ietf.org/html.charters/xcon-charter.html>
「２９」 ＜ｈっｔｐ：／／ｗっｗ。いえｔｆ。おｒｇ／ｈｔｍｌ。ちゃｒてｒｓ／ｘこんーちゃｒてｒ。ｈｔｍｌ＞
[30] <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>
「３０」 ＜ｈっｔｐ：／／ｗっｗ。３ｇっｐ。おｒｇ／ｆｔｐ／Ｓぺｃｓ／ｈｔｍｌーいんふぉ／２３２２８。ｈｔｍ＞
[31] <mailto:eburger@cantata.com>
[31] <のmailto：eburger@cantata.com>
Appendix A. Regex Grammar Syntax
付録A.正規表現文法の構文
The regular expression syntax used in MSCML is a telephony-oriented subset of POSIX Extended Regular Expressions (ERE) [22] termed Digit REGular EXpression (DRegex). This syntax was first described in KPML [23].
MSCMLで使用される正規表現構文は、POSIX拡張正規表現（ERE）の電話指向サブセットである[22]桁正規表現（DRegex）と呼ばれます。この構文は、最初KPML [23]に記載されました。
DRegex includes ordinary characters, special characters, bracket expressions, and interval expressions. These entities are defined in the list below.
DRegexは通常の文字、特殊文字、ブラケット表現、および間隔の表現が含まれています。これらのエンティティは、以下のリストに定義されています。
. matches digits 0-9, *, #, and A-D (case insensitive) * matches the * character # matches the # character [character selector] matches any character in selector [range1-range2] matches any character in range from range1 to range2, inclusive x matches any digit 0-9 {m} matches m repetitions of the previous pattern {m,} matches m or more repetitions of the previous pattern {,n} matches at most n (including zero) repetitions of the previous pattern {m,n} at least m and at most n repetitions of the previous pattern L the presence of 'L' in any regex expression causes the media server to enable "long" digit detection mode. See Section 7.1 for the definition of "long" digits.
。一致する数字0-9、*、＃、およびAD（大文字と小文字を区別しない）* *は文字＃は、＃文字[文字選択]がセレクタ内の任意の文字と一致一致一致[範囲1、範囲2]は、範囲1からRange2の範囲内の任意の文字にマッチします包括Xは任意の数字0-9 {M}は、前のパターン{M}前のパターンのM回以上の繰り返しに一致するm個の繰り返しに一致する一致{N}（ゼロを含む）最もNに一致する前パターン{Mの繰り返し、n}は少なくともMと前パターンLの最大n回の繰り返しで、任意の正規表現式の「L」の存在は、「長い」デジット検出モードを有効にするために、メディアサーバを引き起こします。 「長い」の数字の定義については、セクション7.1を参照してください。
Table 7 illustrates DRegex usage through examples.
表7に、実施例を介してDRegexの使用を示します。
+--------------+--------------------------------------------+
| Example | Description |
+--------------+--------------------------------------------+
| 1 | Matches the digit 1 |
| [179] | Matches 1, 7, or 9 |
| [2-9] | Matches 2, 3, 4, 5, 6, 7, 8, 9 |
| [02-46-9A-D] | Matches 0, 2, 3, 4, 6, 7, 8, 9, A, B, C, D |
| x | Matches 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 |
| . | Matches 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B,|
| | C, D, #, * |
| *6[179#] | Matches *61, *67, *69, or *6# |
| x{10} | Ten digits (0-9) |
| 011x{7,15} | 011 followed by seven to fifteen digits |
| L* | Long star |
+--------------+--------------------------------------------+
Table 7: DRegex Examples
表7：DRegex例
Appendix B. Contributors
付録B.協力者
Jeff Van Dyke and Andy Spitzer did the concept, development, documentation, and execution for MSCML at SnowShore Networks, Inc., which is now part of Cantata Technology, Inc. Andy Spitzer's original work at The Telephone Connection, Inc., influenced the IVR implementation. Mary Ann Leekley implemented the personalized mix feature and several other enhancements.
ジェフ・ヴァン・ダイクとアンディスピッツァーは、コンセプト、開発、ドキュメンテーション、そして今カンタータテクノロジー、電話接続、Inc.の株式会社アンディスピッツァーのオリジナル作品の一部であるSnowShoreネットワークス、でMSCMLの実行をしたIVRに影響を与えました実装。メアリー・アンLeekleyは、パーソナライズされたミックス機能や他のいくつかの機能強化を実施しました。
Cliff Schornak of Commetrex and Jeff Van Dyke developed the facsimile service.
CommetrexのクリフSchornakとジェフ・ヴァン・ダイクは、ファクシミリサービスを開発しました。
Jai Cauvet, Rolando Herrero, Srinivas Motamarri, and Ashish Patel contributed greatly by testing MSCML.
JAI Cauvet、ローランドエレーロ、スリニバスMotamarri、及びアシシュパテルはMSCMLを試験することにより大きく貢献しました。
Appendix C. Acknowledgements
付録C.謝辞
The following individuals provided valuable assistance in the direction, development, or debugging of MSCML:
以下の個人はMSCMLの方向、開発、またはデバッグに貴重な支援を提供します：
o Brian Badger and Phil Crable from Verizon Business o Stephane Bastien from BroadSoft o Peter Danielsen of Lucent Technologies o Kevin Flemming, formerly of SnowShore Networks, Inc. o Wesley Hicks and Ravindra Kabre, formerly from Sonus Networks o Jon Hinckley from SkyWave/Sestro o Terence Lobo, formerly of SnowShore Networks, Inc. o Kunal Nawale, formerly of SnowShore Networks, Inc. o Edwina Nowicki, formerly of SnowShore Networks, Inc. o Diana Rawlins and Sharadha Vijay, formerly of WorldCom o Gaurav Srivastva and Subhash Verma from BayPackets o Kevin Summers from Sonus Networks o Tim Wong from at&t
SkyWave / Sestro Oからジョン・ヒンクリーO旧ソナス・ネットワークからのウェスリー・ヒックスとラビンドラKabre O以前SnowShoreネットワークス社のケビン・フレミングOルーセント・テクノロジーズのピーターDanielsen O BroadSoftにからステファン・バスティアンOベライゾンビジネスからOブライアン・バジャーとフィル・Crable、 BayPacketsからのGaurav Srivastvaとサブハッシュ・バーマO旧ワールドコムのダイアナローリンズとSharadhaビジェイO以前SnowShoreネットワークス株式会社のエドウィナNowicki O以前SnowShoreネットワークス株式会社のクナルNawale O以前SnowShoreネットワークス株式会社のテレンス・ロボ、、、、 AT＆Tからのティム・ウォンOソナス・ネットワークからOケビン・サマーズ
The authors would like to thank Cullen Jennings and Dan Wing from Cisco Systems for their helpful review comments.
作者は彼らの役に立つレビューコメントのために、シスコシステムズからカレン・ジェニングスとダン・ウィングに感謝したいと思います。
The authors would also like to thank Scotty Farber for applying her technical writing expertise to the documentation of MSCML.
著者らはまた、MSCMLのドキュメントを彼女のテクニカルライティングの専門知識を適用するためのスコッティファーバーに感謝したいと思います。
Authors' Addresses
著者のアドレス
Jeff Van Dyke Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
ジェフ・ヴァン・ダイクカンタータ・テクノロジー社18 Keewaydin博士セーラム、NH 03079 USA
EMail: jvandyke@cantata.com
メールアドレス：jvandyke@cantata.com
Eric Burger (editor) BEA Systems, Inc. USA
エリック・バーガー（編集者）BEA Systems、Inc.の米国
Email: eburger@standardstrack.com URI: http://www.standardstrack.com
メール：eburger@standardstrack.com URI：http://www.standardstrack.com
Andy Spitzer Bluesocket Inc. 10 North Avenue Burlington, MA 01803 USA
アンディスピッツァーBluesocket株式会社10ノースアベニューバーリントン、MA 01803 USA
EMail: woof@pingtel.com
メールアドレス：woof@pingtel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。