RFC4722 日本語訳
4722 Media Server Control Markup Language (MSCML) and Protocol. J. VanDyke, E. Burger, Ed., A. Spitzer. November 2006. (Format: TXT=184055 bytes) (Obsoleted by RFC5022) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Van Dyke
Request for Comments: 4722 E. Burger, Ed.
Category: Informational Cantata Technology, Inc.
A. Spitzer
Pingtel Corporation
November 2006
コメントを求めるワーキンググループJ.ヴァンダイク要求をネットワークでつないでください: エド4722年のE.バーガー、カテゴリ: 情報のカンタータのInc.A.スピッツァーPingtel社の技術2006年11月
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
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.
メディアServer Control Markup Language(MSCML)は高度な会議と対話的な声の応答(IVR)機能を提供するのにSIPに関連して使用されるマークアップ言語です。 MSCMLはデバイスレベルコントロールモデルと対照的にアプリケーションレベルコントロールモデルを提示します。 このプロトコルの1つの使用が会議焦点とミキサーとのコミュニケーションのためにIETF SIP Conferencing Frameworkにあります。
Van Dyke, et al. Informational [Page 1] RFC 4722 MSCML November 2006
ヴァンダイク、他 [1ページ]情報のRFC4722MSCML2006年11月
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
1. 序論…4 1.1. このドキュメントで中古のコンベンション…5 2. MSCMLはアプローチします…5 3. 一口要求メソッドの使用…6 4. MSCMLデザイン…8 4.1. トランザクションモデル…8 4.2. XML用法…9 4.2.1. MSCML時間的価値…9 5. 会議を進めます…10 5.1. コンファレンスモデル…10 5.2. コンファレンス要求<が_会議>を構成するのを構成してください…11 5.3. 脚の要求<が_脚の>を構成するのを構成してください…13 5.4. コンファレンスを終えます…14 5.5. コンファレンス操作…15 5.6. ビデオ会議…16 5.7. コンファレンスイベント…17 5.8. 個人化されるのを伴う会議は混入します…18 5.8.1. 個人化されたミックスのためのMSCML要素と属性…19 5.8.2. 個人化されることの例の用法は混入します…20 6. 対話的な声の応答(IVR)…23 6.1. 迅速な内容を指定します…24 6.1.1. 迅速な要素の使用…24 6.2. IVRのためのマルチメディア処理…30 6.3. プレーしている発表<は>をプレーします…31 6.4. <playcollect>をうながして、集めてください…32 6.4.1. ケタバッファリングと中ではしけで運ぶコントロール…33 6.4.2. 特別番組のDTMFキーを写像するのは機能します…33 6.4.3. 収集タイマ…35 6.4.4. 伐採訪問者DTMF入力…36 6.4.5. DTMF文法を指定します…36 6.4.6. Playcollect応答…37 6.4.7. Playcollectの例…38 6.5. <playrecord>をうながして、記録してください…38 6.5.1. フェーズをうながしてください…38 6.5.2. フェーズを記録してください…39 6.5.3. Playrecordの例…41 6.6. 要求<停止>を止めてください…42 7. 脚のイベントに電話をしてください…43 7.1. Keypressイベント…43 7.1.1. Keypress購読の例…45 7.1.2. Keypress通知の例…45 7.2. イベントに合図してください…46 7.2.1. イベントの例に合図してください…47 8. 内容<managecontent>を管理します…48 8.1. Managecontentの例…50
Van Dyke, et al. Informational [Page 2] RFC 4722 MSCML November 2006
ヴァンダイク、他 [2ページ]情報のRFC4722MSCML2006年11月
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
9. ファックスで、処理を送ってください…51 9.1. ファックス<faxrecord>を記録します…51 9.2. ファックス<faxplay>を送ります…53 10. MSCML応答属性と要素…56 10.1. メカニズム…56 10.2. <応答>属性を基礎づけてください…56 10.3. <のための応答属性と要素は_脚の>を構成します…57 10.4. <のための応答属性と要素は>をプレーします…57 10.4.1. 満足している検索誤りを報告します…58 10.5. <playcollect>のための応答属性と要素…59 10.6. <playrecord>のための応答属性と要素…60 10.7. <managecontent>のための応答属性と要素…61 10.8. <faxplay>のための応答属性と要素と<faxrecord>…61 11. 正式な構文…62 11.1. 図式…62 12. IANA問題…73 12.1. MIMEメディアTypeアプリケーション/mediaservercontrol+xmlのIANA Registration…73 13. セキュリティ問題…74 14. 参照…75 14.1. 標準の参照…75 14.2. 有益な参照…76付録A.Regex文法構文…78 付録B.貢献者…79 付録C.承認…79
Van Dyke, et al. Informational [Page 3] RFC 4722 MSCML November 2006
ヴァンダイク、他 [3ページ]情報のRFC4722MSCML2006年11月
1. Introduction
1. 序論
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.
このドキュメントはメディアServer Control Markup Language(MSCML)とその用法を説明します。 それは、これらのペイロードが実装する標準のSIP INVITE、INFOメソッド、および能力を使用することで1つがメディアサーバに送ることができるペイロードについて説明します。 RFC4240[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ベースの高められた会議を提供する標準の方法がありませんでした。 RFC4240[2]で説明されたものなどの基本的なSIP構造物は簡単なn-道の会議によく役立ちます。 SIP URIは特定のSIP会議を特定するのに自然なメカニズムを提供します、メソッドが上品に会議を実装するINVITEとBYEは意味論を接合して、残しますが。 しかしながら、また、高められた会議アプリケーションはサイズ処理やリサイズなどの特徴、コネ会議IVR操作(例えば、完全な会議に関与している名前を記録して、プレーする)、および会議イベント報告を必要とします。 標準のSIPメソッドの中のMSCMLペイロードはこれらの特徴がわかります。
The structure and approach of MSCML satisfy the requirements set out in RFC 4353 [10]. In particular, MSCML serves as the interface between the conference server or focus and a centralized conference mixer. In this case, a media server has the role of the conference mixer.
MSCMLの構造とアプローチはRFC4353[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つの広いクラスがあります。 一流は会議構成や、関与している脚の操作や、会議イベント報告などの高度な会議のための基関数を含んでいます。 二等は対話的な声の応答(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.
一般に、メディアサーバはApplication Serversや、Feature Serversや、メディアゲートウェイControllersなどのSIP UACsに対するサービスを提供します。 これらの用語の定義に関してIPCC Reference Architecture[12]を見てください。ありそうもないのですが、エンドユーザSIP UACsのために、メディアサーバとのダイレクトシグナリング関係を持っているのは、禁止されていません。「クライアント」という用語は、一般的にSIPとMSCMLを使用することでメディアサーバと対話する実体について言及するのに本書では使用されます。
Van Dyke, et al. Informational [Page 4] RFC 4722 MSCML November 2006
ヴァンダイク、他 [4ページ]情報のRFC4722MSCML2006年11月
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.
[13] 3GPPによって説明されるようにメディアサーバはIP Multimedia Subsystem(IMS)にメディアResource Function(MRF)の役割を実現させます。 MSCMLとRFC4240[2](MSCMLは建てる)は明確にアプリケーション論理とMRFとの相互作用をサポートするメディアリソース(さん)インタフェースに焦点を合わせられます。
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ベースのサービスを作成しています。 XCON[29]はグループを扱います、そして、IMS[30]は3GPPで働いています、そして、この経験はIETFの進行中の仕事に非常に関連しています、特にSIP[26]、SIPPING[27]、MMUSIC[28]、CCXMLはW3CのVoice Browser Work Groupで働いています。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. MSCML Approach
2. MSCMLアプローチ
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.
まず最初に、プログラミングモデルはマスター奴隷よりむしろピアツーピアのものです。 重要に、これは、メディアサーバが同時に複数のアプリケーションに1ポイントのコントロールに結ばれるよりむしろ使用されるのを許容します。 また、それは、標準の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.
2番目に、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パラダイムは開発者社会に重要です、開発者とオペレータが概念的に呼び出し、会議、および呼び出し脚に関するアプリケーションを書くので。 開発者とアプリケーションの大部分のために、このアプローチは、開発をかなり簡素化して、促進します。
Van Dyke, et al. Informational [Page 5] RFC 4722 MSCML November 2006
ヴァンダイク、他 [5ページ]情報のRFC4722MSCML2006年11月
3. Use of SIP Request Methods
3. 一口要求メソッドの使用
As mentioned above, MSCML payloads may be carried in either SIP INVITE or INFO requests. The initial INVITE, which creates an enhanced conference, MAY include an MSCML payload. A subsequent INVITE to the same Request-URI joins a participant leg to the conference. This INVITE MAY include an MSCML payload. The initial INVITE that establishes an IVR session MUST NOT include an MSCML payload. The client sends all mid-call MSCML payloads for conferencing and IVR via SIP INFO requests.
以上のように、MSCMLペイロードはSIP INVITEかINFO要求のどちらかで運ばれるかもしれません。 初期のINVITE(高められた会議を創設する)はMSCMLペイロードを含むかもしれません。 同じRequest-URIへのその後のINVITEは関与している脚を会議に接合します。 このINVITE MAYはMSCMLペイロードを含んでいます。 IVRセッションを確立する初期のINVITEはMSCMLペイロードを含んではいけません。 クライアントは会議とIVRのためにSIP INFO要求ですべての中間の呼び出しに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とSession記述プロトコル(SDP)身体の部分の両方を含むSIP INVITE要求が会議シナリオで頻繁に使用されます。 したがって、メディアサーバはSIP INVITE要求で「複合か混ぜられた」MIMEの種類でメッセージ本体を支えなければなりません。
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 INVITEへの最終的な応答かSIP INFOメッセージにおけるMSCML応答を輸送します。 メッセージ本体を含むSIP INFOへの唯一の許容できる最終的な応答が200OKです、RFC2976[3]単位で。 したがって、クライアントがSIP INFOを通してMSCML要求を送るなら、メディアサーバは別々のINFO要求におけるMSCML応答で反応します。 一般に、これらの応答は、現実に非同期であり、タイミング問題のため別々のトランザクションを必要とします。
There has been considerable debate on the use of the SIP INFO method for any purpose. Our experience is that MSCML would not have been possible without it. At the time the first MSCML specification was published, the first SIP Event Notification draft had just been submitted as an individual submission. At that time, there was no mechanism to link SUBSCRIBE/NOTIFY to an existing dialog. This prevented its use in MSCML, since all events occurred in an INVITE- established dialog. And while SUBSCRIBE/NOTIFY was well suited for reporting conference events, its semantics seemed inappropriate for modifying a participant leg or conference setting where the only "event" was the success or failure of the request. Lastly, since SIP INFO was an established RFC, most SIP stack implementations supported it at that time. We had few, if any, interoperability issues as a result.
SIP INFOメソッドのどんな目的の使用に関するかなりの討論もありました。 私たちの経験はMSCMLがそれなしで可能でなかっただろうということです。 最初のMSCML仕様を発表したとき、個々の服従としてちょうど最初のSIP Event Notification草稿を提出したところでした。 その時、登録、/NOTIFYを既存の対話にリンクするために、メカニズムは全くありませんでした。 すべてのイベントがINVITEの確立した対話で起こったので、これはMSCMLにおける使用を防ぎました。 そして、登録、/NOTIFYである間、会議イベントであり、意味論が見えたと報告するのに関与している脚を変更するために不適当な状態でよく合うか、会議設定が唯一の「イベント」が要求の成否であったところにありましたか? ほとんどのSIPスタック実装が、SIP INFOが確立したRFCであったので、その時、最後に、それをサポートしました。 私たちには、わずかしかその結果、どんな、相互運用性問題であるならもありませんでした。
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.
より最近の開発はMSCMLにおける使用に適切な状態で登録、/NOTIFYがである追加理由を提供しました。 登録、プレゼントtwo問題1番目はそうです。使用、意味的です。 目的、登録、Userエージェント状態への関心を示すことになっています。 登録、使用して、MSCMLが中で結果になるのでしかしながら、登録、Userエージェント状態を変更します。 2番目が、登録と推論する、適切でないのは本来MSCMLが基づく呼び出しであるからです。 呼び出し脚があるSIP対話の協会は、MSCMLが信じられないほど簡単である場合があることを意味します。
Van Dyke, et al. Informational [Page 6] RFC 4722 MSCML November 2006
ヴァンダイク、他 [6ページ]情報のRFC4722MSCML2006年11月
For example, if one used SUBSCRIBE or other SIP method to send commands about some context, one must identify that context somehow. Relating commands to the SIP dialog they arrive on defines the context for free. Moreover, it is conceptually easy for the developer. Using NOTIFY to transport MSCML responses is also not appropriate, as the NOTIFY would be in response to an implicit subscription. The SIP and SIPPING lists have discussed the dangers of implicit subscription.
例えば1である、中古である、登録、何らかの、発信するSIPメソッドは何らかの文脈に関して命令して、どうにかその文脈を特定しなければなりません。 それらが到着するSIP対話にコマンドに関連すると、文脈はただで定義されます。 そのうえ、開発者には、それは概念的に簡単です。 また、MSCML応答を輸送するのにNOTIFYを使用するのも適切ではありません、NOTIFYが暗黙の購読に対応しているだろうというとき。 SIPとSIPPINGリストは暗黙の購読という危険について議論しました。
In order to guarantee interoperability with this specification, as well as with SIP User Agents that are unaware of MSCML, SIP UACs that wish to use MSCML services MUST specify a service indicator that supports MSCML in the initial INVITE. RFC 4240 [2] defines the service indicator "conf", which MUST be used for MSCML conferencing applications. The service indicator "ivr" MUST be used for MSCML interactive voice response applications. In this specification, only "conf" and "ivr" are described.
この仕様、およびMSCMLに気づかないSIP Userエージェントと共に相互運用性を保証するために、MSCMLサービスを利用したがっているSIP UACsは初期のINVITEでMSCMLをサポートするサービスインディケータを指定しなければなりません。 RFC4240[2]はサービスインディケータ"conf"を定義します。(MSCML会議アプリケーションにそれを使用しなければなりません)。 MSCMLの対話的な音声応答アプリケーションにサービスインディケータ"ivr"を使用しなければなりません。 この仕様では、"conf"と"ivr"だけ、が説明されます。
The media server MUST support moving the call between services through sending the media server a BYE on the existing dialog and establishing a new dialog with an INVITE to the desired service. Media servers SHOULD support moving between services without requiring modification of the previously established SDP parameters. This is achieved by sending a re-INVITE on the existing dialog in which the Request-URI is modified to specify the new service desired by the client. This eliminates the need for the client to send an INVITE to the caller or gateway to establish new SDP parameters.
メディアサーバは、移行が電話することであると既存の対話でメディアサーバにBYEを送って、INVITEと共に新しい対話を必要なサービスに確立するのによるサービスの間でサポートしなければなりません。 SHOULDがサポートするサービスの間で以前に確立したSDPパラメタの変更を必要としないで移行するメディアサーバ。 これは、Request-URIがクライアントによって望まれていた新しいサービスを指定するように変更される既存の対話に再INVITEを送ることによって、達成されます。 これはクライアントが新しいSDPパラメタを証明するために訪問者かゲートウェイにINVITEを送る必要性を排除します。
The media server, as a SIP UAS, MUST respond appropriately to an INVITE that contains an MSCML body. If MSCML is not supported, the media server MUST generate a 415 final response and include a list of the supported content types in the response per RFC 3261 [4]. The media server MUST also advertise its support of MSCML in responses to OPTIONS requests, by including "application/mediaservercontrol+xml" as a supported content type in an Accept header. This alleviates the major issues with using INFO for the transport of application data; namely, the User Agent's proper interpretation of what is, by design, an opaque message request.
SIP UASとして、メディアサーバは適切にMSCMLボディーを含むINVITEに反応しなければなりません。 MSCMLがサポートされないなら、メディアサーバは、RFC3261[4]あたりの応答に415の最終的な応答を生成して、サポートしているcontent typeのリストを含まなければなりません。 また、メディアサーバはOPTIONS要求への応答における、MSCMLのサポートの広告を出さなければなりません、サポートしているcontent typeとしてAcceptヘッダーに「アプリケーション/mediaservercontrol+xml」を含んでいることによって。 これはアプリケーションデータの輸送にINFOを使用する大変な問題を軽減します。 すなわち、何に関するUserエージェントの適切な解釈は故意に不明瞭なメッセージ要求であるか。
Van Dyke, et al. Informational [Page 7] RFC 4722 MSCML November 2006
ヴァンダイク、他 [7ページ]情報のRFC4722MSCML2006年11月
4. MSCML Design
4. MSCMLデザイン
4.1. Transaction Model
4.1. トランザクションモデル
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番目は1つのMSCMLボディーだけがSIP要求に存在しているかもしれないということです。 2番目はそれぞれのMSCMLボディーが1つの要求か応答だけを含むかもしれないということです。 これはトランザクション管理を大いに簡素化します。 MSCML構文はただ一つの身体の部分での複数の要求のユニークな識別に備えます。 しかしながら、これはこの仕様でサポートされません。
Per the guidelines of RFC 3470 [14], MSCML bodies MUST be well formed and valid.
RFC3470[14]のガイドラインに従って、MSCMLボディーは、整形式であって有効であるに違いありません。
MSCML is a direct request-response protocol. There are no provisional responses, only final responses. A request may, however, result in multiple notifications. For example, a request for active talker reports will result in a notification for each speaker set. This maps to the three major element trees for MSCML: <request>, <response>, and <notification>.
MSCMLはダイレクト要求応答プロトコルです。 どんな暫定的な応答もなくて、唯一の決勝は応答です。 しかしながら、要求は複数の通知をもたらすかもしれません。 例えば、アクティブな話し手レポートに関する要求はそれぞれのスピーカーセットのための通知をもたらすでしょう。 これはMSCMLのために3多量栄養素に木を写像します: <要求>、<応答>、および<通知>。
Figure 1 shows a request body. Depending on the command, one can send the request in an INVITE or an INFO. Figure 2 shows a response body. The SIP INFO method transports response bodies. Figure 3 shows a notification body. The SIP INFO method transports notifications.
図1は要求本体を示しています。 コマンドによって、1つはINVITEかINFOでの要求を送ることができます。 図2は応答本体を示しています。 SIP INFOメソッドは応答本体を輸送します。 図3は通知本体を示しています。 SIP INFOメソッドは通知を輸送します。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
... request body ...
</request>
</MediaServerControl>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ><MediaServerControlバージョンは「1インチの><要求>…要求ボディー」と等しいです… </要求></MediaServerControl>。
Figure 1: MSCML Request Format
図1: MSCMLは書式を要求します。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<response>
... response body ...
</response>
</MediaServerControl>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ><MediaServerControlバージョンは「1インチの><応答>…応答ボディー」と等しいです… </応答></MediaServerControl>。
Figure 2: MSCML Response Format
図2: MSCML応答形式
Van Dyke, et al. Informational [Page 8] RFC 4722 MSCML November 2006
ヴァンダイク、他 [8ページ]情報のRFC4722MSCML2006年11月
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<notification>
... notification body ...
</notification>
</MediaServerControl>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ><MediaServerControlバージョンは「1インチの><通知>…通知ボディー」と等しいです… </通知></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に使用される値は要求が出される対話の範囲の中でユニークであるだけでよいです。
4.2. XML Usage
4.2. XML用法
In the philosophy of XML as a text-based description language, and not as a programming language, MSCML makes the choice of many attribute values for readability by a human. Thus, many attributes that would often be "boolean" instead take "yes" or "no" values. For example, what does 'report="false"' or 'report="1"' mean? However, 'report="yes"' is clearer: I want a report. Some programmers prefer the precision of a boolean. To satisfy both styles, MSCML defines an XML type, "yesnoType", that takes on the values "yes" and "no" as well as "true", "false", "1", and "0".
プログラミング言語ではなく、テキストベースの記述言語としてのXMLの哲学では、MSCMLは読み易さのために人間で多くの属性値の選択をします。 したがって、しばしば「論理演算子」である多くの属性が代わりに「はい」か「いいえ」値を取ります。 例えば、何がそうするかは'=が「誤っている」と報告する'か、'「1インチ'が意味するレポート=?」 しかしながら、'「はい」というレポート='は、より明確です: 私は、レポートが欲しいと思います。 論理演算子の精度を好むプログラマもいます。 両方のスタイルを満たすために、MSCMLはXMLタイプ、「本当である」としてまた、値「はい」と「いいえ」を呈する"yesnoType"を定義します、「誤っている」、「1インチ、および「0インチ。」
Many attributes in the MSCML schema have default values. In order to limit demands on the XML parser, MSCML applies these values at the protocol, not XML, level. The MSCML schema documents these defaults as XML annotations to the appropriate attribute.
MSCML図式の多くの属性に、デフォルト値があります。 XMLパーサの上で要求を制限するために、MSCMLはXML、レベルではなく、プロトコルにおけるこれらの値を適用します。 MSCML図式はXML注釈としてこれらのデフォルトを適切な属性に記録します。
4.2.1. MSCML Time Values
4.2.1. MSCML時間的価値
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の時間的価値は名称がCascadingスタイルシートでレベル2(CSS2) 仕様[15]を説明した時に基づいています。 それらの形式は以下のフォームの任意のタイム・ユニット識別子がすぐにあとに続いた数から成ります:
ms: milliseconds (default)
s: seconds
ms: ミリセカンド(デフォルト)s: 秒
If no time unit identifier is present, the value MUST be interpreted as being in milliseconds. As extensions to [15] MSCML allows the string values "immediate" and "infinite", which have special meaning for certain timers.
どんなタイム・ユニット識別子も存在していないなら、ミリセカンドであって、値を解釈しなければなりません。 [15]への拡大として、MSCMLは「即座で」「無限」でストリング値を許容します(あるタイマのための特別な意味があります)。
Van Dyke, et al. Informational [Page 9] RFC 4722 MSCML November 2006
ヴァンダイク、他 [9ページ]情報のRFC4722MSCML2006年11月
5. Advanced Conferencing
5. 高度な会議
5.1. Conference Model
5.1. コンファレンスモデル
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はエンドユーザのUACsの間の典型的なシグナリング関係、会議アプリケーション・サーバー、およびメディアサーバについて表現します。
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.
RFC4353[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 |---/ | |
+-------+ +--------------+
+-------+ | UAC1|---\公共のURI+-------------+ +-------+ \ _____________| アプリケーション| / / | サーバ| 目立ちません: +-------+ / / +-------------+ RTPは直接流れます。| UAC2|---/ / | UACsと+の間で個人的です。-------+ / | URIメディアサーバ/+--------------+ : / | | +-------+ / | メディアサーバ| | 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はPublicコンファレンスURIにINVITEを送ります。 おそらく、クライアントはこのURIを発行するか、それが臨時のURIです。 約束を守るのは、RFC4240[2]でとにかく、クライアントが兵士のURIを生成すると指定しました。 すなわち、URIは以下のフォームのものです:
sip:conf=UniqueID@ms.example.net
一口: 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
UniqueIDがどこのユニークな会議識別子と原稿example.netであるかはメディアサーバのホスト名かIPアドレスです。何もUACsがメディアに連絡するのを防ぐものがありません。
Van Dyke, et al. Informational [Page 10] RFC 4722 MSCML November 2006
ヴァンダイク、他 [10ページ]情報のRFC4722MSCML2006年11月
server directly. However, one would expect the owner of the media
server to restrict who can use its resources.
サーバ、直接。 しかしながら、人はリソースを使用できる制限するメディアサーバの所有者を予想するでしょう。
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.
RFC4240[2]によって説明された基本的な会議に関して、UniqueIDとのメディアサーバへの最初のINVITEは会議を創設します。 高度な会議における最初のINVITE MAYがどのようにMSCML<を含んでも、_会議の参加者のSDPよりむしろ会議>ペイロードを構成してください。 <は、_会議>ペイロードが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.
_会議>ペイロード、結果として起こるSIP対話は「コンファレンスコントロール脚」と呼ばれます。会議がMSCML<を含むINVITEを送ることによって創設されたら、This脚には数個の役に立つ特性があるのを構成してください。 会議の寿命はコントロール脚のものと同じです。これは、すべての関与している脚がいなくなる、またはまだ到着していなくても会議が現存していたままで残っているのを確実にします。 さらに、クライアントがコンファレンスControl Legを終えると、メディアサーバは自動的にすべての関与している脚を終えます。 また、コンファレンスControl Legは全体の会議からの/へのプレーか記録的な操作と活発な話し手通知に使用されます。 コンファレンスControl Legで完全な会議メディア操作と活発な話し手レポート購読を実行しなければなりません。
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.
完全な高度な会議能力がそれなしで利用可能でないので、コンファレンスControl Legの作成はRECOMMENDEDです。 クライアントは会議を創設する初期のINVITEにコンファレンスControl Legを設立しなければなりません。 後でそれを作成できません。
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.
クライアントがコンファレンスControl Legのあるなしにかかわらずいったん会議を創設すると、関係者に会議で加わることができます。 クライアントが各関係者のために兵士のコンファレンスURIにINVITEを向けることによって、これは達成されます。 上に与えられた例の会議URIを使用して、これは一口でしょう: confは UniqueID@ms.example.net と等しいです。
5.2. Configure Conference Request <configure_conference>
5.2. コンファレンス要求<が_会議>を構成するのを構成してください。
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.
<は、_会議>要求にはメディアサーバが傍らに会議に設定するリソースを制御する2つの属性があるのを構成します。 これらは以下のリストで説明されます。
Attributes of <configure_conference>:
<の属性は_会議>を構成します:
o reservedtalkers - optional (see note), no default value: The
maximum number of talker legs allocated for the conference. Note:
o reservedtalkers--任意であることで(注意を見ます)、どんなデフォルトも以下を評価しません。 会議のために割り当てられた話し手脚の最大数。 以下に注意してください。
Van Dyke, et al. Informational [Page 11] RFC 4722 MSCML November 2006
ヴァンダイク、他 [11ページ]情報のRFC4722MSCML2006年11月
required when establishing the Conference Control Leg but optional
in subsequent <configure_conference> requests.
その後の<でControl Legの、しかし、任意のコンファレンスを確立するとき、必要であることで、_会議>要求を構成してください。
o reserveconfmedia - optional, default value "yes": Controls
allocation of resources to enable playing or recording to or from
the entire conference
o reserveconfmedia--任意のデフォルト値「はい」: 会議、または、全体の会議からプレーか録音を可能にするためにリソースの配分を制御します。
When the reservedtalkers+1st INVITE arrives at the media server, the media server SHOULD generate a 486 Busy Here response. Failure to send a 486 response to this condition can cause the media server to oversubscribe its resources.
reservedtalkers+最初のINVITEがメディアサーバに到着すると、メディアサーバSHOULDは486Busy Here応答を生成します。 486応答をこの状態に送らない場合、メディアサーバにoversubscribeへのリソースを引き起こす場合があります。
NOTE: It would be symmetric to have a reservedlisteners parameter.
However, the practical limitation on the media server is the
number of talkers for a mixer to monitor. In either case, the
client regulates who gets into the conference by either proxying
the INVITEs from the user agent clients or metering to whom it
gives the conference URI.
以下に注意してください。 reservedlistenersパラメタを持っているのは左右対称でしょう。 しかしながら、メディアサーバにおける実用的な制限はミキサーがモニターする話し手の数です。 どちらの場合ではも、クライアントはユーザエージェントのクライアントからINVITEsをproxyingすることによってだれが会議に興味を持つか、そして、それが会議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>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ「はい」/></要求></MediaServerControl「><MediaServerControlバージョンは「1インチの><要求><は_会議reservedtalkers=を構成する」という120と等しく」reserveconfmedia=>。
Figure 6: 120 Speaker MSCML Example
図6: 120議長MSCML Example
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.
これらに加えた属性、<は、_含むかもしれない>が子供<を要求する会議が>要素を申し込むのを構成します。 <は、会議全体のアクティブな話し手イベントのための通知を要求するために使用される>要素を申し込みます。 アクティブな話し手イベントの詳細な情報はセクション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.
クライアントは<を入れなければなりません。_>がコンファレンスControl Legを作成するとき会議を設立する初期のINVITEで要求する会議を構成してください。クライアントサーバは、あいまいな応答を避けるために別々に(すなわち、INFOメッセージで)<プレー>などの非同期なコマンドを発行しなければなりません。
Media operations on the Conference Control leg are performed internally, no external RTP streams are involved. Accordingly, the
コンファレンスControl脚におけるメディア操作は内部的に実行されて、どんな外部のRTPストリームもかかわりません。 それに従って
Van Dyke, et al. Informational [Page 12] RFC 4722 MSCML November 2006
ヴァンダイク、他 [12ページ]情報のRFC4722MSCML2006年11月
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.
メディアサーバはコンファレンスControl Legの上のRTPを予想しません。したがって、クライアントがSDPを全く送ってはいけない、さもなければ、<を含むINVITE要求における保持SDPは_会議>ペイロードを構成します。 メディアサーバは系列が「不活発に」設定するすべてのメディアかアドレスが0.0に設定する接続と共にSDPを扱わなければなりません。.0 .0 (遅れている互換性のための) 保持SDPとして。
The media server sends a response when it has finished processing the <configure_conference> request. The format of the <configure_conference> response is detailed in Section 10.2.
<を処理し終えたとき、サーバが応答を送るメディアは_会議>要求を構成します。 <の形式は、_会議>応答がセクション10.2で詳細であることを構成します。
5.3. Configure Leg Request <configure_leg>
5.3. 脚の要求<が_脚の>を構成するのを構成してください。
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.
コンファレンス脚には、クライアントが変更できる多くの特性があります。 これらによる<を使用するセットが_脚の>要求を構成するということです。 この要求には、以下のリストで説明された属性があります。
Attributes of <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>.
これらの属性に加えて、<が_脚の>を構成するので定義された4つの子供要素があります。 これらは<inputgain>です、そして、<outputgain>、<は_チーム>を構成します、そして、<は>を申し込みます。
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
最初の2(<inputgain>と<outputgain>)は、オーディオがそれぞれ流す入出力に適用された利得を変更します。 これらは、自動利得制御(AGC)か>が修理された<を使用するために<の自動>を含むかもしれません。 <の自動>要素には、属性"startlevel"、"targetlevel"、および"silencethreshold"があります。 すべてのパラメタがdBにあります。 >要素が固定された<は属性「レベル」を持っています。(それは、dBにあります)。 <inputgain>と<outputgain>の両方のためのデフォルトは>が修理された<です。 メディアサーバはそうするかもしれません。
Van Dyke, et al. Informational [Page 13] RFC 4722 MSCML November 2006
ヴァンダイク、他 [13ページ]情報のRFC4722MSCML2006年11月
silently cap <inputgain> or <outputgain> requests that exceed the gain limits imposed by the platform.
静かにプラットホームによって課された利得限界を超えている<inputgain>か<outputgain>要求にふたをしてください。
Clients most commonly manipulate only the input gain for a conference leg and rely on the mixer to set an optimum output gain based on the inputs currently in the mix. However, as described above, MSCML does allow for manipulation of the output gain as well. Some of the IVR commands, such as <play>, enable control of the output gain for content playback operations. The interaction of conference output gain and IVR playback gain controls is described in Section 6.1.1. Note that <inputgain> and <outputgain> settings apply only to conference legs and do not apply to IVR sessions.
クライアントは、会議脚のために最も一般的に入力利得だけを操って、現在ミックスにおける入力に基づく最適生産量利得を設定するためにミキサーを当てにします。 しかしながら、上で説明されるように、MSCMLはまた、出力利得の操作を考慮します。 <プレー>などのIVRコマンドのいくつかが満足している再生操作のために出力利得のコントロールを可能にします。 会議出力利得とIVR再生利得制御の相互作用はセクション6.1.1で説明されます。 <inputgain>と<outputgain>設定は会議脚だけに適用して、IVRセッションに適用されないことに注意してください。
The <configure_team> element is used to create and manipulate groups for personalized mixes. Details of personalized mixes are discussed in Section 5.8.
<は、_チーム>要素が個人化されたミックスのためにグループを創設して、操るのに使用されるのを構成します。 セクション5.8で個人化されたミックスの詳細について議論します。
The <subscribe> element is used to request notifications for call leg related events, such as asynchronous DTMF digit reports. Detailed information regarding call leg events is discussed in Section 7.
<は、呼び出し脚のための通知が非同期なDTMFケタレポートなどのイベントを関係づけたよう要求するために使用される>要素を申し込みます。 セクション7で呼び出し脚のイベントの詳細な情報について議論します。
If the default parameters are acceptable for the leg the client wishes to enter into the conference, then a normal SIP INVITE, with no MSCML body, is sufficient. However, if the client wishes to modify one or more of the parameters, the client can include a MSCML body in addition to the SDP body.
クライアントが会議に入れたがっている脚において、デフォルトパラメタが許容できるなら、正常なSIP INVITEはMSCMLボディーなしで十分です。 しかしながら、クライアントがパラメタの1つ以上を変更したいなら、クライアントはSDPボディーに加えたMSCMLボディーを入れることができます。
The client can modify the conference leg parameters during the conference by issuing a SIP INFO on the dialog representing the conference leg. Of course, the client cannot modify SDP in an INFO message.
クライアントは、会議の間、会議脚を表しながら対話でSIP INFOを発行することによって、会議脚のパラメタを変更できます。もちろん、クライアントはINFOメッセージでSDPを変更できません。
The media server sends a response when it has finished processing the <configure_leg> request. The format of the <configure_leg> response is detailed in Section 10.3.
<を処理し終えたとき、サーバが応答を送るメディアは_脚の>要求を構成します。 <の形式は、_脚の>応答がセクション10.3で詳細であることを構成します。
5.4. Terminating a Conference
5.4. コンファレンスを終えます。
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.
クライアントは、会議でコンファレンスControl Legに関するSIP BYE要求を出すことによって、すべての脚を終えることができます。メディアサーバがコンファレンスControl Legに関するSIP BYE要求を受け取るとき、1人以上の関係者がまだ会議中であるなら、メディアサーバは脚のクリーンアップを確実にするというすべての残っている会議脚に関する要求をSIP BYEに出します。
Van Dyke, et al. Informational [Page 14] RFC 4722 MSCML November 2006
ヴァンダイク、他 [14ページ]情報のRFC4722MSCML2006年11月
The media server returns a 200 OK to the SIP BYE request as it sends BYE requests to the other legs. This is because we cannot issue a provisional response to a non-INVITE request, yet the teardown of the other legs may exceed the retransmission timer limits of the original request. While the conference is being cleaned up, the media server MUST reject any new INVITEs to the terminated conference with a 486 Busy Here response. This response indicates that the specified conference cannot accept any new members, pending deletion.
他の脚への要求をBYEに送るとき、メディアサーバは200OKをSIP BYE要求に返します。 これが私たちが非INVITE要求への暫定的な応答を発行できないからであるしかし、他の脚の分解はオリジナルの要求の再送信タイマー限界を超えるかもしれません。 会議がきれいにされている間、メディアサーバは486Busy Here応答との終えられた会議にどんな新しいINVITEsも拒絶しなければなりません。 この応答は、指定された会議が削除までどんな新しいメンバーも受け入れることができないのを示します。
5.5. Conference Manipulation
5.5. コンファレンス操作
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対話で命令を出すことによって、全体で会議か特定の関与している脚を操ることができます。 例えば、メディアサーバが記録するクライアントが要求できるコンファレンスControl Legに関するMSCML要求に会議を送ることによって、会議にプロンプトをプレーするか、またはアクティブな話し手イベントに関するレポートを要求してください。 同様に、クライアントは、関与している脚に音を消すか、個人化されたミックスを構成するか、または呼び出し脚のイベントのためのレポートを要求するかもしれません、DTMF keypressesなどのように。
Figure 7 shows an example of an MSCML command that plays a prompt to all conference participants.
図7は会議参加者全員にプロンプトをプレーするMSCMLコマンドに関する例を示しています。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<play>
<prompt>
<audio url="http://prompts.example.net/en_US/welcome.au"/>
</prompt>
</play>
</request>
</MediaServerControl>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ><MediaServerControlバージョン= 「1インチの><要求><プレー迅速な>の><オーディオurl=" http://prompts.example.net/en_US/welcome.au "/></迅速な><</プレー></要求></MediaServerControl>」
Figure 7: Full Conference Audio Command - Play
図7: 完全なコンファレンスオーディオコマンド--プレーしてください。
A client can modify a leg by issuing an INFO on the dialog associated with the participant leg. For example, Figure 8 mutes a conference leg.
クライアントは、関与している脚に関連している対話でINFOを発行することによって、脚を変更できます。例えば、図8は会議脚に音を消します。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_leg mixmode="mute"/>
</request>
</MediaServerControl>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ「><MediaServerControlバージョンは「1インチの><要求><は_脚のmixmode=を構成する」という無言と等しく」/></要求></MediaServerControl>。
Figure 8: Sample Change Leg Command
エイト環: サンプル手前を変えコマンド
Van Dyke, et al. Informational [Page 15] RFC 4722 MSCML November 2006
ヴァンダイク、他 [15ページ]情報のRFC4722MSCML2006年11月
In Figure 7, we saw a request to play a prompt to the entire conference. The client can also request to play a prompt to an individual call leg. In that case, the MSCML request is issued within the SIP dialog of the desired conference participant.
私たちは全体の会議にプロンプトをプレーするという図7の、要求を見ました。 また、クライアントは個々の呼び出し脚へのプロンプトをプレーに要求できます。その場合、MSCML要求は必要な会議の参加者のSIP対話の中で出されます。
Section 6 describes the interactive voice response (IVR) services offered by MSCML. If an IVR command arrives on the control channel, it takes effect on the whole conference. This is a mechanism for playing prompts to the entire conference (e.g., announcing new participants). If an IVR command arrives on an individual leg, it only affects that leg. This is a mechanism for interacting with users, such as the creation of "waiting rooms", allowing a user to mute themselves using key presses, allowing a moderator to out-dial, etc.
セクション6はMSCMLによって提供された対話的な声の応答(IVR)サービスについて説明します。 IVRコマンドが制御チャンネルで到着するなら、それは全体の会議で効きます。 これは、全体の会議(例えば、新しい関係者を発表する)にプロンプトをプレーするためのメカニズムです。 IVRコマンドが個々の脚で到着するなら、それはその脚に影響するだけです。これはユーザと対話するためのメカニズムです、「待合室」の作成などのように、ユーザが自分たちに音を消すのを主要なプレスを使用することで許容して、出ているダイヤルなどに議長を許容して
A participant leg MUST be configured with mixmode="parked" prior to
the issuance of any IVR commands with prompt content ('prompturl'
attribute or <prompt> element). Parking the leg isolates the
participant's input and output media from the conference and allows
use of those streams for playing and recording purposes. However,
the mixmode has no effect if just digit collection or recording is
desired. <playcollect> and <playrecord> requests without prompt
content MAY be sent on participant legs without setting
mixmode="parked".
どんなIVRコマンドの発行の前にも迅速な内容('prompturl'属性か<の迅速な>要素)で「駐車される」mixmode=で関与している脚を構成しなければなりません。 脚を駐車すると、関係者の入力とアウトプット・メディアが会議から隔離されて、それらのストリームの目的をプレーして、記録する使用は許されます。 しかしながら、まさしくケタ収集か録音が望まれているなら、mixmodeは効き目がありません。 迅速な内容のない要求が関与している脚でmixmode=を設定しないで送られるかもしれない<playcollect>と<playrecord>は「駐車しました」。
5.6. Video Conferencing
5.6. ビデオ会議
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によって制御された高度な会議、およびRFC4240の[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メディアを使う別の関係者からビデオを受け取らないでしょう。 SHOULDが関係者の間のメディア非互換性を最小にするためにビデオコード変換を実装するメディアサーバ。
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).
メディアサーバはリフレッシュしなければなりません。aを受けるときだけ、スイッチビデオストリームはビデオフレームをリフレッシュします。 Aはリフレッシュします。フレームは情報がそのフレームを解読するのを必要としたすべてのビデオを含んでいます(依存が全く前のビデオフレームからのデータにありません)。
Van Dyke, et al. Informational [Page 16] RFC 4722 MSCML November 2006
ヴァンダイク、他 [16ページ]情報のRFC4722MSCML2006年11月
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を伝えるよう要求する標準のメカニズムは、急速にビデオを切り換えることができるのを保証するためにフレームをリフレッシュします。
5.7. Conference Events
5.7. コンファレンスイベント
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.
クライアントはどの関係者が会議ミックスに含まれているかを示した周期的なアクティブな話し手イベントレポートを予約できます。 これらが会議レベルイベントであるので、購読と通知をコンファレンス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.
メディアサーバは最小間隔に性能理由によるアクティブな話し手レポートのために限界を課すかもしれません。 クライアント要求が課された最小限の下にあるなら、メディアサーバSHOULDはサポートされた最小値に間隔を設定します。 不要な通知トラフィックを制限するために、会議のためのアクティブな話し手情報が報告間隔の間、変化していないなら、メディアサーバSHOULD NOTはレポートを送ります。
A request for an active talker report is in Figure 9. The active talker report enumerates the current call legs in the mix.
アクティブな話し手レポートに関する要求が図9にあります。 アクティブな話し手レポートはミックスで現在の呼び出し脚を数え上げます。
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
<configure_conference>
<subscribe>
<events>
<activetalkers report="yes" interval="60s"/>
</events>
</subscribe>
</configure_conference>
</request>
</MediaServerControl>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ</イベント></が></を申し込む「><MediaServerControlバージョンははいと「1インチの><要求><は、_会議><が><イベント><activetalkersレポート=を申し込むのを構成する」という等しく」間隔=「60年代」/>を_会議></要求></MediaServerControl>を構成します。
Figure 9: Active Talker Request
図9: 活発な話し手要求
Event notifications are sent in SIP INFO messages. Figure 10 shows an example of a report.
SIP INFOメッセージでイベント通知を送ります。 図10はレポートに関する例を示しています。
Van Dyke, et al. Informational [Page 17] RFC 4722 MSCML November 2006
ヴァンダイク、他 [17ページ]情報のRFC4722MSCML2006年11月
<?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>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ><MediaServerControlバージョン=、「1インチ><通知><会議uniqueid="ab34h76z"numtalkersが等しい、「47インチの><activetalkers><話し手callid="myhost4sn123"/><話し手callid="myhost2sn456"/><話し手callid=「myhost12sn78"/></activetalkers></会議></通知></MediaServerControl>」
Figure 10: Active Talker Event Example
図10: アクティブな話し手イベントの例
The value of the "callid" attribute in the <talker> element corresponds to the value of the SIP Call-ID header of the associated dialog. This enables the client to associate the active talker with a specific participant leg.
<話し手>要素の"callid"属性の値は関連対話のSIP Call-IDヘッダーの値に対応しています。 これは、クライアントが特定の関与している脚に活発な話し手を関連づけるのを可能にします。
5.8. Conferencing with Personalized Mixes
5.8. 個人化されたミックスがある会議
MSCML enables clients to create personalized mixes through the <configure_team> element for scenarios where the standard mixmode settings do not provide sufficient control. The <configure_team> element is a child of <configure_leg>.
MSCMLは、クライアントが<を通して個人化されたミックスを作成するのを可能にします。シナリオのために標準のmixmode設定が十分なコントロールを提供しないところで_チーム>要素を構成してください。 <は、_チーム>要素が<の子供が_脚の>を構成するということであることを構成します。
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. チームメンバー(<チームメート>要素)のリストであり、<を使用するセットが_チーム>を構成します。
2. The mixmode attribute set through <configure_leg>
2. <を通して設定された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.
チーム関係はそれとなく左右対称です。 クライアントが関係者Bのチームメンバーとして関係者Aを設定するなら、メディアサーバはAのためのチームメンバーとして自動的に関係者Bを設定します。
Van Dyke, et al. Informational [Page 18] RFC 4722 MSCML November 2006
ヴァンダイク、他 [18ページ]情報のRFC4722MSCML2006年11月
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.
<を通して設定されたイド属性は、_脚の>が様々な関係者を特定するのに使用されるのを構成します。 個人化されたミックスに各関係者を含んでいるのに固有のIDを割り当てなければなりません。 使用されるIDはそれらが現れる会議の範囲の中でユニークであるに違いありません。
By itself, the team list only defines those participants that the leg can hear. The mixmode attribute of each team member determines whether to include their audio input in the personalized mix. If the client sets the teammate's mixmode to private, then it is part of the mix. If the mixmode is set to any other value, it is not.
チームリスト自体は脚が聞くことができる声それらの関係者を定義するだけです。 それぞれのチームメンバーのmixmode属性は、個人化されたミックスにおける彼らの音声入力を含んでいるかどうか決定します。 クライアントがチームメートのmixmodeを個人的に設定するなら、それはミックスの一部です。 mixmodeがいかなる他の値にも用意ができているなら、それは用意ができていません。
5.8.1. MSCML Elements and Attributes for Personalized Mixes
5.8.1. 個人化されたミックスのためのMSCML要素と属性
Control of personalized mixes rely on two major MSCML elements:
個人化されたミックスのコントロールは2つの主要なMSCML要素を当てにします:
1. <configure_leg>, using the mixmode attribute setting
mixmode="private"
1. 「個人的に」mixmode属性設定mixmode=を使用して、<は_脚の>を構成します。
2. <configure_team>
2. <は_チーム>を構成します。
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.
<は、_ユーザが特定の会議の中でチーム>要素でチームのメンバーを関係者にすることができるのを構成します。 <の子供が_脚の>親要素を構成するということです。
The client sends the <configure_team> element in a <configure_leg> request in either a SIP INVITE or SIP INFO.
クライアントは発信します。<は、_<のチーム>要素が_SIP INVITEかSIP INFOのどちらかでの脚の>要求を構成するのを構成します。
o In an INVITE, to join a participant whose properties differ from
the properties established for the conference as a whole.
o INVITEで特性が全体で会議のために確立された特性と異なっている関係者に加わるために。
o In an INFO, to change the properties for an existing leg.
o INFOでは、存在のために資産を変えるために、急いで歩いてください。
The two attributes of the configure_team element are "id" and "action". The id attribute MUST contain the unique ID of the leg being modified, as set in the original <configure_leg> request. The action attribute can take on the values "add", "delete", "query", and "set". The default value is "query". This attribute allows the user to modify the team list. Table 1 describes the actions that can be performed on the team list.
2つの属性、_チーム要素が「イド」と「動作」であると構成してください。 変更されていて、オリジナルの<のセットが_脚の>要求を構成するとき、イド属性は脚の固有のIDを含まなければなりません。 動作属性は「加えてください」、「削除」が「質問し」て、「設定する」値を呈することができます。 デフォルト値は「質問」です。 この属性で、ユーザはチームリストを変更できます。 テーブル1はチームリストに実行できる動作について説明します。
Van Dyke, et al. Informational [Page 19] RFC 4722 MSCML November 2006
ヴァンダイク、他 [19ページ]情報のRFC4722MSCML2006年11月
+--------+----------------------------------------------------------+ | 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. | +--------+----------------------------------------------------------+
+--------+----------------------------------------------------------+ | 動作| 記述| +--------+----------------------------------------------------------+ | 加えてください。| ミックスにチームメートを加えます。 | | 削除します。| ミックスからチームメートを削除します。 | | 質問| チームメートリストを要請者に返します。 これはそうです。| | | デフォルト値。 | | セットします。| <チームメートイド=があとに続いているとチームリストを作成する、「n">"| | | また、チームリストからすべてのチームメートを外します。| | | 例えば、時はチームのクリエイター(創始者)です。| | | そんなに特定の会議脚の必需品に記載して、すべてを取り除いてください。| | | チームからのチームメートについて。 集合演算です。| | | 関係者からすべてのチームメートを外す、それ| | | 関係者は、完全な会議が混入するのを聞きます。 | +--------+----------------------------------------------------------+
Table 1: Configure Team Actions
テーブル1: チーム動作を構成してください。
5.8.2. Example Usage of Personalized Mixes
5.8.2. 個人化されたミックスの例の用法
A common use of personalized mixing is to support coaching of one participant by another. The coaching scenario includes three participants: 1. The Supervisor, who coaches the agent. 2. The Agent, who interacts with the customer. 3. The Customer, who interacts with the agent.
個人化された混合の一般の使用は別のものによる1人の関係者のコーチをサポートすることです。 コーチしているシナリオは3人の関係者を含んでいます: 1. Supervisor。(そのSupervisorはエージェントをコーチします)。 2. エージェント。(そのエージェントは顧客と対話します)。 3. Customer。(そのCustomerはエージェントと対話します)。
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 | +-------------+------------+------------+---------+-----------------+
+-------------+------------+------------+---------+-----------------+ | 関係者| ID| チーム| Mixmode| 聞きます。| | | | メンバー| | | +-------------+------------+------------+---------+-----------------+ | 監督| 監督| エージェント| 個人的| 顧客+| | | | | | エージェント| | エージェント| エージェント| 監督| 完全| 顧客+| | | | | | 監督| | 顧客| 顧客| なし| 完全| エージェント| +-------------+------------+------------+---------+-----------------+
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. クライアントは各脚に会議で加わって、<に固有のIDを含んでいるのが確かであることが_脚の>要求を構成します。 脚のIDは、それが属する会議の範囲だけの中で特有である必要があります。
Van Dyke, et al. Informational [Page 20] RFC 4722 MSCML November 2006
ヴァンダイク、他 [20ページ]情報のRFC4722MSCML2006年11月
2. The client configures the teammate list and mixmode of each
participant, as required.
2. クライアントは必要に応じてそれぞれの関係者のチームメートリストとmixmodeを構成します。
Both actions (steps 1 and 2) may be combined in a single MSCML request. The following sections detail these actions and their corresponding MSCML payloads.
両方の動作(ステップ1と2)はただ一つのMSCML要求で結合されるかもしれません。 以下のセクションはこれらの動作とそれらの対応するMSCMLペイロードについて詳述します。
5.8.2.1. Create the Conference
5.8.2.1. コンファレンスを作成してください。
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<を含むSIP INVITEを送ることによって、ユニークな会議識別子で_会議>要求を構成してください。
5.8.2.2. Joining and Configuring the Coach
5.8.2.2. 監督を接合して、構成します。
Join the coach leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to supervisor and its mixmode to private.
コーチ脚を会議に接合してください、そして、<を含むSIP INVITEを送るのによる必要な特性が_脚の>要求を構成するのを構成してください。 <は、_脚の>要素が監督への脚の固有のIDと個人的へのそのmixmodeを設定するのを構成します。
The corresponding MSCML request is as follows.
対応するMSCML要求は以下の通りです。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="supervisor" mixmode="private"/>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「><MediaServerControlバージョンは「1インチの><要求><は_脚のイド=を構成する」という監督と等しく」mixmodeが「個人的」/></要求></MediaServerControl>と等しいです。
Figure 11: Join Coach Request
図11: 監督要求に参加してください。
Note that the client cannot configure the teammate list for the coach yet, as there are no other participants in the conference. One must join a participant to the conference before one can add it as a teammate for another leg.
クライアントがコーチのためにまだチームメートリストを構成できないことに注意してください、会議の他の関係者が全くいないとき。 人が別の脚のためのチームメートとしてそれを加えることができる前に関係者に会議で加わらなければなりません。
5.8.2.3. Joining and Configuring the Agent
5.8.2.3. エージェントを接合して、構成します。
Join the agent leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to "agent" and sets the supervisor as a team member of the agent. Because team member relationships are symmetric, this action also adds the agent as a team member for the coach.
エージェント脚を会議に接合してください、そして、<を含むSIP INVITEを送るのによる必要な特性が_脚の>要求を構成するのを構成してください。 <は、_脚の>要素が「エージェント」に脚の固有のIDを設定して、エージェントのチームメンバーとして監督を設定するのを構成します。 チームメンバー関係が左右対称であるので、また、この動作はコーチのためのチームメンバーとしてエージェントを加えます。
Van Dyke, et al. Informational [Page 21] RFC 4722 MSCML November 2006
ヴァンダイク、他 [21ページ]情報のRFC4722MSCML2006年11月
The corresponding MSCML request is as follows.
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="agent">
<configure_team action="set">
<teammate id="supervisor"/>
</configure_team>
</configure_leg>
</request>
</MediaServerControl>
対応するMSCML要求は以下の通りです。 <?xmlバージョン= 「1インチ?」「><MediaServerControlバージョンは「1インチの><要求><は_脚のイド=を構成する」というエージェント「><は_チーム動作=を構成する」というセット「><チームメートイド=」監督と等しく」/></が構成する_チーム></は_脚の></要求></MediaServerControl>を構成します。
Figure 12: Join Agent Request
図12: エージェント要求に参加してください。
Because the desired mixmode for this leg is full, which is the default value, there is no need to set it explicitly.
この脚のための必要なmixmodeが完全であるので、(デフォルト値です)明らかにそれを設定する必要は全くありません。
5.8.2.4. Joining and Configuring the Client
5.8.2.4. クライアントを接合して、構成します。
Join the client leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element simply sets the leg's unique ID to "customer". The media server does not need further configuration because the desired mixmode, full, is the default and the customer has no team members.
クライアント脚を会議に接合してください、そして、<を含むSIP INVITEを送るのによる必要な特性が_脚の>要求を構成するのを構成してください。 <は、_脚の>要素が単に「顧客」に脚の固有のIDを設定するのを構成します。 必要な完全なmixmodeがデフォルトであり、顧客にはチームメンバーが全くいないので、メディアサーバはさらなる構成を必要としません。
The corresponding MSCML request is as follows.
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg id="customer"/>
</request>
</MediaServerControl>
対応するMSCML要求は以下の通りです。 <?xmlバージョン= 「1インチ?」「><MediaServerControlバージョンは「1インチの><要求><は_脚のイド=を構成する」という顧客と等しく」/></要求></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を与えるという要件ではありません。 しかしながら、いつ使用は会議をコーチして、私たちはそれぞれへのある案配a固有のIDが初期のINVITE要求を急いで歩くRECOMMENDであるか。 固有のIDを割り当てると、後で1つの後の願望が顧客脚のための混合を個人化したならSIP INFOを送ることによってそれを設定する必要性は排除されます。
The conference is now in the desired configuration, shown previously in Table 2.
現在、以前にTable2に示された必要な構成には会議があります。
Van Dyke, et al. Informational [Page 22] RFC 4722 MSCML November 2006
ヴァンダイク、他 [22ページ]情報のRFC4722MSCML2006年11月
6. Interactive Voice Response (IVR)
6. 対話的な声の応答(IVR)
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 Service URI概念(RFC3087)を使用できます。 次に、クライアントは、メディアサーバのMSCMLセッションを開始するのにRFC4240[2]を使用します。これらの関係は図14に示されます。
SIP +--------------+
Service URI | Application |
/----------------| Server |
/(e.g., RFC 3087) +--------------+
/ | MSCML
/ SIP | Session
/ +--------------+
+-----+/ RTP | |
| UAC |======================| Media Server |
+-----+ | |
+--------------+
一口+--------------+ サービスURI| アプリケーション| /----------------| サーバ| /(例えば、RFC3087)+--------------+ / | MSCML/一口| セッション/+--------------+ +-----+/RTP| | | UAC|======================| メディアサーバ| +-----+ | | +--------------+
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サービスは基本的なInteractive Voice Response機能をサポートします、発表をプレーして、DTMFケタを集めて、SIP要求のメッセージ本体に加えられたメディアServer Control Markup Language(MSCML)指示に基づいて記録して。 主要なMSCML IVR要求は、<プレー>と、<playcollect>と、<playrecord>です。
Multifunction media servers MUST use the URI conventions described in RFC 4240 [2]. The service indicator for MSCML IVR MUST be set to "ivr", as shown in the following example:
多機能メディアサーバはRFC4240[2]で説明されたURIコンベンションを使用しなければなりません。 MSCML IVR MUSTのためにインディケータを修理してください。"ivr"以下の例に示されるように、設定されてください:
sip:ivr@ms.example.net
一口: ivr@ms.example.net
The VoiceXML IVR service indicator is "dialog". This service indicator MUST NOT be used for any other interactive voice response control mechanism.
VoiceXML IVRサービスインディケータは「対話」です。 いかなる他の対話的な声の応答制御機構にもこのサービスインディケータを使用してはいけません。
The media server MUST accept MSCML IVR payloads in INFO requests and MUST NOT accept MSCML IVR payloads in the initial or subsequent INVITEs. The INFO method reduces certain timing issues that occur with INVITEs and requires less processing on both the client and media server.
メディアサーバは、INFO要求でMSCML IVRペイロードを受け入れなければならなくて、初期の、または、その後のINVITEsでMSCML IVRペイロードは受け入れてはいけません。 INFOメソッドは、INVITEsと共に起こるあるタイミング問題を減少させて、両方でそれほどクライアントとメディアサーバを処理しないのを必要とします。
Van Dyke, et al. Informational [Page 23] RFC 4722 MSCML November 2006
ヴァンダイク、他 [23ページ]情報のRFC4722MSCML2006年11月
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要求を受け取るなら、メディアサーバは最初の操作を止めます、そして、それは新しい要求を行います。 メディアサーバは、最初の要求への<応答>メッセージを生成して、そのポイントまで集められたどんなデータも返します。 クライアントが進行中の要求を止めることを願っていますが、別の操作を開始したいと思わないなら、それは<停止>要求を出します。 また、これで、メディアサーバは<応答>メッセージを生成します。
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を変更するSIP再INVITEを扱います。 そのようなSDP変更に関する例は、保持SDPを受けるか、またはオーディオかビデオストリームを取り外すのを含んでいます。 これが起こると、メディアサーバで、すぐに、プレー>、<playcollect>、または<playrecord>が要求する実行している<を終えて、<応答>は、「理由=は止まりました。」と示します。
6.1. Specifying Prompt Content
6.1. 迅速な内容を指定します。
The MSCML IVR requests support two methods of specifying content to be delivered to the user. These are the <prompt> element and the prompturl attribute. Clients MUST NOT utilize both methods in a single IVR request. Clients SHOULD use the more flexible <prompt> mechanism. Use of the prompturl attribute is deprecated and may not be supported in future MSCML versions.
MSCML IVR要求は内容を指定するユーザに提供されるべき2つのメソッドをサポートします。 これらは、<の迅速な>要素とprompturl属性です。 クライアントはただ一つのIVR要求で両方のメソッドを利用してはいけません。 クライアントSHOULDは、よりフレキシブルな<迅速な>メカニズムを使用します。 prompturl属性の使用は、推奨しなく、将来のMSCMLバージョンでサポートされないかもしれません。
6.1.1. Use of the Prompt Element
6.1.1. 迅速な要素の使用
The <prompt> element MAY be included in the body of a <play>, <playcollect>, or <playrecord> request to specify a prompt sequence to be delivered to the caller. The prompt sequence consists of one or more references to physical content files, spoken variables, or dynamic URLs that return a sub-sequence of files or variables. In addition, the <prompt> element has several attributes that control playback of the included content. These are described in the list below.
<の迅速な>要素はプレー>、<playcollect>、または<playrecord>が訪問者に提供される迅速な系列を指定するよう要求する<のボディーに含まれるかもしれません。 迅速な系列はファイルか変数のサブ系列を返す物理的な内容ファイル、話された変数、またはダイナミックなURLの1つ以上の参照箇所から成ります。 さらに、<の迅速な>要素には、含まれている内容の再生を制御するいくつかの属性があります。 これらは以下のリストで説明されます。
Attributes of <prompt>:
<の属性は>をうながします:
o baseurl - optional, no default value: For notational convenience,
as well as reducing the MSCML payload size, the "baseurl"
attribute is used to specify a base URL that is prepended to any
other URLs in the sequence that are not fully qualified.
o baseurl--任意であることで、どんなデフォルトも以下を評価しません。 記号法の便利において、MSCMLペイロードサイズを減少させることと同様に"baseurl"属性は、系列の完全に資格があるというわけではないいかなる他のURLにもprependedされるベースURLを指定するのに使用されます。
Van Dyke, et al. Informational [Page 24] RFC 4722 MSCML November 2006
ヴァンダイク、他 [24ページ]情報のRFC4722MSCML2006年11月
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インチ:」 迅速な要素への「遅れ」属性は<の迅速な>系列の反復の間に止まる時間を指定します。 それは系列の最初の繰り返しのときに効き目がありません。 時間的価値(セクション4.2.1)として、0から、前方へ言い表されます。
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 持続時間--任意のデフォルト値「無限」: 迅速な要素への「持続時間」属性はメディアサーバが系列を繰り返す間の経過するかもしれない最大の時間、制御されます。 これで、クライアントはプレーの長さに上限をけしかけることができます。 時間的価値(セクション4.2.1)として、1msから、前方へ言い表されました。または、ストリング「即座で」「無限」。 「即座」はすぐに、メディアサーバを軸方向の遊びに向けますが、「無限」は、メディアサーバが限界を全く課さないのを示します。
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インチ:」 絶対利得に<の迅速な>に含まれた内容に適用されるように設定します。 この属性の値はユニットのdBで指定されます。 メディアサーバは静かにプラットホームによって課された利得限界を超えている値にふたをするかもしれません。 <の迅速な>に含まれる内容の再生が完成したとき、レベルは元の値に戻って戻ります。
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インチ:」 相対的な利得に<の迅速な>に含まれた内容に適用されるように設定します。 この属性の値はユニットのdBで指定されます。 メディアサーバは静かにプラットホームによって課された利得限界を超えている値にふたをするかもしれません。 <の迅速な>に含まれる内容の再生が完成したとき、レベルは元の値に戻って戻ります。
o rate - optional, default value "0": Specifies the absolute
playback rate of the content relative to normal as either a
positive percentage (faster) or a negative percentage (slower).
Any value that attempts to set the rate above the maximum allowed
or below the minimum allowed silently sets the rate to the maximum
or minimum. The rate reverts back to its original value when
playback of the content contained in <prompt> has been completed.
o 評価してください--任意であることで、デフォルトとしてください、値、「0インチ:」 陽の割合(より速い)か負の割合(より遅い)のどちらかとしての標準に比例して内容の絶対再生レートを指定します。 静かに許容されているか、または最小限より下で許容された最大よりレートを重要とみなすのを試みるどんな値も最大か最小限にレートを設定します。 <の迅速な>に含まれる内容の再生が完成したとき、レートは元の値に戻って戻ります。
o ratedelta - optional, default value "0": Specifies the playback
rate of the content relative to it's current rate as either a
positive percentage (faster) or negative percentage (slower). Any
value that attempts to set the rate above the maximum allowed or
below the minimum allowed silently sets the rate to the maximum or
minimum. The rate reverts back to its original value when
playback of the content contained in <prompt> has completed.
o ratedelta--任意であることで、デフォルトとしてください、値、「0インチ:」 陽の割合(より速い)か負の割合(より遅い)のどちらかとしてのそれの成り行き相場に比例して内容の再生レートを指定します。 静かに許容されているか、または最小限より下で許容された最大よりレートを重要とみなすのを試みるどんな値も最大か最小限にレートを設定します。 迅速な>が完成した<に含まれた内容の再生であるときに、レートは元の値に戻って戻ります。
Van Dyke, et al. Informational [Page 25] RFC 4722 MSCML November 2006
ヴァンダイク、他 [25ページ]情報のRFC4722MSCML2006年11月
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 現場--任意であることで、どんなデフォルトも以下を評価しません。 話された変数を決議するのに使用される言語と国の異形を指定します。 言語はISO639あたり2レター・コードと定義されます。 また、国の異形はISO3166あたり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インチ:」 どのプレーで系列の始まりからの時間を指定する時間的価値(セクション4.2.1)は始まることになっています。 オフセットは最初の反復に適用されるだけです。 その後の反復はオフセット0時にプレーを始めます。 許容量は前方へ0からの積極的な時間的価値です。 系列が複数の内容ファイルから成ると、オフセットは系列で任意な点を選択するかもしれません。 メディアサーバが指定されたオフセットに達するまで、それは、系列がオフセット値であるなら合計より大きい時間があり始めまで「包装し」て、そこから続けるでしょう。
o repeat - optional, default value "1": The "repeat" attribute to
the prompt element controls the number of times the media server
plays the sequence in the <prompt> element. Allowable values are
integers from 0 on and the string "infinite", which indicates that
repetition should occur indefinitely. For example, "repeat=2"
means that the sequence will be played twice, and "repeat=0",
which is allowed, means that the sequence is not played.
o 繰り返してください--任意であることで、デフォルトとしてください、値、「1インチ:」 迅速な要素への「反復」属性はメディアサーバが<の迅速な>要素の系列をプレーするという回の数を制御します。 許容量は、反復が無期限に起こるべきであるのを示す0からの整数とストリング「無限」です。 例えば、「反復=2インチは、系列が二度プレーされることを意味します、そして、「反復=0インチ(許容されている)は、系列がプレーされないことを意味します」。
o stoponerror - optional, default value "no": Controls media server
handling and reporting of errors encountered when retrieving
remote content. If set to "yes", content play will end if a fetch
error occurs, and the response will contain details regarding the
failure. If set to "no", the media server will silently move on
to the next URL in the sequence if a fetch failure occurs.
o stoponerror--任意のデフォルト値「いいえ」: リモート内容を検索するとき誤りのサーバ取り扱いと報告が遭遇したコントロールメディア。 「はい」に設定されると、フェッチ誤りが発生すると、満足しているプレーは終わるでしょう、そして、応答は失敗に関する詳細を含むでしょう。 「いいえ」に設定されると、フェッチ失敗が起こるなら、メディアサーバは系列で静かに次のURLに移行するでしょう。
Clients MUST NOT include both 'gain' and 'gaindelta' attributes within a single <prompt> element.
クライアントはただ一つの<迅速な>要素の中で両方の'利得'と'gaindelta'属性を入れてはいけません。
When the client explicitly controls the output gain on a conference leg, as described in Section 5.3, the 'gain' and 'gaindelta' attributes SHOULD interact with the conference leg output gain settings in the following manner.
クライアントがセクション5.3で説明されるように会議脚の上で明らかに出力利得を制御すると、'利得'と'gaindelta'属性SHOULDは以下の方法で会議脚の出力利得設定と対話します。
o Conference leg output gain set to <fixed>: The operation of the
'gain' and 'gaindelta' attributes are unchanged. However, the
baseline gain value before any playback changes are applied is the
value specified for the conference leg.
o コンファレンス脚の出力利得は>が修理された<にセットしました: '利得'と'gaindelta'属性の操作は変わりがありません。 しかしながら、どんな再生変化も適用されている前に基線利得価値は会議脚に指定された値です。
o Conference leg output gain set to <auto>: When playback gain
controls are used, the automatic gain control settings for the leg
are suspended for the duration of the playback operation. The
o コンファレンス脚の出力利得は<の自動>にセットしました: 再生利得制御が使用されているとき、脚のための自動利得制御設定は再生操作の持続時間のために中断します。 The
Van Dyke, et al. Informational [Page 26] RFC 4722 MSCML November 2006
ヴァンダイク、他 [26ページ]情報のRFC4722MSCML2006年11月
operation of the 'gain' and 'gaindelta' attributes are unchanged.
The automatic gain control settings are reinstated when playback
has finished.
'利得'と'gaindelta'属性の操作は変わりがありません。 再生が終わったとき、自動利得制御設定は復職します。
Media servers SHOULD support rate controls for content. However, media servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <prompt> element.
SHOULDがサポートするメディアサーバは内容のためのコントロールを評定します。 しかしながら、満足している制限が光栄に思うという要求を許さないなら、メディアサーバは静かにレート変更要求を無視するかもしれません。 クライアントはただ一つの<迅速な>要素の中で両方の'レート'と'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>
迅速..はい..ファイル..現場..等しい..アン..米国..オフセット..0インチ..利得..0インチ..レート..0インチ..遅れ..0インチ..持続時間..無限..反復..1インチ..オーディオ..コード化..可変..タイプ..皮肉..値..オーディオ..オーディオ..迅速
Figure 16: Prompt Block Example
図16: 迅速なブロックの例
6.1.1.1. <audio> and <variable> Elements
6.1.1.1. <のオーディオの>と<の可変>Elements
Clients compose prompt sequences using the <audio> and <variable> elements. An <audio> element MAY refer to content that contains audio, video, or both; the generic name is preserved for backwards compatibility. The <audio> element has the attributes described in the list below.
クライアントは、<のオーディオの>と<の可変>要素を使用することで迅速な系列を構成します。 <オーディオ>要素はオーディオ、ビデオ、または両方を含む内容を示すかもしれません。 総称は遅れている互換性のために保存されます。 <オーディオ>要素には、以下のリストで説明された属性があります。
Attributes of <audio>:
<オーディオ>の属性:
o url - required, no default value: The URL of the content to be
retrieved and played. The target may be a local or remote (NFS)
"file://" scheme URL or an "http://" or "https://" scheme URL. If
the URL is not fully qualified and a "baseurl" attribute was set,
the value of the "baseurl" attribute will be prepended to this
value to generate the target URL.
o url--必要であることで、どんなデフォルトも以下を評価しません。 検索された、プレーされるべき内容のURL。 目標は、ローカルの、または、リモートな(NFS)「ファイル://」体系URLか「http://」か「https://」体系URLであるかもしれません。 URLは完全に資格があったというわけではなくて、"baseurl"属性が設定されたなら、"baseurl"属性の値は、目標URLを生成するためにこの値にprependedされるでしょう。
o encoding - optional, default value "ulaw": Specifies the content
encoding for file formats that are not self-describing (e.g.,
.WAV). Allowable values are "ulaw", "alaw", and "msgsm". This
attribute only affects "file://" scheme URLs.
o コード化--任意のデフォルト値の"ulaw": ファイルのために自己に(例えば、.WAV)について説明していない形式をコード化する内容を指定します。 許容量は、"ulaw"と、"alaw"と、"msgsm"です。 この属性は「ファイル://」体系URLに影響するだけです。
o gain - optional, default value "0": Sets the absolute gain to be
applied to the content URL. The value of this attribute is
o 獲得してください--任意であることで、デフォルトとしてください、値、「0インチ:」 絶対利得に満足しているURLに適用されるように設定します。 この属性の値はそうです。
Van Dyke, et al. Informational [Page 27] RFC 4722 MSCML November 2006
ヴァンダイク、他 [27ページ]情報のRFC4722MSCML2006年11月
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.
ユニットの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.
クライアントはただ一つの<オーディオ>要素の中で両方の'利得'と'gaindelta'属性を入れてはいけません。
When the client explicitly controls the output gain on a conference leg, as described in Section 5.3, the 'gain' and 'gaindelta' attributes SHOULD interact with the conference leg output gain settings in the following manner.
クライアントがセクション5.3で説明されるように会議脚の上で明らかに出力利得を制御すると、'利得'と'gaindelta'属性SHOULDは以下の方法で会議脚の出力利得設定と対話します。
o Conference leg output gain set to <fixed>: The operation of the
'gain' and 'gaindelta' attributes are unchanged. However, the
baseline gain value before any playback changes are applied is the
value specified for the conference leg.
o コンファレンス脚の出力利得は>が修理された<にセットしました: '利得'と'gaindelta'属性の操作は変わりがありません。 しかしながら、どんな再生変化も適用されている前に基線利得価値は会議脚に指定された値です。
o Conference leg output gain set to <auto>: When playback gain
controls are used, the automatic gain control settings for the leg
are suspended for the duration of the playback operation. The
operation of the 'gain' and 'gaindelta' attributes are unchanged.
The automatic gain control settings are reinstated when playback
has finished.
o コンファレンス脚の出力利得は<の自動>にセットしました: 再生利得制御が使用されているとき、脚のための自動利得制御設定は再生操作の持続時間のために中断します。 '利得'と'gaindelta'属性の操作は変わりがありません。 再生が終わったとき、自動利得制御設定は復職します。
Van Dyke, et al. Informational [Page 28] RFC 4722 MSCML November 2006
ヴァンダイク、他 [28ページ]情報のRFC4722MSCML2006年11月
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.
SHOULDがサポートするメディアサーバは内容のためのコントロールを評定します。 しかしながら、満足している制限が光栄に思うという要求を許さないなら、メディアサーバは静かにレート変更要求を無視するかもしれません。 クライアントはただ一つの<オーディオ>要素の中で両方の'レート'と'ratedelta'属性を入れてはいけません。
Media servers MUST support local and remote (NFS) "file://" scheme URLs and "http://" and "https://" scheme URLs for content retrieval.
メディアサーバは、満足している検索のために地方の、そして、リモートな(NFS)が「ファイル://」体系URLと「http://」と「https://」体系URLであるとサポートしなければなりません。
NOTE: The provisioning of NFS mount points and their mapping to
the "file://" schema is purely a local matter at the media server.
以下に注意してください。 「ファイル://」図式へのNFSマウントポイントとそれらのマッピングの食糧を供給するのはメディアサーバで純粋に地域にかかわる事柄です。
MSCML also supports "http://" and "https://" scheme URLS that return a list of physical URLs using the "text/uri-list" MIME type. This facility provides flexibility for applications to dynamically generate prompt sequences at execution time and enables separation of this function from the client and media server.
また、MSCMLは、「http://」と「https://」が「uriテキスト/リスト」MIMEの種類を使用することで物理的なURLのリストを返す体系URLSであるとサポートします。 この施設は、アプリケーションがダイナミックに実行時間における迅速な系列を生成するように柔軟性を提供して、クライアントとメディアサーバからこの機能の分離を可能にします。
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の話された変数はAudio Serverプロトコル[17]で説明されたものに基づいています。
Attributes of <variable>:
<の可変>の属性:
o type - required, no default value: Specifies the major type format
of the spoken variable to be played. Allowable values are "dat"
(date), "dig" (digit), "dur" (duration), "mth" (month), "mny"
(money), "num" (number), "sil" (silence), "str" (string), "tme"
(time), and "wkd" (weekday).
o タイプしてください--必要であることで、どんなデフォルトも以下を評価しません。 プレーされるために話された変数の主要なタイプ形式を指定します。 許容量は、"dat"(日付)と、「皮肉」(ケタ)と、"dur"(持続時間)と、"mth"(月)と、"mny"(お金)と、"num"(数)と、"sil"(沈黙)と、"str"(ストリング)と、"tme"(時間)と、"wkd"(平日)です。
o subtype - optional, no default value: Specifies the minor type
format of the spoken variable to be played. Allowable values
depend on the value of the corresponding "type" attribute.
Possible values are "mdy", "ymd", and "dmy" for dates, "t12" and
"t24" for times, "gen", "ndn", "crd", and "ord" for digits, and
"USD" for money.
o 「副-タイプ」--任意であることで、どんなデフォルトも以下を評価しません。 プレーされるために話された変数の小さい方のタイプ形式を指定します。 許容量は対応する「タイプ」属性の値に依存します。 可能な値が"mdy"と、"ymd"と、日付に"dmy"である、「t12"、および「何倍もt24"、「情報を得てください」、"ndn"は、ケタ、およびお金のための「U.S.ドル」のために"crdする"であると"ordする"です。」
o value - required, no default value: A string that will be
interpreted based on the formatting information specified in the
"type" and "subtype" attributes and the "locale" attribute of the
parent <prompt> element to render the spoken variable.
o 値--必要であることで、どんなデフォルトも以下を評価しません。 形式情報に基づいて解釈される五弦は、話された変数を表すために「タイプ」と"「副-タイプ」"属性と親の<の迅速な>要素の「現場」属性で指定しました。
If the "locale" attribute was not specified in <prompt>, the media server SHOULD make a selection based on platform configuration. If the precise "locale" requested cannot be honored, the media server SHOULD select the closest match based on the available content.
「現場」属性が<の迅速な>で指定されなかったなら、メディアサーバSHOULDはプラットホーム構成に基づいて選定します。 要求された正確な「現場」を光栄に思うことができないなら、メディアサーバSHOULDは利用可能な内容に基づく中で最も近いマッチを選択します。
Van Dyke, et al. Informational [Page 29] RFC 4722 MSCML November 2006
ヴァンダイク、他 [29ページ]情報のRFC4722MSCML2006年11月
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アプリケーションはアプリケーションプロバイダーによって書かれる専門化している迅速な内容を必要とします。 同じスピーカーは上質のユーザ相互作用、専門化しているプロンプト、および話された変数を提供するのを生成しなければなりません。 メディアサーバが本来複数の同時のアプリケーションをサポートするので、それがメディアサーバですべての必要なアプリケーションがうながす支給と局所的に話された可変内容を合わせるのに非常に難しい、したがって、私たち、クライアントが話された変数を生成するのにより早く説明されたダイナミックなURLメカニズムを使う「uriテキスト/リスト」内容を返す外部のウェブサーバーを使用するSTRONGLY RECOMMEND。
6.2. Multimedia Processing for IVR
6.2. IVRのためのマルチメディア処理
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.
リアルタイムのメディアと指定された内容の間には、ミスマッチがあれば、メディアサーバは、要求に失敗するよりむしろ適切な満足している道を自由に動かなければならないか、または記録しなければなりません。 例えば、クライアントが、オーディオとビデオ道にもかかわらず、オーディオメディアだけがある内容の再生が対話のために設立されたよう要求したなら、メディアサーバはオーディオトラックを自由に動かせるべきです。 対話でオーディオとビデオメディアの両方があるか、しかし、内容はオーディオだけ、メディアサーバがあらかじめ食糧を供給されたビデオ道を訪問者に流すかもしれないということです。 SHOULDがリアルタイムのメディアと内容の間の非互換性を最小にするためにビデオコード変換機能を実装するメディアサーバ。
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.
aを受けるときだけビデオメディアを記録するサーバが始めなければならないメディアはビデオフレームをリフレッシュします。 Aはリフレッシュします。フレームは情報がそのフレームを解読するのを必要としたすべてのビデオを含んでいます(依存が全く前のビデオフレームからのデータにありません)。 大きく、一般に、ネットワーク回線容量を保存するためにまれに送って、フレームをリフレッシュしてください。 メディアサーバは実装しなければなりません。訪問者(ビデオエンコーダ)がaを伝えるよう要求する標準のメカニズムはビデオ録音が急速に始まるのを保証するフレームをリフレッシュします。 メディアサーバは、すぐビデオを受け取るのを待つのがフレームをリフレッシュしている間、オーディオトラックを記録し始めなければなりません。
Van Dyke, et al. Informational [Page 30] RFC 4722 MSCML November 2006
ヴァンダイク、他 [30ページ]情報のRFC4722MSCML2006年11月
6.3. Playing Announcements <play>
6.3. 発表<プレー>をプレーします。
The client issues a <play> request to play an announcement without interruption and with no digit collection. One use, for example, is to announce the name of a new participant to the entire conference. The <play> request has the attributes described in the list below.
クライアントは中断なしでケタ収集なしで発表をプレーするという<プレー>要求を出します。 例えば、1つの使用は新しい関係者の名前を全体の会議に発表することです。 <プレー>要求には、以下のリストで説明された属性があります。
Attributes of <play>:
<の属性は>をプレーします:
o id - optional, no default value: Specifies a client-defined ID for
purposes of matching requests and responses.
o イド--任意であることで、どんなデフォルトも以下を評価しません。 要求と応答に合う目的にクライアントによって定義されたIDを指定します。
o offset - optional, default value "0": Specifies the time from the
beginning of the URL specified in the 'prompturl' attribute at
which play will begin. Expressed as a time value (Section 4.2.1)
from 0 onwards. If the offset value is greater than the total
time of the content, it will "wrap" to the beginning and continue
from there until the media server reaches the specified offset.
NOTE: Use of this attribute is deprecated.
o 相殺してください--任意であることで、デフォルトとしてください、値、「0インチ:」 プレーが始まる'prompturl'属性で指定されたURLの始まりからの時間を指定します。 時間的価値(セクション4.2.1)として、0から、前方へ言い表されます。 メディアサーバが指定されたオフセットに達するまで、それは、内容がオフセット値であるなら合計より大きい時間があり始めまで「包装し」て、そこから続けるでしょう。 以下に注意してください。 この属性の使用は推奨しないです。
o promptencoding - optional, no default value: Specifies the content
encoding for file formats that are not self-describing (e.g.,
.WAV). Allowable values are "ulaw", "alaw", and "msgsm". This
attribute only affects "file://" scheme URLs. NOTE: Use of this
attribute is deprecated.
o promptencoding--任意であることで、どんなデフォルトも以下を評価しません。 ファイルのために自己に(例えば、.WAV)について説明していない形式をコード化する内容を指定します。 許容量は、"ulaw"と、"alaw"と、"msgsm"です。 この属性は「ファイル://」体系URLに影響するだけです。 以下に注意してください。 この属性の使用は推奨しないです。
o prompturl - optional, no default value: The URL of the content to
be retrieved and played. The target may be a local or remote
(NFS) "file://" scheme URL or an "http://" or "https://" scheme
URL. NOTE: Use of this attribute is deprecated.
o prompturl--任意であることで、どんなデフォルトも以下を評価しません。 検索された、プレーされるべき内容のURL。 目標は、ローカルの、または、リモートな(NFS)「ファイル://」体系URLか「http://」か「https://」体系URLであるかもしれません。 以下に注意してください。 この属性の使用は推奨しないです。
The <play> request has one child element defined, <prompt>. Use of <prompt> is described in Section 6.1.1.
<プレー>要求には、定義された1つの子供要素、<の迅速な>があります。 <の迅速な>の使用はセクション6.1.1で説明されます。
The client MUST NOT use both the <prompt> element and "prompturl" attribute in a single request. As previously discussed, the "prompturl" attribute is supported for backwards compatibility with older MSCML applications, but its use is deprecated. The more flexible <prompt> element SHOULD be used instead.
クライアントは<の迅速な>要素と"prompturl"がただ一つの要求で結果と考える両方を使用してはいけません。 以前に議論するように、"prompturl"属性は後方にようにサポートされて、しかし、より古いMSCMLアプリケーションとの互換性、使用が推奨しないということです。 より多くのフレキシブルな<迅速な>要素SHOULDに、いてください。代わりに使用されます。
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と話された変数でアクセスされた内容から成るのを示します。
Van Dyke, et al. Informational [Page 31] RFC 4722 MSCML November 2006
ヴァンダイク、他 [31ページ]情報のRFC4722MSCML2006年11月
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<play id="332985001">
<prompt stoponerror="yes"
baseurl="file:////var/mediaserver/prompts/"
locale="en_US" offset="0" gain="0" rate="0"
delay="0" duration="infinite" repeat="1">
<audio url="num_dialed.raw" encoding="ulaw"/>
<variable type="dig" subtype="ndn" value="3014170700"/>
<audio url="num_invalid.wav"/>
<audio url="please_check.wav"/>
</prompt>
</play>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「無限」の「アン_米国」オフセット=「0インチの利得=」0インチレート=「0インチの遅れ=」の0インチの「ファイル:////var/mediaserver/prompts/」「><MediaServerControlバージョン=「1インチの><要求><プレーイド=」332985001「>の<の迅速なstoponerror=」はい」baseurl=現場=持続時間=反復は「1インチの><オーディオ」と等しいです; urlが「3014170700」/><オーディオurl=「num_invalid.wav」/><="ulaw"/>の<の可変タイプ=「皮肉」「副-タイプ」="ndn"価値=オーディオurl=「_お願いします、check.wav」をコード化しながら「num_dialed.raw」と等しい、/></迅速な></プレー></要求></MediaServerControl>。
Figure 17: <Play> Request Example
図17: <プレー>は例を要求します。
When the announcement has finished playing, the media server sends a <response> payload to the client in a SIP INFO message. Details regarding the format of <play> responses are provided in Section 10.4.
発表が、プレーし終えたとき、メディアサーバは<応答>ペイロードをSIP INFOメッセージのクライアントに送ります。 <プレー>応答の形式に関する詳細はセクション10.4に明らかにされます。
6.4. Prompt and Collect <playcollect>
6.4. <playcollect>をうながして、集めてください。
The client issues a <playcollect> request to play an announcement (optional) and collect digits. The <playcollect> request is executed in two phases, prompt and collect. If the client specifies prompt content to be played, using the <prompt> element or prompturl attribute, the media server plays the content before starting the collection phase. If no prompt content is specified, the collect phase begins immediately.
クライアントは発表(任意の)をプレーして、ケタを集めるという<playcollect>要求を出します。 <playcollect>要求は、二相で実行されて、迅速であって、料金先方払いです。 <の迅速な>要素かprompturl属性を使用して、クライアントがプレーされるために迅速な内容を指定するなら、収集フェーズを始める前に、メディアサーバは内容をプレーします。 どんな迅速な内容も指定されないなら、料金先方払いのフェーズはすぐに、始まります。
The basic attributes of <playcollect> are the same as those of <play>, which were described in Section 6.3. In addition to these basic attributes, <playcollect> defines others which control digit buffering and barge-in behavior, collection timers, special purpose DTMF key functions, and logging of user DTMF input. Each functional category and its attributes are described below.
<playcollect>の基本的な属性は<のものが>(セクション6.3で説明された)をプレーするのと同じです。 これらの基本的な属性に加えて、<playcollect>はユーザDTMFのコントロールケタバッファリング、中のはしけの振舞い、収集タイマ、専用DTMF主要な機能、および伐採が入力した他のものを定義します。 それぞれの機能的なカテゴリとその属性は以下で説明されます。
Van Dyke, et al. Informational [Page 32] RFC 4722 MSCML November 2006
ヴァンダイク、他 [32ページ]情報のRFC4722MSCML2006年11月
6.4.1. Control of Digit Buffering and Barge-In
6.4.1. ケタバッファリングと中ではしけで運ぶコントロール
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"が「いいえ」に設定されて、中ではしけで運ぶのが可能にされると、以前にバッファリングされたケタはすぐに、迅速なフェーズを終えるでしょう。 この場合、プロンプトはプレーされません、そして、ケタ収集はすぐに、始まります。
o barge - optional, default value "yes": Specifies whether user
input will barge the prompt and force transition to the collect
phase. When it is set to "yes", a DTMF input will barge the
prompt. When it is set to "no", the prompt phase cannot be
barged, and any user input during the prompt is placed in the
quarantine buffer for inspection during the collect phase. Note
that if the "barge" attribute is set to "no", the "cleardigits"
attribute implicitly has a value of "yes". This ensures that the
media server does not leave DTMF input that occurred prior to the
current collection in the quarantine buffer after the request is
completed.
o はしけ--任意のデフォルト値「はい」: ユーザ入力がプロンプトをはしけで運んで、料金先方払いのフェーズへの変遷を強制するかどうか指定します。 それが「はい」に設定されるとき、DTMF入力はプロンプトをはしけで運ぶでしょう。 それが「いいえ」に設定されるとき、迅速なフェーズをはしけで運ぶことができません、そして、プロンプトの間のどんなユーザ入力も料金先方払いの段階の間、点検のための隔離バッファに置かれます。 「はしけ」属性が「いいえ」に設定されるなら、「はい」の値がそれとなく"cleardigits"属性にあることに注意してください。 これは、メディアサーバが要求が終了した後に隔離バッファにおける現在の収集の前に現れた入力にDTMFを残さないのを確実にします。
6.4.2. Mapping DTMF Keys to Special Functions
6.4.2. 特別な機能の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つの属性があります。 これらの属性は以下のリストで説明されます。
Van Dyke, et al. Informational [Page 33] RFC 4722 MSCML November 2006
ヴァンダイク、他 [33ページ]情報のRFC4722MSCML2006年11月
DTMF Key Mappings for <playcollect>:
DTMFの<playcollect>に、主要なマッピング:
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 「再-牢番」--任意のデフォルト値「#」: ユーザが入力を終了したのを示して、すべての集まっているケタをクライアントに返したがっているDTMFキーを指定します。 メディアサーバが「再-牢番」を検出するとき、それは、<応答>メッセージのクライアントにすぐに、収集を終えて、集まっているケタを返します。
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つの追加マッピングを定義します。 SHOULDが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--任意であることで、デフォルトは「6」を評価します: "skipinterval"属性が、メディアサーバがどれくらい遠くに後方にか前方にいつをスキップするべきであるかを示す、速い前進のキー(ffkey)は、a時間的価値(セクション4.2.1)としてキー(rwkey)を巻き戻してください。さもないと、押される、指定されています。
o ffkey - optional, no default value: The "ffkey" attribute maps a
DTMF key to a fast forward operation equal to the value of the
"skipinterval" attribute.
o ffkey--任意であることで、どんなデフォルトも以下を評価しません。 "ffkey"属性は"skipinterval"属性の値と等しい速い先物取引に主要なDTMFを写像します。
o rwkey - optional, no default value: The "rwkey" attribute maps a
DTMF key to a rewind action equal to the value of the
"skipinterval" attribute.
o rwkey--任意であることで、どんなデフォルトも以下を評価しません。 a DTMFがaに合わせる"rwkey"属性地図は"skipinterval"属性の値に動作同輩を巻き戻します。
Clients MUST NOT map the same DTMF digit to both the "rwkey" and "ffkey" attributes in a single <playcollect> request.
クライアントは"rwkey"と単一の<playcollect>の属性が要求する"ffkey"の両方に同じDTMFケタを写像してはいけません。
VCR control operations are bounded by the beginning and end of the prompt sequence. A rewind action that moves the offset before the beginning of the sequence results in playback starting at the beginning of the sequence (i.e., offset=0). A fast forward action that moves the offset past the end of the sequence results in the media server's treating the sequence as complete.
VCR制御機能は迅速な系列の始めと終わりまでに境界があります。 Aは系列の始めの再生始めにおける系列結果の始まりの以前オフセットを動かす動作を巻き戻します(すなわち、=0を相殺してください)。 オフセットをメディアサーバの系列結果の終わりの先に動かす速い前進の行為は完全な状態で系列を扱っています。
Van Dyke, et al. Informational [Page 34] RFC 4722 MSCML November 2006
ヴァンダイク、他 [34ページ]情報のRFC4722MSCML2006年11月
6.4.3. Collection Timers
6.4.3. 収集タイマ
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入力を待つかを指定します。 時間的価値(セクション4.2.1)として、1msから、前方へ言い表されました。または、ストリング「即座で」「無限」。 「即座値の」は、タイマがすぐに撃たれるはずであるのを示しますが、「無限」は、タイマが決して撃たれないのを示します。
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入力の間で待つかを指定します。 時間的価値(セクション4.2.1)として、1msから、前方へ言い表されました。または、ストリング「即座で」「無限」。 「即座値の」は、タイマがすぐに撃たれるはずであるのを示しますが、「無限」は、タイマが決して撃たれないのを示します。
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": ケタの指定された数を集めてある後にメディアサーバがどれくらい長い間追加ユーザ入力を待つかを指定します。 時間的価値(セクション4.2.1)として、1msから、前方へ言い表されました。または、ストリング「即座で」「無限」。 「即座値の」は、タイマがすぐに撃たれるはずであるのを示しますが、「無限」は、タイマが決して撃たれないのを示します。
o interdigitcriticaltimer - optional, defaults to the value of the
interdigittimer attribute: Specifies how long the media server
waits after a grammar has been matched for a subsequent digit that
may cause a longer match. Expressed as a time value (Section
4.2.1) from 1ms onwards or the strings "immediate" and "infinite."
The value "immediate" results in "shortest match first" behavior,
whereas "infinite" means to wait indefinitely for additional
input. If not explicitly specified otherwise, this attribute is
set to the value of the 'interdigittimer' attribute.
o interdigitcriticaltimer--任意であることで、interdigittimerの値へのデフォルトは以下を結果と考えます。 文法が、より長いマッチを引き起こすかもしれないその後のケタのために合わせられた後にメディアサーバがどれくらい長い間待つかを指定します。 時間的価値(セクション4.2.1)として、1msから、前方へ言い表されました。または、ストリング「即座で」「無限」。 最も急に、合ってください。値の「即座」が中に結果として生じる、「」 「無限」は、追加入力が無期限に待つことを意味しますが、最初に、振舞い。 別の方法で明らかに指定されないなら、この属性は'interdigittimer'属性の値に設定されます。
The extradigittimer setting enables the "returnkey" input to be associated with the current collection. For example, if maxdigits is set to 3 and returnkey is set to #, the user may enter either "x#", "xx#", or "xxx#", where x represents a DTMF digit.
extradigittimer設定は、"「再-牢番」"入力が現在の収集に関連しているのを可能にします。 例えば、maxdigitsが3に用意ができていて、「再-牢番」が#、に用意ができているなら、ユーザは「x#」、「xx#」か「xxx#」のどちらかに入るかもしれません。そこでは、xがDTMFケタを表します。
Van Dyke, et al. Informational [Page 35] RFC 4722 MSCML November 2006
ヴァンダイク、他 [35ページ]情報のRFC4722MSCML2006年11月
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.
メディアサーバが"「超-ケタ」"間隔の間、"「再-牢番」"パターンを検出するなら、メディアサーバは、集まっているケタをクライアントに返して、ケタバッファから"「再-牢番」"を移します。
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.
「再-牢番」が用意ができていない場合、extradigittimerは効き目がありません。
6.4.4. Logging Caller DTMF Input
6.4.4. 伐採訪問者DTMF入力
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.
Security Considerations(セクション14)で議論したものなどの標準のSIPメカニズムはMSCMLプロトコル交換とそれらが含む情報を保護します。 これらの保護はメディアサーバログファイルで得られたデータに適用されません。 一般に、メディアサーバ伐採は、プラットホーム特有であり、したがって、この仕様でカバーされていません。 しかしながら、伐採の1つの局面(機密情報(個人識別番号かクレジットカード番号などの)の捕獲)が関連しています。 メディアサーバには、それが受け取るDTMF入力が機密であるかもしれないかどうか決定する手段が全くありません、それがクライアントの範囲にいるとき。 これを認識して、MSCMLがaを含んでいる、-、必要に応じてクライアントによって可能にされるように捕らわれている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.
検出されたDTMFケタが丸太のままで出力に現れるか否かに関係なく、「maskdigits」はコントロールを結果と考えます。 メディアサーバがログファイルを通してアクセス可能であるべきでない機密情報を集めると、クライアントはこの属性を使用します。
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入力を得るか否かに関係なく、コントロールはファイルを登録します。 この属性のための可能な値は、「はい」と「いいえ」です。
6.4.5. Specifying DTMF Grammars
6.4.5. 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]ケタ地図、およびH.248.1[6]ケタ地図まで提供します)。 MGCPとH.248.1がメソッドであるとメディアサーバは、maxdigitsと正規表現がDTMF文法を指定するためのメソッドであるとサポートしなければならなくて、SHOULDは、サポートします。 クライアントは単一の<playcollect>のタイプが要求するDTMF文法を混ぜてはいけません。
Van Dyke, et al. Informational [Page 36] RFC 4722 MSCML November 2006
ヴァンダイク、他 [36ページ]情報のRFC4722MSCML2006年11月
Following is a description of the "maxdigits" attribute.
以下に、"maxdigits"属性の記述があります。
Maxdigits Attribute:
Maxdigitsは以下を結果と考えます。
o maxdigits - optional, no default value: Specifies the maximum
number of DTMF digits to be collected.
o maxdigits--任意であることで、どんなデフォルトも以下を評価しません。 集められるためにDTMFケタの最大数を指定します。
The <pattern> element specifies a digit pattern or patterns for the media server to look for. This element may contain three different child elements that specify the type of DTMF grammar used in the expression. The <pattern> element has no attributes.
<パターン>要素はケタパターンかメディアサーバが探すパターンを指定します。 この要素は式に使用されるDTMF文法のタイプを指定する3つの異なった子供要素を含むかもしれません。 <パターン>要素には、属性が全くありません。
<regex> Use regular expressions to define DTMF patterns to match.
The complete regular expression syntax used in MSCML is described
in Appendix A.
合うようにDTMFパターンを定義する<regex>Use正規表現。 MSCMLで使用される完全な正規表現構文はAppendix Aで説明されます。
<mgcpdigitmap> Use digit maps as specified in MGCP [5].
MGCP[5]の指定されるとしての<mgcpdigitmap>Useケタ地図。
<megacodigitmap> Use digit maps as specified in H.248.1 [6].
H.248.1[6]の指定されるとしての<megacodigitmap>Useケタ地図。
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.
regex文法が使用されているとき、少なくとも1つの<regex>要素が<パターン>に存在していなければなりません。 複数の<regex>要素が存在しているかもしれません。 <mgcpdigitmap>か<megacodigitmap>文法が使用されているとき、<パターン>は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 Grammar Elementsの属性:
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文法を表すストリングを指定します。 Regex値はただ一つのDTMF文法を表します。MGCPとMEGACOケタ地図は、複数の文法が一連で説明されるのを許容します。
o name - optional, no default value: Associates a client defined
name for the grammar that is sent back in the <playcollect>
response. This attribute is most useful with regex type grammars
as each grammar element can have a unique name.
o 名前--任意であることで、どんなデフォルトも以下を評価しません。 <playcollect>応答で返送される文法のためにクライアントの定義された名を関連づけます。 それぞれの文法要素がユニークな名前を持つことができるようにこの属性はregexタイプ文法によって最も役に立ちます。
6.4.6. Playcollect Response
6.4.6. Playcollect応答
When the <playcollect> has finished, the media server sends a <response> payload to the client in a SIP INFO message.
<playcollect>が終わったとき、メディアサーバは<応答>ペイロードをSIP INFOメッセージのクライアントに送ります。
Details of the <playcollect> response are described in Section 10.5.
<playcollect>応答の詳細はセクション10.5で説明されます。
Van Dyke, et al. Informational [Page 37] RFC 4722 MSCML November 2006
ヴァンダイク、他 [37ページ]情報のRFC4722MSCML2006年11月
6.4.7. Playcollect Example
6.4.7. Playcollectの例
The following <playcollect> request (Figure 18) example depicts use of the "maxdigits" attribute to control digit collection.
以下の<playcollect>要求(図18)の例は、ケタ収集を制御するために"maxdigits"属性の使用について表現します。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<playcollect id="332986004" maxdigits="6" firstdigittimer="10000"
interdigittimer="5000" extradigittimer="1000"
interdigitcriticaltimer="1000" returnkey="#" escapekey="*"
cleardigits="no" barge="yes" maskdigits="no">
<prompt baseurl="http://www.example.com/prompts/">
<audio url="generic/en_US/enter_pin.wav"/>
</prompt>
</playcollect>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「><MediaServerControlバージョン=「1インチの><要求><playcollectイド=」332986004インチmaxdigits=「6インチのfirstdigittimer=」10000インチinterdigittimerは「5000インチextradigittimer=「1000インチinterdigitcriticaltimerは「1000年のインチ「再-牢番」=」#、と等しく」escapekey=」*と等しく」cleardigitsは「いいえ」と等しいです; =「はい」maskdigits=をはしけで運んでください、「「><迅速なbaseurl=「 http://www.example.com/prompts/ 「><オーディオurl=」ジェネリック/アン_米国/は_pin.wavに入り」/></迅速な></playcollect></要求></MediaServerControl>」がありません。
Figure 18: <Playcollect> Request Example Using the Maxdigits Attribute
図18: Maxdigits属性を使用する<Playcollect>要求の例
6.5. Prompt and Record <playrecord>
6.5. 迅速で記録的な<playrecord>。
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としてそれらを保存してください。 この要求は二相で続きます。 迅速であって、記録的です。
The <playrecord> request shares the basic attributes of <play> and <playcollect> as described in Section 6.3. MSCML also defines other attributes that control the behavior of the prompt and recording phases. These phases and the attributes that control them are described in the text and tables below.
<playrecord>要求はセクション6.3で説明されるように<プレー>と<playcollect>の基本的な属性を共有します。 また、MSCMLはプロンプトの振舞いを制御する他の属性と録音フェーズを定義します。 それらを制御するこれらのフェーズと属性は以下のテキストとテーブルで説明されます。
6.5.1. Prompt Phase
6.5.1. 迅速なフェーズ
The presence or absence of a "prompturl" attribute or child <prompt> element controls whether a prompt is played before recording begins. As previously noted, use of the "prompturl" attribute is deprecated, and clients SHOULD use <prompt> instead.
"prompturl"属性か子供の<の迅速な>要素の存在か欠如が、録音が始まる前にプロンプトがプレーされるかどうかを制御します。 上述しているように、"prompturl"属性の使用は推奨しないです、そして、クライアントSHOULDは代わりに<の迅速な>を使用します。
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>操作に同等です。 クライアントは、迅速なフェーズにinterruptibleであるようにDTMF入力(はしけ)で設定して、録音フェーズが始まる前に<playrecord>要求を終えるESCキーを指定するかもしれません。
Van Dyke, et al. Informational [Page 38] RFC 4722 MSCML November 2006
ヴァンダイク、他 [38ページ]情報のRFC4722MSCML2006年11月
The list below describes the attributes of <playrecord> that specify the behavior of the prompt phase of the request.
以下のリストは要求の迅速なフェーズの振舞いを指定する<playrecord>の属性について説明します。
Playrecord Attributes for the Prompt Phase:
迅速なフェーズのためのPlayrecord属性:
o barge - optional, default value "yes": Specifies whether user
input will barge the prompt and force transition to the record
phase. When it is set to "yes", a DTMF input will barge the
prompt. When it is set to "no", the prompt phase cannot be
barged, and any user input during the prompt is placed in the
quarantine buffer for inspection during the collect phase. Note
that if the "barge" attribute is set to "no", the "cleardigits"
attribute implicitly has a value of "yes". This ensures that the
media server does not leave DTMF input that occurred prior to the
current collection in the quarantine buffer after the request
completes.
o はしけ--任意のデフォルト値「はい」: ユーザ入力がプロンプトをはしけで運んで、記録的なフェーズへの変遷を強制するかどうか指定します。 それが「はい」に設定されるとき、DTMF入力はプロンプトをはしけで運ぶでしょう。 それが「いいえ」に設定されるとき、迅速なフェーズをはしけで運ぶことができません、そして、プロンプトの間のどんなユーザ入力も料金先方払いの段階の間、点検のための隔離バッファに置かれます。 「はしけ」属性が「いいえ」に設定されるなら、「はい」の値がそれとなく"cleardigits"属性にあることに注意してください。 これは、メディアサーバがそれが現在の収集の前に起こった要求の後の隔離バッファが終了する入力にDTMFを残さないのを確実にします。
o cleardigits - optional, default value "no": Specifies whether
previous user input should be considered or ignored for barge-in
purposes. When it is set to "yes", any previously buffered digits
are removed, so prior user input is ignored. If it is set to
"no", previously buffered digits will be considered. If
"cleardigits" is set to "no" and barge-in is enabled, previously
buffered digits will terminate the prompt phase immediately. In
this case, the prompt is not played, and recording begins
immediately.
o cleardigits--任意のデフォルト値「いいえ」: 前のユーザ入力が中のはしけの目的のために考えられるべきであるか、または無視されるべきであるかを指定します。 「はい」にそれを設定するとき、どんな以前にバッファリングされたケタも取り除くので、先使用者入力は無視されます。 それが「いいえ」に設定されると、以前にバッファリングされたケタは考えられるでしょう。 "cleardigits"が「いいえ」に設定されて、中ではしけで運ぶのが可能にされると、以前にバッファリングされたケタはすぐに、迅速なフェーズを終えるでしょう。 この場合、プロンプトはプレーされません、そして、録音はすぐに、始まります。
o escapekey - optional, default value "*": Specifies a DTMF key that
indicates the user wishes to terminate the current operation
without saving any input recorded to that point. Detection of the
mapped DTMF key terminates the request immediately and generates a
response.
o escapekey--任意のデフォルト値「*」: ユーザがそのポイントに記録されたどんな入力も保存しないで現在の操作を終えたがっているのを示すDTMFキーを指定します。 写像しているDTMFキーの検出は、すぐに、要求を終えて、応答を生成します。
Detection of the escape key generates a response message, and the operation returns immediately. If the user presses any other keys and if the prompt is interruptible (barge="yes"), then the play stops immediately, and the recording phase begins.
ESCキーの検出は応答メッセージを生成します、そして、操作はすぐに、戻ります。 ユーザが他のキーを押して、プロンプトがinterruptible(はしけ=「はい」)であるなら、プレーはすぐに止まります、そして、録音フェーズは始まります。
6.5.2. Record Phase
6.5.2. フェーズを記録してください。
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:
記録的なフェーズのためのPlayrecord属性:
Van Dyke, et al. Informational [Page 39] RFC 4722 MSCML November 2006
ヴァンダイク、他 [39ページ]情報のRFC4722MSCML2006年11月
o recurl - required, no default value: Specifies the target URL for
the recorded content.
o 再カール--必要であることで、どんなデフォルトも以下を評価しません。 記録された内容に目標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 持続時間--任意のデフォルト値「無限」: 最大の許容できる持続時間を録音に指定します。 時間的価値(セクション4.2.1)として、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": 長く録音を終える(取り消します)前に入力された初期のスピーチを待つ方法を指定します。 時間的価値(セクション4.2.1)として、1msから、前方へ言い表されました。または、ストリング「即座で」「無限」。 「即座値の」は、タイマがすぐに撃たれるはずであるのを示しますが、「無限」は、無期限に待つようメディアサーバに指示します。
o endsilence - optional, default value "4000ms": Specifies how long
the media server waits after speech has ended to stop the
recording. Expressed as a time value (Section 4.2.1) from 1ms
onwards or the strings "immediate" and "infinite." When set to
"infinite", the recording will continue indefinitely after speech
has ended and will only terminate due to a DTMF keypress or
because the input has reached the maximum desired duration.
o endsilence--任意のデフォルト値の"4000ms": スピーチが録音を止めるために終わった後にメディアサーバがどれくらい長い間待つかを指定します。 時間的価値(セクション4.2.1)として、1msから、前方へ言い表されました。または、ストリング「即座で」「無限」。 「無限」に設定されると、DTMF keypressのためか入力が最大の必要な持続時間に達したので、スピーチが終わって、終わっただけである後に録音は無期限に続くでしょう。
o recstopmask - optional, default value "0123456789ABCD#*":
Specifies a list of individual DTMF characters that, if detected,
will cause the recording to be terminated. To ensure that the
input of a specific key does not cause the recording to stop,
remove the DTMF key from the list.
o recstopmask--任意のデフォルト値「0123456789ABCD#*」: 検出されるなら録音を終えさせる個々のDTMFキャラクタのリストを指定します。 録音が特定のキーの入力で止まらないのを保証するには、リストから主要なDTMFを取り外してください。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバは、"再カール"属性で地方の、そして、リモートな(NFS)「ファイル://」が体系URLであるとサポートしなければなりません。 MSCMLは、間接的に(セクション8)が要求する<managecontent>を通して「http://」と「https://」が体系URLであるとサポートします。
Van Dyke, et al. Informational [Page 40] RFC 4722 MSCML November 2006
ヴァンダイク、他 [40ページ]情報のRFC4722MSCML2006年11月
The media server buffers and returns any digits collected in the prompt phase, with the exception of those contained in the "recstopmask" attribute, in the response.
メディアサーバは、迅速なフェーズで集められたどんなケタも、バッファリングして、返します、"recstopmask"属性に含まれたものを除いて、応答で。
The media server compares digits detected during the recording phase to the digits specified in the "recstopmask" to determine whether they indicate a recording termination request.
メディアサーバは録音段階の間に彼らが録音終了要求を示すかどうか決定するために"recstopmask"で指定されたケタに検出されたケタを比較します。
The media server ignores digits not present in the recstopmask and passes them into the recording. If DTMF input terminates the recording, the media server returns the collected digit to the client in the <response>.
メディアサーバは、recstopmaskの現在でないケタを無視して、それらを録音に通過します。 DTMF入力が録音を終えるなら、メディアサーバは<応答>におけるクライアントに集まっているケタを返します。
Once recording has begun, the media server writes the received media to the specified recurl URL no matter what DTMF events the media server detects. It is the responsibility of the client to examine the DTMF input returned in the <response> message to determine whether the audio file should be saved or deleted and, potentially, re-recorded.
録音がいったん始まると、メディアサーバがどんなDTMFイベントを検出しても、メディアサーバは指定された再カールURLへの受け取られていているメディアに書きます。 オーディオファイルが保存されるべきであるか、削除されて、または潜在的に再記録されるべきであるかを決定する<応答>メッセージで返されたDTMF入力を調べるのは、クライアントの責任です。
If the endsilence timer expires, the media server trims the end of the recorded audio by an amount equal to the value of the "endsilence" attribute.
endsilenceタイマが期限が切れるなら、"endsilence"属性の値と等しい量に従って、メディアサーバは記録されたオーディオの端を整えます。
When the recording is finished, the media server generates a <response> message and sends it to the client in a SIP INFO message. Details of the <playrecord> response are described in Section 10.6.
録音が終わっているとき、メディアサーバは、<応答>メッセージを生成して、SIP INFOメッセージのクライアントにそれを送ります。 <playrecord>応答の詳細はセクション10.6で説明されます。
6.5.3. Playrecord Example
6.5.3. Playrecordの例
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として波の形式でコード化された"再カール"属性で指定された目的地に、プロンプトをプレーして、それを記録します。
Van Dyke, et al. Informational [Page 41] RFC 4722 MSCML November 2006
ヴァンダイク、他 [41ページ]情報のRFC4722MSCML2006年11月
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<playrecord id="5556123"
recurl="file:////nfs.example.com/rec/name.wav"
recencoding="msgsm"
initsilence="5000" endsilence="3000" duration="30000"
barge="yes"
beep="yes"
mode="overwrite"
cleardigits="no"
escapekey="*"
recstopmask="0123456789#*">
<prompt>
<audio url="http://www.example.com/prompts/recordname.wav"/>
</prompt>
</playrecord>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「はい」「はい」「3000」「5000」"msgsm"「ファイル:////nfs.example.com/rec/name.wav」再カール=recencoding=initsilence=endsilence=持続時間=「30000」がはしけで運ぶ「「1インチの><要求><playrecordイド=」><MediaServerControlバージョン=5556123」=ビープ音=モードは「重ね書き」と等しいです; 「どんなcleardigits=escapekeyも」 *と等しくなく」recstopmaskが等しい、「0123456789#*「迅速な>の><オーディオurl=" http://www.example.com/prompts/recordname.wav "/></迅速な></playrecord><</要求></MediaServerControl>」
Figure 19: Recording Example
図19: 例を記録します。
6.6. Stop Request <stop>
6.6. 要求<停止>を止めてください。
The client issues a <stop> request when the objective is to stop a request in progress and not to initiate another operation. This request generates a <response> message from the media server.
クライアントは進行中の要求を止めて、別の操作を開始しないときに目的がことである時<停止>要求を出します。 この要求はメディアサーバからの<応答>メッセージを生成します。
The only attribute is id, which is optional.
唯一の属性がイドです。(そのイドは任意です)。
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.
クライアントによって定義された要求イドはメディアサーバの応答でクライアントへのそのオリジナルの要求とエコーに伴う非同期な応答を関連させます。
The following MSCML payload (Figure 20) depicts an example <stop> request.
以下のMSCMLペイロード(図20)は例の<停止>要求について表現します。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<stop id="4578903"/>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「><MediaServerControlバージョン=「1インチの><要求><停止イド=」4578903」/></要求></MediaServerControl>。
Figure 20: Stop Example
図20: 例を止めてください。
The format of a response to a <stop> request is detailed in Section 10.2.
<停止>要求への応答の形式はセクション10.2で詳細です。
Van Dyke, et al. Informational [Page 42] RFC 4722 MSCML November 2006
ヴァンダイク、他 [42ページ]情報のRFC4722MSCML2006年11月
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を変更するSIP再INVITEを扱います。 そのようなSDP変更に関する例は、保持SDPを受けるか、またはオーディオかビデオストリームを取り外すのを含んでいます。 これが起こると、メディアサーバで、すぐに、プレー>、<playcollect>、または<playrecord>が要求する実行している<を終えて、<応答>は、「理由=は止まりました。」と示します。
7. Call Leg Events
7. 脚のイベントに電話をしてください。
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 keypressesについて通知されるのを許容します、よく様々な呼び出し進歩信号のように。 呼び出し脚のイベントのための購読、イベント検出、および通知は同じ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.
呼び出し脚のイベントがMSCML<を送ることによって作られているので、購読は_必要なSIP対話に関する脚の>要求を構成します。 呼び出し脚のイベントはMSCML会議かIVRサービスと共に使用されるかもしれません。 IVRサービスで中古のいつ、<は、_脚の>要求SHOULD NOTがどんな会議関連の属性も含んでいるのを構成するか。 存在しているなら、メディアサーバはこれらを無視しなければなりません。 会議コントロール脚の上で呼び出し脚のイベント購読をしてはいけません、それにはイベント検出のために処理するどんな実際のRTPメディアもないので。 メディアサーバは<を拒絶しなければなりません。_>が要求する脚が会議コントロール脚を転送したのを構成してください。
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.
<は、含んでいる脚の>が子供要素<を要求する_が>と<イベント>を申し込むのを構成します。 <イベント>要素は脚のイベントと呼ぶために購読を制御する2つの子供要素を含むかもしれません。 これらは、<keypress>と<信号>です。 <は脚の>が1つの<keypress>要素を高々含まなければなりませんが、異なった呼び出し進歩イベントの通知を要求する複数の<信号>要素を含むかもしれないよう要求する_を構成します。
7.1. Keypress Events
7.1. Keypressイベント
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イベントの通知を受け取りたがっているとき、Keypressイベントは使用されています。 この施設の1つの使用はアプリケーション介入を必要とするDTMF入力のための会議脚をモニターすることです。 例えば、訪問者がそうしたがっているように議長に通知するには、話してください。 また、アプリケーション願望が文法とタイミング規制のコントロールを終了すると、Keypressイベントは使用されます。
Van Dyke, et al. Informational [Page 43] RFC 4722 MSCML November 2006
ヴァンダイク、他 [43ページ]情報のRFC4722MSCML2006年11月
When used in a subscription context, the <keypress> element has two attributes, 'report' and 'maskdigits', which are detailed in the list below.
購読文脈で使用されると、<keypress>要素には2つの属性、'レポート'、および'maskdigits'があります。(それは、以下のリストで詳細です)。
Keypress Subscription Attributes:
Keypress購読属性:
o report - required, no default value: Possible values are
'standard', 'long', 'both', and 'none'. 'Standard' means that
detected digits should be reported. 'Long' means that long digits
should be reported. 'Long' digits are defined as a single key
press held down for more than one second, or two distinct key
presses (a "double") of the same digit that occur within two
seconds of each other with no other intervening digits. 'Both'
means that both 'standard' and 'long' digit events should be
reported. As a 'long' digit consists of one or more "normal"
digits, a single long duration key press will generate one
standard event and one 'long' event. A "double" will produce two
standard events and one 'long' event. 'None' means that no
keypress events should be reported; it disables keypress event
reporting if enabled.
o 報告してください--必要であることで、どんなデフォルトも以下を評価しません。 可能な値は、'標準'の、そして、'長い''両方'と、'なにも'です。 '規格'は、検出されたケタが報告されるべきであることを意味します。 '長い'の間、長いケタが報告されるべきであることを意味します。 '長い'ケタは互いの2秒以内に他の介入しているケタなしで現れる1秒以上間押さえられた、単一の主要なプレス、または同じケタの2個の異なった主要なプレス(「二重」)と定義されます。 '両方'は、ともに'標準'の、そして、'長い'ケタイベントが報告されるべきであることを意味します。 '長い'ケタが複数の「正常な」ケタから成るとき、単一の長い持続時間主要なプレスは1つの標準のイベントと1つの'長い'イベントを生成するでしょう。 「二重」は2つの標準のイベントと1つの'長い'イベントを生産するでしょう。 'なにも'は、keypressイベントが全く報告されるべきでないことを意味します。 可能にされるなら、それは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要求の情報も提供する<状態>を含んでいます。 これらの通知属性の詳細は以下のリストで説明されます。
Keypress Notification Attributes:
Keypress通知属性:
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 メソッド--必要であることで、どんなデフォルトも以下を評価しません。 通知を生成したkeypress検出メソッドを指定します。 可能な値は、'標準'で、'長く'、'二重です'。
Van Dyke, et al. Informational [Page 44] RFC 4722 MSCML November 2006
ヴァンダイク、他 [44ページ]情報のRFC4722MSCML2006年11月
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)として経過時間を指定します。
7.1.1. Keypress Subscription Examples
7.1.1. Keypress購読の例
The following examples of MSCML payloads depict a subscription for standard keypress events and disabling keypress reporting.
MSCMLペイロードに関する以下の例は標準のkeypressイベントとkeypress報告を無効にするための購読について表現します。
Figure 21 shows a subscription for standard keypress events.
図21は標準のkeypressイベントのための購読を示しています。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<keypress report="standard"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「><MediaServerControlバージョン=、「><が、_脚の><が」 」 規格/></イベント></が></を申し込むという><イベント><keypressレポート=を申し込むのを構成するという1インチの><要求は_脚の></要求></MediaServerControl>を構成します。
Figure 21: Standard Digit Events Subscription
図21: 標準のケタイベント購読
Figure 22 shows a client disabling keypress event notifications.
図22は、クライアントが、keypressがイベント通知であると無効にするのを示します。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<keypress report="none"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「><MediaServerControlバージョン= なにもに「1インチの><要求><は、_脚の><が><イベント><keypressレポート=を申し込むのを構成」」という/></イベント></が</が構成する>を申し込む、_></要求></MediaServerControl>を急いで歩いてください。
Figure 22: Disabling Keypress Event Reporting
図22: イベント報告をKeypressに無効にします。
7.1.2. Keypress Notification Examples
7.1.2. Keypress通知の例
The following MSCML payloads depict keypress event notifications caused by various types of DTMF input.
以下のMSCMLペイロードは様々なタイプのDTMF入力で引き起こされたkeypressイベント通知について表現します。
Van Dyke, et al. Informational [Page 45] RFC 4722 MSCML November 2006
ヴァンダイク、他 [45ページ]情報のRFC4722MSCML2006年11月
Figure 23 shows a notification generated by the detection of a standard "4" DTMF digit. In this example, this is the first digit detected. Thus, the 'interdigittime' attribute has a value of '0'.
図23は標準の「4インチのDTMFケタ」の検出で生成された通知を示しています。 この例では、これは検出された最初のケタです。 したがって、'interdigittime'属性に、'0'の値があります。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<keypress digit="4" length="standard" method="standard"
interdigittime="0">
<status command="play" duration="10"/>
</keypress>
</notification>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「「標準」の「標準」の>の<のMediaServerControlのバージョンの=「1インチの><通知><keypressケタ=」の4インチの長さ=メソッド=interdigittimeは「0インチの><状態コマンド=」プレーと等しく」持続時間=「10インチ/>の</keypress></通知></MediaServerControl>」
Figure 23: Standard Keypress Notification
図23: 標準のKeypress通知
Figure 24 shows a notification generated by detection of a long pound (#).
図24は長いポンド(#)の検出で生成された通知を示しています。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<keypress digit="#" length="long" method="long"
interdigittime="200">
<status command="idle" duration="4"/>
</keypress>
</notification>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「長い」「長い」「><MediaServerControlバージョン=「1インチの><通知><keypressケタ=」#」の長さ=メソッド=interdigittimeは「200「><状態コマンド=」は怠け」持続時間=「4インチ/>の</keypress></通知></MediaServerControl>」と等しいです。
Figure 24: Long Keypress Notification
図24: 長いKeypress通知
7.2. Signal Events
7.2. 信号イベント
MSCML supports notification of certain call progress tones through the <signal> element. When used in a subscription context, the <signal> element has two attributes, 'type' and 'report', and no child elements. These attributes are detailed in the list below.
MSCMLは<信号>要素を通したある呼び出し進歩トーンの通知をサポートします。 購読文脈で使用される場合、<信号>要素には、2つの属性、'タイプ'、および'レポート'を持っていますが、どんな子供要素もありません。 これらの属性は以下のリストで詳細です。
Signal Subscription Attributes:
購読属性に合図してください:
o report - required, no default value: Controls whether the
specified signal is reported. Possible values are 'yes' and 'no'.
When set to 'yes', the media server invokes the required signal
detection code and reports detected events. When it is set to
'no', the media server disables the associated signal detection
code and does not report events.
o 報告してください--必要であることで、どんなデフォルトも以下を評価しません。 指定された信号が報告されるかどうかを制御します。 可能な値は、'はい'と'いいえ'です。 'はい'に設定されると、メディアサーバは、必要な信号検出コードを呼び出して、検出されたイベントを報告します。 それが'いいえ'に設定されるとき、メディアサーバは、関連信号が検出コードであることを無効にして、イベントを報告しません。
Van Dyke, et al. Informational [Page 46] RFC 4722 MSCML November 2006
ヴァンダイク、他 [46ページ]情報のRFC4722MSCML2006年11月
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、および400Hzと忙しくするために対応する'リング'、'CED'、'CNG'、および'400'がそれぞれ調子を変えるということです。
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.
先に述べたとおり、単一の<は脚の>が異なった呼び出し進歩トーンの通知を要求する複数の<信号>要素を含むかもしれないよう要求する_を構成します。 単一の<は、_脚の>要求SHOULD NOTが同じ'タイプ'属性値を持っている複数の<信号>要素を含むのを構成します。 サーバはメディアであるならそのような要求を受け取って、それはSHOULD名誉です。それをタイプする最後の要素指定は要求に現れます。
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.
サーバが即時型反応であることを<に作るメディアは、_指定された信号が検出されるとき、脚の>購読が通知を要求して、送るのを構成します。 指定された信号が確かに検出されるとすぐに、ただ一つの通知を送ります。 信号が絶え間なく持続していると、追加通知は送られないでしょう。 信号が中断されて、次に、再開すると、追加通知を送るでしょう。
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、および400Hzと忙しくするために対応する'リング'、'CED'、'CNG'、および'400'がそれぞれ調子を変えるということです。
7.2.1. Signal Event Examples
7.2.1. 信号イベントの例
The following MSCML payloads show a signal event subscription (Figure 25) and notification (Figure 26).
以下のMSCMLペイロードは信号イベント購読(図25)と通知(図26)を示しています。
Van Dyke, et al. Informational [Page 47] RFC 4722 MSCML November 2006
ヴァンダイク、他 [47ページ]情報のRFC4722MSCML2006年11月
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<configure_leg>
<subscribe>
<events>
<signal type="busy" report="yes"/>
</events>
</subscribe>
</configure_leg>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」= 「はい」/></イベント></が></を申し込むという「><MediaServerControlバージョンは「1インチの><要求><は、_脚の><が><イベント><信号タイプ=を申し込むのを構成すること」と忙しい状態で等しく」レポートが_脚の></要求></MediaServerControl>を構成します。
Figure 25: Signal Event Subscription
図25: 信号イベント購読
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<notification>
<signal type="busy"/>
</notification>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「「1インチの><通知><信号タイプ=」が忙しくする><MediaServerControlバージョン=」/></通知></MediaServerControl>。
Figure 26: Signal Event Notification
図26: 信号イベント通知
8. Managing Content <managecontent>
8. 内容<managecontent>を管理します。
MSCML uses the <managecontent> request to move recorded content from the media server to remote locations using the HTTP protocol. This is a store-and-forward model, which requires the completion of local temporary recording before the media server can send it to the web server. This facility is useful in applications such as voice messaging, where a message may be reviewed by the caller prior to being committed to persistent storage.
MSCMLはHTTPプロトコルを使用することでメディアサーバから離れた場所まで記録された内容を動かすという<managecontent>要求を使用します。 これは店とフォワードモデルです。(メディアサーバがそれをウェブサーバーに送ることができる前にモデルは地方の一時的な録音の完成を必要とします)。この施設は声のメッセージングなどのアプリケーションで役に立ちます。(そこでは、メッセージが永続的なストレージに心がける前に、訪問者によって再検討されるかもしれません)。
The <managecontent> request contains no child elements and has the attributes described in the list below.
<managecontent>要求は、子供要素を全く含んでいなくて、以下のリストで説明された属性を持っています。
Managecontent Attributes:
Managecontent属性:
o src - required, no default value: Specifies the local source URL
of the content. The URL scheme MUST be "file://".
o src--必要であることで、どんなデフォルトも以下を評価しません。 内容の地元筋URLを指定します。 URL体系は「ファイル://」であるに違いありません。
o dest - required (see note), no default value: Specifies the
destination URL. The URL scheme MUST be "http://". Note: If the
selected action is 'delete', this attribute is optional; otherwise
it is required.
o dest--必要であることで(注意を見ます)、どんなデフォルトも以下を評価しません。 目的地URLを指定します。 URL体系は「http://」であるに違いありません。 以下に注意してください。 選択された動作が'削除'であるなら、この属性は任意です。 さもなければ、それが必要です。
Van Dyke, et al. Informational [Page 48] RFC 4722 MSCML November 2006
ヴァンダイク、他 [48ページ]情報のRFC4722MSCML2006年11月
o action - optional, default value "move": Specifies the operation
for the media server to execute. Values can be either 'move' or
'delete'. The 'delete' action operates on the local source file.
After a successful move or delete, the media server deletes the
source file from its local storage. If the request is
unsuccessful, the source file is not deleted, which gives the
client complete control of the retry strategy.
o 動作--任意のデフォルト値「移動」: メディアサーバが実行する操作を指定します。 値は、'移動'か'削除'のどちらかであることができます。 '削除'動作は地元筋ファイルを作動させます。 うまくいっている移動の後、削除、メディアサーバは地方のストレージからソースファイルを削除します。 要求が失敗しているなら、ソースファイル(再試行戦略のクライアントの完全な支配力を与える)は削除されません。
o httpmethod - optional, default value "post": HTTP protocol method
for the media server to use in the HTTP request. The only values
are 'post' or 'put'.
o httpmethod--任意のデフォルト値「ポスト」: メディアサーバがHTTP要求で使用するHTTPプロトコルメソッド。 'ポスト'であるか'置かれた'唯一の値。
o name - required (see note), no default value: Specifies the field
name for the content in the form when using the 'post' method.
This is not to be confused with the "src" or "dest" attributes.
Note: This attribute is required when the "htttpmethod" has the
value "post" and is optional otherwise.
o 名前--必要であることで(注意を見ます)、どんなデフォルトも以下を評価しません。 'ポスト'メソッドを使用するとき、フォームで内容にフィールド名を指定します。 "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": 転送が完成する最大の日限を指定します。 時間的価値(セクション4.2.1)として、1msから、前方へ言い表されます。
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の種類を指定します。 それが提供されないなら、メディアサーバはプラットホームの特定のマッピングテーブルに基づく内容ファイル拡大からそれを推論しようとしなければなりません。 非標準の例のマッピングテーブルはTable3で見せられます。 あいまいさを避けるために私たち、RECOMMEND、クライアントは明らかにこの属性を設定します。 以下に注意してください。 ファイル拡張子から内容のMIMEの種類を推論できないなら、この属性が必要です。
Table 3 shows common audio and video MIME types and possible file extension mappings.
テーブル3は一般的なオーディオ、ビデオMIMEの種類、および可能なファイル拡張子マッピングを見せています。
Van Dyke, et al. Informational [Page 49] RFC 4722 MSCML November 2006
ヴァンダイク、他 [49ページ]情報のRFC4722MSCML2006年11月
+-----------+--------------------+
| 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 |
+-----------+--------------------+
+-----------+--------------------+ | 拡大| MIMEの種類| +-----------+--------------------+ | alaw| オーディオ的であるか、またはx-alaw基本的です。| | ulaw| オーディオ的であるか、または基本的です。| | msgsm| オーディオ/ms-gsm| | wav| オーディオ/x-wav| | tif| イメージ/いさかい| | いさかい| イメージ/いさかい| | mov| ビデオ/quicktime| | qt| ビデオ/quicktime| | 3gp| ビデオ/3gpp| | 3gpp| ビデオ/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>を使用するときimplementers限界ローカルファイルシステムがアクセスするSTRONGLY RECOMMENDです。 例えば、私たちは、ファイル所有権、そして/または、特定のディレクトリに基づいているようにアクセスを制限するよう奨励します。
8.1. Managecontent Example
8.1. Managecontentの例
The following is an example (Figure 27) showing a local file on the media server being transferred to an HTTP URL using the "put" method. The client sends the following request.
↓これはメディアサーバに関するローカルファイルが「置かれて」メソッドを使用することでHTTP URLに移されるのを示す例(図27)です。 クライアントは以下の要求を送ります。
<?xml version="1.0"?>
<MediaServerControl version="1.0">
<request>
<managecontent id="102"
src="file:////var/mediaserver/rec/6A5GH49B.ulaw"
dest="http://www.example.com/recordings/myrecording.ulaw"
mimetype="audio/basic" action="move" httpmethod="put"
fetchtimeout="5000"/>
</request>
</MediaServerControl>
<?xmlバージョン= 「1インチ?」「5000」/></要求></MediaServerControl「移動」「オーディオ的か基本的である」" http://www.example.com/recordings/myrecording.ulaw "「ファイル:////var/mediaserver/rec/6A5GH49B. ulaw」src=dest=mimetype=動作=httpmethod=が「置いた」「「1インチの><要求><managecontentイド=」><MediaServerControlバージョン=102」fetchtimeout=>。
Figure 27: Managecontent Example
図27: Managecontentの例
Van Dyke, et al. Informational [Page 50] RFC 4722 MSCML November 2006
ヴァンダイク、他 [50ページ]情報のRFC4722MSCML2006年11月
Note that the client can change the temporary file name assigned by the media server as part of this operation as shown.
クライアントが示されるようにこの操作の一部としてメディアサーバによって割り当てられた一時ファイル名を変えることができることに注意してください。
If the request is ambiguous, the media server MUST return a status code of "400" and text "Bad Request." If the media server is unable to execute a syntactically correct and unambiguous request, it MUST return a "500" status code with the text "Server Error." For example, the local file system access restrictions may prevent deletion of the specified file. In this case, the "reason" attribute in the response conveys additional details on the server error that occurred. If there is a network or remote server error, the media server provides detailed error information in the <error_info> element contained in the media server response. Additional information regarding <managecontent> responses is provided in Section 10.7.
要求があいまいであるなら、メディアサーバは「400」とテキストのステータスコードに「悪い要求」を返さなければなりません。 メディアサーバがシンタクス上正しくて明白な要求を実行できないなら、それはテキスト「サーバ誤り」と共に「500」ステータスコードを返さなければなりません。 例えば、ローカルファイルシステムアクセス制限は指定されたファイルの削除を防ぐかもしれません。 この場合、応答における「理由」属性は発生したサーバ誤りに関する追加詳細を伝えます。 ネットワークかリモートサーバ誤りがあれば、メディアサーバはメディアサーバ応答に含まれた<誤り_インフォメーション>要素に詳細なエラー情報を供給します。 <managecontent>応答に関する追加情報をセクション10.7に提供します。
9. Fax Processing
9. ファックス処理
9.1. Recording a Fax <faxrecord>
9.1. ファックス<faxrecord>を記録します。
The <faxrecord> request directs the media server to process a fax in answer mode. The reason for a request separate from <playrecord> is that the media server needs to know to process the T.30 [18] or T.38 [19] fax protocols.
<faxrecord>要求は、アンサーモードでファックスを処理するようメディアサーバに指示します。 <playrecord>から別々の要求の理由はメディアサーバが、T.30[18]を処理するのを知る必要があるか、またはT.38[19]がファックスでプロトコルを送るということです。
The <faxrecord> request has multiple attributes and one child element, <prompt>. Its attributes are described in the list below.
<faxrecord>要求には、複数の属性と1つの子供要素、<の迅速な>があります。 属性は以下のリストで説明されます。
Attributes of <faxrecord>:
<faxrecord>の属性:
o lclid - optional, default value "" (the empty string): A string
that identifies the called station.
o lclid--任意であることで、デフォルトとしてください、値、「「(空のストリング):」 被呼局を特定する五弦。
o prompturl - optional, no default value: The URL of the fax content
to be retrieved and played. The target may be a local or remote
(NFS) "file://" scheme URL or an "http://" or "https://" scheme
URL. NOTE: Use of this attribute is deprecated.
o prompturl--任意であることで、どんなデフォルトも以下を評価しません。 検索された、プレーされるべきファックス内容のURL。 目標は、ローカルの、または、リモートな(NFS)「ファイル://」体系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 promptencoding--任意であることで、どんなデフォルトも以下を評価しません。 'tif'を持っていないファイルか'いさかい'のために拡大をコード化する内容を指定します。 唯一の許容量が'いさかい'です。 この属性は「ファイル://」体系URLに影響するだけです。 以下に注意してください。 この属性の使用は推奨しないです。
o recurl - optional, no default value: Specifies the target URL for
the recorded content.
o 再カール--任意であることで、どんなデフォルトも以下を評価しません。 記録された内容に目標URLを指定します。
o rmtid - optional, no default value: Specifies the calling station
identifier of the remote terminal. If present, the media server
o rmtid--任意であることで、どんなデフォルトも以下を評価しません。 遠隔端末に関する起呼端末識別子を指定します。 プレゼント、メディアサーバです。
Van Dyke, et al. Informational [Page 51] RFC 4722 MSCML November 2006
ヴァンダイク、他 [51ページ]情報のRFC4722MSCML2006年11月
MUST reject transactions with the remote terminal if the remote
terminal's identifier does not match the value of 'rmtid'.
遠隔端末の識別子が'rmtid'の値に合っていないなら、遠隔端末でトランザクションを拒絶しなければなりません。
Clients SHOULD use the more flexible <prompt> mechanism for specifying fax content. Use of the 'prompturl' attribute is deprecated and may not be supported in future MSCML versions. The <prompt> element is described in Section 6.1.1. A <prompt> element sent in a <faxrecord> request MUST NOT contain <variable> elements.
クライアントSHOULDは、ファックス内容を指定するのによりフレキシブルな<迅速な>メカニズムを使用します。 'prompturl'属性の使用は、推奨しなく、将来のMSCMLバージョンでサポートされないかもしれません。 <の迅速な>要素はセクション6.1.1で説明されます。 <の迅速な>要素は、<faxrecord>要求が<の可変>要素を含んではいけないのを送りました。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバは、"再カール"属性で地方の、そして、リモートな(NFS)「ファイル://」が体系URLであるとサポートしなければなりません。 MSCMLは、間接的に(セクション8)が要求する<managecontent>を通して「http://」と「https://」が体系URLであるとサポートします。
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つのモードの1つで作動します: 受信して、投票してください。そうすれば、ターンアラウンドに投票します。 <の迅速な>の組み合わせか'prompturl'属性と'再カール'属性はモードを定義します。 テーブル4は詳細にこれらのモードを説明します。 テーブルの'迅速な'コラムには、要求に<の迅速な>要素か'prompturl'属性のどちらかがあるなら、値の'はい'があります。
+--------+--------+---------+---------------------------------------+ | prompt | recurl | Mode | Operation | +--------+--------+---------+---------------------------------------+ | no | no | Invalid | Request fails. | | no | yes | Receive | Record the fax to the target URL | | | | | specified in 'recurl'. | | yes | no | Poll | Send fax from source specified in the | | | | | <prompt> element or 'prompturl' | | | | | attribute. If there is a 'rmtid', it | | | | | MUST match the remote terminal's | | | | | identifier, or the request will fail. | | yes | yes | TP | Turnaround Poll (TP) mode. If the | | | | | remote terminal wishes to transmit, | | | | | the media server records the fax to | | | | | the target URL specified in 'recurl'. | | | | | If the remote terminal wishes to | | | | | receive, the media server sends the | | | | | fax from the source URL contained in | | | | | <prompt> or 'prompturl'. If there is | | | | | a 'rmtid', it MUST match remote | | | | | terminal's identifier, or the send | | | | | request will fail. A receive | | | | | operation will still succeed, | | | | | however. | +--------+--------+---------+---------------------------------------+
+--------+--------+---------+---------------------------------------+ | プロンプト| 再カール| モード| 操作| +--------+--------+---------+---------------------------------------+ | いいえ| いいえ| 病人| 要求は失敗します。 | | いいえ| はい| 受信してください。| 目標URLにファックスを記録してください。| | | | | '再カール'では、指定されています。 | | はい| いいえ| 投票| 指定されたソースからのファックスを送ってください。| | | | | <の迅速な>要素か'prompturl'| | | | | 結果と考えます。 'rmtid'があればそれ| | | | | 遠隔端末のものを合わせなければなりません。| | | | | 識別子、または要求意志のやり損ない。 | | はい| はい| TP| ターンアラウンドPoll(TP)モード。 the| | | | | 遠隔端末は伝わりたがっています。| | | | | サーバがファックスを記録するメディア| | | | | 目標URLは'再カール'で指定しました。 | | | | | 遠隔端末がそうしたいなら| | | | | 受信してください、そして、メディアサーバは発信します。| | | | | 中に含まれたソースURLからのファックス| | | | | <の迅速な>か'prompturl'。 あれば| | | | | a'rmtid'、それはリモートな状態で合わなければなりません。| | | | | または、端末の識別子、発信| | | | | 要求は失敗するでしょう。 Aは受信されます。| | | | | それでも、操作は成功するでしょう。| | | | | しかしながら。| +--------+--------+---------+---------------------------------------+
Table 4: Fax Receive Modes
テーブル4: ファックスはモードを受けます。
Van Dyke, et al. Informational [Page 52] RFC 4722 MSCML November 2006
ヴァンダイク、他 [52ページ]情報のRFC4722MSCML2006年11月
In receive mode, the media server receives the fax and writes the fax data to the target URL specified by the 'recurl' attribute.
モードが中で受信されて、メディアサーバは、'再カール'属性によって指定された目標URLに、ファックスを受け止めて、ファックスデータを書きます。
In poll mode, the media server sends a fax, but as a polled (called) device.
しかし、投票モードで、メディアサーバは投票された(呼ばれる)デバイスとしてファックスを送信します。
In turnaround poll mode, the media server will record a fax that the remote machine sends. If the remote machine requests a transmission, then the media server will send the fax.
ターンアラウンド投票モードに、メディアサーバはリモートマシンが送るファックスを記録するでしょう。 リモートマシンがトランスミッションを要求すると、メディアサーバはファックスを送るでしょう。
When transmitting a fax, the media server will advertise that it can receive faxes in the DIS message. Likewise, when receiving a fax, the media server will advertise that it can send faxes in the DIS message.
ファックスを送るとき、メディアサーバは、DISメッセージでファックスを受け止めることができるのは広告を出すでしょう。 ファックスを受け止めるとき、同様に、メディアサーバは、DISメッセージでファックスを送ることができるのは広告を出すでしょう。
The media server MUST flush any quarantined digits when it receives a <faxrecord> request.
<faxrecord>要求を受け取るとき、メディアサーバはどんな検疫しているケタも洗い流さなければなりません。
9.2. Sending a Fax <faxplay>
9.2. ファックス<faxplay>を送ります。
The <faxplay> request directs the media server to process a fax in originate mode. The reason for a request separate from <play> is that the media server needs to know to process the T.30 [18] or T.38 [19] fax protocols.
<faxplay>要求は、オリジネイトモードでファックスを処理するようメディアサーバに指示します。 <プレー>から別々の要求の理由はメディアサーバが、T.30[18]を処理するのを知る必要があるか、またはT.38[19]がファックスでプロトコルを送るということです。
The <faxplay> request has multiple attributes and one child element, <prompt>. Its attributes are described in the list below.
<faxplay>要求には、複数の属性と1つの子供要素、<の迅速な>があります。 属性は以下のリストで説明されます。
Attributes of <faxplay>:
<faxplay>の属性:
o lclid - optional, default value "" (the empty string): A string
that identifies the called station.
o lclid--任意であることで、デフォルトとしてください、値、「「(空のストリング):」 被呼局を特定する五弦。
o prompturl - optional, no default value: The URL of the content to
be retrieved and played. The target may be a local or remote
(NFS) "file://" scheme URL or an "http://" or "https://" scheme
URL. NOTE: Use of this attribute is deprecated.
o prompturl--任意であることで、どんなデフォルトも以下を評価しません。 検索された、プレーされるべき内容のURL。 目標は、ローカルの、または、リモートな(NFS)「ファイル://」体系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 promptencoding--任意であることで、どんなデフォルトも以下を評価しません。 'tif'を持っていないファイルか'いさかい'のために拡大をコード化する内容を指定します。 唯一の許容量が'いさかい'です。 この属性は「ファイル://」体系URLに影響するだけです。 以下に注意してください。 この属性の使用は推奨しないです。
o recurl - optional, no default value: Specifies the target URL for
the recorded content.
o 再カール--任意であることで、どんなデフォルトも以下を評価しません。 記録された内容に目標URLを指定します。
o rmtid - optional, no default value: Specifies the calling station
identifier of the remote terminal. If present, the media server
o rmtid--任意であることで、どんなデフォルトも以下を評価しません。 遠隔端末に関する起呼端末識別子を指定します。 プレゼント、メディアサーバです。
Van Dyke, et al. Informational [Page 53] RFC 4722 MSCML November 2006
ヴァンダイク、他 [53ページ]情報のRFC4722MSCML2006年11月
MUST reject transactions with the remote terminal if the remote
terminal's identifier does not match the value of 'rmtid'.
遠隔端末の識別子が'rmtid'の値に合っていないなら、遠隔端末でトランザクションを拒絶しなければなりません。
Clients SHOULD use the more flexible <prompt> mechanism for specifying fax content. Use of the 'prompturl' attribute is deprecated and may not be supported in future MSCML versions. The <prompt> element is described in Section 6.1.1. A <prompt> element sent in a <faxrecord> request MUST NOT contain <variable> elements.
クライアントSHOULDは、ファックス内容を指定するのによりフレキシブルな<迅速な>メカニズムを使用します。 'prompturl'属性の使用は、推奨しなく、将来のMSCMLバージョンでサポートされないかもしれません。 <の迅速な>要素はセクション6.1.1で説明されます。 <の迅速な>要素は、<faxrecord>要求が<の可変>要素を含んではいけないのを送りました。
Media servers MUST support local and remote (NFS) "file://" scheme URLs in the "recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request.
メディアサーバは、"再カール"属性で地方の、そして、リモートな(NFS)「ファイル://」が体系URLであるとサポートしなければなりません。 MSCMLは、間接的に(セクション8)が要求する<managecontent>を通して「http://」と「https://」が体系URLであるとサポートします。
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つのモードの1つで作動します: リモートな状態で発信してください。投票、およびターンアラウンド投票。 <の迅速な>の組み合わせか'prompturl'属性と'再カール'属性はモードを定義します。 テーブル5は詳細にこれらのモードを説明します。 テーブルの'迅速な'コラムには、要求に<の迅速な>要素か'prompturl'属性のどちらかがあるなら、値の'はい'があります。
Van Dyke, et al. Informational [Page 54] RFC 4722 MSCML November 2006
ヴァンダイク、他 [54ページ]情報のRFC4722MSCML2006年11月
+--------+--------+---------+---------------------------------------+ | 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. | +--------+--------+---------+---------------------------------------+
+--------+--------+---------+---------------------------------------+ | プロンプト| 再カール| モード| 操作| +--------+--------+---------+---------------------------------------+ | いいえ| いいえ| 病人| 要求は失敗します。 | | はい| いいえ| 発信してください。| 指定されたソースからのファックスを送ってください。| | | | | <の迅速な>要素か'prompturl'| | | | | 結果と考えます。 'rmtid'があればそれ| | | | | 遠隔端末のものを合わせなければなりません。| | | | | 識別子、または要求意志のやり損ない。 | | いいえ| はい| 投票| 指定されたソースからのファックスを送ってください。| | | | | <の迅速な>要素か'prompturl'| | | | | リモートを仮定する属性| | | | | 端末が指定する、それはaを受けることができます。| | | | | DISメッセージでは、ファックスします。 リモートです。| | | | | 端末は逆をサポートしません。| | | | | 投票すると、要求は失敗するでしょう。 if| | | | | 'rmtid'は指定されて、それは合わなければなりません。| | | | | または遠隔端末の識別子。| | | | | 要求は失敗するでしょう。 | | はい| はい| TP| ターンアラウンドPoll(TP)モード。 the| | | | | 遠隔端末は伝わりたがっています。| | | | | サーバがファックスを記録するメディア| | | | | 目標URLは'再カール'で指定しました。 | | | | | 遠隔端末がそうしたいなら| | | | | 受信してください、そして、メディアサーバは発信します。| | | | | 中に含まれたソースURLからのファックス| | | | | <の迅速な>か'prompturl'。 あれば| | | | | a'rmtid'、それはリモートな状態で合わなければなりません。| | | | | または、端末の識別子、発信| | | | | 要求は失敗するでしょう。 Aは受信されます。| | | | | それでも、操作は成功するでしょう。| | | | | しかしながら。| +--------+--------+---------+---------------------------------------+
Table 5: Fax Send Modes
テーブル5: ファックスはモードを送ります。
In send mode, the media server sends the fax.
モード、サーバがファックスを送るメディアは中に発信します。
In remote poll mode, the client places a call on behalf of the media server. The media server requests a fax transmission from the remote fax terminal.
リモート投票モードに、クライアントはメディアサーバを代表して電話をします。メディアサーバは遠く離れたファックス端末からファックス送信を要求します。
In turnaround poll mode, the media server will record a fax that the remote machine sends. If the remote machine requests a transmission, then the media server will send the fax.
ターンアラウンド投票モードに、メディアサーバはリモートマシンが送るファックスを記録するでしょう。 リモートマシンがトランスミッションを要求すると、メディアサーバはファックスを送るでしょう。
When transmitting a fax, the media server will advertise that it can receive faxes in the DIS message. Likewise, when receiving a fax,
ファックスを送るとき、メディアサーバは、DISメッセージでファックスを受け止めることができるのは広告を出すでしょう。 同様にファックスを受け止めるとき
Van Dyke, et al. Informational [Page 55] RFC 4722 MSCML November 2006
ヴァンダイク、他 [55ページ]情報のRFC4722MSCML2006年11月
the media server will advertise that it can send faxes in the DIS message.
メディアサーバは、DISメッセージでファックスを送ることができるのは広告を出すでしょう。
The media server MUST flush any quarantined digits when it receives a <faxplay> request.
<faxplay>要求を受け取るとき、メディアサーバはどんな検疫しているケタも洗い流さなければなりません。
10. MSCML Response Attributes and Elements
10. MSCML応答属性と要素
10.1. Mechanism
10.1. メカニズム
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".
メディアサーバは、MSCMLが要求するクライアントの領収書が200OKのTypeか415BadメディアTypeの応答を送ることによってSIP INVITEを送ったと認めます。 SIP要求が「アプリケーション/sdp」か「アプリケーション/mediaservercontrol+xml」を除いたcontent typeを含んでいると、メディアサーバは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".
メディアサーバは、MSCMLが要求するクライアントの領収書が200OKか415BadメディアTypeと共にSIP INFOを送ったと認めます。 INFO要求が「アプリケーション/mediaservercontrol+xml」を除いたcontent typeを含んでいるなら、メディアサーバは415で反応します。
The media server transports the MSCML <response> message in a SIP INFO request.
メディアサーバはSIP INFO要求におけるMSCML<応答>メッセージを輸送します。
If there is an error in the request or the media server cannot complete the request, the media server sends the <response> message very shortly after receiving the request. If the request is able to proceed, the <response> contains final status information as described below.
要求における誤りがあることができないか、メディアサーバが要求を終了できないなら、要求を受け取った非常にすぐ後に、メディアサーバは<応答>メッセージを送ります。 要求が続くことができるなら、<応答>は以下で説明されるように最終的な状態情報を含んでいます。
10.2. Base <response> Attributes
10.2. 基地の<応答>属性
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が要求に含んだエコーズ。
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要求タイプを指定します。 許容量は、「_会議を構成してください」と、「_脚を構成してください」と、「プレー」と、"playcollect"と、"playrecord"と、「停止」と、"faxplay"と、"faxrecord"と、"managecontent"です。
Van Dyke, et al. Informational [Page 56] RFC 4722 MSCML November 2006
ヴァンダイク、他 [56ページ]情報のRFC4722MSCML2006年11月
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はRFC3261[4]で定義された状態のクラスの部分集合を使用します。 MSCMLでは、2XX応答は成功を示します、そして、4XX応答はクライアント誤りを示します、そして、5XX応答はメディアサーバで誤りを示します。どんな1XX、3XXも、または6XXステータスコードもMSCMLにありません。
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.
<への応答は、_会議>と<停止>要求が上の属性だけを含むのを構成します。 他の要求へのMSCML応答は追加要求特有の属性と要素を含むかもしれません。 これらは以下のセクションで説明されます。
10.3. Response Attributes and Elements for <configure_leg>
10.3. <のための応答属性と要素は_脚の>を構成します。
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.
<への応答は、_脚の>要求にはセクション10.2で定義されたベース応答属性しかないのを構成します。 _チーム>要素、応答はその脚のためにチームメート構成について説明する<チーム>要素を含んでいます。しかしながら、要求が<を含んでいるときには、<チーム>要素の属性が以下のリストに示されるのを構成してください。
Attributes of <team>:
<の属性は>を組にします:
o id - required, no default value: The client-defined unique
identifier for the conference leg.
o イド--必要であることで、どんなデフォルトも以下を評価しません。 会議脚のためのクライアントによって定義されたユニークな識別子。
o numteam - required, no default value: The number of team members
for the leg.
o numteam--必要であることで、どんなデフォルトも以下を評価しません。 脚のためのチームメンバーの数。
Additional information on each team member is conveyed by child <teammate> elements contained within <team>. Each teammate is represented by a single element in the list. The <teammate> element has a single attribute, as described below.
それぞれのチームメンバーの追加情報は<チーム>の中に含まれた子供<チームメート>要素によって伝えられます。 各チームメートはリストでただ一つの要素によって代理をされます。 <チームメート>要素には、ただ一つの属性が以下で説明されるようにあります。
Attributes of <teammate>:
<チームメート>の属性:
o id - required, no default value: The client-defined unique
identifier for the teammate leg.
o イド--必要であることで、どんなデフォルトも以下を評価しません。 チームメート脚のためのクライアントによって定義されたユニークな識別子。
10.4. Response Attributes and Elements for <play>
10.4. <のための応答属性と要素は>をプレーします。
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で定義されたベース応答属性に加えて、<プレー>要求への応答には、以下のリストで説明された追加属性があります。
Van Dyke, et al. Informational [Page 57] RFC 4722 MSCML November 2006
ヴァンダイク、他 [57ページ]情報のRFC4722MSCML2006年11月
MSCML Response Attributes for <play>:
<のためのMSCML応答属性は>をプレーします:
o reason - optional, no default value: For requests that are not
completed immediately, the "reason" attribute conveys additional
information regarding why the command was completed. Possible
values are "stopped", indicating that an explicit or implicit
<stop> request was received, and "EOF", indicating that the end of
the specified sequence of URLs was reached.
o 理由--任意であることで、どんなデフォルトも以下を評価しません。 すぐに終了していない要求のために、「理由」属性はコマンドが終了した理由に関する追加情報を伝えます。 可能な値は「止められます」、その停止>が受け取られたよう、要求する明白であるか内在している<、および"EOF"を示して、URLの指定された系列の端に達したのを示して。
o playduration - required, no default value: A time value (Section
4.2.1) that returns the duration of the associated content
playout.
o playduration--必要であることで、どんなデフォルトも以下を評価しません。 関連満足している再生の持続時間を返す時間的価値(セクション4.2.1)。
o playoffset - required, no default value: A time value (Section
4.2.1) that returns the time offset into the specified content
sequence where play was terminated. If the initial "offset" value
in the sequence was "0", then "playduration" and "playoffset" are
equal. However, if the initial offset had some other value,
"playoffset" serves as a bookmark for the client to resume play in
a subsequent request.
o playoffset--必要であることで、どんなデフォルトも以下を評価しません。 時間を返す時間的価値(セクション4.2.1)はプレーが終えられた指定された満足している系列に相殺されました。 初期の「オフセット」の値であるなら、系列には、「その時、"playduration"と"playoffset"は何0インチも、等しいこと」がありました。 しかしながら、初期のオフセットにある他の値があったなら、クライアントが再開するブックマークとしての"playoffset"サーブはその後の要求でプレーします。
10.4.1. Reporting Content Retrieval Errors
10.4.1. 満足している検索誤りを報告します。
If the associated request set "stoponerror=yes" in <prompt> and an error occurred while retrieving the specified content the response will include an <error_info> element detailing the problem. This element contains the response information received from the remote content server. The <error_info> element has the attributes described in the list below.
関連要求が「stoponerrorははいと等しいこと」を<の迅速な>にはめ込んで、誤りが指定された内容を検索している間、発生したなら、応答は問題を詳しく述べる<誤り_インフォメーション>要素を含むでしょう。 この要素はリモート満足しているサーバから受け取られた応答情報を含んでいます。<誤り_インフォメーション>要素には、以下のリストで説明された属性があります。
Attributes of <error_info>:
<誤り_インフォメーション>の属性:
o code - required, no default value: The status code returned by the
remote content server. For example, a web server might return 404
to indicate that the requested content was not found.
o コード--必要であることで、どんなデフォルトも以下を評価しません。 ステータスコードはリモート満足しているサーバで戻りました。例えば、ウェブサーバーは、要求された内容が見つけられなかったのを示すために404を返すかもしれません。
o text - required, no default value: The human-readable reason
phrase returned by the remote content server. For example, the
reason phrase "Not Found" would be returned if the requested
content was not found.
o テキスト--必要であることで、どんなデフォルトも以下を評価しません。 人間読み込み可能な理由句はリモート満足しているサーバで戻りました。例えば、要求された内容を見つけないなら、「見つけられない」という理由句を返すでしょうに。
o context - required, no default value: Contains the content URL
that was being fetched when the retrieval error occurred. This
enables the client to know precisely which URL in a sequence
caused the problem.
o 文脈--必要であることで、どんなデフォルトも以下を評価しません。 検索誤りが発生したときとって来られていた満足しているURLを含んでいます。 これは、クライアントが、どのURLが次々に問題を引き起こしたかを正確に知っているのを可能にします。
An <error_info> element MAY be present in the response to any request that contains a child <prompt> element.
<誤り_インフォメーション>要素は子供の<の迅速な>要素を含むどんな要求への応答でも存在しているかもしれません。
Van Dyke, et al. Informational [Page 58] RFC 4722 MSCML November 2006
ヴァンダイク、他 [58ページ]情報のRFC4722MSCML2006年11月
10.5. Response Attributes and Elements for <playcollect>
10.5. <playcollect>のための応答属性と要素
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 理由--任意であることで、どんなデフォルトも以下を評価しません。 すぐに終了していない要求のために、「理由」属性はコマンドが終了した理由に関する追加情報を伝えます。 明白であるか暗黙の<停止>要求が受け取られたのを示して、可能な値は「止められます」。 DTMF文法が合わせられたことを意味する「マッチ」。 収集タイマの1つが期限が切れる前にDTMFが入力したそのノーを示す「タイムアウト」を受け取りました。 そして、"「再-牢番」"か"escapekey"、DTMFケタがそのキーに写像した意味が検出されました、そして、リターンキーかESCキーがそれぞれ操作を終えました。
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 playoffset--必要であることで、どんなデフォルトも以下を評価しません。 時間を返す時間的価値(セクション4.2.1)はプレーが終えられた指定された満足している系列に相殺されました。 初期の「オフセット」の値であるなら、系列には、「その時、"playduration"と"playoffset"は何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で説明されるように<誤り_インフォメーション>要素を含むかもしれません。
Van Dyke, et al. Informational [Page 59] RFC 4722 MSCML November 2006
ヴァンダイク、他 [59ページ]情報のRFC4722MSCML2006年11月
10.6. Response Attributes and Elements for <playrecord>
10.6. <playrecord>のための応答属性と要素
In addition to the base response attributes defined in Section 10.2, responses to <playrecord> requests have the additional attributes described in the list below.
セクション10.2で定義されたベース応答属性に加えて、<playrecord>要求への応答には、以下のリストで説明された追加属性があります。
o reason - optional, no default value: For requests that are not
completed immediately, the "reason" attribute conveys additional
information regarding why the command was completed. Possible
values are "stopped", indicating that an explicit or implicit
<stop> request was received; "digit", meaning that a DTMF digit
was detected and that the prompt phase was barged; "init_silence",
meaning the recording terminated because of no input;
"end_silence", meaning that the recording was terminated because
the "endsilence" timer elapsed; "max_duration", indicating that
the maximum time for the recording was reached; "escapekey",
indicating that the DTMF input mapped to "escapekey" was detected,
thus terminating the recording; and "error", indicating a general
operation failure.
o 理由--任意であることで、どんなデフォルトも以下を評価しません。 すぐに終了していない要求のために、「理由」属性はコマンドが終了した理由に関する追加情報を伝えます。 明白であるか暗黙の<停止>要求が受け取られたのを示して、可能な値は「止められます」。 DTMFケタが検出されて、迅速なフェーズがはしけで運ばれたことを意味する「ケタ」 録音を意味する「イニット_沈黙」がどんな入力でも終わりませんでした。 "endsilence"タイマが経過したので録音が終えられたことを意味する「終わり_沈黙」。 録音のための最大の時間に達したのを示す「最大_持続時間」。 "escapekey"、それをDTMF入力が"escapekey"に写像した示すのは検出されて、その結果、録音を終えました。 そして、一般的な操作失敗を示す「誤り。」
o playduration - required, no default value: A time value (Section
4.2.1) that returns the duration of the associated content
playout. If the caller barged the prompt, this value will reflect
the play duration up to that event.
o playduration--必要であることで、どんなデフォルトも以下を評価しません。 関連満足している再生の持続時間を返す時間的価値(セクション4.2.1)。 訪問者がプロンプトをはしけで運んだなら、この値はプレー持続時間をそのイベントまで反映するでしょう。
o playoffset - required, no default value: A time value (Section
4.2.1) that returns the time offset into the specified content
sequence where play was terminated. If the initial "offset" value
in the sequence was "0", then "playduration" and "playoffset" are
equal. However, if the initial offset had some other value,
"playoffset" serves as a bookmark for the client to resume play in
a subsequent request. If the caller barged the prompt this value
will reflect the time offset at which barge-in occurred.
o playoffset--必要であることで、どんなデフォルトも以下を評価しません。 時間を返す時間的価値(セクション4.2.1)はプレーが終えられた指定された満足している系列に相殺されました。 初期の「オフセット」の値であるなら、系列には、「その時、"playduration"と"playoffset"は何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 recduration - required, no default value: A time value (Section 4.2.1) indicating the elapsed duration of the recording.
Responses to <playrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
Responses to <playrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
Van Dyke, et al. Informational [Page 60] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 60] RFC 4722 MSCML November 2006
10.7. Response Attributes and Elements for <managecontent>
10.7. Response Attributes and Elements for <managecontent>
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.
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.
10.8. Response Attributes and Elements for <faxplay> and <faxrecord>
10.8. Response Attributes and Elements for <faxplay> and <faxrecord>
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.
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.
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 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 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 - 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_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 - required (see note), no default value: Indicates the number of fax pages sent. Note: This attribute is required if any pages were sent.
o faxcode - required, no default value: The value of the "faxcode"
attribute is the binary-or of the bit patterns defined in Table 6.
o faxcode - required, no default value: The value of the "faxcode" attribute is the binary-or of the bit patterns defined in Table 6.
Van Dyke, et al. Informational [Page 61] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 61] RFC 4722 MSCML November 2006
+------+--------------------------------------+
| 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 |
+------+--------------------------------------+
+------+--------------------------------------+ | 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
Table 6: Faxcode Mask
Responses to <faxplay> and <faxrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
Responses to <faxplay> and <faxrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
11. Formal Syntax
11. Formal Syntax
The following syntax specification uses XML Schema as described in XML [7].
The following syntax specification uses XML Schema as described in XML [7].
11.1. Schema
11.1. Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="MediaServerControl">
<xs:complexType>
<xs:choice>
<xs:element name="request">
<xs:complexType>
<xs:choice>
<xs:element name="configure_conference"
type="configure_conferenceRequestType"/>
<xs:element name="configure_leg"
type="configure_legRequestType"/>
<xs:element name="play" type="playRequestType"/>
<xs:element name="playcollect"
type="playcollectRequestType"/>
<xs:element name="playrecord"
type="playrecordRequestType"/>
<?xml version="1.0" 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"/>
Van Dyke, et al. Informational [Page 62] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 62] RFC 4722 MSCML November 2006
<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: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">
Van Dyke, et al. Informational [Page 63] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 63] RFC 4722 MSCML November 2006
<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: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>
Van Dyke, et al. Informational [Page 64] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 64] RFC 4722 MSCML November 2006
<xs:complexType name="configure_teamType">
<xs:sequence>
<xs:element name="teammate" type="teammateType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string"/>
<xs:attribute name="action" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="add"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="query"/>
<xs:enumeration value="set"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="teammateType">
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="playcollectRequestType">
<xs:complexContent>
<xs:extension base="base_requestType">
<xs:sequence>
<xs:element name="prompt" type="promptType"
minOccurs="0"/>
<xs:element name="pattern" type="dtmfGrammarType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="prompturl" type="xs:string"/>
<xs:attribute name="offset" type="xs:string"/>
<xs:attribute name="barge" type="yesnoType" default="yes"/>
<xs:attribute name="promptencoding" type="xs:string"/>
<xs:attribute name="cleardigits" type="yesnoType"
default="no"/>
<xs:attribute name="maxdigits" type="xs:string"/>
<xs:attribute name="firstdigittimer" type="xs:string"
default="5000ms"/>
<xs:attribute name="interdigittimer" type="xs:string"
default="2000ms"/>
<xs:attribute name="extradigittimer" type="xs:string"
default="1000ms"/>
<xs:attribute name="interdigitcriticaltimer"
type="xs:string"/>
<xs:attribute name="skipinterval" type="xs:string"
default="6s"/>
<xs:attribute name="ffkey" type="DTMFkeyType"/>
<xs:attribute name="rwkey" type="DTMFkeyType"/>
<xs:complexType 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"/>
Van Dyke, et al. Informational [Page 65] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 65] RFC 4722 MSCML November 2006
<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="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"/>
Van Dyke, et al. Informational [Page 66] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 66] RFC 4722 MSCML November 2006
<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: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>
Van Dyke, et al. Informational [Page 67] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 67] RFC 4722 MSCML November 2006
<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="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>
Van Dyke, et al. Informational [Page 68] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 68] RFC 4722 MSCML November 2006
<xs:complexType name="stoponerrorResponseType">
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attribute name="text" type="xs:string" use="required"/>
<xs:attribute name="context" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="configure_teamResponseType">
<xs:sequence>
<xs:element name="teammate" type="teammateType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="numteam" type="xs:integer" use="required"/>
</xs:complexType>
<!-- Definitions for MSCML event subscriptions and -->
<!-- embedded types -->
<xs:complexType name="conference_eventsubscriptionType">
<xs:sequence>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="activetalkers"
type="activetalkersSubscriptionType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="activetalkersSubscriptionType">
<xs:attribute name="report" type="yesnoType" use="required"/>
<xs:attribute name="interval" type="xs:string" default="60s"/>
</xs:complexType>
<xs:complexType name="leg_eventsubscriptionType">
<xs:sequence>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="keypress"
type="keypressSubscriptionType" minOccurs="0"
maxOccurs="1"/>
<xs:element name="signal" type="signalSubscriptionType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="keypressSubscriptionType">
<xs:attribute name="report" use="required">
<xs:complexType 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">
Van Dyke, et al. Informational [Page 69] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 69] RFC 4722 MSCML November 2006
<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: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>
Van Dyke, et al. Informational [Page 70] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 70] RFC 4722 MSCML November 2006
</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: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>
Van Dyke, et al. Informational [Page 71] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 71] RFC 4722 MSCML November 2006
<xs:complexType name="promptcontentType">
<xs:attribute name="url" type="xs:string" use="required"/>
<xs:attribute name="encoding" type="xs:string"/>
<xs:attribute name="gain" type="xs:string" default="0"/>
<xs:attribute name="gaindelta" type="xs:string" default="0"/>
<xs:attribute name="rate" type="xs:string" default="0"/>
<xs:attribute name="ratedelta" type="xs:string" default="0"/>
</xs:complexType>
<xs:complexType name="spokenvariableType">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="dat"/>
<xs:enumeration value="dig"/>
<xs:enumeration value="dur"/>
<xs:enumeration value="mth"/>
<xs:enumeration value="mny"/>
<xs:enumeration value="num"/>
<xs:enumeration value="sil"/>
<xs:enumeration value="str"/>
<xs:enumeration value="tme"/>
<xs:enumeration value="wkd"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="subtype">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="mdy"/>
<xs:enumeration value="dmy"/>
<xs:enumeration value="ymd"/>
<xs:enumeration value="ndn"/>
<xs:enumeration value="t12"/>
<xs:enumeration value="t24"/>
<xs:enumeration value="USD"/>
<xs:enumeration value="gen"/>
<xs:enumeration value="ndn"/>
<xs:enumeration value="crd"/>
<xs:enumeration value="ord"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
<xs:simpleType name="yesnoType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
<xs:complexType 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"/>
Van Dyke, et al. Informational [Page 72] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 72] RFC 4722 MSCML November 2006
<xs:enumeration value="1"/>
<xs:enumeration value="0"/>
<xs:enumeration value="true"/>
<xs:enumeration value="false"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="DTMFkeyType">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]"/>
<xs:pattern value="[A-D]"/>
<xs:pattern value="[a-d]"/>
<xs:pattern value="#"/>
<xs:pattern value="\*"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="gainType">
<xs:choice>
<xs:element name="auto" type="autogainType"/>
<xs:element name="fixed" type="fixedgainType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="autogainType">
<xs:attribute name="startlevel" type="xs:string"/>
<xs:attribute name="targetlevel" type="xs:string"/>
<xs:attribute name="silencethreshold" type="xs:string"/>
</xs:complexType>
<xs:complexType name="fixedgainType">
<xs:attribute name="level" type="xs:string"/>
</xs:complexType>
</xs:schema>
<xs: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. IANA Considerations
12. IANA Considerations
12.1. IANA Registration of MIME Media Type application/
mediaservercontrol+xml
12.1. IANA Registration of MIME Media Type application/ mediaservercontrol+xml
MIME media type name: application
MIME subtype name: mediaservercontrol+xml
Required parameters: none
Optional parameters: charset
MIME media type name: application MIME subtype name: mediaservercontrol+xml Required parameters: none Optional parameters: charset
charset This parameter has identical semantics to the charset
parameter of the "application/xml" media type, as specified in
XML Media Types [8].
charset This parameter has identical semantics to the charset parameter of the "application/xml" media type, as specified in XML Media Types [8].
Encoding considerations: See RFC 3023 [8]. Interoperability considerations: See RFC 2023 [8] and RFC 4722. Published specification: RFC 4722
Encoding considerations: See RFC 3023 [8]. Interoperability considerations: See RFC 2023 [8] and RFC 4722. Published specification: RFC 4722
Van Dyke, et al. Informational [Page 73] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 73] RFC 4722 MSCML November 2006
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
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
13. Security Considerations
13. Security Considerations
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 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.
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.
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.
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.
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.
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.
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
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
Van Dyke, et al. Informational [Page 74] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 74] RFC 4722 MSCML November 2006
multiple applications to utilize the resources of a single media server simultaneously without interfering with one another.
multiple applications to utilize the resources of a single media server simultaneously without interfering with one another.
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.
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.
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).
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).
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.
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.
As this is an XML markup, all the security considerations of RFC 3023 [8] apply.
As this is an XML markup, all the security considerations of RFC 3023 [8] apply.
14. References
14. References
14.1. Normative References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
Van Dyke, et al. Informational [Page 75] RFC 4722 MSCML November 2006
Van Dyke, et al. Informational [Page 75] RFC 4722 MSCML November 2006
[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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[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] "Network call signalling protocol for the delivery of time- critical services over cable television networks using cable modems", ITU-T J.162, March 2001.
[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., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[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., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.
[8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[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., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
14.2. Informative References
14.2. Informative References
[10] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
2006年2月の[10] ローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のための枠組み」RFC4353。
[11] Carter, J., Danielsen, P., Hunt, A., Ferrans, J., Lucas, B.,
Porter, B., Rehor, K., Tryphonas, S., McGlashan, S., and D.
Burnett, "Voice Extensible Markup Language (VoiceXML) Version
2.0", W3C REC REC-voicexml20-20040316, March 2004.
[11] カーター、J.、Danielsen、P.、狩り、A.、Ferrans、J.、ルーカス、B.、ポーター、B.、Rehor、K.、Tryphonas、S.、マックグラシャン、S.、およびD.バーネット、「拡張マークアップ言語(VoiceXML)バージョン2インチを声に出してください、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]のヨーロッパのTelecommunications Standards Institute、「デジタルセル情報通信システム(フェーズ2+)」。 普遍的な移動体通信システム(UMTS)。 IPマルチメディアサブシステム(IMS)。 2005年12月の「ステージ2(3GPP TS23.228バージョン7.2.0Release7)。」
[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.、ローズ、M.、およびL.Masinter、「IETFプロトコルの中の拡張マークアップ言語(XML)の使用のためのガイドライン」、BCP70、RFC3470(2003年1月)。
[15] Jacobs, I., Lie, H., Bos, B., and C. Lilley, "Cascading Style
Sheets, level 2 (CSS2) Specification", W3C REC REC-CSS2-
19980512, May 1998.
[15] ジェイコブズ、I.、Lie、H.、ボス、B.、およびC.リリー、「スタイルシートをどっと落させて、2(CSS2)仕様を平らにしてください」、W3C REC REC-CSS2 19980512、1998年5月。
Van Dyke, et al. Informational [Page 76] RFC 4722 MSCML November 2006
ヴァンダイク、他 [76ページ]情報のRFC4722MSCML2006年11月
[16] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[16] ローゼンバーグ、J.、Schulzrinne、H.、およびO.レヴィン、「コンファレンス状態へのセッション開始プロトコル(一口)イベントパッケージ」、RFC4575(2006年8月)。
[17] Cable Television Laboratories, Inc., "Audio Server Protocol",
January 2005.
[17] ケーブルテレビ研究所Inc.、「オーディオサーバプロトコル」、2005年1月。
[18] "Procedures for document facsimile transmission in the general
switched telephone network", Recommendation T.30, April 1999.
[18] 「一般的な切り換えられた電話網におけるドキュメントファクシミリ伝送のための手順」、Recommendation T.30、1999年4月。
[19] "Procedures for real-time Group 3 facsimile communication over
IP networks", Recommendation T.38, March 2002.
[19] 「IPネットワークの上のリアルタイムのGroup3ファクシミリ通信のための手順」、Recommendation T.38、2002年3月。
[20] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH
Extension", RFC 4467, May 2006.
[20] クリスピン、M.、「インターネットはアクセス・プロトコル(IMAP)を通信させます--URLAUTH拡張子」、RFC4467、5月2006日
[21] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV",
RFC 2518, February 1999.
[21]Goland、Y.、ホワイトヘッド、E.、Faizi、A.、カーター、S.、およびD.ジェンセン、「分配されたオーサリングのためのHTTP拡大--、WEBDAV、」、RFC2518(1999年2月)
[22] Institute of Electrical and Electronics Engineers, "Information
Technology - Portable Operating System Interface (POSIX) - Part
1: Base Definitions, Chapter 9", IEEE Standard 1003.1, June
2001.
[22] 米国電気電子技術者学会、「情報技術--携帯用のオペレーティングシステムインタフェース(POSIX)--第1部:、」 IEEE規格1003.1、2001年6月を定義、章の9インチ基礎づけてください。
[23] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[23] バーガー、E.、およびM.は、「主要なプレス刺激(KPML)のためのセッション開始プロトコル(一口)イベントパッケージ」とドリーに載せて移動させます、RFC4730、2006年11月。
[24] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[24]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[25] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The
Message Session Relay Protocol", Work in Progress, June 2006.
[25] キャンベル、B.(エド)、マーイ、R.(エド)、およびC.ジョニングス(エド)、「メッセージセッションリレープロトコル」は進行中(2006年6月)で働いています。
URIs
URI
[26] <http://www.ietf.org/html.charters/sip-charter.html>
[26] <一口http://www.ietf.org/html.charters/charter.html>。
[27] <http://www.ietf.org/html.charters/sipping-charter.html>
[27] <ちびちび飲みhttp://www.ietf.org/html.charters/charter.html>。
[28] <http://www.ietf.org/html.charters/mmusic.html>
[28] <http://www.ietf.org/html.charters/mmusic.html>。
[29] <http://www.ietf.org/html.charters/xcon-charter.html>
[29] <http://www.ietf.org/html.charters/xcon-charter.html>。
[30] <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>
[30] <html http://www.3gpp.org/ftp/仕様/インフォメーション/23228.htm>。
[31] <mailto:eburger@cantata.com>
[31] <mailto: eburger@cantata.com 、gt。
Van Dyke, et al. Informational [Page 77] RFC 4722 MSCML November 2006
ヴァンダイク、他 [77ページ]情報のRFC4722MSCML2006年11月
Appendix A. Regex Grammar Syntax
付録A.Regex文法構文
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で使用される正規表現構文はDigit REGular EXpression(DRegex)と呼ばれたPOSIX Extended Regular Expressions(ERE)[22]の電話指向の部分集合です。 この構文は最初に、KPML[23]で説明されました。
DRegex includes ordinary characters, special characters, bracket expressions, and interval expressions. These entities are defined in the list below.
DRegexは普通のキャラクタ、特殊文字、括弧式、および間隔表現を含んでいます。 これらの実体は以下のリストで定義されます。
character 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はmがmか、より多くの反復に合っている前のパターンの複写にどんな0-9mのケタマッチm合っています。前のパターン、nは少なくともmとどんなregex表現でも、'L'の存在が「長い」ケタ検出モードをメディアサーバを可能にさせる前のパターンLのほとんどのn複写のときに前のパターンのほとんどのn(ゼロを含んでいる)複写のときにm、nに合っています。 「長い」ケタの定義に関してセクション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 |
| *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 |
+--------------+--------------------------------------------+
+--------------+--------------------------------------------+ | 例| 記述| +--------------+--------------------------------------------+ | 1 | ケタ1を合わせます。| | [179] | マッチ1、7、または9| | [2-9] | マッチ2、3、4、5、6、7、8、9| | [02-46-9A D]| マッチ0、2、3、4、6、7、8、9、A、B C、D| | x| マッチ0、1、2、3、4、5、6、7、8、9| | *6[179#] | マッチ*61、*67、*69、または*6#| | x10| 10ケタ(0-9)| | 011x7、15| 7〜15ケタに従って、011は続きました。| | L*| 長い間、主演してください。| +--------------+--------------------------------------------+
Table 7: DRegex Examples
テーブル7: DRegexの例
Van Dyke, et al. Informational [Page 78] RFC 4722 MSCML November 2006
ヴァンダイク、他 [78ページ]情報のRFC4722MSCML2006年11月
Appendix B. Contributors
付録B.貢献者
Jeff Van Dyke and Andy Spitzer did the concept, development, documentation, and execution for MSCML at SnowShore Networks, Inc., which is now part of Cantata Technology, Inc. Andy Spitzer's original work at The Telephone Connection, Inc., influenced the IVR implementation. Mary Ann Leekley implemented the personalized mix feature and several other enhancements.
ジェフ・ヴァンダイクとアンディ・スピッツァーは概念をしました、開発、ドキュメンテーション、そして、現在Telephone Connection Inc.におけるCantata Technology Inc.アンディ・スピッツァーのオリジナルの仕事の一部であるSnowShore Networks Inc.におけるMSCMLのための実行がIVR実現に影響を及ぼしました。 メアリアンLeekleyは個人化されたミックス機能と他のいくつかの増進を実行しました。
Cliff Schornak of Commetrex and Jeff Van Dyke developed the facsimile service.
Commetrexとジェフ・ヴァンダイクのクリフSchornakはファクシミリサービスを開発しました。
Jai Cauvet, Rolando Herrero, Srinivas Motamarri, and Ashish Patel contributed greatly by testing MSCML.
ジェイCauvet、ロランドHerrero、Srinivas Motamarri、およびAshishパテルは、MSCMLをテストすることによって、大いに貢献しました。
Appendix C. Acknowledgements
付録C.承認
The following individuals provided valuable assistance in the direction, development, or debugging of MSCML:
以下の個人はMSCMLの指示、開発、またはデバッグにおける貴重な援助を提供しました:
o Brian Badger and Phil Crable from Verizon Business o Stephane Bastien from BroadSoft o Peter Danielsen of Lucent Technologies o Kevin Flemming, formerly of SnowShore Networks, Inc. o Wesley Hicks and Ravindra Kabre, formerly from Sonus Networks o Jon Hinckley from SkyWave/Sestro o Terence Lobo, formerly of SnowShore Networks, Inc. o Kunal Nawale, formerly of SnowShore Networks, Inc. o Edwina Nowicki, formerly of SnowShore Networks, Inc. o Diana Rawlins and Sharadha Vijay, formerly of WorldCom o Gaurav Srivastva and Subhash Verma from BayPackets o Kevin Summers from Sonus Networks o Tim Wong from at&t
o ルーセントテクノロジーズoのケビン・フレミングのBroadSoft oピーターDanielsenからのベライゾンBusiness oステファーヌBastienからの以前ブライアンBadgerとフィルCrable、SnowShore Networks Inc.oのウエスリー・ヒックスとラビンドラKabreについて以前、SkyWave/Sestro oテレンスLoboからのSonus Networks oジョン・ヒンクリーから以前、SnowShore Networks Inc; 以前o Kunal Nawale、SnowShore Networks Inc.oエドウィナNowickiについて以前、SnowShore Networks Inc.oダイアナ・ローリンズとSharadhaビジェイについて以前、BayPackets○ケビン・サマーズからのSonus Networks oティムWongからのワールドコムoのGaurav SrivastvaとSubhash Verma、t
The authors would like to thank Cullen Jennings and Dan Wing from Cisco Systems for their helpful review comments.
作者は彼らの役立っているレビューコメントについてシスコシステムズからCullenジョニングスとダンWingに感謝したがっています。
The authors would also like to thank Scotty Farber for applying her technical writing expertise to the documentation of MSCML.
また、作者は、彼女のテクニカル・ライティング専門的技術をMSCMLのドキュメンテーションに適用して頂いて、スコティー・ファーバーに感謝したがっています。
Van Dyke, et al. Informational [Page 79] RFC 4722 MSCML November 2006
ヴァンダイク、他 [79ページ]情報のRFC4722MSCML2006年11月
Authors' Addresses
作者のアドレス
Jeff Van Dyke Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
ジェフヴァンダイクカンタータ技術Inc.18Keewaydin礼拝堂ニューハンプシャー03079博士(米国)
EMail: jvandyke@cantata.com
メール: jvandyke@cantata.com
Eric Burger (editor) Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
エリックバーガー(エディタ)カンタータ技術Inc.18Keewaydin礼拝堂ニューハンプシャー03079博士(米国)
EMail: eburger@cantata.com
メール: eburger@cantata.com
Andy Spitzer Pingtel Corporation 400 West Cummings Park Woburn, MA 01801 USA
西カミングズ・ParkアンディスピッツァーPingtel社400のMA01801ウォバーン(米国)
EMail: woof@pingtel.com
メール: woof@pingtel.com
Van Dyke, et al. Informational [Page 80] RFC 4722 MSCML November 2006
ヴァンダイク、他 [80ページ]情報のRFC4722MSCML2006年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
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.
このドキュメントはBCP78と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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Van Dyke, et al. Informational [Page 81]
ヴァンダイク、他 情報[81ページ]
一覧
スポンサーリンク
