[要約] RFC 5022は、メディアサーバーの制御に使用されるMSCMLとプロトコルに関する標準仕様です。このRFCの目的は、メディアサーバーの制御を容易にするための統一されたマークアップ言語とプロトコルを提供することです。
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
メディアサーバー制御マークアップ言語（MSCML）とプロトコル
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、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）は、SIPと組み合わせて使用されるマークアップ言語で、高度な会議とインタラクティブな音声応答（IVR）関数を提供します。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）とその使用について説明します。標準のSIP招待状と情報方法、およびこれらのペイロードが実装する機能を使用して、メディアサーバーに送信できるペイロードについて説明しています。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 [2]に記載されているような基本的なSIPコンストラクトは、シンプルなNウェイ会議をうまく提供しています。SIP URIは、特定のSIP会議を識別するための自然なメカニズムを提供しますが、招待状とさようならの方法は、会議の参加と去りのセマンティクスをエレガントに実装します。ただし、拡張された会議アプリケーションでは、サイジングとサイズ変更、会議内の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機能には2つの広範なクラスがあります。ファーストクラスには、会議の構成、参加者の脚の操作、会議イベントの報告など、上級会議のためのプリミティブが含まれます。2番目のクラスは、インタラクティブな音声応答（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 UACSがメディアサーバーと直接シグナル伝達関係を持つことはありそうもないが、禁止されていない。「クライアント」という用語は、このドキュメントで使用され、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が構築するMSCMLおよびRFC 4240 [2]は、アプリケーションロジックとMRF間の相互作用をサポートするメディアリソース（MR）インターフェイスに特に焦点を当てています。
This document describes a working framework and protocol with which there is considerable implementation experience. Application developers and service providers have created several MSCML-based services since the availability of the initial version in 2001. This experience is highly relevant to the ongoing work of the IETF, particularly the SIP [26], SIPPING [27], MMUSIC [28], and XCON [29] work groups, the IMS [30] work in 3GPP, and the CCXML work in the Voice Browser Work Group of the W3C.
このドキュメントでは、実装エクスペリエンスがかなりある作業フレームワークとプロトコルについて説明しています。アプリケーション開発者とサービスプロバイダーは、2001年の初期バージョンの可用性以来、いくつかのMSCMLベースのサービスを作成しています。この経験は、IETF、特にSIP [26]、Sippe [27]、MMUSIC [28]の進行中の作業に非常に関連しています。]、およびXCON [29]ワークグループ、IMS [30]は3GPPで機能し、CCXMLはW3Cの音声ブラウザワークグループで動作します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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招待状または情報リクエストのいずれかで運ばれる場合があります。強化された会議を作成する最初の招待状には、MSCMLペイロードが含まれる場合があります。その後の同じリクエストに招待された招待は、参加者の脚に参加します。これには、MSCMLペイロードが含まれる場合があります。IVRセッションを確立する最初の招待状には、MSCMLペイロードを含めてはなりません。クライアントは、SIP情報リクエストを介して会議と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招待リクエストは、会議シナリオで頻繁に使用されます。したがって、メディアサーバーは、SIP InviteリクエストでMIMEタイプ「MultiPart/Mixed」を使用してメッセージ本文をサポートする必要があります。
The media server transports MSCML responses in the final response to the SIP INVITE containing the matching MSCML request or in a SIP INFO message. The only allowable final response to a SIP INFO containing a message body is a 200 OK, per RFC 2976 [3]. Therefore, if the client sends the MSCML request via SIP INFO, the media server responds with the MSCML response in a separate INFO request. In general, these responses are asynchronous in nature and require a separate transaction due to timing considerations.
メディアサーバーは、一致するMSCML要求を含むSIP招待に対する最終的な応答またはSIP情報メッセージにMSCML応答を輸送します。メッセージ本文を含むSIP情報に対する唯一の許容最終応答は、RFC 2976 [3]ごとに200 OKです。したがって、クライアントがSIP情報を介してMSCML要求を送信すると、メディアサーバーは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情報方法の使用についてかなりの議論がありました。私たちの経験は、MSCMLがそれなしでは不可能だったということです。最初のMSCML仕様が公開された時点で、最初のSIPイベント通知ドラフトが個別の提出物として提出されたばかりでした。当時、購読/通知を既存のダイアログにリンクするメカニズムはありませんでした。これにより、すべてのイベントが招待されたダイアログで発生したため、MSCMLでの使用が妨げられました。また、Subscribe/Notifyは会議イベントの報告に適していましたが、そのセマンティクスは、唯一の「イベント」がリクエストの成功または失敗であった参加者の脚または会議の設定を変更するのに不適切と思われました。最後に、SIP情報は確立された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での使用に適していない追加の理由が提供されています。購読の使用は2つの問題を示します。1つ目はセマンティックです。サブスクライブの目的は、ユーザーエージェントの状態に関心を登録することです。ただし、MSCMLのサブスクライブを使用して、ユーザーエージェントの状態を変更するサブスクライブが表示されます。サブスクライブが適切でない2番目の理由は、MSCMLが本質的にコールベースであるためです。SIPダイアログとコールレッグとの関連は、MSCMLが非常に簡単であることを意味します。
For example, if one used SUBSCRIBE or other SIP method to send commands about some context, one must identify that context somehow. Relating commands to the SIP dialog they arrive on defines the context for free. Moreover, it is conceptually easy for the developer. Using NOTIFY to transport MSCML responses is also not appropriate, as the NOTIFY would be in response to an implicit subscription. The SIP and SIPPING lists have discussed the dangers of implicit subscription.
たとえば、サブスクライブまたは他のSIPメソッドを使用して、コンテキストに関するコマンドを送信する場合、そのコンテキストを何らかの形で特定する必要があります。コマンドをSIPダイアログに関連付けます。彼らは到着し、コンテキストを無料で定義します。さらに、開発者にとって概念的に簡単です。NotifyはMSCML応答を輸送するために使用することも適切ではありません。Notifyは暗黙のサブスクリプションに応答します。SIPとすすりのリストは、暗黙のサブスクリプションの危険性について議論しています。
In order to guarantee interoperability with this specification, as well as with SIP User Agents that are unaware of MSCML, SIP UACs that wish to use MSCML services MUST specify a service indicator that supports MSCML in the initial INVITE. RFC 4240 [2] defines the service indicator "conf", which MUST be used for MSCML conferencing applications. The service indicator "ivr" MUST be used for MSCML interactive voice response applications. In this specification, only "conf" and "ivr" are described.
この仕様とMSCMLに気付いていないSIPユーザーエージェントとの相互運用性を保証するために、MSCMLサービスを使用したいSIP UACは、最初の招待でMSCMLをサポートするサービスインジケーターを指定する必要があります。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.
メディアサーバーは、メディアサーバーに既存のダイアログでさようならを送信し、目的のサービスへの招待状で新しいダイアログを確立することにより、サービス間で通話の移動をサポートする必要があります。メディアサーバーは、以前に確立されたSDPパラメーターの変更を必要とせずに、サービス間の移動をサポートする必要があります。これは、クライアントが望む新しいサービスを指定するためにリクエスト-URIが変更される既存のダイアログに再インベンタルを送信することによって達成されます。これにより、クライアントが発信者またはゲートウェイに招待を送信して、新しいSDPパラメーターを確立する必要性がなくなります。
The media server, as a SIP UAS, MUST respond appropriately to an INVITE that contains an MSCML body. If MSCML is not supported, the media server MUST generate a 415 final response and include a list of the supported content types in the response per RFC 3261 [4]. The media server MUST also advertise its support of MSCML in responses to OPTIONS requests, by including "application/mediaservercontrol+xml" as a supported content type in an Accept header. This alleviates the major issues with using INFO for the transport of application data; namely, the User Agent's proper interpretation of what is, by design, an opaque message request.
SIP UASとしてのメディアサーバーは、MSCMLボディを含む招待に適切に対応する必要があります。MSCMLがサポートされていない場合、メディアサーバーは415の最終応答を生成し、RFC 3261 [4]ごとに応答にサポートされているコンテンツタイプのリストを含める必要があります。メディアサーバーは、「アプリケーション/MediaServerControl XML」を受け入れヘッダーにサポートされているコンテンツタイプとして含めることにより、オプションリクエストへの応答でMSCMLのサポートを宣伝する必要があります。これは、アプリケーションデータの輸送に情報を使用することに関する主要な問題を軽減します。つまり、ユーザーエージェントの適切な解釈は、設計上、不透明なメッセージリクエストです。
To avoid undue complexity, MSCML establishes two rules regarding its usage. The first is that only one MSCML body may be present in a SIP request. The second is that each MSCML body may contain only one request or response. This greatly simplifies transaction management. MSCML syntax does provide for the unique identification of multiple requests in a single body part. However, this is not supported in this specification.
過度の複雑さを避けるために、MSCMLはその使用に関する2つのルールを確立します。1つ目は、SIPリクエストに1つのMSCMLボディのみが存在する可能性があることです。2つ目は、各MSCML本文には1つのリクエストまたは応答のみが含まれている可能性があることです。これにより、トランザクション管理が大幅に簡素化されます。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つの主要な要素ツリーにマッピングします：<question>、<response>、および<通知>。
Figure 1 shows a request body. Depending on the command, one can send the request in an INVITE or an INFO. Figure 2 shows a response body. The SIP INFO method transports response bodies. Figure 3 shows a notification body. The SIP INFO method transports notifications.
図1は、リクエスト本体を示しています。コマンドに応じて、招待状または情報でリクエストを送信できます。図2は、応答本体を示しています。SIP情報メソッドは応答本体を輸送します。図3は通知本体を示しています。SIP情報メソッドは通知を輸送します。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
... request body ...
</request>
</MediaServerControl>
Figure 1: MSCML Request Format
図1：MSCML要求形式
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<response>
... response body ...
</response>
</MediaServerControl>
Figure 2: MSCML Response Format
図2：MSCML応答形式
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<notification>
... notification body ...
</notification>
</MediaServerControl>
Figure 3: MSCML Notification Format
図3：MSCML通知形式
MSCML requests MAY include a client-defined ID attribute for the purposes of matching requests and responses. The values used for these IDs need only be unique within the scope of the dialog in which the requests are issued.
MSCMLリクエストには、リクエストと応答を一致させる目的で、クライアント定義のID属性が含まれる場合があります。これらのIDに使用される値は、リクエストが発行されるダイアログの範囲内でのみ一意である必要があります。
In the philosophy of XML as a text-based description language, and not as a programming language, MSCML makes the choice of many attribute values for readability by a human. Thus, many attributes that would often be "boolean" instead take "yes" or "no" values. For example, what does 'report="false"' or 'report="1"' mean? However, 'report="yes"' is clearer: I want a report. Some programmers prefer the precision of a boolean. To satisfy both styles, MSCML defines an XML type, "yesnoType", that takes on the values "yes" and "no" as well as "true", "false", "1", and "0".
MSCMLは、プログラミング言語としてではなく、テキストベースの説明言語としてのXMLの哲学で、人間による読みやすさのために多くの属性値を選択します。したがって、しばしば「ブール」である多くの属性は、代わりに「はい」または「いいえ」値を取得します。たとえば、 'Report = "false"'または 'Report = "1"'は何を意味しますか？ただし、「レポート=「はい」」は明確です。レポートが必要です。一部のプログラマーは、ブール波の精度を好む。両方のスタイルを満たすために、MSCMLはXMLタイプ「YESNOTYPE」を定義します。「YESNOTYPE」は、「はい」と「いいえ」、および「True」、「false」、「1」、および「0」を帯びます。
Many attributes in the MSCML schema have default values. In order to limit demands on the XML parser, MSCML applies these values at the protocol, not XML, level. The MSCML schema documents these defaults as XML annotations to the appropriate attribute.
MSCMLスキーマの多くの属性にはデフォルト値があります。XMLパーサーの要求を制限するために、MSCMLはXMLレベルではなくプロトコルにこれらの値を適用します。MSCMLスキーマは、これらのデフォルトを適切な属性へのXMLアノテーションとして文書化します。
For clarity, time values in MSCML are based on the time designations described in the Cascading Style Sheets level 2 (CSS2) Specification [15]. Their format consists of a number immediately followed by an optional time unit identifier of the following form:
明確にするために、MSCMLの時間値は、カスケードスタイルのシートレベル2（CSS2）仕様[15]に記載されている時間指定に基づいています。それらの形式は、次のフォームのオプションのタイムユニット識別子がすぐに続く数字で構成されます。
ms: milliseconds (default) s: seconds
MS：Milliseconds（デフォルト）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.
時間単位識別子が存在しない場合、値はミリ秒であると解釈する必要があります。[15] MSCMLへの拡張により、文字列値が「即時」と「無限」を値すると、特定のタイマーに特別な意味があります。
The advanced conferencing model is a star controller model, with both signaling and media directed to a central location. Figure 4 depicts a typical signaling relationship between end users' UACs, a conference application server, and a media server.
高度な会議モデルはスターコントローラーモデルであり、シグナリングとメディアの両方が中央の場所に向けられています。図4は、エンドユーザーのUAC、会議アプリケーションサーバー、およびメディアサーバーの典型的なシグナル伝達関係を示しています。
RFC 4353 [10] describes this model. The application server is an instantiation of the conference focus. The media server is an instantiation of the media mixer. Note that user-level constructs, such as event notifications, are in the purview of the application server. This is why, for example, the media server sends active talker reports using MSCML notifications, while the application server would instead use the conference package [16] for individual notifications to SIP user agents. Note that we do not recommend the use of the conference package for media server to application server notifications because none of the filtering and membership information is available at the media server.
RFC 4353 [10]はこのモデルについて説明しています。アプリケーションサーバーは、会議の焦点のインスタンス化です。メディアサーバーは、メディアミキサーのインスタンス化です。イベント通知などのユーザーレベルのコンストラクトは、アプリケーションサーバーの範囲内にあることに注意してください。たとえば、メディアサーバーがMSCML通知を使用してアクティブなトーカーレポートを送信し、アプリケーションサーバーは代わりに、ユーザーエージェントをSIPするための個々の通知に会議パッケージ[16]を使用する理由です。メディアサーバーではフィルタリング情報とメンバーシップ情報が利用できないため、メディアサーバーに会議パッケージをアプリケーションサーバー通知に使用することをお勧めしないことに注意してください。
+-------+
| UAC 1 |---\ Public URI +-------------+
+-------+ \ _____________| Application |
/ / | Server | Not shown:
+-------+ / / +-------------+ RTP flows directly
| UAC 2 |---/ / | Private between UACs and
+-------+ / | URI media server
. / +--------------+
: / | |
+-------+ / | Media Server |
| UAC n |---/ | |
+-------+ +--------------+
Figure 4: Conference Model
図4：会議モデル
Each UAC sends an INVITE to a Public Conference URI. Presumably, the client publishes this URI, or it is an ad hoc URI. In any event, the client generates a Private URI, following the rules specified by RFC 4240 [2]. That is, the URI is of the following form:
各UACは、公開会議URIに招待状を送信します。おそらく、クライアントはこのURIを公開するか、それはアドホックURIです。いずれにせよ、クライアントはRFC 4240 [2]で指定されたルールに従って、プライベートURIを生成します。つまり、URIは次の形式です。
sip:conf=UniqueID@ms.example.net
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.
UniqueIDは一意の会議識別子であり、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.
RFC 4240 [2]で説明されている基本的な会議については、Conferenceを作成したMedia Serverへの最初の招待が会議を作成します。ただし、高度な会議では、最初の招待には、会議参加者のSDPではなく、MSCML <Configure_Conference>ペイロードが含まれる場合があります。<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>ペイロードを含む招待状を送信することにより、会議が作成されると、結果のSIPダイアログは「会議制御脚」と呼ばれます。この脚にはいくつかの有用な特性があります。会議の寿命は、そのコントロールレッグの寿命と同じです。これにより、すべての参加者の脚が去るか、まだ到着していない場合でも、会議が存在することが保証されます。さらに、クライアントがカンファレンスコントロールレッグを終了すると、メディアサーバーはすべての参加者の脚を自動的に終了します。会議管理の脚は、会議全体との間でのプレイまたはレコードオペレーション、およびアクティブなトーカー通知にも使用されます。完全な会議メディアオペレーションとアクティブトーカーレポートサブスクリプションは、会議管理脚で実行する必要があります。
Creation of a Conference Control Leg is RECOMMENDED because full advanced conferencing capabilities are not available without it. Clients MUST establish the Conference Control Leg in the initial INVITE that creates the conference; it cannot be created later.
カンファレンスコントロールレッグの作成が推奨されます。これは、完全な高度な会議機能が利用できないため、推奨されます。クライアントは、会議を作成する最初の招待で会議管理の脚を確立する必要があります。後で作成することはできません。
Once the client has created the conference with or without the Conference Control Leg, participants can be joined to the conference. This is achieved by the client's directing an INVITE to the Private Conference URI for each participant. Using the example conference URI given above, this would be sip:conf=UniqueID@ms.example.net.
クライアントが会議管理脚の有無にかかわらず会議を作成したら、参加者を会議に参加させることができます。これは、クライアントが各参加者のプライベートカンファレンスURIへの招待を指示することによって達成されます。上記のカンファレンスURIの例を使用して、これはsip：conf = uniqueid@ms.example.netになります。
The <configure_conference> request has two attributes that control the resources the media server sets aside for the conference. These are described in the list below.
<configure_conference>リクエストには、メディアサーバーが会議のために設定するリソースを制御する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の1st 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.
注：リザーブリステナーパラメーターを持つことは対称です。ただし、メディアサーバーの実際的な制限は、監視するミキサーのトーカーの数です。どちらの場合でも、クライアントは、ユーザーエージェントクライアントからの招待状をプロキシングするか、会議URIを提供する人に誘惑することにより、誰が会議に参加するかを規制します。
For example, to create a conference with up to 120 active talkers and the ability to play audio into the conference or record portions or all of the conference full mix, the client specifies both attributes, as shown in Figure 6.
たとえば、最大120人のアクティブなトーカーと会議のオーディオを再生する機能、または記録的な部分、またはすべてのカンファレンスフルミックスを作成するために、図6に示すように、クライアントは両方の属性を指定します。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_conference reservedtalkers="120"
reserveconfmedia="yes"/>
</request>
</MediaServerControl>
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>要求には、子<Subscribe>要素が含まれる場合があります。<購読>要素は、会議全体のアクティブトーカーイベントの通知を要求するために使用されます。アクティブなトーカーイベントに関する詳細情報は、セクション5.7に含まれています。
The client MUST include a <configure_conference> request in the initial INVITE which establishes the conference when creating the Conference Control Leg. The client server MUST issue asynchronous commands, such as <play>, separately (i.e., in INFO messages) to avoid ambiguous responses.
クライアントは、会議制御脚を作成するときに会議を確立する最初の招待状に<configure_conference>リクエストを含める必要があります。クライアントサーバーは、あいまいな応答を避けるために、<play>などの非同期コマンドを個別に（つまり、情報メッセージ）発行する必要があります。
Media operations on the Conference Control leg are performed internally, no external RTP streams are involved. Accordingly, the 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を期待していません。したがって、クライアントは、<configure_conference>ペイロードを含むInviteリクエストにSDPを送信しないか、SDPを保持する必要があります。メディアサーバーは、すべてのメディアラインが「非アクティブ」に設定されているか、接続アドレスが0.0.0.0（後方互換性のため）に設定されているSDPとして設定されている場合、SDPを扱う必要があります。
The media server sends a response when it has finished processing the <configure_conference> request. The format of the <configure_conference> response is detailed in Section 10.2.
メディアサーバーは、<configure_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つの子要素が定義されています。これらは<inuptgain>、<outputgain>、<configure_team>、および<Subscribe>です。
The first two, <inputgain> and <outputgain>, modify the gain applied to the input and output audio streams, respectively. These may contain <auto>, to use automatic gain control (AGC) or <fixed>. The <auto> element has the attributes "startlevel", "targetlevel", and "silencethreshold". All the parameters are in dB. The <fixed> element has the attribute "level", which is in dB. The default for both <inputgain> and <outputgain> is <fixed>. The media server MAY silently cap <inputgain> or <outputgain> requests that exceed the gain limits imposed by the platform.
最初の2つの<inuptgain>および<outputGain>は、それぞれ入力オーディオストリームに適用されるゲインを変更します。これらには、自動ゲインコントロール（AGC）または<固定>を使用するために<Auto>を含む場合があります。<auto>要素には、「startlevel」、「ターゲットレベル」、「サイレンセットレベル」の属性があります。すべてのパラメーターはdbにあります。<fixed>要素には、dbにある属性「レベル」があります。<inuptgain>と<OutputGain>の両方のデフォルトは<Xix>です。メディアサーバーは、プラットフォームによって課されるゲイン制限を超える<inuptgain>または<EutputGain>要求を静かにcaplyに制限する場合があります。
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は出力ゲインの操作も可能にします。<play>などのIVRコマンドの一部は、コンテンツ再生操作の出力ゲインを制御できるようにします。会議出力ゲインとIVR再生ゲインコントロールの相互作用は、セクション6.1.1で説明されています。<inuptgain>および<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.
クライアントが会議に参加することを望んでいる脚に対してデフォルトのパラメーターが許容される場合、MSCMLボディのない通常のSIP招待で十分です。ただし、クライアントが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情報を発行することにより、会議中に会議の脚パラメーターを変更できます。もちろん、クライアントは情報メッセージで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リクエストを発行することにより、会議のすべての脚を終了できます。メディアサーバーがカンファレンスコントロールレッグでSIP Byeリクエストを受け取ったときに1人以上の参加者がまだ会議に参加している場合、メディアサーバーは、残りのすべての会議の脚のSIPバイリクエストを発行して、足のクリーンアップを確保します。
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.
メディアサーバーは、他の脚にさようならリクエストを送信するため、SIP Byeリクエストに200 OKを返します。これは、非インバイトの要求に対する暫定的な応答を発行できないためですが、他の脚の分裂は元のリクエストの再送信タイマーの制限を超える可能性があるためです。会議がクリーンアップされている間、メディアサーバーは、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>
Figure 7: Full Conference Audio Command - Play
図7：完全な会議オーディオコマンド - 再生
A client can modify a leg by issuing an INFO on the dialog associated with the participant leg. For example, Figure 8 mutes a conference leg.
クライアントは、参加者レッグに関連付けられたダイアログに関する情報を発行することにより、脚を変更できます。たとえば、図8は会議の脚をミュートします。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_leg mixmode="mute"/>
</request>
</MediaServerControl>
Figure 8: Sample Change Leg Command 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.
図8：サンプル変更脚のコマンド図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".
プロンプトコンテンツ（ 'Prosturl'属性または<prompt>要素）を使用して、IVRコマンドの発行の前に、参加者の脚をMixMode = "Parked"で構成する必要があります。脚の駐車場は、参加者の入力と出力メディアを会議から分離し、それらのストリームを再生および記録するために使用することを許可します。ただし、桁の収集または録音が必要な場合、ミックスモードは効果がありません。<PlayCollect>および<PlayRecord>プロンプトコンテンツのないリクエストは、MixMode = "Parked"を設定せずに参加者の脚に送信できます。
MSCML-controlled advanced conferences, as well as RFC 4240 [2] controlled basic conferences, implicitly support video conferencing in the form of video switching. In video switching, the video stream of the loudest talker (with some hysteresis) is sent to all participants other than that talker. The loudest talker receives the video stream from the immediately prior loudest talker.
MSCML制御の上級会議、およびRFC 4240 [2]は基本的な会議を管理し、ビデオ交換の形でビデオ会議を暗黙的にサポートしています。ビデオスイッチングでは、最も大きな話者のビデオストリーム（いくつかのヒステリシスを含む）が、その話者以外のすべての参加者に送信されます。最も騒々しい話者は、すぐに最適な最も大きな話者からビデオストリームを受け取ります。
Media servers MUST ensure that participants receive video media compatible with their session. For example, a participant who has established an H.263 video stream will not receive video from another participant employing H.264 media. Media servers SHOULD implement video transcoding to minimize media incompatibilities between participants.
メディアサーバーは、参加者がセッションと互換性のあるビデオメディアを確実に受信できるようにする必要があります。たとえば、H.263ビデオストリームを確立した参加者は、H.264メディアを採用している別の参加者からビデオを受け取りません。メディアサーバーは、参加者間のメディアの互換性を最小限に抑えるために、ビデオトランスコーディングを実装する必要があります。
The media server MUST switch video streams only when it receives a refresh video frame. A refresh frame contains all the video information required to decode that frame (i.e., there is no dependency on data from previous video frames).
メディアサーバーは、更新ビデオフレームを受信した場合にのみビデオストリームを切り替える必要があります。更新フレームには、そのフレームをデコードするために必要なすべてのビデオ情報が含まれています（つまり、以前のビデオフレームからのデータに依存しません）。
Refresh frames are large and generally sent infrequently to conserve network bandwidth. The media server MUST implement standard mechanisms to request that the new loudest talker's video encoder transmits a refresh frame to ensure that video can be switched quickly.
更新フレームは大きく、一般にネットワークの帯域幅を節約するためにまれに送られます。メディアサーバーは、標準のメカニズムを実装して、新しい大音量のトーカーのビデオエンコーダーが更新フレームを送信して、ビデオをすばやく切り替えることができるようにする必要があります。
A client can subscribe for periodic active talker event reports that indicate which participants are included in the conference mix. As these are conference-level events, the subscription and notifications are sent on the Conference Control Leg.
クライアントは、会議ミックスに含まれている参加者を示す定期的なアクティブなトーカーイベントレポートを購読できます。これらは会議レベルのイベントであるため、サブスクリプションと通知は会議管理脚に送信されます。
Media servers MAY impose limits on the minimum interval for active talker reports for performance reasons. If the client request is below the imposed minimum, the media server SHOULD set the interval to the minimum value supported. To limit unnecessary notification traffic, the media server SHOULD NOT send a report if the active talker information for the conference has not changed during the reporting interval.
メディアサーバーは、パフォーマンス上の理由でアクティブなトーカーレポートの最小間隔に制限を課す場合があります。クライアント要求が課された最小値を下回っている場合、メディアサーバーは間隔をサポートされている最小値に設定する必要があります。不必要な通知トラフィックを制限するために、メディアサーバーは、レポート間隔中に会議のアクティブなトーカー情報が変更されていない場合、レポートを送信する必要はありません。
A request for an active talker report is in Figure 9. The active talker report enumerates the current call legs in the mix.
アクティブなトーカーレポートのリクエストは図9にあります。アクティブなトーカーレポートは、ミックス内の現在のコール脚を列挙しています。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_conference>
<subscribe>
<events>
<activetalkers report="yes" interval="60s"/>
</events>
</subscribe>
</configure_conference>
</request>
</MediaServerControl>
Figure 9: Active Talker Request
図9：アクティブなトーカーのリクエスト
Event notifications are sent in SIP INFO messages. Figure 10 shows an example of a report.
イベント通知は、SIP情報メッセージで送信されます。図10は、レポートの例を示しています。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<notification>
<conference uniqueid="ab34h76z" numtalkers="47">
<activetalkers>
<talker callid="myhost4sn123"/>
<talker callid="myhost2sn456"/>
<talker callid="myhost12sn78"/>
</activetalkers>
</conference>
</notification>
</MediaServerControl>
Figure 10: Active Talker Event Example
図10：アクティブなトーカーイベントの例
The value of the "callid" attribute in the <talker> element corresponds to the value of the SIP Call-ID header of the associated dialog. This enables the client to associate the active talker with a specific participant leg.
<talker>要素の「callid」属性の値は、関連するダイアログのSIPコールIDヘッダーの値に対応します。これにより、クライアントはアクティブなトーカーを特定の参加者レッグに関連付けることができます。
MSCML enables clients to create personalized mixes through the <configure_team> element for scenarios where the standard mixmode settings do not provide sufficient control. The <configure_team> element is a child of <configure_leg>.
MSCMLを使用すると、クライアントは、標準のミックスモード設定が十分なコントロールを提供しないシナリオの<configure_team>要素を介してパーソナライズされたミックスを作成できます。<configure_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>を使用して設定されたチームメンバー（<チームメイト>要素）のリスト
2. The mixmode attribute set through <configure_leg>
2. <configure_leg>を介して設定されたMixMode属性
The media server uses the values of these objects to determine which audio inputs to combine for output to the participant. In a normal conference, each participant hears the conference mix minus their own input if they are part of the mixed output. The team list enables the client to specify other participants that the leg can hear in addition to the normal mixed output. Note that personalized mix settings apply only to audio media and do not affect video switching.
メディアサーバーは、これらのオブジェクトの値を使用して、参加者への出力のために組み合わせるオーディオ入力を決定します。通常の会議では、各参加者は、混合出力の一部である場合、会議のミックスが自分の入力を差し引いたものを聞きます。チームリストにより、クライアントは、通常の混合出力に加えて、脚が聞こえる他の参加者を指定できます。パーソナライズされたミックス設定は、オーディオメディアにのみ適用され、ビデオの切り替えには影響しないことに注意してください。
Team relationships are implicitly symmetric. If the client sets participant A as a team member of participant B, then the media server automatically sets participant B as a team member for A.
チームの関係は暗黙的に対称です。クライアントが参加者Aを参加者Bのチームメンバーとして設定した場合、メディアサーバーは参加者BをAのチームメンバーとして自動的に設定します。
The id attribute set through <configure_leg> is used to identify the various participants. A unique ID MUST be assigned to each participant included in a personalized mix. The IDs used MUST be unique within the scope of the conference in which they appear.
<configure_leg>を介して設定されたID属性は、さまざまな参加者を識別するために使用されます。パーソナライズされたミックスに含まれる各参加者に一意のIDを割り当てる必要があります。使用されるIDは、表示される会議の範囲内で一意でなければなりません。
By itself, the team list only defines those participants that the leg can hear. The mixmode attribute of each team member determines whether to include their audio input in the personalized mix. If the client sets the teammate's mixmode to private, then it is part of the mix. If the mixmode is set to any other value, it is not.
それ自体、チームリストは、脚が聞こえる参加者のみを定義します。各チームメンバーのミックスモード属性は、パーソナライズされたミックスにオーディオ入力を含めるかどうかを決定します。クライアントがチームメイトのミックスモードをプライベートに設定する場合、それはミックスの一部です。MixModeが他の値に設定されている場合、そうではありません。
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 = "Private"を使用して
2. <configure_team>
2. <configure_team>
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.
o 招待状で、会議全体のために確立されたプロパティと異なる参加者に参加します。
o In an INFO, to change the properties for an existing leg.
o 情報では、既存の脚のプロパティを変更します。
The two attributes of the configure_team element are "id" and "action". The id attribute MUST contain the unique ID of the leg being modified, as set in the original <configure_leg> request. The action attribute can take on the values "add", "delete", "query", and "set". The default value is "query". This attribute allows the user to modify the team list. Table 1 describes the actions that can be performed on the team list.
configure_team要素の2つの属性は、「id」と「action」です。ID属性には、元の<configure_leg>リクエストに設定されているように、変更される脚の一意のIDを含める必要があります。アクション属性は、「add」、「削除」、「クエリ」、および「設定」の値を引き受けることができます。デフォルト値は「クエリ」です。この属性により、ユーザーはチームリストを変更できます。表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.
パーソナライズされたミキシングの一般的な使用は、ある参加者のコーチングを別の参加者によるコーチングをサポートすることです。コーチングシナリオには、3人の参加者が含まれます。1。エージェントをコーチする監督者。2.顧客と対話するエージェント。3.エージェントと対話する顧客。
Table 2 illustrates the details of the coached conference topology.
表2は、コーチされた会議のトポロジの詳細を示しています。
+-------------+------------+------------+---------+-----------------+
| Participant | ID | Team | Mixmode | Hears |
| | | Members | | |
+-------------+------------+------------+---------+-----------------+
| Supervisor | supervisor | Agent | Private | customer + |
| | | | | agent |
| Agent | agent | Supervisor | Full | customer + |
| | | | | supervisor |
| Customer | customer | none | Full | agent |
+-------------+------------+------------+---------+-----------------+
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. クライアントは、必要に応じて各参加者のチームメイトリストとミックスモードを構成します。
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>リクエストを含む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.
コーチレッグを会議に参加させ、<configure_leg>リクエストを含むSIP招待状を送信して、目的のプロパティを構成します。<configure_leg>要素は、脚の一意の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>
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.
会議には他の参加者がいないため、クライアントはまだコーチのチームメイトリストを構成できないことに注意してください。別の足のチームメイトとして追加する前に、参加者に参加者に参加する必要があります。
Join the agent leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to "agent" and sets the supervisor as a team member of the agent. Because team member relationships are symmetric, this action also adds the agent as a team member for the coach.
エージェントレッグを会議に参加させ、<configure_leg>リクエストを含むSIP 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>
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.
このレッグの目的のミックスモードは完全であり、デフォルト値であるため、明示的に設定する必要はありません。
Join the client leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element simply sets the leg's unique ID to "customer". The media server does not need further configuration because the desired mixmode, full, is the default and the customer has no team members.
クライアントレッグを会議に参加させ、<configure_leg>リクエストを含むSIP Inviteを送信して、目的のプロパティを構成します。<configure_leg>要素は、脚の一意のIDを「顧客」に設定するだけです。目的のMixMode（Full）がデフォルトであり、顧客にはチームメンバーがいないため、メディアサーバーはさらに構成を必要としません。
The corresponding MSCML request is as follows.
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="customer"/>
</request>
</MediaServerControl>
Figure 13: Join Client Request
図13：クライアントリクエストに参加します
Strictly speaking, it is not a requirement that the client give the customer leg a unique ID because it will not be a team member. However, when using coached conferencing, we RECOMMEND that one assign a unique ID to each leg in the initial INVITE request. Assigning a unique ID eliminates the need to set it later by sending a SIP INFO if one later desires personalized mixing for the customer leg.
厳密に言えば、それはチームメンバーではないため、クライアントが顧客の脚に一意のIDを与えることは要件ではありません。ただし、Coached Conferencingを使用する場合は、最初の招待リクエストで各レッグに一意のIDを割り当てることをお勧めします。一意のIDを割り当てることで、後で顧客脚の個別のミキシングが必要な場合にSIP情報を送信することにより、後で設定する必要がなくなります。
The conference is now in the desired configuration, shown previously in Table 2.
会議は現在、前に表2に示されている目的の構成にあります。
In the IVR model, the media server acts as a media-processing proxy for the UAC. This is particularly useful when the UAC is a media gateway or other device with limited media processing capability.
IVRモデルでは、メディアサーバーはUACのメディア処理プロキシとして機能します。これは、UACがメディアゲートウェイまたはメディア処理機能が限られている他のデバイスである場合に特に便利です。
The typical use case for MSCML is when there is an application server that is the MSCML client. The client can use the SIP Service URI concept (RFC 3087) to initiate a service. The client then uses RFC 4240 [2] to initiate a MSCML session on a media server. These relationships are shown in Figure 14.
MSCMLの典型的なユースケースは、MSCMLクライアントであるアプリケーションサーバーがある場合です。クライアントは、SIPサービスURIコンセプト（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リクエストは、<play>、<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 [2]に記載されているURI規則を使用する必要があります。次の例に示すように、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.
メディアサーバーは、情報リクエストでMSCML IVRペイロードを受け入れる必要があり、初期またはその後の招待状でMSCML IVRペイロードを受け入れてはなりません。情報方法は、招待状で発生する特定のタイミングの問題を減らし、クライアントサーバーとメディアサーバーの両方での処理が少なくなります。
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リクエストを受信している場合、別のサーバーが進行中である場合、メディアサーバーは最初の操作を停止し、新しいリクエストを実行します。メディアサーバーは、最初のリクエストに対して<応答>メッセージを生成し、収集したデータをその時点まで返します。クライアントが進行中のリクエストを停止したいが、別の操作を開始することを希望しない場合、<Stop>リクエストを発行します。これにより、メディアサーバーが<応答>メッセージを生成します。
The media server treats a SIP re-INVITE that modifies the established SDP parameters as an implicit <stop> request. Examples of such SDP modifications include receiving hold SDP or removing an audio or video stream. When this occurs, the media server immediately terminates the running <play>, <playcollect>, or <playrecord> request and sends a <response> indicating "reason=stopped".
メディアサーバーは、確立されたSDPパラメーターを暗黙の<Stop>リクエストとして変更するSIP Re-Inviteを扱います。このようなSDPの変更の例には、Hold SDPの受信またはオーディオまたはビデオストリームの削除が含まれます。これが発生すると、メディアサーバーはすぐに<play>、<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つの方法をサポートしています。これらは、<prompt>要素とprompturl属性です。クライアントは、単一のIVRリクエストで両方の方法を利用してはなりません。クライアントは、より柔軟な<prompt>メカニズムを使用する必要があります。Prompturl属性の使用は非推奨であり、将来のMSCMLバージョンではサポートされない場合があります。
The <prompt> element MAY be included in the body of a <play>, <playcollect>, or <playrecord> request to specify a prompt sequence to be delivered to the caller. The prompt sequence consists of one or more references to physical content files, spoken variables, or dynamic URLs that return a sub-sequence of files or variables. In addition, the <prompt> element has several attributes that control playback of the included content. These are described in the list below.
<prompt>要素は、<play>、<playcollect>、または<playRecord>リクエストのボディに含めることができます。プロンプトシーケンスは、ファイルまたは変数のサブシーケンスを返す物理コンテンツファイル、音声変数、または動的URLへの1つ以上の参照で構成されています。さらに、<prompt>要素には、含まれるコンテンツの再生を制御するいくつかの属性があります。これらについては、以下のリストに記載されています。
Attributes of <prompt>:
<prompt>の属性：
o baseurl - optional, no default value: For notational convenience, as well as reducing the MSCML payload size, the "baseurl" attribute is used to specify a base URL that is prepended to any other URLs in the sequence that are not fully qualified.
o Baseurl-オプション、デフォルト値なし：表記の利便性のため、およびMSCMLペイロードサイズを削減するために、「baseurl」属性は、完全に適格でないシーケンス内の他のURLに加えられるベースURLを指定するために使用されます。
o delay - optional, default value "0": The "delay" attribute to the prompt element specifies the time to pause between repetitions of the <prompt> sequence. It has no effect on the first iteration of the sequence. Expressed as a time value (Section 4.2.1) from 0 onwards.
o 遅延 - オプション、デフォルト値 "0"：プロンプト要素への「遅延」属性は、<prompt>シーケンスの繰り返し間で一時停止する時間を指定します。シーケンスの最初の反復には影響しません。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 持続時間 - オプション、デフォルト値「Infinite」：プロンプト要素への「持続時間」属性は、メディアサーバーがシーケンスを繰り返している間に経過する可能性のある最大時間を制御します。これにより、クライアントはプレイの長さに上限を設定できます。1MS以降または「即時」および「無限」から文字列から時間値（セクション4.2.1）として表されます。「即時」はメディアサーバーにすぐにプレイを終了するよう指示しますが、「無限」はメディアサーバーが制限を課さないことを示します。
o gain - optional, default value "0": Sets the absolute gain to be applied to the content contained in <prompt>. The value of this attribute is specified in units of dB. The media server MAY silently cap values that exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content contained in <prompt> has been completed.
o ゲイン - オプション、デフォルト値 "0"：<prompt>に含まれるコンテンツに適用される絶対的なゲインを設定します。この属性の値は、DBの単位で指定されています。メディアサーバーは、プラットフォームによって課されるゲイン制限を超える値を静かにキャップする場合があります。<prompt>に含まれるコンテンツの再生が完了した場合、レベルは元の値に戻ります。
o gaindelta - optional, default value "0": Sets the relative gain to be applied to the content contained in <prompt>. The value of this attribute is specified in units of dB. The media server MAY silently cap values which exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content contained in <prompt> has been completed.
o GainDelta-オプション、デフォルト値 "0"：<prompt>に含まれるコンテンツに適用される相対的なゲインを設定します。この属性の値は、DBの単位で指定されています。メディアサーバーは、プラットフォームによって課されるゲイン制限を超える静かに値を制限する場合があります。<prompt>に含まれるコンテンツの再生が完了した場合、レベルは元の値に戻ります。
o rate - optional, default value "0": Specifies the absolute playback rate of the content relative to normal as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content contained in <prompt> has been completed.
o レート - オプション、デフォルト値 "0"：正のパーセンテージ（より速い）または負の割合（遅い）として、通常に対するコンテンツの絶対再生率を指定します。許可された最大値を上回るか、最小値を下回ろうとする値を静かに設定しようとする値は、レートを最大または最小に設定します。<prompt>に含まれるコンテンツの再生が完了した場合、レートは元の値に戻ります。
o ratedelta - optional, default value "0": Specifies the playback rate of the content relative to it's current rate as either a positive percentage (faster) or negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content contained in <prompt> has completed.
o ratedelta-オプション、デフォルト値 "0"：現在のレートに対するコンテンツの再生率を、正の割合（より速い）または負の割合（遅い）として指定します。許可された最大値を上回るか、最小値を下回ろうとする値を静かに設定しようとする値は、レートを最大または最小に設定します。<prompt>に含まれるコンテンツの再生が完了した場合、レートは元の値に戻ります。
o locale - optional, no default value: Specifies the language and country variant used for resolving spoken variables. The language is defined as a two-letter code per ISO 639. The country variant is also defined as a two-letter code per ISO 3166. These codes are concatenated with a single underscore (%x5F) character.
o ロケール - オプション、デフォルト値なし：音声変数の解決に使用される言語と国のバリアントを指定します。言語は、ISO 639ごとに2文字のコードとして定義されます。国のバリアントは、ISO 3166ごとに2文字のコードとして定義されます。これらのコードは、単一のアンダースコア（％x5F）文字で連結されています。
o offset - optional, default value "0": A time value (Section 4.2.1) which specifies the time from the beginning of the sequence at which play is to begin. Offset only applies to the first repetition; subsequent repetitions begin play at offset 0. Allowable values are positive time values from 0 onwards. When the sequence consists of multiple content files, the offset may select any point in the sequence. If the offset value is greater than the total time of the sequence, it will "wrap" to the beginning and continue from there until the media server reaches the specified offset.
o オフセット - オプション、デフォルト値 "0"：A Time値（セクション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」：プロンプト要素への「繰り返し」属性は、メディアサーバーが<prompt>要素でシーケンスを再生する回数を制御します。許容値は0オンからの整数と文字列「無限」です。これは、繰り返しが無期限に発生することを示しています。たとえば、「Repeat = 2」とは、シーケンスが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.
クライアントは、単一の<prompt>要素内に「ゲイン」と「ゲインデルタ」属性の両方を含めるべきではありません。
When the client explicitly controls the output gain on a conference leg, as described in Section 5.3, the 'gain' and 'gaindelta' attributes SHOULD interact with the conference leg output gain settings in the following manner.
セクション5.3で説明されているように、クライアントがカンファレンスレッグの出力ゲインを明示的に制御する場合、「ゲイン」および「ゲインデルタ」属性は、会議のレッグ出力ゲイン設定と次の方法で相互作用する必要があります。
o Conference leg output gain set to <fixed>: The operation of the 'gain' and 'gaindelta' attributes are unchanged. However, the baseline gain value before any playback changes are applied is the value specified for the conference leg.
o Conference Leg Output Gainは<axix>に設定されています：「ゲイン」と「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 会議の脚の出力ゲインは<auto>に設定されています：再生ゲインコントロールを使用すると、再生操作の期間中、レッグの自動ゲインコントロール設定が停止されます。「ゲイン」および「ゲインデルタ」属性の操作は変更されません。再生が終了すると、自動ゲイン制御設定が復活します。
Media servers SHOULD support rate controls for content. However, media servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <prompt> element.
メディアサーバーは、コンテンツのレートコントロールをサポートする必要があります。ただし、メディアサーバーは、コンテンツの制限が要求を尊重することを許可しない場合、レートの変更要求を静かに無視する場合があります。クライアントは、単一の<prompt>要素内に「レート」と「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>
Figure 16: Prompt Block Example
図16：プロンプトブロックの例
Clients compose prompt sequences using the <audio> and <variable> elements. An <audio> element MAY refer to content that contains audio, video, or both; the generic name is preserved for backwards compatibility. The <audio> element has the attributes described in the list below.
クライアントは、<audio>および<variable>要素を使用してプロンプトシーケンスを作成します。<オーディオ>要素は、オーディオ、ビデオ、またはその両方を含むコンテンツを指す場合があります。汎用名は、逆方向の互換性のために保存されています。<Audio>要素には、以下のリストで説明されている属性があります。
Attributes of <audio>:
<audio>の属性：
o url - required, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. If the URL is not fully qualified and a "baseurl" attribute was set, the value of the "baseurl" attribute will be prepended to this value to generate the target URL.
o URL-必須、デフォルト値なし：取得および再生されるコンテンツのURL。ターゲットは、ローカルまたはリモート（nfs）「file：// "スキームURLまたは「http：//」または「https：//」スキームurlです。URLが完全に適格でなく、「baseurl」属性が設定されている場合、ターゲットURLを生成するために「baseurl」属性の値がこの値に準備されます。
o encoding - optional, default value "ulaw": Specifies the content encoding for file formats that are not self-describing (e.g., .WAV). Allowable values are "ulaw", "alaw", and "msgsm". This attribute only affects "file://" scheme URLs.
o エンコーディング - オプション、デフォルト値「ULAW」：自己記述ではないファイル形式のコンテンツエンコード（.WAVなど）を指定します。許容値は、「ULAW」、「ALAW」、および「MSGSM」です。この属性は、「file：//」スキームURLSのみに影響します。
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に適用する絶対的なゲインを設定します。この属性の値は、DBの単位で指定されています。メディアサーバーは、プラットフォームによって課されるゲイン制限を超える値を静かにキャップする場合があります。レベルは、コンテンツURLの再生が完了すると、元の値に戻ります。
o gaindelta - optional, default value "0": Sets the relative gain to be applied to the content URL. The value of this attribute is specified in units of dB. The media server MAY silently cap values that exceed the gain limits imposed by the platform. The level reverts back to its original value when playback of the content URL has been completed.
o GainDelta-オプション、デフォルト値 "0"：コンテンツURLに適用される相対的なゲインを設定します。この属性の値は、DBの単位で指定されています。メディアサーバーは、プラットフォームによって課されるゲイン制限を超える値を静かにキャップする場合があります。レベルは、コンテンツURLの再生が完了すると、元の値に戻ります。
o rate - optional, default value "0": Specifies the absolute playback rate of the content relative to normal as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content URL has been completed.
o レート - オプション、デフォルト値 "0"：正のパーセンテージ（より速い）または負の割合（遅い）として、通常に対するコンテンツの絶対再生率を指定します。許可された最大値を上回るか、最小値を下回ろうとする値を静かに設定しようとする値は、レートを最大または最小に設定します。レートは、コンテンツURLの再生が完了したときに元の値に戻ります。
o ratedelta - optional, default value "0": Specifies the playback rate of the content relative to it's current rate as either a positive percentage (faster) or a negative percentage (slower). Any value that attempts to set the rate above the maximum allowed or below the minimum allowed silently sets the rate to the maximum or minimum. The rate reverts back to its original value when playback of the content URL has been completed.
o ratedelta-オプション、デフォルト値 "0"：現在のレートに対するコンテンツの再生率を、正の割合（より速い）または負の割合（遅い）として指定します。許可された最大値を上回るか、最小値を下回ろうとする値を静かに設定しようとする値は、レートを最大または最小に設定します。レートは、コンテンツURLの再生が完了したときに元の値に戻ります。
Clients MUST NOT include both 'gain' and 'gaindelta' attributes within a single <audio> element.
クライアントは、単一の<オーディオ>要素内に「ゲイン」と「ゲインデルタ」属性の両方を含めるべきではありません。
When the client explicitly controls the output gain on a conference leg, as described in Section 5.3, the 'gain' and 'gaindelta' attributes SHOULD interact with the conference leg output gain settings in the following manner.
セクション5.3で説明されているように、クライアントがカンファレンスレッグの出力ゲインを明示的に制御する場合、「ゲイン」および「ゲインデルタ」属性は、会議のレッグ出力ゲイン設定と次の方法で相互作用する必要があります。
o Conference leg output gain set to <fixed>: The operation of the 'gain' and 'gaindelta' attributes are unchanged. However, the baseline gain value before any playback changes are applied is the value specified for the conference leg.
o Conference Leg Output Gainは<axix>に設定されています：「ゲイン」と「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 会議の脚の出力ゲインは<auto>に設定されています：再生ゲインコントロールを使用すると、再生操作の期間中、レッグの自動ゲインコントロール設定が停止されます。「ゲイン」および「ゲインデルタ」属性の操作は変更されません。再生が終了すると、自動ゲイン制御設定が復活します。
Media servers SHOULD support rate controls for content. However, media servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <audio> element.
メディアサーバーは、コンテンツのレートコントロールをサポートする必要があります。ただし、メディアサーバーは、コンテンツの制限が要求を尊重することを許可しない場合、レートの変更要求を静かに無視する場合があります。クライアントは、単一の<audio>要素内に「レート」と「定格」属性の両方を含めるべきではありません。
Media servers MUST support local and remote (NFS) "file://" scheme URLs and "http://" and "https://" scheme URLs for content retrieval.
メディアサーバーは、ローカルおよびリモート（NFS）「file：//」スキームURLSおよび「http：//」および「https：//」スキームURLSをサポートする必要があります。
NOTE: The provisioning of NFS mount points and their mapping to the "file://" schema is purely a local matter at the media server.
注：NFSマウントポイントのプロビジョニングと「file：//」スキーマへのマッピングは、純粋にメディアサーバーのローカル問題です。
MSCML also supports "http://" and "https://" scheme URLS that return a list of physical URLs using the "text/uri-list" MIME type. This facility provides flexibility for applications to dynamically generate prompt sequences at execution time and enables separation of this function from the client and media server.
MSCMLは、「http：//」および「https：//」スキームURLをサポートしています。これは、「テキスト/URI-List」MIMEタイプを使用して物理URLのリストを返すものです。この施設は、アプリケーションが実行時に迅速なシーケンスを動的に生成し、クライアントとメディアサーバーからこの機能を分離できるように柔軟性を提供します。
Spoken variables are specified using the <variable> element. This element has the attributes described in the list below. MSCML's spoken variables are based on those described in Audio Server Protocol [17].
音声変数は、<変数>要素を使用して指定されています。この要素には、以下のリストで説明されている属性があります。MSCMLの音声変数は、オーディオサーバープロトコル[17]に記載されている変数に基づいています。
Attributes of <variable>:
<variable>の属性：
o type - required, no default value: Specifies the major type format of the spoken variable to be played. Allowable values are "dat" (date), "dig" (digit), "dur" (duration), "mth" (month), "mny" (money), "num" (number), "sil" (silence), "str" (string), "tme" (time), and "wkd" (weekday).
o タイプ - 必須、デフォルト値なし：再生される音声変数の主要なタイプ形式を指定します。許容値は「dat」（日付）、「dig」（digit）、 "dur"（dur "（dur"）、 "mth"（mont）、 "mny"（money）、 "num"（number）、 "sil"（silence）、 "str"（string）、 "tme"（time）、および "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」、「GEN」、「NDN」、「CRD」、「ORD」、および「ORD」の場合は「T24」、「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 値 - 必須、デフォルト値なし：「タイプ」および「サブタイプ」属性で指定されているフォーマット情報と、親の変数をレンダリングする親<Prompt>要素の「ロケール」属性に基づいて解釈される文字列。
If the "locale" attribute was not specified in <prompt>, the media server SHOULD make a selection based on platform configuration. If the precise "locale" requested cannot be honored, the media server SHOULD select the closest match based on the available content.
<prompt>で「ロケール」属性が指定されていない場合、メディアサーバーはプラットフォーム構成に基づいて選択を行う必要があります。要求された正確な「ロケール」を尊重できない場合、メディアサーバーは、利用可能なコンテンツに基づいて最も近い一致を選択する必要があります。
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アプリケーションでは、通常、アプリケーションプロバイダーによって作成された特殊なプロンプトコンテンツが必要です。高品質のユーザーインタラクションを提供するには、同じスピーカーによって特殊なプロンプトと音声変数を生成する必要があります。Media Serverは本質的に複数の同時アプリケーションをサポートしているため、必要なすべてのアプリケーションプロンプトと、メディアサーバーでローカルで変数コンテンツを一致させることは非常に困難です。したがって、クライアントは前述の動的なURLメカニズムを採用して、「テキスト/URIリスト」コンテンツを返す外部Webサーバーを使用して音声変数を生成することを強くお勧めします。
MSCML IVR requests implicitly support multimedia content. Multimedia capabilities are controlled by the audio and video media negotiated for the dialog and the content specified by the client for play and record operations. If the content specified for delivery contains both audio and video tracks and the dialog has audio and video streams, both tracks are streamed to the caller. Likewise, if the dialog has both audio and video streams and the content format specified supports both (e.g., .3gp files) the media server records both streams to the file.
MSCML IVRは、マルチメディアコンテンツを暗黙的にサポートします。マルチメディア機能は、プレイおよびレコードオペレーションのためにクライアントが指定したダイアログとコンテンツについてネゴシエートされたオーディオおよびビデオメディアによって制御されます。配信用に指定されたコンテンツにオーディオトラックとビデオトラックの両方が含まれ、ダイアログにオーディオストリームとビデオストリームがある場合、両方のトラックが発信者にストリーミングされます。同様に、ダイアログにオーディオストリームとビデオストリームの両方があり、コンテンツ形式が指定された両方のサポート（例：.3GPファイル）が両方のサポートをサポートする場合、メディアサーバーは両方のストリームをファイルに記録します。
If there is a mismatch between the real time media and specified content, the media server MUST play or record the appropriate content tracks rather than failing the request. For example, if the client has requested playback of content with audio and video tracks but only audio media has been established for the dialog, the media server should play the audio track. If the dialog has both audio and video media but the content is audio-only, the media server MAY stream a pre-provisioned video track to the caller. Media servers SHOULD implement video transcoding functions to minimize incompatibilities between real time media and content.
リアルタイムメディアと指定されたコンテンツの間に不一致がある場合、メディアサーバーはリクエストに障害を失うのではなく、適切なコンテンツトラックを再生または記録する必要があります。たとえば、クライアントがオーディオトラックとビデオトラックでコンテンツの再生を要求しているが、ダイアログに対してオーディオメディアのみが確立されている場合、メディアサーバーはオーディオトラックを再生する必要があります。ダイアログにオーディオメディアとビデオメディアの両方があるが、コンテンツの両方がオーディオのみの場合、メディアサーバーは事前に解放されたビデオトラックを発信者にストリーミングする場合があります。メディアサーバーは、リアルタイムメディアとコンテンツの互換性を最小限に抑えるために、ビデオトランスコーディング機能を実装する必要があります。
The media server MUST begin recording video media only when it receives a refresh video frame. A refresh frame contains all the video information required to decode that frame (i.e., there is no dependency on data from previous video frames). Refresh frames are large and generally sent infrequently to conserve network bandwidth. The media server MUST implement standard mechanisms to request that the caller (video encoder) transmit a refresh frame to ensure video recording begins quickly. The media server MUST begin recording the audio track immediately while waiting to receive the video refresh frame.
メディアサーバーは、更新ビデオフレームを受信した場合にのみ、ビデオメディアの録画を開始する必要があります。更新フレームには、そのフレームをデコードするために必要なすべてのビデオ情報が含まれています（つまり、以前のビデオフレームからのデータに依存しません）。更新フレームは大きく、一般にネットワークの帯域幅を節約するためにまれに送られます。メディアサーバーは、標準メカニズムを実装して、発信者（ビデオエンコーダー）が更新フレームを送信して、ビデオ録画が迅速に開始されるようにすることを要求する必要があります。メディアサーバーは、ビデオの更新フレームの受信を待っている間、すぐにオーディオトラックの録音を開始する必要があります。
The client issues a <play> request to play an announcement without interruption and with no digit collection. One use, for example, is to announce the name of a new participant to the entire conference. The <play> request has the attributes described in the list below.
クライアントは、中断せずに桁のコレクションなしで発表を再生するように<Play>リクエストを発行します。たとえば、1つの用途は、会議全体に新しい参加者の名前を発表することです。<play>リクエストには、以下のリストで説明されている属性があります。
Attributes of <play>:
<play>の属性：
o id - optional, no default value: Specifies a client-defined ID for purposes of matching requests and responses.
o ID-オプション、デフォルト値なし：一致するリクエストと応答の目的で、クライアント定義のIDを指定します。
o offset - optional, default value "0": Specifies the time from the beginning of the URL specified in the 'prompturl' attribute at which play will begin. Expressed as a time value (Section 4.2.1) from 0 onwards. If the offset value is greater than the total time of the content, it will "wrap" to the beginning and continue from there until the media server reaches the specified offset. NOTE: Use of this attribute is deprecated.
o オフセット - オプション、デフォルト値 "0"：Playが開始される「Prospturl」属性で指定された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 PROSTENTENCODING-オプション、デフォルト値なし：自己記述ではないファイル形式のコンテンツエンコード（.wavなど）を指定します。許容値は、「ULAW」、「ALAW」、および「MSGSM」です。この属性は、「file：//」スキームURLSのみに影響します。注：この属性の使用は非推奨です。
o prompturl - optional, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
o PROMPTURL-オプション、デフォルト値なし：取得および再生されるコンテンツのURL。ターゲットは、ローカルまたはリモート（nfs）「file：// "スキームURLまたは「http：//」または「https：//」スキームurlです。注：この属性の使用は非推奨です。
The <play> request has one child element defined, <prompt>. Use of <prompt> is described in Section 6.1.1.
<play>リクエストには、1つの子要素が定義されている<prompt>があります。<prompt>の使用は、セクション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.
クライアントは、単一のリクエストで<prompt>要素と「prompturl」属性の両方を使用してはなりません。前述のように、「Prompturl」属性は、古いMSCMLアプリケーションとの後方互換性のためにサポートされていますが、その使用は非推奨です。代わりに、より柔軟な<prompt>要素を使用する必要があります。
The following play request (Figure 17) example shows the delivery of a complex prompt sequence consisting of content accessed via NFS and spoken variables.
次の再生リクエスト（図17）の例は、NFSと音声変数を介してアクセスされるコンテンツで構成される複雑なプロンプトシーケンスの配信を示しています。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<play id="332985001">
<prompt stoponerror="yes"
baseurl="file:////var/mediaserver/prompts/"
locale="en_US" offset="0" gain="0" rate="0"
delay="0" duration="infinite" repeat="1">
<audio url="num_dialed.raw" encoding="ulaw"/>
<variable type="dig" subtype="ndn" value="3014170700"/>
<audio url="num_invalid.wav"/>
<audio url="please_check.wav"/>
</prompt>
</play>
</request>
</MediaServerControl>
Figure 17: <Play> Request Example
When the announcement has finished playing, the media server sends a <response> payload to the client in a SIP INFO message. Details regarding the format of <play> responses are provided in Section 10.4.
発表が再生が終了したとき、メディアサーバーはSIP情報メッセージでクライアントに<応答>ペイロードを送信します。<play>応答の形式に関する詳細は、セクション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>リクエストは、プロンプトと収集の2つのフェーズで実行されます。クライアントが<prompt>要素またはprospurl属性を使用して、プロンプトコンテンツを再生するように指定した場合、メディアサーバーはコレクションフェーズを開始する前にコンテンツを再生します。プロンプトコンテンツが指定されていない場合、収集フェーズはすぐに開始されます。
The basic attributes of <playcollect> are the same as those of <play>, which were described in Section 6.3. In addition to these basic attributes, <playcollect> defines others which control digit buffering and barge-in behavior, collection timers, special purpose DTMF key functions, and logging of user DTMF input. Each functional category and its attributes are described below.
<playcollect>の基本属性は、セクション6.3で説明されている<play>の属性と同じです。これらの基本的な属性に加えて、<PlayCollect>は、桁バッファリングとバージインの動作、収集タイマー、特別な目的DTMFキー関数、ユーザーDTMF入力のロギングを制御する他のものを定義します。各機能カテゴリとその属性については、以下に説明します。
Whenever the media server is processing a call that specifies an MSCML service (i.e., "conf" and "ivr"), the media server continuously looks for DTMF digits and places them in a quarantine buffer. The quarantine buffer is examined when a <playcollect> request is received. The media server compares any previously buffered digits for barge-in, and to look for matches with DTMF grammars or special purpose keys. This provides the type-ahead behavior for menu traversal and other types of IVR interactions.
メディアサーバーがMSCMLサービス（つまり、「conf」と「ivr」）を指定するコールを処理しているときはいつでも、メディアサーバーはdtmf桁を継続的に探し、それらを検疫バッファーに配置します。検疫バッファーは、<PlayCollect>リクエストを受信したときに調べられます。メディアサーバーは、バージイン用に以前にバッファリングされた数字を比較し、DTMFグラマーまたは特別な目的キーとのマッチを探すためです。これにより、メニュートラバーサルおよびその他のタイプのIVR相互作用のタイプアライド動作が提供されます。
Attributes for Control of Digit Buffering and Barge-In:
数字バッファリングとバージインの制御のための属性：
o cleardigits - optional, default value "no": Specifies whether previous user input should be considered or ignored for barge-in purposes and DTMF matching. When it is set to "yes", any previously buffered digits are removed, so prior user input is ignored. If it is set to "no", previously buffered digits will be considered. If "cleardigits" is set to "no" and barge-in is enabled, previously buffered digits will immediately terminate the prompt phase. In this case, the prompt is not played, and digit collection begins immediately.
o ClearDigits-オプション、デフォルト値「いいえ」：バージインの目的とDTMFマッチングのために、以前のユーザー入力を考慮すべきか無視する必要があるかを指定します。「はい」に設定されると、以前にバッファリングされた数字が削除されるため、以前のユーザー入力は無視されます。「いいえ」に設定されている場合、以前にバッファリングされた数字が考慮されます。「clearDigits」が「no」に設定され、バージインが有効になっている場合、以前にバッファリングされた数字はすぐにプロンプトフェーズを終了します。この場合、プロンプトは再生されず、桁の収集はすぐに開始されます。
o barge - optional, default value "yes": Specifies whether user input will barge the prompt and force transition to the collect phase. When it is set to "yes", a DTMF input will barge the prompt. When it is set to "no", the prompt phase cannot be barged, and any user input during the prompt is placed in the quarantine buffer for inspection during the collect phase. Note that if the "barge" attribute is set to "no", the "cleardigits" attribute implicitly has a value of "yes". This ensures that the media server does not leave DTMF input that occurred prior to the current collection in the quarantine buffer after the request is completed.
o Barge-オプション、デフォルト値「はい」：ユーザー入力がプロンプトをはしけ、コレクションフェーズへの強制移行を指定します。「はい」に設定されると、DTMF入力がプロンプトをはるかにします。「いいえ」に設定されている場合、プロンプトフェーズを取得することはできず、プロンプト中のユーザー入力は、収集フェーズ中に検査のために隔離バッファーに配置されます。「バージ」属性が「いいえ」に設定されている場合、「clearDigits」属性には「はい」の値が暗黙的にあることに注意してください。これにより、メディアサーバーは、リクエストが完了した後、隔離バッファーの現在のコレクションの前に発生したDTMF入力を残さないようにします。
The client can define mappings between DTMF digits and special functions. The media server invokes the special function if the associated DTMF digit is detected. MSCML has two attributes that define mappings that affect termination of the collect phase. These attributes are described in the list below.
クライアントは、DTMF数字と特別な機能の間のマッピングを定義できます。メディアサーバーは、関連するDTMFデジットが検出された場合、特殊機能を呼び出します。MSCMLには、収集フェーズの終了に影響するマッピングを定義する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」属性は、Rewindキー（RWKEY）またはFast Forwardキー（FFKEY）がタイム値として指定されている場合、メディアサーバーが後方または転送の距離を示します。4.2.1）。
o ffkey - optional, no default value: The "ffkey" attribute maps a DTMF key to a fast forward operation equal to the value of the "skipinterval" attribute.
o ffkey-オプション、デフォルト値なし：「ffkey」属性は、dtmfキーを「skipinterval」属性の値に等しい早送り操作にマップします。
o rwkey - optional, no default value: The "rwkey" attribute maps a DTMF key to a rewind action equal to the value of the "skipinterval" attribute.
o rwkey-オプション、デフォルト値なし：「rwkey」属性は、dtmfキーを「skipinterval」属性の値に等しい巻き戻しアクションにマップします。
Clients MUST NOT map the same DTMF digit to both the "rwkey" and "ffkey" attributes in a single <playcollect> request.
クライアントは、同じDTMF数字を単一の<PlayCollect>リクエストで「RWKEY」属性と「FFKEY」属性の両方にマッピングしてはなりません。
VCR control operations are bounded by the beginning and end of the prompt sequence. A rewind action that moves the offset before the beginning of the sequence results in playback starting at the beginning of the sequence (i.e., offset=0). A fast forward action that moves the offset past the end of the sequence results in the media server's treating the sequence as complete.
VCR制御操作は、プロンプトシーケンスの開始と終了によって制限されます。シーケンスの開始前にオフセットを移動する巻き戻しアクションにより、シーケンスの開始時から再生が行われます（つまり、オフセット= 0）。シーケンスの端を過ぎてオフセットを移動する早送りアクションにより、メディアサーバーはシーケンスを完全に扱います。
MSCML defines several timer attributes that control how long the media server waits for digits in the input sequence. All timer settings are time values (Section 4.2.1). The list below describes these attributes and their use.
MSCMLは、入力シーケンス内の数字をメディアサーバーが待機する時間を制御するいくつかのタイマー属性を定義します。すべてのタイマー設定は時間値です（セクション4.2.1）。以下のリストは、これらの属性とその使用について説明しています。
Collection Timer Attributes:
収集タイマーの属性：
o firstdigittimer - optional, default value "5000ms": Specifies how long the media server waits for the initial DTMF input before terminating the collection. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately whereas "infinite" indicates that the timer will never fire.
o FirstDigittimer-オプション、デフォルト値「5000ms」：メディアサーバーがコレクションを終了する前に最初のDTMF入力を待機する時間を指定します。1MS以降または「即時」および「無限」から文字列から時間値（セクション4.2.1）として表されます。「即時」値は、タイマーがすぐに発射する必要があることを示しますが、「無限」はタイマーが発生しないことを示します。
o interdigittimer - optional, default value "2000ms": Specifies how long the media server waits between DTMF inputs. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately, whereas "infinite" indicates that the timer will never fire.
o Interdigittimer-オプション、デフォルト値 "2000ms"：メディアサーバーがDTMF入力間で待機する時間を指定します。1MS以降または「即時」および「無限」から文字列から時間値（セクション4.2.1）として表されます。「即時」値は、タイマーがすぐに発射する必要があることを示しますが、「無限」はタイマーが発生しないことを示します。
o extradigittimer - optional, default value "1000ms": Specifies how long the media server waits for additional user input after the specified number of digits has been collected. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" indicates that the timer should fire immediately, whereas "infinite" indicates that the timer will never fire.
o Extradigittimer-オプション、デフォルト値「1000ms」：指定された数字の数が収集された後、メディアサーバーが追加のユーザー入力を待つ時間を指定します。1MS以降または「即時」および「無限」から文字列から時間値（セクション4.2.1）として表されます。「即時」値は、タイマーがすぐに発射する必要があることを示しますが、「無限」はタイマーが発生しないことを示します。
o interdigitcriticaltimer - optional, defaults to the value of the interdigittimer attribute: Specifies how long the media server waits after a grammar has been matched for a subsequent digit that may cause a longer match. Expressed as a time value (Section 4.2.1) from 1ms onwards or the strings "immediate" and "infinite." The value "immediate" results in "shortest match first" behavior, whereas "infinite" means to wait indefinitely for additional input. If not explicitly specified otherwise, this attribute is set to the value of the 'interdigittimer' attribute.
o Interdigitcriticaltimer-オプションは、デフォルトでは、インターディジティマー属性の値になります。メディアサーバーが、長い一致を引き起こす可能性のある後続の数字と一致した後、メディアサーバーが待機する時間を指定します。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.
Exthigittimer設定により、「ReturnKey」入力が現在のコレクションに関連付けられます。たとえば、maxdigitsが3に設定され、returnKeyが＃に設定されている場合、ユーザーは「x＃」、「xx＃」、または「xxx＃」のいずれかを入力できます。xはdtmf桁を表します。
If the media server detects the "returnkey" pattern during the "extradigit" interval, the media server returns the collected digits to the client and removes the "returnkey" from the digit buffer.
メディアサーバーが「採用」間隔中に「returnKey」パターンを検出した場合、メディアサーバーは収集された数字をクライアントに返し、桁バッファーから「returnキー」を削除します。
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が設定されていない限り、Exthigittimerは効果がありません。
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プロトコル交換とそれらに含まれる情報を保護します。これらの保護は、メディアサーバーログファイルでキャプチャされたデータには適用されません。一般に、メディアサーバーのロギングはプラットフォーム固有であるため、この仕様ではカバーされません。ただし、ロギングの1つの側面、機密情報（個人識別番号やクレジットカード番号など）のキャプチャが関連しています。メディアサーバーには、クライアントの範囲内にあるため、受信するDTMF入力が敏感であるかどうかを判断する手段はありません。これを認識すると、MSCMLには、必要に応じてクライアントが有効にするキャプチャされたDTMFのロギングを抑制するためのリクエストごとのメカニズムが含まれています。
The "maskdigits" attribute controls whether detected DTMF digits appear in the log output. Clients use this attribute when the media server collects sensitive information that should not be accessible through the log files.
「MaskDigits」属性は、検出されたDTMF数字がログ出力に表示されるかどうかを制御します。クライアントは、メディアサーバーがログファイルを介してアクセスできない機密情報を収集したときにこの属性を使用します。
Maskdigits Attribute:
MaskDigits属性：
o maskdigits - optional, default value "no": Controls whether user DTMF inputs are captured in media server log files. The possible values for this attribute are "yes" and "no".
o MASKDIGITS-オプション、デフォルト値「いいえ」：ユーザーDTMF入力がメディアサーバーログファイルでキャプチャされるかどうかを制御します。この属性の可能な値は、「はい」と「いいえ」です。
MSCML supports four methods for specifying DTMF grammars: the "maxdigits" attribute, which provides a simple mechanism for collecting any number of digits up to the maximum, regular expressions, MGCP [5] digit maps, and H.248.1 [6] digit maps. A media server MUST support the maxdigits and regular expression methods for specifying DTMF grammars and SHOULD support MGCP and H.248.1 methods. A client MUST NOT mix DTMF grammar types in a single <playcollect> request.
MSCMLは、DTMF文法を指定するための4つの方法をサポートしています。「MaxDigits」属性は、最大式、正規式、MGCP [5]桁マップまで任意の数字を収集するための簡単なメカニズムを提供します。。メディアサーバーは、DTMFグラマーを指定するためのMaxDigitsと正規表現方法をサポートする必要があり、MGCPおよびH.248.1メソッドをサポートする必要があります。クライアントは、DTMFの文法タイプを単一の<PlayCollect>リクエストに組み合わせてはなりません。
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.
<pattern>要素は、メディアサーバーが探すための数字パターンまたはパターンを指定します。この要素には、式で使用されるDTMF文法のタイプを指定する3つの異なる子要素が含まれる場合があります。<pattern>要素には属性がありません。
<regex> Use regular expressions to define DTMF patterns to match. The complete regular expression syntax used in MSCML is described in Appendix A.
<regex>正規表現を使用して、一致するDTMFパターンを定義します。MSCMLで使用される完全な正規表現構文は、付録Aで説明されています。
<mgcpdigitmap> Use digit maps as specified in MGCP [5].
<MGCPDIGITMAP> MGCPで指定されているような数字マップを使用します[5]。
<megacodigitmap> Use digit maps as specified in H.248.1 [6].
<megacodigitmap> H.248.1 [6]で指定されている指のマップを使用します。
At least one <regex> element MUST be present in <pattern> when regex grammars are used. Multiple <regex> elements MAY be present. When <mgcpdigitmap> or <megacodigitmap> grammars are used, <pattern> MUST contain only one grammar element.
正規表現文法を使用する場合、少なくとも1つの<regex>要素を<パターン>に存在する必要があります。複数の<regex>要素が存在する場合があります。<mgcpdigitmap>または<megacodigitmap>グラマーが使用される場合、<pattern>は1つの文法要素のみを含める必要があります。
The DTMF grammar elements <regex>, <mgcpdigitmap>, and <megacodigitmap> have the attributes described in the list below.
DTMF文法要素<Regex>、<mgcpdigitmap>、および<megacodigitmap>には、以下のリストで説明されている属性があります。
Attributes of DTMF Grammar Elements:
DTMF文法要素の属性：
o value - required, no default value: Specifies a string representing a DTMF grammar matching the parent element type (e.g., regex). Regex values represent a single DTMF grammar. MGCP and MEGACO digit maps allow multiple grammars to be described in a single string.
o 値 - 必須、デフォルト値なし：親要素タイプ（例えば、regex）に一致するDTMF文法を表す文字列を指定します。正規表現値は、単一のDTMF文法を表します。MGCPおよびMegaco Digitマップにより、複数の文字が単一の文字列に記述されます。
o name - optional, no default value: Associates a client defined name for the grammar that is sent back in the <playcollect> response. This attribute is most useful with regex type grammars as each grammar element can have a unique name.
o 名前 - オプション、デフォルト値なし：<playcollect>応答で送信される文法のクライアント定義の名前を関連付けます。この属性は、各文法要素に一意の名前を持つことができるため、正規表現型文法で最も便利です。
When the <playcollect> has finished, the media server sends a <response> payload to the client in a SIP INFO message.
<PlayCollect>が終了すると、メディアサーバーはSIP情報メッセージでクライアントに<応答>ペイロードを送信します。
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」属性の使用を制御するための「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>
Figure 18: <Playcollect> Request Example Using the Maxdigits Attribute
図18：<PlayCollect> MaxDigits属性を使用した例のリクエスト例
The <playrecord> request directs the media server to convert and possibly to transcode the RTP payloads it receives and store them to the specified URL using the requested content codec(s) and file format. This request proceeds in two phases; prompt and record.
<PlayRecord>要求は、メディアサーバーに、受信したRTPペイロードを変換し、場合によっては、要求されたコンテンツコーデックとファイル形式を使用して指定されたURLに保存するように指示します。この要求は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で説明されているように、<Play>および<PlayCollect>の基本属性を共有します。MSCMLは、プロンプトフェーズと記録フェーズの動作を制御する他の属性も定義します。これらのフェーズとそれらを制御する属性については、以下のテキストと表に記載されています。
The presence or absence of a "prompturl" attribute or child <prompt> element controls whether a prompt is played before recording begins. As previously noted, use of the "prompturl" attribute is deprecated, and clients SHOULD use <prompt> instead.
「prospturl」属性または子<prompt>要素の有無は、録音が開始される前にプロンプトが再生されるかどうかを制御します。前述のように、「Prompturl」属性の使用は非推奨であり、クライアントは代わりに<Prompt>を使用する必要があります。
When the client requests that the media server prompt the caller before recording audio, <playrecord> has two stages. The first is equivalent to a <playcollect> operation. The client may set the prompt phase to be interruptible by DTMF input (barge) and may specify an escape key that will terminate the <playrecord> request before the recording phase begins.
クライアントがメディアサーバーがオーディオを録画する前に発信者にプロンプトをプロンプトするように要求したとき、<PlayRecord>には2つの段階があります。1つ目は、<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 Barge-オプション、デフォルト値「はい」：ユーザー入力がプロンプトをはしけ、レコードフェーズに強制的に移行するかどうかを指定します。「はい」に設定されると、DTMF入力がプロンプトをはるかにします。「いいえ」に設定されている場合、プロンプトフェーズを取得することはできず、プロンプト中のユーザー入力は、収集フェーズ中に検査のために隔離バッファーに配置されます。「バージ」属性が「いいえ」に設定されている場合、「clearDigits」属性には「はい」の値が暗黙的にあることに注意してください。これにより、メディアサーバーは、リクエストが完了した後、隔離バッファー内の現在のコレクションの前に発生したDTMF入力を残さないようにします。
o cleardigits - optional, default value "no": Specifies whether previous user input should be considered or ignored for barge-in purposes. When it is set to "yes", any previously buffered digits are removed, so prior user input is ignored. If it is set to "no", previously buffered digits will be considered. If "cleardigits" is set to "no" and barge-in is enabled, previously buffered digits will terminate the prompt phase immediately. In this case, the prompt is not played, and recording begins immediately.
o ClearDigits-オプション、デフォルト値「いいえ」：以前のユーザー入力を検討するか無視する必要があるかを指定します。「はい」に設定されると、以前にバッファリングされた数字が削除されるため、以前のユーザー入力は無視されます。「いいえ」に設定されている場合、以前にバッファリングされた数字が考慮されます。「clearDigits」が「no」に設定され、バージインが有効になっている場合、以前にバッファリングされた数字はすぐにプロンプトフェーズを終了します。この場合、プロンプトは再生されず、録音はすぐに開始されます。
o escapekey - optional, default value "*": Specifies a DTMF key that indicates the user wishes to terminate the current operation without saving any input recorded to that point. Detection of the mapped DTMF key terminates the request immediately and generates a response.
o EscapeKey-オプション、デフォルト値 "*"：記録された入力を保存せずにユーザーが現在の操作を終了したいことを示すDTMFキーを指定します。マッピングされたDTMFキーの検出は、リクエストをすぐに終了し、応答を生成します。
Detection of the escape key generates a response message, and the operation returns immediately. If the user presses any other keys and if the prompt is interruptible (barge="yes"), then the play stops immediately, and the recording phase begins.
エスケープキーを検出すると、応答メッセージが生成され、操作はすぐに戻ります。ユーザーが他のキーを押し、プロンプトが中断可能である場合（Barge = "Yes"）、プレイはすぐに停止し、記録フェーズが開始されます。
If the request proceeds to the recording phase, the media server discards any digits from the collect phase from the quarantine buffer to eliminate unintended termination of the recording. The following attributes control recording behavior.
リクエストが録音段階に進むと、メディアサーバーは、記録バッファーから収集フェーズから数字を破棄して、録音の意図しない終了を排除します。次の属性は、記録動作を制御します。
Playrecord Attributes for the Record Phase: o recurl - required, no default value: Specifies the target URL for the recorded content.
レコードフェーズのplayRecord属性：o racurl-必須、デフォルト値なし：記録されたコンテンツのターゲット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 期間 - オプション、デフォルト値「Infinite」：録音の最大許容期間を指定します。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 endilence-オプション、デフォルト値「4000ms」：録音を停止するためにスピーチが終了した後にメディアサーバーが待機する時間を指定します。1MS以降または「即時」および「無限」から文字列から時間値（セクション4.2.1）として表されます。「無限」に設定すると、音声が終了した後、録音は無期限に継続され、DTMFキープレスまたは入力が最大目的の持続時間に達したためにのみ終了します。
o recstopmask - optional, default value "0123456789ABCD#*": Specifies a list of individual DTMF characters that, if detected, will cause the recording to be terminated. To ensure that the input of a specific key does not cause the recording to stop, remove the DTMF key from the list.
o RecStopMask-オプション、デフォルト値 "0123456789ABCD＃*"：検出された場合、録音が終了する個々のDTMF文字のリストを指定します。特定のキーの入力が記録を停止させないようにするには、リストからDTMFキーを削除します。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバーは、「Recurl」属性のローカルおよびリモート（NFS）「ファイル：//」スキームURLをサポートする必要があります。MSCMLは、「http：//」および「https：//」スキームURLを<manageContent>（セクション8）要求を介して間接的にサポートしています。
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イベントに関係なく、受信したメディアを指定されたRecurl 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.
Endilenceタイマーの有効期限が切れると、メディアサーバーは、記録されたオーディオの端を「endilence」属性の値に等しい量だけトリミングします。
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情報メッセージでクライアントに送信します。<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）はプロンプトを再生し、波形式で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>
Figure 19: Recording Example
図19：記録の例
The client issues a <stop> request when the objective is to stop a request in progress and not to initiate another operation. This request generates a <response> message from the media server.
クライアントは、目標が進行中のリクエストを停止し、別の操作を開始しないことである場合、<Stop>要求を発行します。この要求は、メディアサーバーから<応答>メッセージを生成します。
The only attribute is id, which is optional.
唯一の属性はIDで、オプションです。
The client-defined request id correlates the asynchronous response with its original request and echoes back to the client in the media server's response.
クライアント定義の要求IDは、非同期応答を元の要求と相関させ、メディアサーバーの応答でクライアントに戻ります。
The following MSCML payload (Figure 20) depicts an example <stop> request.
次のMSCMLペイロード（図20）は、<Stop>リクエストの例を示しています。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<stop id="4578903"/>
</request>
</MediaServerControl>
Figure 20: Stop Example
図20：停止例
The format of a response to a <stop> request is detailed in Section 10.2.
<Stop>リクエストへの応答の形式については、セクション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".
前述のように、メディアサーバーは、確立されたSDPパラメーターを暗黙の<Stop>リクエストとして変更するSIP Re-Inviteを扱います。このようなSDPの変更の例には、Hold SDPの受信またはオーディオまたはビデオストリームの削除が含まれます。これが発生すると、メディアサーバーはすぐに<play>、<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ダイアログで発生します。これは、前述の会議レベルのアクティブトーカーイベントとは異なります。アクティブなトーカーイベントのサブスクリプションと通知は、カンファレンスコントロールレッグで発生しますが、実際のイベント検出は1つ以上の参加者の脚で発生します。
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>要求には、子要素<Subscribe>および<Events>が含まれます。<tevents>要素には、レッグイベントを呼び出すサブスクリプションを制御する2つの子要素が含まれる場合があります。これらは<keypress>および<signal>です。<configure_leg>要求は、最大1つの<keypress>要素を含める必要がありますが、異なるコールプログレスイベントの通知を要求する複数の<signal>要素を含めることができます。
Keypress events are used when the client wishes to receive notifications of individual DTMF events that are not tied to a specific <playcollect> request. One use of this facility is to monitor conference legs for DTMF inputs that require application intervention; for example, to notify the moderator that the caller wishes to speak. Keypress events are also used when the application desires complete control of grammars and timing constraints.
キープレスイベントは、クライアントが特定の<PlayCollect>リクエストに関連付けられていない個々のDTMFイベントの通知を受け取ることを望んでいるときに使用されます。この施設の1つの使用は、アプリケーション介入を必要とするDTMF入力について会議の脚を監視することです。たとえば、発信者が話したいと思っているモデレーターに通知する。キープレスイベントは、アプリケーションが文法とタイミングの制約を完全に制御することを望んでいる場合にも使用されます。
When used in a subscription context, the <keypress> element has two attributes, 'report' and 'maskdigits', which are detailed in the list below.
サブスクリプションコンテキストで使用する場合、<keypress>要素には、「レポート」と「マスクディジッツ」という2つの属性があり、以下のリストに詳しく説明されています。
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 レポート - 必須、デフォルト値はありません：可能な値は「標準」、「長い」、「両方」、および「なし」です。「標準」とは、検出された数字を報告する必要があることを意味します。「LONG」とは、長い桁を報告する必要があることを意味します。「長い」数字は、1秒以上、または2秒以内に発生する同じ数字の2つの異なるキープレス（「ダブル」）を1秒以上抑えて定義されます。「両方」とは、「標準」と「長い」桁の両方のイベントが報告されることを意味します。「長い」数字は1つ以上の「通常の」数字で構成されているため、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.
通知のコンテキストで使用する場合、<keypress>要素には、検出されたイベントの詳細を伝えるために使用されるいくつかの属性があります。また、イベントが発生したときに進行中のMSCML要求に関する情報を提供する子要素<status>も含まれています。これらの通知属性の詳細については、以下のリストに記載されています。
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>
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>
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>
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>
Figure 24: Long Keypress Notification
図24：ロングキープレス通知
MSCML supports notification of certain call progress tones through the <signal> element. When used in a subscription context, the <signal> element has two attributes, 'type' and 'report', and no child elements. These attributes are detailed in the list below.
MSCMLは、<signal>要素を介した特定のコールプログレストーンの通知をサポートしています。サブスクリプションコンテキストで使用する場合、<signal>要素には「タイプ」と「レポート」という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 レポート - 必須、デフォルト値なし：指定された信号が報告されるかどうかを制御します。考えられる値は「はい」と「いいえ」です。「はい」に設定すると、メディアサーバーは必要な信号検出コードを呼び出し、検出されたイベントをレポートします。「いいえ」に設定されている場合、メディアサーバーは関連する信号検出コードを無効にし、イベントを報告しません。
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 タイプ - 必須、デフォルト値なし：検出するコールプログレス信号のタイプを指定します。考えられる値は、「ビジー」、「リング」、「CED」、「CNG」、および「400」であり、それぞれビジートーン、着信音、FAX CED、FAX CNG、および400 Hzトーンに対応しています。
NOTE: The details of media server provisioning required to support country-specific variants of 'busy' and 'ring' is not covered by this specification.
注：「ビジー」と「リング」の国固有のバリエーションをサポートするために必要なメディアサーバープロビジョニングの詳細は、この仕様ではカバーされていません。
As stated previously, a single <configure_leg> request MAY contain multiple <signal> elements that request notification of different call progress tones. A single <configure_leg> request SHOULD NOT contain multiple <signal> elements that have the same 'type' attribute value. If the media server receives such a request, it SHOULD honor the last element specifying that type that appears in the request.
前述のように、単一の<configure_leg>要求には、異なるコールプログレストーンの通知を要求する複数の<signal>要素が含まれる場合があります。単一の<configure_leg>要求には、同じ「タイプ」属性値を持つ複数の<signal>要素を含める必要があります。メディアサーバーがそのような要求を受信した場合、リクエストに表示されるタイプを指定する最後の要素を尊重する必要があります。
The media server generates an immediate response to the <configure_leg> subscription request and sends notifications when the specified signals are detected. A single notification is sent as soon as the specified signal has been reliably detected. If the signal persists continuously, additional notifications will not be sent. If the signal is interrupted and then resumes, additional notifications will be sent.
メディアサーバーは、<configure_leg>サブスクリプション要求に対する即時の応答を生成し、指定された信号が検出されたときに通知を送信します。指定された信号が確実に検出されるとすぐに、単一の通知が送信されます。信号が継続的に持続する場合、追加の通知は送信されません。信号が中断されてから再開されると、追加の通知が送信されます。
Signal notifications have a single attribute, "type", as described in the list below.
信号通知には、以下のリストで説明されているように、単一の属性「タイプ」があります。
Signal Notification Attribute:
信号通知属性：
o type - required, no default value: Specifies the type of call progress signal that was detected. Possible values are 'busy', 'ring', 'CED', 'CNG', and '400', which correspond to busy tone, ring tone, fax CED, fax CNG, and 400 Hz tone, respectively.
o タイプ - 必須、デフォルト値なし：検出された呼び出し進行信号のタイプを指定します。考えられる値は、「ビジー」、「リング」、「CED」、「CNG」、および「400」であり、それぞれビジートーン、着信音、FAX CED、FAX CNG、および400 Hzトーンに対応しています。
The following MSCML payloads show a signal event subscription (Figure 25) and notification (Figure 26).
次のMSCMLペイロードは、信号イベントサブスクリプション（図25）と通知（図26）を示しています。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<signal type="busy" report="yes"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
Figure 25: Signal Event Subscription
図25：信号イベントサブスクリプション
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<signal type="busy"/>
</notification>
</MediaServerControl>
Figure 26: Signal Event Notification
図26：信号イベント通知
MSCML uses the <managecontent> request to move recorded content from the media server to remote locations using the HTTP protocol. This is a store-and-forward model, which requires the completion of local temporary recording before the media server can send it to the web server. This facility is useful in applications such as voice messaging, where a message may be reviewed by the caller prior to being committed to persistent storage.
MSCMLは<manageContent>要求を使用して、HTTPプロトコルを使用して、記録されたコンテンツをメディアサーバーからリモートロケーションに移動します。これはストアアンドフォワードモデルであり、メディアサーバーがWebサーバーに送信する前にローカルの一時録音を完了する必要があります。この施設は、マッピングされたストレージにコミットする前に、発信者がメッセージをレビューできる音声メッセージングなどのアプリケーションで役立ちます。
The <managecontent> request contains no child elements and has the attributes described in the list below.
<manageContent>リクエストには、子要素が含まれておらず、以下のリストに記載されている属性があります。
Managecontent Attributes:
管理属性：
o src - required, no default value: Specifies the local source URL of the content. The URL scheme MUST be "file://".
o SRC-必須、デフォルト値なし：コンテンツのローカルソースURLを指定します。URLスキームは「file：//」でなければなりません。
o dest - required (see note), no default value: Specifies the destination URL. The URL scheme MUST be "http://". Note: If the selected action is 'delete', this attribute is optional; otherwise it is required.
o DEST-必須（注を参照）、デフォルト値なし：宛先URLを指定します。URLスキームは「http：//」でなければなりません。注：選択したアクションが「削除」の場合、この属性はオプションです。それ以外の場合は必要です。
o action - optional, default value "move": Specifies the operation for the media server to execute. Values can be either 'move' or 'delete'. The 'delete' action operates on the local source file. After a successful move or delete, the media server deletes the source file from its local storage. If the request is unsuccessful, the source file is not deleted, which gives the client complete control of the retry strategy.
o アクション - オプション、デフォルト値「移動」：メディアサーバーが実行する操作を指定します。値は、「移動」または「削除」のいずれかです。「削除」アクションは、ローカルソースファイルで動作します。移動または削除が成功した後、メディアサーバーはローカルストレージからソースファイルを削除します。リクエストが失敗した場合、ソースファイルは削除されておらず、クライアントに再試行戦略を完全に制御できます。
o httpmethod - optional, default value "post": HTTP protocol method for the media server to use in the HTTP request. The only values are 'post' or 'put'.
o httpmethod-オプション、デフォルト値 "post"：HTTPリクエストでメディアサーバーを使用するHTTPプロトコルメソッド。唯一の値は「POST」または「Put」です。
o name - required (see note), no default value: Specifies the field name for the content in the form when using the 'post' method. This is not to be confused with the "src" or "dest" attributes. Note: This attribute is required when the "htttpmethod" has the value "post" and is optional otherwise.
o 名前 - 必須（メモを参照）、デフォルト値なし：「POST」メソッドを使用する場合、フォームのコンテンツのフィールド名を指定します。これは、「SRC」または「Dest」属性と混同しないでください。注：「htttpmethod」に値「投稿」があり、それ以外の場合はオプションである場合、この属性が必要です。
o fetchtimeout - optional, default value "10000ms": Specifies the maximum time allowed for the transfer to complete. Expressed as a time value (Section 4.2.1) from 1ms onwards.
o FetchTimeout-オプション、デフォルト値「10000ms」：転送が完了するのに許可された最大時間を指定します。1MS以降の時間値（セクション4.2.1）として表されます。
o mimetype - required (see note), no default value: Specifies the MIME type that the media server will use for the content transfer. If it is not provided, the media server MUST try to infer it from the content file extension based on a platform specific mapping table. A non-normative, example mapping table is shown in Table 3. To avoid ambiguity, we RECOMMEND that clients explicitly set this attribute. Note: If the MIME type of the content cannot be inferred from the file extension, this attribute is required.
o MIMETYPE-必須（注を参照）、デフォルト値なし：メディアサーバーがコンテンツ転送に使用するMIMEタイプを指定します。提供されていない場合、メディアサーバーは、プラットフォーム固有のマッピングテーブルに基づいて、コンテンツファイル拡張子から推測しようとする必要があります。非規範的な例のマッピングテーブルを表3に示します。あいまいさを避けるために、クライアントがこの属性を明示的に設定することをお勧めします。注：コンテンツのMIMEタイプをファイル拡張子から推測できない場合、この属性が必要です。
Table 3 shows common audio and video MIME types and possible file extension mappings.
表3は、一般的なオーディオおよびビデオマイムの種類と可能なファイル拡張マッピングを示しています。
+-----------+--------------------+
| 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.
以下は、「Put」メソッドを使用して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>
Figure 27: Managecontent Example Note that the client can change the temporary file name assigned by the media server as part of this operation as shown.
図27：ManageContentの例は、クライアントがこの操作の一部としてメディアサーバーによって割り当てられた一時ファイル名を変更できることに注意してください。
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」ステータスコードを返す必要があります。たとえば、ローカルファイルシステムのアクセス制限により、指定されたファイルの削除を防ぐ場合があります。この場合、応答の「理由」属性は、発生したサーバーエラーの追加の詳細を伝えます。ネットワークまたはリモートサーバーエラーがある場合、メディアサーバーは、メディアサーバーの応答に含まれる<ERRE_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>要求は、メディアサーバーに、回答モードでFAXを処理するように指示します。<PlayRecord>とは別の要求の理由は、メディアサーバーがT.30 [18]またはT.38 [19] Faxプロトコルを処理するために知る必要があることです。
The <faxrecord> request has multiple attributes and one child element, <prompt>. Its attributes are described in the list below.
<FaxRecord>リクエストには、複数の属性と1つの子要素があります<prompt>。その属性については、以下のリストに記載されています。
Attributes of <faxrecord>:
<faxRecord>の属性：
o lclid - optional, default value "" (the empty string): A string that identifies the called station.
o lclid-オプション、デフォルト値 ""（空の文字列）：呼び出されたステーションを識別する文字列。
o prompturl - optional, no default value: The URL of the fax content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
o PROMPTURL-オプション、デフォルト値なし：取得および再生されるFAXコンテンツのURL。ターゲットは、ローカルまたはリモート（nfs）「file：// "スキームURLまたは「http：//」または「https：//」スキームurlです。注：この属性の使用は非推奨です。
o promptencoding - optional, no default value: Specifies the content encoding for files that do not have a 'tif' or 'tiff' extension. The only allowable value is 'tiff'. This attribute only affects "file://" scheme URLs. NOTE: Use of this attribute is deprecated.
o PROSTENTENCODING-オプション、デフォルト値なし：「TIF」または「TIFF」拡張機能がないファイルのコンテンツエンコードを指定します。唯一の許容値は「TIFF」です。この属性は、「file：//」スキームURLSのみに影響します。注：この属性の使用は非推奨です。
o recurl - optional, no default value: Specifies the target URL for the recorded content.
o Recurl-オプション、デフォルト値なし：記録されたコンテンツのターゲットURLを指定します。
o rmtid - optional, no default value: Specifies the calling station identifier of the remote terminal. If present, the media server MUST reject transactions with the remote terminal if the remote terminal's identifier does not match the value of 'rmtid'.
o 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.
クライアントは、FAXコンテンツを指定するために、より柔軟な<prompt>メカニズムを使用する必要があります。「Prompturl」属性の使用は非推奨であり、将来のMSCMLバージョンではサポートされない場合があります。<prompt>要素は、セクション6.1.1で説明されています。<FaxRecord>リクエストで送信される<prompt>要素は、<変数>要素を含めてはなりません。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバーは、「Recurl」属性のローカルおよびリモート（NFS）「ファイル：//」スキームURLをサポートする必要があります。MSCMLは、「http：//」および「https：//」スキームURLを<manageContent>（セクション8）要求を介して間接的にサポートしています。
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つのモードのいずれかで動作します。<prompt>または 'prosputurl'属性と「再 '属性の組み合わせがモードを定義します。表4にこれらのモードを詳細に説明します。テーブルの「プロンプト」列には、要求に<prompt>要素または「prospurl」属性のいずれかがある場合、値「yes」があります。
+--------+--------+---------+---------------------------------------+
| prompt | recurl | Mode | Operation |
+--------+--------+---------+---------------------------------------+
| no | no | Invalid | Request fails. |
| no | yes | Receive | Record the fax to the target URL |
| | | | specified in 'recurl'. |
| yes | no | Poll | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute. If there is a 'rmtid', it |
| | | | MUST match the remote terminal's |
| | | | identifier, or the request will fail. |
| yes | yes | TP | Turnaround Poll (TP) mode. If the |
| | | | remote terminal wishes to transmit, |
| | | | the media server records the fax to |
| | | | the target URL specified in 'recurl'. |
| | | | If the remote terminal wishes to |
| | | | receive, the media server sends the |
| | | | fax from the source URL contained in |
| | | | <prompt> or 'prompturl'. If there is |
| | | | a 'rmtid', it MUST match remote |
| | | | terminal's identifier, or the send |
| | | | request will fail. A receive |
| | | | operation will still succeed, |
| | | | however. |
+--------+--------+---------+---------------------------------------+
Table 4: Fax Receive Modes
表4：FAXの受信モード
In receive mode, the media server receives the fax and writes the fax data to the target URL specified by the 'recurl' attribute.
受信モードでは、メディアサーバーはFAXを受信し、「Recurl」属性で指定されたターゲットURLにFAXデータを書き込みます。
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.
FAXを送信するとき、メディアサーバーは、DISメッセージのファックスを受信できることを宣伝します。同様に、FAXを受信すると、メディアサーバーはDISメッセージにファックスを送信できることを宣伝します。
The media server MUST flush any quarantined digits when it receives a <faxrecord> request.
メディアサーバーは、<FaxRecord>リクエストを受信したときに隔離された数字をフラッシュする必要があります。
The <faxplay> request directs the media server to process a fax in originate mode. The reason for a request separate from <play> is that the media server needs to know to process the T.30 [18] or T.38 [19] fax protocols.
<faxplay>要求は、メディアサーバーに、起源モードでファックスを処理するように指示します。<play>とは別の要求の理由は、メディアサーバーがT.30 [18]またはT.38 [19] Faxプロトコルを処理するために知る必要があるためです。
The <faxplay> request has multiple attributes and one child element, <prompt>. Its attributes are described in the list below.
<faxplay>リクエストには、複数の属性と1つの子要素があります<prompt>。その属性については、以下のリストに記載されています。
Attributes of <faxplay>:
<faxplay>の属性>：
o lclid - optional, default value "" (the empty string): A string that identifies the called station.
o lclid-オプション、デフォルト値 ""（空の文字列）：呼び出されたステーションを識別する文字列。
o prompturl - optional, no default value: The URL of the content to be retrieved and played. The target may be a local or remote (NFS) "file://" scheme URL or an "http://" or "https://" scheme URL. NOTE: Use of this attribute is deprecated.
o PROMPTURL-オプション、デフォルト値なし：取得および再生されるコンテンツのURL。ターゲットは、ローカルまたはリモート（nfs）「file：// "スキームURLまたは「http：//」または「https：//」スキームurlです。注：この属性の使用は非推奨です。
o promptencoding - optional, no default value: Specifies the content encoding for files that do not have a 'tif' or 'tiff' extension. The only allowable value is 'tiff'. This attribute only affects "file://" scheme URLs. NOTE: Use of this attribute is deprecated.
o PROSTENTENCODING-オプション、デフォルト値なし：「TIF」または「TIFF」拡張機能がないファイルのコンテンツエンコードを指定します。唯一の許容値は「TIFF」です。この属性は、「file：//」スキームURLSのみに影響します。注：この属性の使用は非推奨です。
o recurl - optional, no default value: Specifies the target URL for the recorded content.
o Recurl-オプション、デフォルト値なし：記録されたコンテンツのターゲットURLを指定します。
o rmtid - optional, no default value: Specifies the calling station identifier of the remote terminal. If present, the media server MUST reject transactions with the remote terminal if the remote terminal's identifier does not match the value of 'rmtid'.
o 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.
クライアントは、FAXコンテンツを指定するために、より柔軟な<prompt>メカニズムを使用する必要があります。「Prompturl」属性の使用は非推奨であり、将来のMSCMLバージョンではサポートされない場合があります。<prompt>要素は、セクション6.1.1で説明されています。<FaxRecord>リクエストで送信される<prompt>要素は、<変数>要素を含めてはなりません。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバーは、「Recurl」属性のローカルおよびリモート（NFS）「ファイル：//」スキームURLをサポートする必要があります。MSCMLは、「http：//」および「https：//」スキームURLを<manageContent>（セクション8）要求を介して間接的にサポートしています。
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つのモードのいずれかで動作します。<prompt>または 'prosputurl'属性と「再 '属性の組み合わせがモードを定義します。表5にこれらのモードを詳細に説明します。テーブルの「プロンプト」列には、要求に<prompt>要素または「prospurl」属性のいずれかがある場合、値「yes」があります。
+--------+--------+---------+---------------------------------------+
| prompt | recurl | Mode | Operation |
+--------+--------+---------+---------------------------------------+
| no | no | Invalid | Request fails. |
| yes | no | Send | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute. If there is a 'rmtid', it |
| | | | MUST match the remote terminal's |
| | | | identifier, or the request will fail. |
| no | yes | Poll | Send fax from source specified in the |
| | | | <prompt> element or 'prompturl' |
| | | | attribute, assuming the remote |
| | | | terminal specifies it can receive a |
| | | | fax in its DIS message. If the remote |
| | | | terminal does not support reverse |
| | | | polling, the request will fail. If |
| | | | 'rmtid' is specified, it MUST match |
| | | | remote terminal's identifier, or the |
| | | | request will fail. |
| yes | yes | TP | Turnaround Poll (TP) mode. If the |
| | | | remote terminal wishes to transmit, |
| | | | the media server records the fax to |
| | | | the target URL specified in 'recurl'. |
| | | | If the remote terminal wishes to |
| | | | receive, the media server sends the |
| | | | fax from the source URL contained in |
| | | | <prompt> or 'prompturl'. If there is |
| | | | a 'rmtid', it MUST match remote |
| | | | terminal's identifier, or the send |
| | | | request will fail. A receive |
| | | | operation will still succeed, |
| | | | however. |
+--------+--------+---------+---------------------------------------+
Table 5: Fax Send Modes
表5：FAX送信モード
In send mode, the media server sends the fax.
送信モードでは、メディアサーバーが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.
FAXを送信するとき、メディアサーバーは、DISメッセージのファックスを受信できることを宣伝します。同様に、FAXを受信すると、メディアサーバーはDISメッセージにファックスを送信できることを宣伝します。
The media server MUST flush any quarantined digits when it receives a <faxplay> request.
メディアサーバーは、<FaxPlay>リクエストを受信したときに隔離された数字をフラッシュする必要があります。
The media server acknowledges receipt of a client MSCML request sent in a SIP INVITE by sending a response of either 200 OK or 415 Bad Media Type. The media server responds with 415 when the SIP request contains a content type other than "application/sdp" or "application/ mediaservercontrol+xml".
メディアサーバーは、200 OKまたは415の悪いメディアタイプの応答を送信することにより、SIP招待状で送信されたクライアントMSCMLリクエストの受信を確認します。SIPリクエストに「アプリケーション/ SDP」または「アプリケーション/ MediaServerControl XML」以外のコンテンツタイプが含まれている場合、メディアサーバーは415で応答します。
The media server acknowledges receipt of a client MSCML request sent in a SIP INFO with a 200 OK or 415 Bad Media Type. The media server responds with 415 if the INFO request contains a content type other than "application/mediaservercontrol+xml".
メディアサーバーは、200 OKまたは415の悪いメディアタイプを持つSIP情報で送信されたクライアントMSCMLリクエストの受信を確認します。情報要求に「アプリケーション/MediaServerControl XML」以外のコンテンツタイプが含まれている場合、メディアサーバーは415で応答します。
The media server transports the MSCML <response> message in a SIP INFO request.
メディアサーバーは、SIP情報リクエストでMSCML <Response>メッセージを輸送します。
If there is an error in the request or the media server cannot complete the request, the media server sends the <response> message very shortly after receiving the request. If the request is able to proceed, the <response> contains final status information as described below.
リクエストにエラーがある場合、またはメディアサーバーがリクエストを完了できない場合、メディアサーバーはリクエストを受信した直後に<応答>メッセージを送信します。リクエストが続行できる場合、<応答>には以下に説明するように最終的なステータス情報が含まれています。
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 "、" config _leg "、" play "、" playcollect "、" playrecord "、" stop "、" 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は、RFC 3261 [4]で定義されているステータスクラスのサブセットを使用します。MSCMLでは、2xxの応答は成功を示し、4xx応答はクライアントエラーを示し、5xx応答はメディアサーバーのエラーを示します。MSCMLには1xx、3xx、または6xxステータスコードはありません。
o text - required, no default value: The human readable reason phrase associated with the status code.
o テキスト - 必須、デフォルト値なし：ステータスコードに関連付けられた人間の読み取り可能な理由フレーズ。
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>および<stop>リクエストへの応答には、上記の属性のみが含まれます。他の要求に対する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>要素が含まれている場合、応答には、その脚のチームメイトの構成を記述する<チーム>要素が含まれます。<team>要素の属性は、以下のリストに示されています。
Attributes of <team>:
<team>の属性：
o id - required, no default value: The client-defined unique identifier for the conference leg.
o ID-必須、デフォルト値なし：会議脚のクライアント定義の一意の識別子。
o numteam - required, no default value: The number of team members for the leg.
o Numteam-必須、デフォルト値なし：脚のチームメンバーの数。
Additional information on each team member is conveyed by child <teammate> elements contained within <team>. Each teammate is represented by a single element in the list. The <teammate> element has a single attribute, as described below.
各チームメンバーに関する追加情報は、<team>に含まれる子<チームメイト>要素によって伝えられます。各チームメイトは、リスト内の単一の要素で表されます。<teammate>要素には、以下で説明するように、単一の属性があります。
Attributes of <teammate>:
<チームメイト>の属性：
o id - required, no default value: The client-defined unique identifier for the teammate leg.
o ID-必須、デフォルト値なし：チームメイトレッグのクライアント定義の一意の識別子。
In addition to the base response attributes defined in Section 10.2, responses to <play> requests have the additional attributes described in the list below.
セクション10.2で定義されている基本応答属性に加えて、<play>リクエストへの応答には、以下のリストに記載されている追加の属性があります。
MSCML Response Attributes for <play>:
<play>のmscml応答属性：
o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received, and "EOF", indicating that the end of the specified sequence of URLs was reached.
o 理由 - オプション、デフォルト値なし：すぐに完了しない要求の場合、「理由」属性は、コマンドが完了した理由に関する追加情報を伝えます。考えられる値は「停止」され、明示的または暗黙的な<Stop>要求が受信されたことを示し、「EOF」は、指定されたURLの端の終了に到達したことを示します。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout.
o 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 プレーオフセット - 必須、デフォルト値なし：タイム値（セクション4.2.1）は、時間オフセットをPlayが終了した指定されたコンテンツシーケンスに戻す。シーケンスの最初の「オフセット」値が「0」である場合、「再生」と「プレーオフセット」が等しい場合。ただし、初期オフセットに他の価値がある場合、「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.
関連するリクエストが<prompt>の「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 コード - 必須、デフォルト値なし：リモートコンテンツサーバーによって返されるステータスコード。たとえば、Webサーバーは404を返して、要求されたコンテンツが見つからなかったことを示します。
o text - required, no default value: The human-readable reason phrase returned by the remote content server. For example, the reason phrase "Not Found" would be returned if the requested content was not found.
o テキスト - 必須、デフォルト値なし：リモートコンテンツサーバーによって返された人間が読める理由フレーズ。たとえば、要求されたコンテンツが見つからなかった場合、「見つかりません」という理由が返されます。
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>要素は、子<prompt>要素を含む任意のリクエストへの応答に存在する場合があります。
In addition to the base response attributes defined in Section 10.2, responses to <playcollect> requests have the additional attributes described in the list below.
セクション10.2で定義されている基本応答属性に加えて、<PlayCollect>リクエストへの応答には、以下のリストで説明されている追加の属性があります。
MSCML Response Attributes for <playcollect>:
<PlayCollect>のMSCML応答属性：
o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "match", meaning that a DTMF grammar was matched; "timeout", indicating that no DTMF input was received before one of the collection timers expired; and "returnkey" or "escapekey", meaning the DTMF digit mapped to that key was detected and the return key or escape key terminated the operation, respectively.
o 理由 - オプション、デフォルト値なし：すぐに完了しない要求の場合、「理由」属性は、コマンドが完了した理由に関する追加情報を伝えます。可能な値は「停止」され、明示的または暗黙的な<Stop>リクエストが受信されたことを示します。「一致」、つまりDTMF文法が一致したことを意味します。「タイムアウト」。コレクションタイマーの1つが期限切れになる前にDTMF入力が受信されなかったことを示しています。および「ReturnKey」または「EscapeKey」。つまり、そのキーにマッピングされたDTMFディジットが検出され、Return KeyまたはEscapeキーがそれぞれ操作を終了しました。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout. If the caller barged the prompt, this value will reflect the play duration up to that event.
o 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 プレーオフセット - 必須、デフォルト値なし：タイム値（セクション4.2.1）は、時間オフセットをPlayが終了した指定されたコンテンツシーケンスに戻す。シーケンスの最初の「オフセット」値が「0」である場合、「再生」と「プレーオフセット」が等しい場合。ただし、初期オフセットに他の価値がある場合、「PlayOffset」は、クライアントが後続のリクエストで再開するためのブックマークとして機能します。発信者がプロンプトを差し出した場合、この値はバージインが発生したタイムオフセットを反映します。
o digits - required, no default value: Contains the collected DTMF input characters. If no DTMF input was collected, this attribute is set to the empty string ("").
o 数字 - 必須、デフォルト値なし：収集されたDTMF入力文字が含まれます。DTMF入力が収集されていない場合、この属性は空の文字列（ ""）に設定されます。
o name - required (see note), no default value: The client-defined name of the DTMF grammar that was matched. Note: This attribute is required if the "name" attribute was set in the matching DTMF grammar.
o 名前 - 必須（メモを参照）、デフォルト値なし：一致したDTMF文法のクライアント定義の名前。注：この属性は、一致するDTMF文法に「名前」属性が設定されている場合に必要です。
Responses to <playcollect> requests MAY include an <error_info> element, as described in Section 10.4.1.
<playcollect>リクエストへの応答には、セクション10.4.1で説明されているように、<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 理由 - オプション、デフォルト値なし：すぐに完了しない要求の場合、「理由」属性は、コマンドが完了した理由に関する追加情報を伝えます。可能な値は「停止」され、明示的または暗黙的な<Stop>リクエストが受信されたことを示します。「数字」。つまり、DTMF桁が検出され、プロンプトフェーズが確認されたことを意味します。「init_silence」、つまり、入力がないために記録が終了したことを意味します。「end_silence」。つまり、「endilence」タイマーが経過したために記録が終了したことを意味します。「max_duration」は、録音の最大時間に達したことを示しています。「EscapeKey」は、「EscapeKey」にマッピングされたDTMF入力が検出されたことを示し、記録を終了します。および「エラー」、一般的な操作の障害を示します。
o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout. If the caller barged the prompt, this value will reflect the play duration up to that event.
o 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 プレーオフセット - 必須、デフォルト値なし：タイム値（セクション4.2.1）は、時間オフセットをPlayが終了した指定されたコンテンツシーケンスに戻す。シーケンスの最初の「オフセット」値が「0」である場合、「再生」と「プレーオフセット」が等しい場合。ただし、初期オフセットに他の価値がある場合、「PlayOffset」は、クライアントが後続のリクエストで再開するためのブックマークとして機能します。発信者がプロンプトを差し出した場合、この値はバージインが発生したタイムオフセットを反映します。
o digits - required, no default value: Contains the DTMF digit that terminated the recording. If no DTMF input was detected, this attribute is set to the empty string ("").
o 数字 - 必須、デフォルト値なし：記録を終了したDTMF桁が含まれます。DTMF入力が検出されなかった場合、この属性は空の文字列（ ""）に設定されます。
o reclength - required, no default value: The length of the recorded content, in bytes.
o reclength-必須、デフォルト値なし：記録されたコンテンツの長さ、バイト。
o recduration - required, no default value: A time value (Section 4.2.1) indicating the elapsed duration of the recording.
o 再現 - 必須、デフォルト値なし：録音の経過期間を示す時間値（セクション4.2.1）。
Responses to <playrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
<PlayRecord>リクエストへの応答には、セクション10.4.1で説明されているように、<ERRER_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.
セクション10.2で定義されている基本応答属性に加えて、<FaxPlay>および<FaxRecord>リクエストへの応答には、以下のリストで説明されている追加の属性があります。
o reason - required, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "complete", indicating successful completion, even if there were bad lines or minor negotiation problems (e.g., a DCN was received); "disconnect", meaning that the session was disconnected; and "notfax", indicating that no DIS or DCS was received on the connection.
o 理由 - 必須、デフォルト値なし：すぐに完了しない要求の場合、「理由」属性は、コマンドが完了した理由に関する追加情報を伝えます。可能な値は「停止」され、明示的または暗黙的な<Stop>リクエストが受信されたことを示します。「完了」、たとえ悪い回線や軽微な交渉の問題があったとしても、正常に完了したことを示しています（例：DCNが受信されました）。「切断」。つまり、セッションが切断されたことを意味します。「NotFax」は、接続にDISまたはDCSが受信されなかったことを示しています。
o pages_received - required (see note), no default value: Indicates the number of fax pages received. Note: This attribute is required if any pages were received.
o pages_received-必須（注を参照）、デフォルト値なし：受信したFAXページの数を示します。注：ページが受信された場合、この属性が必要です。
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-必須（メモを参照）、デフォルト値なし：送信されたFAXページの数を示します。注：ページが送信された場合、この属性が必要です。
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：ファックスコードマスク
Responses to <faxplay> and <faxrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
セクション10.4.1で説明されているように、<FaxPlay>および<FaxRecord>リクエストへの応答には、<ERRER_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"/>
<xs:element name="managecontent"
type="managecontentRequestType"/>
<xs:element name="faxplay"
type="faxRequestType"/>
<xs:element name="faxrecord"
type="faxRequestType"/>
<xs:element name="stop" type="stopRequestType"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="response" type="responseType"/>
<xs:element name="notification">
<xs:complexType>
<xs:choice>
<xs:element name="conference"
type="conferenceNotificationType"/>
<xs:element name="keypress"
type="keypressNotificationType"/>
<xs:element name="signal"
type="signalNotificationType"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:choice>
<xs:attribute name="version" use="required"/>
</xs:complexType>
</xs:element>
<!-- Definitions for base and concrete MSCML requests -->
<!-- and embedded types. -->
<xs:complexType name="base_requestType" abstract="true">
<xs:attribute name="id" type="xs:string"/>
</xs:complexType>
<xs:complexType name="playRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="offset" type="xs:string"/>
<xs:attribute name="promptencoding" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="configure_conferenceRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="subscribe"
type="conference_eventsubscriptionType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="reservedtalkers"
type="xs:positiveInteger"/>
<xs:attribute name="reserveconfmedia" type="yesnoType"
default="yes"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="configure_legRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="inputgain" type="gainType"
minOccurs="0"/>
<xs:element name="outputgain" type="gainType"
minOccurs="0"/>
<xs:element name="configure_team"
type="configure_teamType" minOccurs="0"/>
<xs:element name="subscribe"
type="leg_eventsubscriptionType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="type">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="talker"/>
<xs:enumeration value="listener"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="mixmode">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="full"/>
<xs:enumeration value="mute"/>
<xs:enumeration value="preferred"/>
<xs:enumeration value="parked"/>
<xs:enumeration value="private"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="dtmfclamp" type="yesnoType"/>
<xs:attribute name="toneclamp" type="yesnoType"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="configure_teamType">
<xs:sequence>
<xs:element name="teammate" type="teammateType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string"/>
<xs:attribute name="action" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="add"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="query"/>
<xs:enumeration value="set"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="teammateType">
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="playcollectRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
<xs:element name="pattern" type="dtmfGrammarType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="offset" type="xs:string"/>
<xs:attribute name="barge" type="yesnoType" default="yes"/>
<xs:attribute name="promptencoding" type="xs:string"/>
<xs:attribute name="cleardigits" type="yesnoType"
default="no"/>
<xs:attribute name="maxdigits" type="xs:string"/>
<xs:attribute name="firstdigittimer" type="xs:string"
default="5000ms"/>
<xs:attribute name="interdigittimer" type="xs:string"
default="2000ms"/>
<xs:attribute name="extradigittimer" type="xs:string"
default="1000ms"/>
<xs:attribute name="interdigitcriticaltimer"
type="xs:string"/>
<xs:attribute name="skipinterval" type="xs:string"
default="6s"/>
<xs:attribute name="ffkey" type="DTMFkeyType"/>
<xs:attribute name="rwkey" type="DTMFkeyType"/>
<xs:attribute name="returnkey" type="DTMFkeyType"
default="#"/>
<xs:attribute name="escapekey" type="DTMFkeyType"
default="*"/>
<xs:attribute name="maskdigits" type="yesnoType"
default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="playrecordRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="promptencoding" type="xs:string"/>
<xs:attribute name="offset" type="xs:string" default="0"/>
<xs:attribute name="barge" type="yesnoType" default="yes"/>
<xs:attribute name="cleardigits" type="yesnoType"
default="no"/>
<xs:attribute name="escapekey" type="xs:string" default="*"/>
<xs:attribute name="recurl" type="xs:string" use="required"/>
<xs:attribute name="mode" default="overwrite">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="append"/>
<xs:enumeration value="overwrite"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="recencoding" type="xs:string"/>
<xs:attribute name="initsilence" type="xs:string"/>
<xs:attribute name="endsilence" type="xs:string"/>
<xs:attribute name="duration" type="xs:string"/>
<xs:attribute name="beep" type="yesnoType" default="yes"/>
<xs:attribute name="recstopmask" type="xs:string"
default="01234567890*#"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="managecontentRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:attribute name="fetchtimeout" type="xs:string"
default="10000"/>
<xs:attribute name="mimetype" type="xs:string"/>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="httpmethod">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="put"/>
<xs:enumeration value="post"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="action">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="move"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="dest" type="xs:string"/>
<xs:attribute name="src" type="xs:string" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="stopRequestType">
<xs:complexContent>
<xs:extension base="base_requestType"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="faxRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="lclid" type="xs:string"/>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="recurl" type="xs:string"/>
<xs:attribute name="rmtid" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="dtmfGrammarType">
<xs:choice>
<xs:element name="regex" type="dtmfPatternType"
maxOccurs="unbounded"/>
<xs:element name="mgcpdigitmap" type="dtmfPatternType"/>
<xs:element name="megacodigitmap" type="dtmfPatternType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="dtmfPatternType">
<xs:attribute name="value" type="xs:string" use="required"/>
<xs:attribute name="name" type="xs:string"/>
</xs:complexType>
<!-- Definitions for base and concrete MSCML responses -->
<!-- and embedded types. -->
<xs:complexType name="base_responseType" abstract="true">
<xs:attribute name="request" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="configure_conference"/>
<xs:enumeration value="configure_leg"/>
<xs:enumeration value="play"/>
<xs:enumeration value="playcollect"/>
<xs:enumeration value="playrecord"/>
<xs:enumeration value="managecontent"/>
<xs:enumeration value="faxplay"/>
<xs:enumeration value="faxrecord"/>
<xs:enumeration value="stop"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="id" type="xs:string"/>
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attribute name="text" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="responseType">
<xs:complexContent>
<xs:extension base="base_responseType">
<xs:sequence>
<xs:element name="error_info"
type="stoponerrorResponseType" minOccurs="0"/>
<xs:element name="team" type="configure_teamResponseType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="reason" type="xs:string"/>
<xs:attribute name="reclength" type="xs:string"/>
<xs:attribute name="recduration" type="xs:string"/>
<xs:attribute name="digits" type="xs:string"/>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="playduration" type="xs:string"/>
<xs:attribute name="playoffset" type="xs:string"/>
<xs:attribute name="faxcode" type="xs:string"/>
<xs:attribute name="pages_sent" type="xs:string"/>
<xs:attribute name="pages_recv" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="stoponerrorResponseType">
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attribute name="text" type="xs:string" use="required"/>
<xs:attribute name="context" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="configure_teamResponseType">
<xs:sequence>
<xs:element name="teammate" type="teammateType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="numteam" type="xs:integer" use="required"/>
</xs:complexType>
<!-- Definitions for MSCML event subscriptions and -->
<!-- embedded types -->
<xs:complexType name="conference_eventsubscriptionType">
<xs:sequence>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="activetalkers"
type="activetalkersSubscriptionType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="activetalkersSubscriptionType">
<xs:attribute name="report" type="yesnoType" use="required"/>
<xs:attribute name="interval" type="xs:string" default="60s"/>
</xs:complexType>
<xs:complexType name="leg_eventsubscriptionType">
<xs:sequence>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="keypress"
type="keypressSubscriptionType" minOccurs="0"
maxOccurs="1"/>
<xs:element name="signal" type="signalSubscriptionType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="keypressSubscriptionType">
<xs:attribute name="report" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
<xs:enumeration value="both"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="maskdigits" type="yesnoType" default="no"/>
</xs:complexType>
<xs:complexType name="signalSubscriptionType">
<xs:attribute name="type" type="xs:NMTOKEN" use="required"/>
<xs:attribute name="report" type="yesnoType" use="required"/>
</xs:complexType>
<!-- Definitions for MSCML event notifications and -->
<!-- embedded types. -->
<xs:complexType name="conferenceNotificationType">
<xs:sequence>
<xs:element name="activetalkers"
type="activetalkersNotificationType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="uniqueid" type="xs:string" use="required"/>
<xs:attribute name="numtalkers" type="xs:string"
use="required"/>
</xs:complexType>
<xs:complexType name="activetalkersNotificationType">
<xs:sequence minOccurs="0">
<xs:element name="talker" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="callid" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="keypressNotificationType">
<xs:sequence>
<xs:element name="status" type="statusType"/>
</xs:sequence>
<xs:attribute name="digit" type="DTMFkeyType" use="required"/>
<xs:attribute name="length" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="method" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="standard"/>
<xs:enumeration value="long"/>
<xs:enumeration value="double"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="interdigittime" type="xs:string"
use="required"/>
</xs:complexType>
<xs:complexType name="statusType">
<xs:attribute name="command" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="idle"/>
<xs:enumeration value="play"/>
<xs:enumeration value="collect"/>
<xs:enumeration value="record"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="duration" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="signalNotificationType">
<xs:attribute name="type" use="required" fixed="busy"/>
</xs:complexType>
<!-- Definitions for miscellaneous embedded, helper data types -->
<xs:complexType name="promptType">
<xs:choice maxOccurs="unbounded">
<xs:element name="audio" type="promptcontentType"/>
<xs:element name="variable" type="spokenvariableType"/>
</xs:choice>
<xs:attribute name="locale" type="xs:string"/>
<xs:attribute name="baseurl" type="xs:string"/>
<xs:attribute name="stoponerror" type="yesnoType" default="no"/>
<xs:attribute name="gain" type="xs:string" default="0"/>
<xs:attribute name="gaindelta" type="xs:string" default="0"/>
<xs:attribute name="rate" type="xs:string" default="0"/>
<xs:attribute name="ratedelta" type="xs:string" default="0"/>
<xs:attribute name="repeat" type="xs:string" default="1"/>
<xs:attribute name="duration" type="xs:string"
default="infinite"/>
<xs:attribute name="offset" type="xs:string" default="0"/>
<xs:attribute name="delay" type="xs:string" default="0"/>
</xs:complexType>
<xs:complexType name="promptcontentType">
<xs:attribute name="url" type="xs:string" use="required"/>
<xs:attribute name="encoding" type="xs:string"/>
<xs:attribute name="gain" type="xs:string" default="0"/>
<xs:attribute name="gaindelta" type="xs:string" default="0"/>
<xs:attribute name="rate" type="xs:string" default="0"/>
<xs:attribute name="ratedelta" type="xs:string" default="0"/>
</xs:complexType>
<xs:complexType name="spokenvariableType">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="dat"/>
<xs:enumeration value="dig"/>
<xs:enumeration value="dur"/>
<xs:enumeration value="mth"/>
<xs:enumeration value="mny"/>
<xs:enumeration value="num"/>
<xs:enumeration value="sil"/>
<xs:enumeration value="str"/>
<xs:enumeration value="tme"/>
<xs:enumeration value="wkd"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="subtype">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="mdy"/>
<xs:enumeration value="dmy"/>
<xs:enumeration value="ymd"/>
<xs:enumeration value="ndn"/>
<xs:enumeration value="t12"/>
<xs:enumeration value="t24"/>
<xs:enumeration value="USD"/>
<xs:enumeration value="gen"/>
<xs:enumeration value="ndn"/>
<xs:enumeration value="crd"/>
<xs:enumeration value="ord"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
<xs:simpleType name="yesnoType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
<xs:enumeration value="1"/>
<xs:enumeration value="0"/>
<xs:enumeration value="true"/>
<xs:enumeration value="false"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="DTMFkeyType">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]"/>
<xs:pattern value="[A-D]"/>
<xs:pattern value="[a-d]"/>
<xs:pattern value="#"/>
<xs:pattern value="\*"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="gainType">
<xs:choice>
<xs:element name="auto" type="autogainType"/>
<xs:element name="fixed" type="fixedgainType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="autogainType">
<xs:attribute name="startlevel" type="xs:string"/>
<xs:attribute name="targetlevel" type="xs:string"/>
<xs:attribute name="silencethreshold" type="xs:string"/>
</xs:complexType>
<xs:complexType name="fixedgainType">
<xs:attribute name="level" type="xs:string"/>
</xs:complexType>
</xs:schema>
12.1. IANA Registration of MIME Media Type application/ mediaservercontrol+xml
12.1. MIMEメディアタイプアプリケーションのIANA登録/ MediaServerControl XML
MIME media type name: application MIME subtype name: mediaservercontrol+xml Required parameters: none Optional parameters: charset
MIMEメディアタイプ名：アプリケーションMIMEサブタイプ名：MediaServerControl XML要求パラメーター：なしオプションパラメーター：charset
charset This parameter has identical semantics to the charset parameter of the "application/xml" media type, as specified in XML Media Types [8].
charsetこのパラメーターには、XMLメディアタイプで指定されているように、「アプリケーション/XML」メディアタイプのcharsetパラメーターに対して同一のセマンティクスがあります[8]。
Encoding considerations: See RFC 3023 [8]. Interoperability considerations: See RFC 2023 [8] and RFC 5022. Published specification: 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
考慮事項のエンコード：RFC 3023 [8]を参照してください。相互運用性の考慮事項：RFC 2023 [8]およびRFC5022を参照してください。公開された仕様：このメディアタイプを使用するRFC 5022アプリケーション：マルチメディア、拡張会議、インタラクティブアプリケーション。詳細については個人および電子メールアドレス：eburger@cantata.com [31]意図の使用：共通
Because media flows through a media server in a conference, the media server itself MUST protect the integrity, confidentiality, and security of the sessions. It should not be possible for a conference participant, on her own behalf, to be able to "tap in" to another conference without proper authorization.
メディアは会議でメディアサーバーを流れるため、メディアサーバー自体はセッションの整合性、機密性、セキュリティを保護する必要があります。会議参加者が自分に代わって、適切な承認なしに別の会議に「タップ」することができるようにすることはできません。
Because conferencing is a high-value application, the media server SHOULD implement appropriate security measures. This includes, but is not limited to, access lists for application servers. That is, the media server only allows a select list of application or proxy servers to create conferences, to invite participants to sessions, etc. Note that the mechanisms for such security, like private networks, shared certificates, MAC white/black lists, are beyond the scope of this document.
会議は価値の高いアプリケーションであるため、メディアサーバーは適切なセキュリティ対策を実装する必要があります。これには、アプリケーションサーバーのアクセスリストが含まれますが、これらに限定されません。つまり、メディアサーバーは、アプリケーションまたはプロキシサーバーの選択リストのみを使用して会議を作成し、参加者をセッションに招待します。プライベートネットワーク、共有証明書、Mac White/Blackリストなど、このようなセキュリティのメカニズムはこのドキュメントの範囲を超えて。
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が会議の範囲を持つリクエストを、会議ごとに別のコントロールレッグに制限する重要な理由の1つです。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.
参加者は、申請への招待のおかげで、申請に暗黙の承認を与えます。ただし、1つのサービスのユーザーと別のサービスの明確なクライアントとの間に、明示的または暗黙的な信頼はありません。
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メッセージは、招待された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.
クレジットカード番号やその他の識別情報など、収集されたデータの敏感な性質のため、メディアサーバーはSIPS：およびTLSをサポートする必要があります。おそらく、彼らが収集する情報の価値とユーザーのプライバシーの期待を知っているクライアントは、アプリケーションのニーズに応じて、クリアなテキスト信号または暗号化された安全な信号を自由に使用できます。同様に、メディアサーバーは、安全なリアルタイムトランスポートプロトコル（SRTP）[9]をサポートする必要があります。繰り返しますが、クライアントは、適切なレベルのメディアセキュリティを自由に交渉できます。
The media management facilities of MSCML, such as the <managecontent> (Section 8) request, assume a trust relationship between the media server and file server. This scenario is similar to the one addressed by URLAUTH [20]. Namely, the media server is acting on behalf of a given user, yet the media server does not have credentials for that user. One might be tempted to use the user:pass facility of the HTTP URI to offer per-user security, but that also requires that the media server be secure, as the media server would need to know the user credentials in a form that is easily compromised (clear text passwords).
<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ライティングのユーザーごとまたは一人ごとの許可を提供する方法を調査しています[21]。ただし、その作業が完了するまで、適切な認証手段を使用して、ファイルおよびWebサーバーに自分自身を認証するためにメディアサーバーの実装を準備する必要があります。少なくとも、メディアサーバーはHTTPSの基本認証をサポートする必要があります。実装者は、メディアサーバーがファイルサーバーが必要とするあらゆる認証メカニズムに適切に応答する必要があることに注意する必要があります。
As this is an XML markup, all the security considerations of RFC 3023 [8] apply.
これはXMLマークアップであるため、RFC 3023 [8]のすべてのセキュリティ上の考慮事項が適用されます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[2] Burger、E.、van Dyke、J。、およびA. Spitzer、「SIP付きの基本ネットワークメディアサービス」、RFC 4240、2005年12月。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3] Donovan、S。、「The SIP Info Method」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、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] 2001年3月、ITU-T J.162、ITU-T J.162を使用したケーブルテレビネットワークを介したタイムクリティカルサービスの配信のためのネットワークコールシグナル伝達プロトコル。
[6] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[6] Groves、C.、Pantaleo、M.、Anderson、T。、およびT. Taylor、「Gateway Control Protocolバージョン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] Thompson、H.、Beech、D.、Maloney、M。、およびN. Mendelsohn、「XML Schema Part 1：Structures」、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] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[9] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[10] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[10] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[11] Carter, J., Danielsen, P., Hunt, A., Ferrans, J., Lucas, B., Porter, B., Rehor, K., Tryphonas, S., McGlashan, S., and D. Burnett, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C REC REC-voicexml20-20040316, March 2004.
[11] Carter、J.、Danielsen、P.、Hunt、A.、Ferrans、J.、Lucas、B.、Porter、B.、Rehor、K.、Tryphonas、S.、McGlashan、S。、およびD. Burnett、「Voice Extensible Markup Language（VoiceXML）バージョン2.0」、W3C Rec Rec-VoiceXML20-20040316、2004年3月。
[12] International Packet Communications Consortium, "IPCC Reference Architecture V2", June 2002.
[12] 国際パケット通信コンソーシアム、「IPCCリファレンスアーキテクチャV2」、2002年6月。
[13] European Telecommunications Standards Institute, "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 23.228 version 7.2.0 Release 7)", December 2005.
[13] 欧州通信基準研究所、「デジタルセルラーテレコミュニケーションシステム（フェーズ2）、ユニバーサルモバイル通信システム（UMTS）; IPマルチメディアサブシステム（IMS）;ステージ2（3GPP TS 23.228バージョン7.2.0リリース7）、2005年12月。
[14] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[14] Hollenbeck、S.、Rose、M。、およびL. Masinter、「IETFプロトコル内の拡張マークアップ言語（XML）の使用に関するガイドライン」、BCP 70、RFC 3470、2003年1月。
[15] Jacobs, I., Lie, H., Bos, B., and C. Lilley, "Cascading Style Sheets, level 2 (CSS2) Specification", W3C REC REC-CSS2- 19980512, May 1998.
[15] Jacobs、I.、Lie、H.、Bos、B。、およびC. Lilley、「Cascading Style Sheets、レベル2（CSS2）仕様」、W3C Rec Rec-CSS2- 19980512、1998年5月。
[16] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[16] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議州のセッション開始プロトコル（SIP）イベントパッケージ」、RFC 4575、2006年8月。
[17] Cable Television Laboratories, Inc., "Audio Server Protocol", January 2005.
[17] Cable Television Laboratories、Inc。、「Audio Server Protocol」、2005年1月。
[18] "Procedures for document facsimile transmission in the general switched telephone network", Recommendation T.30, April 1999.
[18] 「一般的な切り替え電話ネットワークにおけるドキュメントファクシミリ送信の手順」、推奨T.30、1999年4月。
[19] "Procedures for real-time Group 3 facsimile communication over IP networks", Recommendation T.38, March 2002.
[19] 「IPネットワークを介したリアルタイムグループ3ファクシミリ通信の手順」、推奨T.38、2002年3月。
[20] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[20] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - Urlauth Extension」、RFC 4467、2006年5月。
[21] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[21] Dusseault、L.、ed。、「Web分散オーサリングとバージョン（WebDav）のHTTP拡張機能」、RFC 4918、2007年6月。
[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] Institute of Electrical and Electronics Engineers、「情報技術 - ポータブルオペレーティングシステムインターフェイス（POSIX） - パート1：基本定義、第9章」、IEEE Standard 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] Burger、E。and M. Dolly、「キープレス刺激用のセッション開始プロトコル（SIP）イベントパッケージ（KPML）」、RFC 4730、2006年11月。
[24] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[24] Klensin、J。、「Simple Mail Transfer Protocol」、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] Campbell、B.、ed。、Mahy、R.、ed。、およびC. Jennings、ed。、「The Message Session Relay Protocol」、Work in Progress、2007年2月。
URIs
ウリス
[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>
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で使用される正規表現構文は、桁の正規表現（DREGEX）と呼ばれるPOSIX拡張正規表現（ERE）[22]のテレフォニー指向のサブセットです。この構文は、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、 *、＃、およびa-D（ケース非感受性） *文字＃マッチング＃＃文字[文字セレクター]の一致セレクター[range1-range2]のキャラクターは、range1からrange2までの範囲のキャラクターと一致します。インクルーシブXは、任意の任意の数字を一致します0-9 {m}前のパターンのm繰り返し{m、}は、前のパターンのm {、n}の繰り返しを一致させます{、n}は、最大のn（ゼロを含む）の繰り返し{mで一致します{m {m、n}少なくともm、およびせいぜい前のパターンのnの繰り返しl regex式式に「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の例
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.
ジェフ・ヴァン・ダイクとアンディ・スピッツァーは、Snowshore Networks、Inc。のMSCMLのコンセプト、開発、ドキュメント、および実行を行いました。実装。メアリー・アン・リークリーは、パーソナライズされたミックス機能とその他のいくつかの拡張機能を実装しました。
Cliff Schornak of Commetrex and Jeff Van Dyke developed the facsimile service.
CommetrexのCliff SchornakとJeff Van Dykeはファクシミリサービスを開発しました。
Jai Cauvet, Rolando Herrero, Srinivas Motamarri, and Ashish Patel contributed greatly by testing MSCML.
Jai Cauvet、Rolando Herrero、Srinivas Motamarri、Ashish Patelは、MSCMLをテストすることで大きく貢献しました。
The following individuals provided valuable assistance in the direction, development, or debugging of MSCML:
次の個人は、MSCMLの方向、開発、またはデバッグに貴重な支援を提供しました。
o Brian Badger and Phil Crable from Verizon Business o Stephane Bastien from BroadSoft o Peter Danielsen of Lucent Technologies o Kevin Flemming, formerly of SnowShore Networks, Inc. o Wesley Hicks and Ravindra Kabre, formerly from Sonus Networks o Jon Hinckley from SkyWave/Sestro o Terence Lobo, formerly of SnowShore Networks, Inc. o Kunal Nawale, formerly of SnowShore Networks, Inc. o Edwina Nowicki, formerly of SnowShore Networks, Inc. o Diana Rawlins and Sharadha Vijay, formerly of WorldCom o Gaurav Srivastva and Subhash Verma from BayPackets o Kevin Summers from Sonus Networks o Tim Wong from at&t
o Verizon BusinessのBrian Badger and Phil Crable o Broadsoft O Lucent TechnologiesのPeter DanielsenのStephane Bastien o Kevin FlemmingのPeter Danielsen、以前はSnowshore Networks、Inc。O Wesley Networks and Ravindra Kabreは、以前はSonus Networks o Jon HinckleyのSkywave/Sestro O Tereenceロボ、以前はSnowshore Networks、Inc。O Kunal NawaleのLobo、以前はSnowshore Networks、Inc。O Edwina NowickiのOf Snowshore Networks、Inc。O Diana RawlinsとSharadha VijayのEdwina Nowiciと、以前はWorldcom O Gaurav SrivastvaおよびSubhash vermaのSharadha Vijayでした。Sonus NetworksのKevin Summers oティムウォンAT＆T
The authors would like to thank Cullen Jennings and Dan Wing from Cisco Systems for their helpful review comments.
著者は、Cisco SystemsのCullen JenningsとDan Wingに役立つレビューのコメントに感謝したいと思います。
The authors would also like to thank Scotty Farber for applying her technical writing expertise to the documentation of MSCML.
著者はまた、MSCMLの文書に彼女の技術執筆の専門知識を適用してくれたScotty Farberに感謝したいと思います。
Authors' Addresses
著者のアドレス
Jeff Van Dyke Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
ジェフ・ヴァン・ダイク・カンタータ・テクノロジー、18キーウェイディン・ドクター・セーラム、ニューハンプシャー03079 USA
EMail: jvandyke@cantata.com
Eric Burger (editor) BEA Systems, Inc. USA
Eric Burger（Editor）Bea Systems、Inc。USA
Email: eburger@standardstrack.com
URI: http://www.standardstrack.com
Andy Spitzer Bluesocket Inc. 10 North Avenue Burlington, MA 01803 USA
Andy Spitzer Bluesocket Inc. 10 North Avenue Burlington、MA 01803 USA
EMail: woof@pingtel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。