[要約] RFC 5552は、VoiceXMLメディアサービスへのSIPインターフェースに関する仕様です。このRFCの目的は、SIPを使用してVoiceXMLメディアサービスとの通信を可能にすることです。
Network Working Group D. Burke
Request for Comments: 5552 Google
Category: Standards Track M. Scott
Genesys
May 2009
SIP Interface to VoiceXML Media Services
VoiceXMLメディアサービスへのSIPインターフェイス
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document describes a SIP interface to VoiceXML media services. Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.
このドキュメントでは、SIPインターフェイスがVoiceXMLメディアサービスへのインターフェイスについて説明しています。一般的に、メディアサーバーを制御するアプリケーションサーバーは、純粋なVoiceXML処理機能にこのプロトコルを使用します。このプロトコルは、完全なメディアックトルプロトコルおよびパッケージメカニズムの補助です。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Use Cases ..................................................3
1.1.1. IVR Services with Application Servers ...............3
1.1.2. PSTN IVR Service Node ...............................4
1.1.3. 3GPP IMS Media Resource Function (MRF) ..............5
1.1.4. CCXML <-> VoiceXML Interaction ......................6
1.1.5. Other Use Cases .....................................6
1.2. Terminology ................................................7
2. VoiceXML Session Establishment and Termination ..................7
2.1. Service Identification .....................................7
2.2. Initiating a VoiceXML Session .............................10
2.3. Preparing a VoiceXML Session ..............................11
2.4. Session Variable Mappings .................................12
2.5. Terminating a VoiceXML Session ............................15
2.6. Examples ..................................................16
2.6.1. Basic Session Establishment ........................16
2.6.2. VoiceXML Session Preparation .......................17
2.6.3. MRCP Establishment .................................18
3. Media Support ..................................................19
3.1. Offer/Answer ..............................................19
3.2. Early Media ...............................................19
3.3. Modifying the Media Session ...............................21
3.4. Audio and Video Codecs ....................................21
3.5. DTMF ......................................................22
4. Returning Data to the Application Server .......................22
4.1. HTTP Mechanism ............................................22
4.2. SIP Mechanism .............................................23
5. Outbound Calling ...............................................25
6. Call Transfer ..................................................25
6.1. Blind .....................................................26
6.2. Bridge ....................................................27
6.3. Consultation ..............................................29
7. Contributors ...................................................31
8. Acknowledgements ...............................................31
9. Security Considerations ........................................31
10. IANA Considerations ...........................................32
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................35
Appendix A. Notes on Normative References ........................36
VoiceXML [VXML20], [VXML21] is a World Wide Web Consortium (W3C) standard for creating audio and video dialogs that feature synthesized speech, digitized audio, recognition of spoken and dual tone multi-frequency (DTMF) key input, recording of audio and video, telephony, and mixed-initiative conversations. VoiceXML allows Web-based development and content delivery paradigms to be used with interactive video and voice response applications.
VoiceXML [VXML20]、[VXML21]は、合成された音声、デジタル化されたオーディオ、音声トーンの認識、DTMFの認識（DTMF）キー入力、オーディオの記録を特徴とするオーディオおよびビデオダイアログを作成するためのワールドワイドウェブコンソーシアム（W3C）標準です。ビデオ、テレフォニー、および混合開始会話。VoiceXMLを使用すると、Webベースの開発とコンテンツ配信パラダイムをインタラクティブなビデオおよび音声応答アプリケーションで使用できます。
This document describes a SIP [RFC3261] interface to VoiceXML media services. Commonly, Application Servers controlling media servers use this protocol for pure VoiceXML processing capabilities. SIP is responsible for initiating a media session to the VoiceXML media server and simultaneously triggering the execution of a specified VoiceXML application. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.
このドキュメントでは、SIP [RFC3261] Interface to VoiceXMLメディアサービスについて説明しています。一般的に、メディアサーバーを制御するアプリケーションサーバーは、純粋なVoiceXML処理機能にこのプロトコルを使用します。SIPは、Media SessionをVoiceXML Media Serverに開始し、同時に指定されたVoiceXMLアプリケーションの実行をトリガーする責任があります。このプロトコルは、完全なメディアックトルプロトコルおよびパッケージメカニズムの補助です。
The interface described here leverages a mechanism for identifying dialog media services first described in [RFC4240]. The interface has been updated and extended to support the W3C Recommendation for VoiceXML 2.0 [VXML20] and VoiceXML 2.1 [VXML21]. A set of commonly implemented functions and extensions have been specified including VoiceXML dialog preparation, outbound calling, video media support, and transfers. VoiceXML session variable mappings have been defined for SIP with an extensible mechanism for passing application-specific values into the VoiceXML application. Mechanisms for returning data to the Application Server have also been added.
ここで説明するインターフェイスは、[RFC4240]で最初に説明されたダイアログメディアサービスを識別するためのメカニズムを活用しています。インターフェイスは更新および拡張され、VoiceXML 2.0 [VXML20]およびVoiceXML 2.1 [VXML21]のW3C推奨がサポートされています。VoiceXMLダイアログの準備、アウトバウンド通話、ビデオメディアサポート、転送など、一般的に実装された関数と拡張機能のセットが指定されています。VoiceXMLセッション変数マッピングは、アプリケーション固有の値をVoiceXMLアプリケーションに渡すための拡張可能なメカニズムを備えたSIP用に定義されています。アプリケーションサーバーにデータを返すメカニズムも追加されています。
The VoiceXML media service user in this document is generically referred to as an Application Server. In practice, it is intended that the interface defined by this document be applicable across a wide range of use cases. Several intended use cases are described below.
このドキュメントのVoiceXMLメディアサービスユーザーは、一般的にアプリケーションサーバーと呼ばれます。実際には、このドキュメントによって定義されたインターフェイスは、幅広いユースケースに適用できることを意図しています。いくつかの意図したユースケースを以下に説明します。
SIP Application Servers provide services to users of the network. Typically, there may be several Application Servers in the same network, each specialized in providing a particular service. Throughout this specification and without loss of generality, we posit the presence of an Application Server specialized in providing Interactive Voice Response (IVR) services. A typical configuration for this use case is illustrated below.
SIPアプリケーションサーバーは、ネットワークのユーザーにサービスを提供します。通常、同じネットワークにいくつかのアプリケーションサーバーがあり、それぞれが特定のサービスを提供することに特化しています。この仕様を通して、一般性を失うことなく、インタラクティブな音声応答（IVR）サービスの提供に特化したアプリケーションサーバーの存在を仮定します。このユースケースの典型的な構成を以下に示します。
+--------------+
| |
| Application |\
| Server | \
| | \ HTTP
SIP +--------------+ \
/ \ \
+-------------+ / SIP \ +--------------+
| |/ \| |
| SIP | | VoiceXML |
| User Agent | RTP/SRTP | Media Server |
| |=====================| |
+-------------+ +--------------+
Assuming the Application Server also supports HTTP, the VoiceXML application may be hosted on it and served up via HTTP [RFC2616]. Note, however, that the Web model allows the VoiceXML application to be hosted on a separate (HTTP) Application Server from the (SIP) Application Server that interacts with the VoiceXML Media Server via this specification. It is also possible for a static VoiceXML application to be stored locally on the VoiceXML Media Server, leveraging the VoiceXML 2.1 [VXML21] <data> mechanism to interact with a Web/Application Server when dynamic behavior is required. The viability of static VoiceXML applications is further enhanced by the mechanisms defined in Section 2.4, through which the Application Server can make session-specific information available within the VoiceXML session context.
アプリケーションサーバーもHTTPをサポートしていると仮定すると、VoiceXMLアプリケーションをホストし、HTTP [RFC2616]を介して提供することができます。ただし、Webモデルでは、この仕様を介してVoiceXML Media Serverと対話する（SIP）アプリケーションサーバーから、VoiceXMLアプリケーションを別の（HTTP）アプリケーションサーバーでホストできることに注意してください。また、静的なVoiceXMLアプリケーションをVoiceXML Media Serverにローカルに保存し、VoiceXML 2.1 [VXML21] <Data>動的動作が必要な場合にWeb/アプリケーションサーバーと対話するメカニズムを活用することも可能です。静的VoiceXMLアプリケーションの実行可能性は、セクション2.4で定義されたメカニズムによってさらに強化され、アプリケーションサーバーはVoiceXMLセッションコンテキスト内でセッション固有の情報を利用可能にすることができます。
The approach described in this document is sometimes termed the "delegation model" -- the Application Server is essentially delegating programmatic control of the human-machine interactions to one or more VoiceXML documents running on the VoiceXML Media Server. During the human-machine interactions, the Application Server remains in the signaling path and can respond to results returned from the VoiceXML Media Server or other external network events.
このドキュメントで説明されているアプローチは、「委任モデル」と呼ばれることがあります。アプリケーションサーバーは、Human-Machine相互作用のプログラム制御を、VoiceXMLメディアサーバーで実行している1つ以上のVoiceXMLドキュメントに基本的に委任しています。ヒューマンマシンの相互作用中、アプリケーションサーバーは信号パスに留まり、VoiceXMLメディアサーバーまたは他の外部ネットワークイベントから返された結果に応答できます。
While this document is intended to enable enhanced use of VoiceXML as a component of larger systems and services, it is intended that devices that are completely unaware of this specification remain capable of invoking VoiceXML services offered by a VoiceXML Media Server compliant with this document. A typical configuration for this use case is as follows:
このドキュメントは、より大きなシステムとサービスのコンポーネントとしてVoiceXMLの使用を強化できるようにすることを目的としていますが、この仕様に完全に気付いていないデバイスは、このドキュメントに準拠したVoiceXMLメディアサーバーが提供するVoiceXMLサービスを呼び出すことができることを意図しています。このユースケースの典型的な構成は次のとおりです。
+-------------+ SIP +--------------+
| |---------------------| |
| IP/PSTN | | VoiceXML |
| Gateway | RTP/SRTP | Media Server |
| |=====================| |
+-------------+ +--------------+
Note also that beyond the invocation and termination of a VoiceXML dialog, the semantics defined for call transfers using REFER are intended to be compatible with standard, existing IP/PSTN (Public Switched Telephone Network) gateways.
また、VoiceXMLダイアログの呼び出しと終了を超えて、紹介を使用したコール転送用に定義されたセマンティクスは、標準の既存のIP/PSTN（パブリックスイッチ付き電話ネットワーク）ゲートウェイと互換性があることを目的としていることに注意してください。
The 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS) [TS23002] defines a Media Resource Function (MRF) used to offer media processing services such as conferencing, transcoding, and prompt/collect. The capabilities offered by VoiceXML are ideal for offering richer media processing services in the context of the MRF. In this architecture, the interface defined here corresponds to the "Mr" interface to the MRFC (MRF Controller); the implementation of this interface might use separated MRFC and MRFP (MRF Processor) elements (as per the IMS architecture), or might be an integrated MRF (as is common practice).
第3世代パートナーシッププロジェクト（3GPP）IPマルチメディアサブシステム（IMS）[TS23002]は、会議、トランスコード、プロンプト/収集などのメディア処理サービスを提供するために使用されるメディアリソース機能（MRF）を定義しています。VoiceXMLが提供する機能は、MRFのコンテキストでより豊富なメディア処理サービスを提供するのに最適です。このアーキテクチャでは、ここで定義されているインターフェイスは、MRFC（MRFコントローラー）への「MR」インターフェイスに対応しています。このインターフェイスの実装では、分離されたMRFCおよびMRFP（MRFプロセッサ）要素（IMSアーキテクチャによる）を使用するか、統合されたMRF（一般的な慣行と同様）である可能性があります。
+----------+
| App |
| Server |
+----------+
|
| SIP (ISC)
|
+----------+ SIP (Mr) +--------------+
| S-CSCF |---------------| VoiceXML |
| | | MRF |
+----------+ +--------------+
||
|| RTP/SRTP (Mb)
||
The above diagram is highly simplified and shows a subset of nodes typically involved in MRF interactions. It should be noted that while the MRF will primarily be used by the Application Server via the Serving Call Session Control Function (S-CSCF), it is also possible for calls to be routed directly to the MRF without the involvement of an Application Server.
上記の図は非常に簡素化されており、MRF相互作用に通常関与するノードのサブセットを示しています。MRFは主に配信コールセッションコントロール機能（S-CSCF）を介してアプリケーションサーバーによって使用されるが、アプリケーションサーバーの関与なしに呼び出しをMRFに直接ルーティングすることも可能であることに注意する必要があります。
Although the above is described in terms of the 3GPP IMS architecture, it is intended that it is also applicable to 3GPP2, Next Generation Network (NGN), and PacketCable architectures that are converging with 3GPP IMS standards.
上記は3GPP IMSアーキテクチャの観点から説明されていますが、3GPP2、次世代ネットワーク（NGN）、および3GPP IMS標準と収束するパケット可能なアーキテクチャにも適用できることを意図しています。
Call Control eXtensible Markup Language (CCXML) 1.0 [CCXML10] applications provide services mainly through controlling the interaction between Connections, Conferences, and Dialogs. Although CCXML is capable of supporting arbitrary dialog environments, VoiceXML is commonly used as a dialog environment in conjunction with CCXML applications; CCXML is specifically designed to effectively support the use of VoiceXML. CCXML 1.0 defines language elements that allow for Dialogs to be prepared, started, and terminated; it further allows for data to be returned by the dialog environment, for call transfers to be requested (by the dialog) and responded to by the CCXML application, and for arbitrary eventing between the CCXML application and running dialog application.
コントロール拡張可能なマークアップ言語（CCXML）1.0 [CCXML10]アプリケーションは、主に接続、会議、およびダイアログ間の相互作用を制御することによりサービスを提供します。CCXMLは任意のダイアログ環境をサポートすることができますが、VoiceXMLは一般にCCXMLアプリケーションと併せてダイアログ環境として使用されます。CCXMLは、VoiceXMLの使用を効果的にサポートするように特別に設計されています。CCXML 1.0は、ダイアログを準備、開始、終了できる言語要素を定義します。さらに、ダイアログ環境によってデータを返すこと、（ダイアログによって）要求され、CCXMLアプリケーションによって応答され、CCXMLアプリケーションと[ダイアログアプリケーションの実行間の任意のイベント）がデータを返すことができます。
The interface described in this document can be used by CCXML 1.0 implementations to control VoiceXML Media Servers. Note, however, that some CCXML language features require eventing facilities between CCXML and VoiceXML sessions that go beyond what is defined in this specification. For example, VoiceXML-controlled call transfers and mid-dialog, application-defined events cannot be fully realized using this specification alone. A SIP event package [RFC3265] MAY be used in addition to this specification to provide extended eventing.
このドキュメントで説明されているインターフェイスは、CCXML 1.0の実装でVoiceXMLメディアサーバーを制御するために使用できます。ただし、一部のCCXML言語機能には、この仕様で定義されているものを超えるCCXMLセッションとVoiceXMLセッションの間のイベント機能が必要であることに注意してください。たとえば、VoiceXML制御のコール転送とミッドダイアログのアプリケーション定義イベントは、この仕様のみを使用して完全に実現することはできません。SIPイベントパッケージ[RFC3265]を使用して、この仕様に加えて拡張イベントを提供することができます。
In addition to the use cases described in some detail above, there are a number of other intended use cases that are not described in detail, such as:
上記のいくつかの詳細で説明されているユースケースに加えて、以下など、詳細に説明されていない他の多くの使用ケースがあります。
1. Use of a VoiceXML Media Server as an adjunct to an IP-based Private Branch Exchange / Automatic Call Distributor (PBX/ACD), possibly to provide voicemail/messaging, automated attendant, or other capabilities.
1. IPベースのプライベートブランチエクスチェンジ/自動コールディストリビューター（PBX/ACD）の補助としてVoiceXMLメディアサーバーを使用して、おそらくボイスメール/メッセージング、自動アテンダント、またはその他の機能を提供します。
2. Invocation and control of a VoiceXML session that provides the voice modality component in a multimodal system.
2. マルチモーダルシステムで音声モダリティコンポーネントを提供するVoiceXMLセッションの呼び出しと制御。
Application Server: A SIP Application Server hosts and executes services, in particular by terminating SIP sessions on a media server. The Application Server MAY also act as an HTTP server [RFC2616] in interactions with media servers.
アプリケーションサーバー：特にメディアサーバーでのSIPセッションを終了することにより、SIPアプリケーションサーバーがサービスをホストおよび実行します。アプリケーションサーバーは、メディアサーバーとの対話において、HTTPサーバー[RFC2616]として機能する場合があります。
VoiceXML Media Server: A VoiceXML interpreter including a SIP-based interpreter context and the requisite media processing capabilities to support VoiceXML functionality.
VoiceXML Media Server：SIPベースのインタープリターコンテキストと、VoiceXML機能をサポートするための必要なメディア処理機能を含むVoiceXMLインタープリター。
VoiceXML Session: A VoiceXML Session is a multimedia session comprising of at least a SIP User Agent, a VoiceXML Media Server, the data streams between them, and an executing VoiceXML application.
VoiceXMLセッション：VoiceXMLセッションは、少なくともSIPユーザーエージェント、VoiceXMLメディアサーバー、それらの間のデータストリーム、およびvoiceXMLアプリケーションの実行で構成されるマルチメディアセッションです。
VoiceXML Dialog: Equivalent to VoiceXML Session.
VoiceXMLダイアログ：VoiceXMLセッションに相当します。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This section describes how to establish a VoiceXML Session, with or without preparation, and how to terminate a session. This section also addresses how session information is made available to VoiceXML applications.
このセクションでは、準備の有無にかかわらず、VoiceXMLセッションを確立する方法、およびセッションを終了する方法について説明します。また、このセクションでは、voiceXMLアプリケーションでセッション情報がどのように利用可能になるかについても説明します。
The SIP Request-URI is used to identify the VoiceXML media service. The user part of the SIP Request-URI is fixed to "dialog". This is done to ensure compatibility with [RFC4240], since this document extends the dialog interface defined in that specification and because this convention from [RFC4240] is widely adopted by existing media servers.
SIP Request-URIは、VoiceXMLメディアサービスを識別するために使用されます。SIP Request-URIのユーザー部分は、「ダイアログ」に固定されています。これは、[RFC4240]との互換性を確保するために行われます。このドキュメントは、その仕様で定義されたダイアログインターフェイスを拡張し、[RFC4240]からのこの規則は既存のメディアサーバーで広く採用されているためです。
Standardizing the SIP Request-URI including the user part also improves interoperability between Application Servers and media servers, and reduces the provisioning overhead that would be required if use of a media server by an Application Server required an individually provisioned URI. In this respect, this document (and [RFC4240]) do not add semantics to the user part, but rather standardize the way that targets on media servers are provisioned. Further, since Application Servers -- and not human beings -- are generally the clients of media servers, issues such as interpretation and internationalization do not apply.
ユーザーパーツを含むSIPリクエストURIを標準化すると、アプリケーションサーバーとメディアサーバー間の相互運用性も向上し、アプリケーションサーバーによるメディアサーバーの使用が個別にプロビジョニングされたURIを必要とする場合に必要なプロビジョニングオーバーヘッドを削減します。この点で、このドキュメント（および[RFC4240]）はユーザーパーツにセマンティクスを追加するのではなく、メディアサーバーのターゲットがプロビジョニングされる方法を標準化します。さらに、アプリケーションサーバーは人間ではなく、一般的にメディアサーバーのクライアントであるため、解釈や国際化などの問題は適用されません。
Exposing a VoiceXML media service with a well-known address may enhance the possibility of exploitation: the VoiceXML Media Server is RECOMMENDED to use standard SIP mechanisms to authenticate endpoints as discussed in Section 9.
voiceXMLメディアサービスをよく知られているアドレスで公開すると、搾取の可能性が高まる場合があります。VoiceXMLメディアサーバーは、セクション9で説明したように、標準のSIPメカニズムを使用してエンドポイントを認証することをお勧めします。
The initial VoiceXML document is specified with the "voicexml" parameter. In addition, parameters are defined that control how the VoiceXML Media Server fetches the specified VoiceXML document. The list of parameters defined by this specification is as follows (note the parameter names are case-insensitive):
最初のVoiceXMLドキュメントは、「VoiceXML」パラメーターで指定されています。さらに、VoiceXML Media Serverが指定されたVoiceXMLドキュメントを取得する方法を制御するパラメーターが定義されています。この仕様で定義されたパラメーターのリストは次のとおりです（パラメーター名はケース非感受性です）。
voicexml: URI of the initial VoiceXML document to fetch. This will typically contain an HTTP URI, but may use other URI schemes, for example, to refer to local, static VoiceXML documents. If the "voicexml" parameter is omitted, the VoiceXML Media Server may select the initial VoiceXML document by other means, such as by applying a default, or may reject the request.
VoiceXML：FIOLTXMLドキュメントのURIを取得します。これには通常、HTTP URIが含まれますが、他のURIスキームを使用して、たとえばローカルの静的なVoiceXMLドキュメントを参照する場合があります。「VoiceXML」パラメーターが省略されている場合、VoiceXMLメディアサーバーは、デフォルトを適用して、リクエストを拒否するなど、他の手段で初期VoiceXMLドキュメントを選択できます。
maxage: Used to set the max-age value of the Cache-Control header in conjunction with VoiceXML documents fetched using HTTP, as per [RFC2616]. If omitted, the VoiceXML Media Server will use a default value.
MAXAGE：[RFC2616]に従って、HTTPを使用してフェッチされたVoiceXMLドキュメントと組み合わせて、キャッシュコントロールヘッダーの最大値を設定するために使用されます。省略した場合、VoiceXMLメディアサーバーはデフォルト値を使用します。
maxstale: Used to set the max-stale value of the Cache-Control header in conjunction with VoiceXML documents fetched using HTTP, as per [RFC2616]. If omitted, the VoiceXML Media Server will use a default value.
MaxStale：[RFC2616]に従って、HTTPを使用してフェッチされたVoiceXMLドキュメントと組み合わせて、キャッシュコントロールヘッダーの最大値を設定するために使用されます。省略した場合、VoiceXMLメディアサーバーはデフォルト値を使用します。
method: Used to set the HTTP method applied in the fetch of the initial VoiceXML document. Allowed values are "get" or "post" (case-insensitive). Default is "get".
方法：初期voiceXMLドキュメントのフェッチに適用されたHTTPメソッドを設定するために使用されます。許可された値は「get」または「post」（ケース非感受性）です。デフォルトは「get」です。
postbody: Used to set the application/x-www-form-urlencoded encoded [HTML4] HTTP body for "post" requests (or is otherwise ignored).
PostBody：「POST」リクエストのためのアプリケーション/X-WWW-FORM-URLENCODED ENCODED [HTML4] HTTPボディを設定するために使用されます（または無視されます）。
ccxml: Used to specify a "JSON value" [RFC4627] that is mapped to the session.connection.ccxml VoiceXML session variable -- see Section 2.4.
CCXML：session.connection.ccxml voicexmlセッション変数にマッピングされる「JSON値」[RFC4627]を指定するために使用されます。セクション2.4を参照してください。
aai: Used to specify a "JSON value" [RFC4627] that is mapped to the session.connection.aai VoiceXML session variable -- see Section 2.4.
AAI：session.connection.aai voicexmlセッション変数にマッピングされる「JSON値」[RFC4627]を指定するために使用されます - セクション2.4を参照してください。
Other application-specific parameters may be added to the Request-URI and are exposed in VoiceXML session variables (see Section 2.4).
他のアプリケーション固有のパラメーターがリクエスト-RIに追加され、VoiceXMLセッション変数で公開されます（セクション2.4を参照）。
Formally, the Request-URI for the VoiceXML media service has a fixed user part "dialog". Seven URI parameters are defined (see the definition of uri-parameter in Section 25.1 of [RFC3261]).
正式には、VoiceXMLメディアサービスのRequest-URIには、固定されたユーザーパーツ「ダイアログ」があります。7つのURIパラメーターが定義されています（[RFC3261]のセクション25.1のURIパラメーターの定義を参照）。
dialog-param = "voicexml=" vxml-url ; vxml-url follows the URI
; syntax defined in [RFC3986]
maxage-param = "maxage=" 1*DIGIT
maxstale-param = "maxstale=" 1*DIGIT
method-param = "method=" ("get" / "post")
postbody-param = "postbody=" token
ccxml-param = "ccxml=" json-value
aai-param = "aai=" json-value
json-value = false /
null /
true /
object /
array /
number /
string ; defined in [RFC4627]
Parameters of the Request-URI in subsequent re-INVITEs are ignored. One consequence of this is that the VoiceXML Media Server cannot be instructed by the Application Server to change the executing VoiceXML Application after a VoiceXML Session has been started.
後続の再インバイトのリクエスト-URIのパラメーターは無視されます。これの1つの結果は、VoiceXMLサーバーがVoiceXMLセッションが開始された後に実行されるVoiceXMLアプリケーションを変更するようにvoiceXMLメディアサーバーを指示できないことです。
Special characters contained in the dialog-param, postbody-param, ccxml-param, and aai-param values must be URL-encoded ("escaped") as required by the SIP URI syntax, for example, '?' (%3f), '=' (%3d), and ';' (%3b). The VoiceXML Media Server MUST therefore unescape these parameter values before making use of them or exposing them to running VoiceXML applications. It is important that the VoiceXML Media Server only unescape the parameter values once since the desired VoiceXML URI value could itself be URL encoded, for example.
Dialog-Param、Postbody-Param、CCXML-Param、およびAAI-Paramの値に含まれる特殊文字は、SIP URI構文の要求など、「？」（％3f）、 '='（％3d）、 ';'（％3b）。したがって、VoiceXMLメディアサーバーは、これらのパラメーター値を使用する前に、これらのパラメーター値を使用したり、VoiceXMLアプリケーションを実行したりする必要があります。VoiceXML Media Serverは、希望するVoiceXML URI値自体がURLエンコードされる可能性があるため、パラメーター値を1回だけ除外することが重要です。
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the sips: scheme as discussed in Section 9.
一部のアプリケーションは機密情報を転送することを選択する可能性があるため、beoveXMLメディアサーバーは、セクション9で説明したSIPS：スキームをサポートする必要があります。
Informative note: With respect to the postbody-param value, since the application/x-www-form-urlencoded content itself escapes non-alphanumeric characters by inserting %HH replacements, the escaping rules above will result in the '%' characters being further escaped in addition to the '&' and '=' name/value separators.
有益なメモ：Postbody-Param値に関しては、アプリケーション/X-WWW-Form-UrlENCODEDコンテンツ自体が％HH代替を挿入することにより非アルファン次元の文字を逃れるため、上記の逃げるルールは「％」文字がさらに発生するでしょう。'＆'および '=' name/value Separatorsに加えて脱出しました。
As an example, the following SIP Request-URI identifies the use of VoiceXML media services, with 'http://appserver.example.com/promptcollect.vxml' as the initial VoiceXML document, to be fetched with max-age/max-stale values of 3600s/0s, respectively:
例として、次のSIPリクエスト-URIは、 'http://appserver.example.com/promptcollect.vxml'を最初のboicexmlドキュメントとしてbowexmlメディアサービスの使用を識別します。それぞれ3600S/0の古い値：
sip:dialog@mediaserver.example.com; \
voicexml=http://appserver.example.com/promptcollect.vxml; \
maxage=3600;maxstale=0
A VoiceXML Session is initiated via the Application Server using a SIP INVITE. Typically, the Application Server will be specialized in providing VoiceXML services. At a minimum, the Application Server may behave as a simple proxy by rewriting the Request-URI received from the User Agent to a Request-URI suitable for consumption by the VoiceXML Media Server (as specified in Section 2.1). For example, a User Agent might present a dialed number:
SIP Inviteを使用して、Application Serverを介してVoiceXMLセッションが開始されます。通常、アプリケーションサーバーはVoiceXMLサービスの提供に特化します。少なくとも、アプリケーションサーバーは、ユーザーエージェントから受信したリクエストURIを、VoiceXMLメディアサーバーによる消費に適したリクエスト-URIに書き換えることにより、単純なプロキシとして動作する場合があります（セクション2.1で指定されています）。たとえば、ユーザーエージェントはダイヤル番号を提示する場合があります。
tel:+1-201-555-0123
Tel：1-201-555-0123
that the Application Server maps to a directory assistance application on the VoiceXML Media Server with a Request-URI of:
アプリケーションサーバーは、次の要求-URIを使用してVoiceXML Media Serverのディレクトリ支援アプリケーションにマッピングします。
sip:dialog@ms1.example.com; \
voicexml=http://as1.example.com/da.vxml
Certain header values in the INVITE message to the VoiceXML Media Server are mapped into VoiceXML session variables and are specified in Section 2.4.
VoiceXMLメディアサーバーへの招待メッセージの特定のヘッダー値は、VoiceXMLセッション変数にマッピングされ、セクション2.4で指定されています。
On receipt of the INVITE, the VoiceXML Media Server issues a provisional response, 100 Trying, and commences the fetch of the initial VoiceXML document. The 200 OK response indicates that the VoiceXML document has been fetched and parsed correctly and is ready for execution. Application execution commences on receipt of the ACK (except if the dialog is being prepared as specified in Section 2.3). Note that the 100 Trying response will usually be sent on receipt of the INVITE in accordance with [RFC3261], since the VoiceXML Media Server cannot in general guarantee that the initial fetch will complete in less than 200 ms. However, certain implementations may be able to guarantee response times to the initial INVITE, and thus may not need to send a 100 Trying response.
招待状を受け取ると、VoiceXML Media Serverは、暫定的な応答を発行し、100を試してみて、最初のVoiceXMLドキュメントのフェッチを開始します。200 OK応答は、VoiceXMLドキュメントが正しくフェッチおよび解析され、実行の準備ができていることを示しています。アプリケーションの実行は、ACKの受領時に開始されます（セクション2.3で指定されているようにダイアログが準備されている場合を除く）。VoiceXMLメディアサーバーは一般的に最初のフェッチが200ミリ秒未満で完了することを保証することは一般的に保証できないため、100の試行試行応答は通常、[RFC3261]に従って招待状の受領時に送信されることに注意してください。ただし、特定の実装では、最初の招待への応答時間を保証できる場合があるため、100の試行応答を送信する必要がない場合があります。
As an optimization, prior to sending the 200 OK response, the VoiceXML Media Server MAY execute the application up to the point of the first VoiceXML waiting state or prompt flush.
最適化として、200 OK応答を送信する前に、VoiceXML Media Serverは、最初のVoiceXML待機状態またはプロンプトフラッシュのポイントまでアプリケーションを実行する場合があります。
A VoiceXML Media Server, like any SIP User Agent, may be unable to accept the INVITE request for a variety of reasons. For instance, a Session Description Protocol (SDP) offer contained in the INVITE might require the use of codecs that are not supported by the Media Server. In such cases, the Media Server should respond as defined by [RFC3261]. However, there are error conditions specific to VoiceXML, as follows:
SIPユーザーエージェントと同様に、VoiceXMLメディアサーバーは、さまざまな理由で招待リクエストを受け入れることができない場合があります。たとえば、招待に含まれるセッション説明プロトコル（SDP）のオファーには、メディアサーバーによってサポートされていないコーデックの使用が必要になる場合があります。そのような場合、メディアサーバーは[RFC3261]で定義されているように応答する必要があります。ただし、次のように、voicexmlに固有のエラー条件があります。
1. If the Request-URI does not conform to this specification, a 400 Bad Request MUST be returned (unless it is used to select other services not defined by this specification).
1. Request-URIがこの仕様に準拠していない場合、400の悪いリクエストを返す必要があります（この仕様で定義されていない他のサービスを選択するために使用されない限り）。
2. If a URI parameter in the Request-URI is repeated, then the request MUST be rejected with a 400 Bad Request response.
2. Request-URIのURIパラメーターが繰り返される場合、400の悪いリクエスト応答でリクエストを拒否する必要があります。
3. If the Request-URI does not include a "voicexml" parameter, and the VoiceXML Media Server does not elect to use a default page, the VoiceXML Media Server MUST return a final response of 400 Bad Request, and it SHOULD include a Warning header with a 3-digit code of 399 and a human-readable error message.
3. Request-URIに「VoiceXML」パラメーターが含まれておらず、VoiceXML Media Serverがデフォルトページを使用することを選択しない場合、VoiceXMLメディアサーバーは400の悪いリクエストの最終応答を返す必要があり、警告ヘッダーを含む必要があります。399の3桁のコードと人間の読み取り可能なエラーメッセージ。
4. If the VoiceXML document cannot be fetched or parsed, the VoiceXML Media Server MUST return a final response of 500 Server Internal Error and SHOULD include a Warning header with a 3-digit code of 399 and a human-readable error message.
4. VoiceXMLドキュメントをフェッチまたは解析できない場合、VoiceXMLメディアサーバーは500サーバー内部エラーの最終応答を返し、3桁のコード399と人間の可読エラーメッセージを持つ警告ヘッダーを含める必要があります。
Informative note: Certain applications may pass a significant amount of data to the VoiceXML dialog in the form of Request-URI parameters. This may cause the total size of the INVITE request to exceed the MTU of the underlying network. In such cases, applications/ implementations must take care either to use a transport appropriate to these larger messages (such as TCP) or to use alternative means of passing the required information to the VoiceXML dialog (such as supplying a unique session identifier in the initial VoiceXML URI and later using that identifier as a key to retrieve data from the HTTP server).
有益なメモ：特定のアプリケーションは、Request-URIパラメーターの形式で、かなりの量のデータをVoiceXMLダイアログに渡す場合があります。これにより、招待要求の合計サイズが基礎となるネットワークのMTUを超える可能性があります。そのような場合、アプリケーション/実装は、これらのより大きなメッセージ（TCPなど）に適したトランスポートを使用するか、必要な情報をVoiceXMLダイアログに渡す代替手段を使用するように注意する必要があります（最初のユニークなセッション識別子の提供などVoiceXML URI以降は、その識別子をHTTPサーバーからデータを取得するためのキーとして使用します）。
In certain scenarios, it is beneficial to prepare a VoiceXML Session for execution prior to running it. A previously prepared VoiceXML Session is expected to execute with minimal delay when instructed to do so.
特定のシナリオでは、実行する前に実行するためにvoiceXMLセッションを準備することが有益です。以前に準備されたbooveXMLセッションは、そうするように指示された場合、最小限の遅延で実行されると予想されます。
If a media-less SIP dialog is established with the initial INVITE to the VoiceXML Media Server, the VoiceXML application will not execute after receipt of the ACK. To run the VoiceXML application, the Application Server (AS) must issue a re-INVITE to establish a media session.
Medion-LessのSIPダイアログがvoiceXMLメディアサーバーへの最初の招待状で確立されている場合、ACKを受信した後、VoiceXMLアプリケーションは実行されません。VoiceXMLアプリケーションを実行するには、アプリケーションサーバー（AS）は、メディアセッションを確立するために再インベンタルを発行する必要があります。
A media-less SIP dialog can be established by sending an SDP containing no media lines in the initial INVITE. Alternatively, if no SDP is sent in the initial INVITE, the VoiceXML Media Server will include an offer in the 200 OK message, which can be responded to with an answer in the ACK with the media port(s) set to 0.
メディアのないSIPダイアログは、最初の招待状にメディアラインを含むSDPを送信することで確立できます。あるいは、最初の招待状にSDPが送信されない場合、VoiceXML Media Serverには200 OKメッセージにオファーが含まれます。これは、メディアポートが0に設定されたACKの回答で応答できます。
Once a VoiceXML application is running, a re-INVITE that disables the media streams (i.e., sets the ports to 0) will not otherwise affect the executing application (except that recognition actions initiated while the media streams are disabled will result in noinput timeouts).
VoiceXMLアプリケーションが実行されると、メディアストリームを無効にする（つまり、ポートを0に設定する）リンバイトは、それ以外の場合は実行アプリケーションに影響しません（メディアストリームが無効になっている間に開始された認識アクションがノーインプットタイムアウトになります）。
The standard VoiceXML session variables are assigned values according to:
標準のVoiceXMLセッション変数は、次の値に応じて割り当てられます。
session.connection.local.uri: Evaluates to the SIP URI specified in the To: header of the initial INVITE.
session.connection.local.uri：TOで指定されたSIP URIを評価します。最初の招待状のヘッダー。
session.connection.remote.uri: Evaluates to the SIP URI specified in the From: header of the initial INVITE.
session.connection.remote.uri：from：header of the hirts Inviteで指定されたSIP URIを評価します。
session.connection.redirect: This array is populated by information contained in the History-Info [RFC4244] header in the initial INVITE or is otherwise undefined. Each entry (hi-entry) in the History-Info header is mapped, in reverse order, into an element of the session.connection.redirect array. Properties of each element of the array are determined as follows:
session.Connection.Redirect：この配列には、最初の招待状のHistory-INFO [RFC4244]ヘッダーに含まれる情報が入力されています。History-infoヘッダーの各エントリ（hi-entry）は、逆の順序で、session.connection.redirect配列の要素にマッピングされます。配列の各要素のプロパティは、次のように決定されます。
* uri - Set to the hi-targeted-to-uri value of the History-Info entry
* uri-履歴infoエントリのHIターゲットから尿の価値に設定
* pi - Set to 'true' if hi-targeted-to-uri contains a "Privacy=history" parameter, or if the INVITE Privacy header includes 'history'; 'false' otherwise
* pi- hiターゲットを絞った尿素に「プライバシー=履歴」パラメーターが含まれている場合、または招待プライバシーヘッダーに「履歴」が含まれている場合、「true」に設定されています。それ以外の場合は「false」
* si - Set to the value of the "si" parameter if it exists, undefined otherwise
* si-存在する場合は「si」パラメーターの値に設定され、それ以外の場合は定義されていません
* reason - Set verbatim to the value of the "Reason" parameter of hi-targeted-to-uri
* 理由 - ターゲットから尿の「理由」パラメーターの値に逐語的に設定します
session.connection.protocol.name: Evaluates to "sip". Note that this is intended to reflect the use of SIP in general, and does not distinguish between whether the media server was accessed via SIP or SIPS procedures.
session.connection.protocol.name：「sip」と評価します。これは、一般的なSIPの使用を反映することを目的としており、SIPまたはSIP手順を介してメディアサーバーにアクセスされたかどうかを区別しないことに注意してください。
session.connection.protocol.version: Evaluates to "2.0".
session.connection.protocol.version：「2.0」と評価します。
session.connection.protocol.sip.headers: This is an associative array where each key in the array is the non-compact name of a SIP header in the initial INVITE converted to lowercase (note the case conversion does not apply to the header value). If multiple header fields of the same field name are present, the values are combined into a single comma-separated value. Implementations MUST at a minimum include the Call-ID header and MAY include other headers. For example, session.connection.protocol.sip.headers["call-id"] evaluates to the Call-ID of the SIP dialog.
session.connection.protocol.sip.headers：これは、配列内の各キーが小文字に変換された最初の招待のSIPヘッダーの非コンパクト名である連想配列です（ケース変換はヘッダー値に適用されません。）。同じフィールド名の複数のヘッダーフィールドが存在する場合、値は単一のコンマ分離値に結合されます。実装には、Call-IDヘッダーを少なくとも含める必要があり、他のヘッダーを含めることができます。たとえば、session.connection.protocol.sip.headers ["call-id"]は、SIPダイアログのcall-idを評価します。
session.connection.protocol.sip.requesturi: This is an associative array where the array keys and values are formed from the URI parameters on the SIP Request-URI of the initial INVITE. The array key is the URI parameter name converted to lowercase (note the case conversion does not apply to the parameter value). The corresponding array value is obtained by evaluating the URI parameter value as a "JSON value" [RFC4627] in the case of the ccxml-param and aai-param values and otherwise as a string. In addition, the array's toString() function returns the full SIP Request-URI. For example, assuming a Request-URI of sip:dialog@ example.com;voicexml=http://example.com;aai=%7b"x":1%2c"y":true%7d then session.connection.protocol.sip.requesturi["voicexml"] evaluates to "http://example.com", session.connection.protocol.sip.requesturi["aai"].x evaluates to 1 (type Number), session.connection.protocol.sip.requesturi["aai"].y evaluates to true (type Boolean), and session.connection.protocol.sip.requesturi evaluates to the complete Request-URI (type String) 'sip:dialog@ example.com;voicexml=http://example.com;aai={"x":1,"y":true}'.
session.connection.protocol.sip.requesturi：これは、最初の招待のSIPリクエスト-URIのURIパラメーターから配列キーと値が形成される連想配列です。配列キーは、小文字に変換されたURIパラメーター名です（ケース変換はパラメーター値には適用されません）。対応する配列値は、CCXML-PARAMおよびAAI-PARAM値の場合、およびそれ以外の場合は文字列としてURIパラメーター値を「JSON値」[RFC4627]として評価することにより取得されます。さらに、配列のtoString（）関数は、完全なSIPリクエスト-URIを返します。たとえば、sip：dialog@ example.com; voicexml = http：//example.com; aai =％7b "x"：1％2c "y"：true％7d then session.connectionを想定してください。protocol.sip.requesturi ["Voicexml"]は、「http://example.com」、Session.connection.protocol.sip.requesturi ["aai"]。protocol.sip.requesturi ["aai"]。yは、true（type boolean）、およびsession.connection.protocol.sip.requesturiを完全なrequest-uri（type string） 'sip：dialog@ example.com;VoiceXml = http：//example.com; aai = {"x"：1、 "y"：true} '。
session.connection.aai: Evaluates to session.connection.protocol.sip.requesturi["aai"].
session.connection.aai：session.connection.protocol.sip.requesturi ["aai"]を評価します。
session.connection.ccxml: Evaluates to session.connection.protocol.sip.requesturi["ccxml"].
session.connection.ccxml：session.connection.protocol.sip.requesturi ["ccxml"]を評価します。
session.connection.protocol.sip.media: This is an array where each array element is an object with the following properties:
session.connection.protocol.sip.media：これは、各配列要素が次のプロパティを持つオブジェクトである配列です。
* type: - This required property indicates the type of the media associated with the stream. The value is a string. It is strongly recommended that the following values are used for common types of media: "audio" for audio media, and "video" for video media.
* タイプ： - この必要なプロパティは、ストリームに関連付けられたメディアのタイプを示します。値は文字列です。一般的なタイプのメディアには、次の値を使用することを強くお勧めします：オーディオメディアの「オーディオ」、ビデオメディアの「ビデオ」。
* direction: - This required property indicates the directionality of the media relative to session.connection.originator. Defined values are sendrecv, sendonly, recvonly, and inactive.
* 方向： - この必要なプロパティは、session.connection.originatorに対するメディアの方向性を示します。定義された値は、sendrecv、sendonly、recvonly、および非アクティブです。
* format: - This property is optional. If defined, the value of the property is an array. Each array element is an object that specifies information about one format of the media (there is an array element for each payload type on the m-line). The object contains at least one property called "name" whose value is the MIME subtype of the media format (MIME subtypes are registered in [RFC4855]). Other properties may be defined with string values; these correspond to required and, if defined, optional parameters of the format.
* 形式： - このプロパティはオプションです。定義されている場合、プロパティの値は配列です。各配列要素は、メディアの1つの形式に関する情報を指定するオブジェクトです（Mラインに各ペイロードタイプに配列要素があります）。オブジェクトには、値がメディア形式のMIMEサブタイプである「名前」と呼ばれる少なくとも1つのプロパティが含まれています（MIMEサブタイプは[RFC4855]に登録されています）。他のプロパティは、文字列値で定義される場合があります。これらは、フォーマットの必要なパラメーターと定義されている場合に対応します。
As a consequence of this definition, there is an array entry in session.connection.protocol.sip.media for each non-disabled m-line for the negotiated media session. Note that this session variable is updated if the media session characteristics for the VoiceXML Session change (i.e., due to a re-INVITE). For an example, consider a connection with bidirectional G.711 mu-law "audio" sampled at 8 kHz. In this case, session.connection.protocol.sip.media[0].type evaluates to "audio", session.connection.protocol.sip.media[0].direction to "sendrecv", session.connection.protocol.sip.media[0].format[0].name evaluates to "audio/PCMU", and session.connection.protocol.sip.media[0].format[0].rate evaluates to "8000".
この定義の結果として、ネゴシエートされたメディアセッションの各障害のないM-Lineについて、session.connection.protocol.sip.mediaに配列エントリがあります。VoiceXMLセッションのメディアセッションの特性が変更された場合（つまり、再インバイトのため）、このセッション変数が更新されることに注意してください。たとえば、8 kHzでサンプリングされた双方向G.711 MU-LAW「オーディオ」との接続を検討してください。この場合、session.connection.protocol.sip.media [0] .typeは「audio」、session.connection.protocol.sip.media [0]に「sendrecv」、session.connection.protocol.sip.media [0] .Format [0] .Nameは「Audio/PCMU」、およびsession.connection.protocol.sip.media [0] .format [0] .Rateを「8000」に評価します。
Note that when accessing SIP headers and Request-URI parameters via the session.connection.protocol.sip.headers and session.connection.protocol.sip.requesturi associative arrays defined above, applications can choose between two semantically equivalent ways of referring to the array. For example, either of the following can be used to access a Request-URI parameter named "foo":
session.connection.protocol.sip.headers.connection.connection.protocol.sip.requesturi連想配列を介してSIPヘッダーとリクエスト-URIパラメーターにアクセスする場合、アプリケーションは、配列に言及する2つの半次同等の方法を選択できることに注意してください。。たとえば、次のいずれかを使用して、「Foo」という名前のリクエスト-URIパラメーターにアクセスできます。
session.connection.protocol.sip.requesturi["foo"] session.connection.protocol.sip.requesturi.foo
session.connection.protocol.sip.requesturi ["foo"] session.connection.protocol.sip.requesturi.foo
However, it is important to note that not all SIP header names or Request-URI parameter names are valid ECMAScript identifiers, and as such, can only be accessed using the first form (array notation). For example, the Call-ID header can only be accessed as session.connection.protocol.sip.headers["call-id"]; attempting to access the same value as session.connection.protocol.sip.headers.call-id would result in an error.
ただし、すべてのSIPヘッダー名またはRequest-URIパラメーター名が有効なECMAScript識別子であるわけではないため、最初のフォーム（配列表記）を使用してのみアクセスできることに注意することが重要です。たとえば、call-idヘッダーはsession.connection.protocol.sip.headers ["call-id"]としてのみアクセスできます。session.connection.protocol.sip.headers.call-idと同じ値にアクセスしようとすると、エラーが発生します。
The Application Server can terminate a VoiceXML Session by issuing a BYE to the VoiceXML Media Server. Upon receipt of a BYE in the context of an existing VoiceXML Session, the VoiceXML Media Server MUST send a 200 OK response and MUST throw a 'connection.disconnect.hangup' event to the VoiceXML application. If the Reason header [RFC3326] is present on the BYE Request, then the value of the Reason header is provided verbatim via the '_message' variable within the catch element's anonymous variable scope.
Application Serverは、VoiceXML Media ServerにByeを発行することにより、VoiceXMLセッションを終了できます。既存のVoiceXMLセッションのコンテキストでさようならを受信すると、VoiceXMLメディアサーバーは200 OK応答を送信する必要があり、 'connection.disconnect.hangup'イベントをVoiceXMLアプリケーションにスローする必要があります。BYEリクエストにHeader [RFC3326]が存在する理由は、Catch Elementの匿名変数スコープ内の「_Message」変数を介してverbatimが提供されます。
The VoiceXML Media Server may also initiate termination of the session by issuing a BYE request. This will typically occur as a result of encountering a <disconnect> or <exit> in the VoiceXML application, due to the VoiceXML application running to completion, or due to unhandled errors within the VoiceXML application.
VoiceXMLメディアサーバーは、BYEリクエストを発行することにより、セッションの終了を開始する場合もあります。これは通常、VoiceXMLアプリケーションでA <切断>または<Exit>に遭遇した結果、voiceXMLアプリケーションが完了まで実行されるか、voiceXMLアプリケーション内の未処理のエラーにより発生します。
See Section 4 for mechanisms to return data to the Application Server.
アプリケーションサーバーにデータを返すメカニズムについては、セクション4を参照してください。
This example illustrates an Application Server setting up a VoiceXML Session on behalf of a User Agent.
この例は、ユーザーエージェントに代わってVoiceXMLセッションを設定するアプリケーションサーバーを示しています。
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
|(1) INVITE [offer] | | |
|------------------->|(2) INVITE [offer] | |
|(3) 100 Trying |------------------->| |
|<-------------------|(4) 100 Trying | |
| |<-------------------| |
| | | |
| | |(5) GET |
| | |------------------->|
| | |(6) 200 OK [VXML] |
| | |<-------------------|
| | | |
| |(7) 200 OK [answer] | |
|(8) 200 OK [answer] |<-------------------| |
|<-------------------| | |
|(9) ACK | | |
|------------------->|(10) ACK | |
| |------------------->| (execute |
|(11) RTP/SRTP | | VoiceXML |
|.........................................| application) |
| | | |
This example demonstrates the preparation of a VoiceXML Session. In this example, the VoiceXML session is prepared prior to placing an outbound call to a User Agent, and is started as soon as the User Agent answers.
この例は、VoiceXMLセッションの準備を示しています。この例では、ユーザーエージェントにアウトバウンドコールを配置する前にVoiceXMLセッションが作成され、ユーザーエージェントが回答するとすぐに開始されます。
The [answer1:0] notation is used to indicate an SDP answer with the media ports set to 0.
[Answer1：0]表記は、メディアポートが0に設定されたSDP回答を示すために使用されます。
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
| |(1) INVITE | |
| |-------------------->| |
| |(2) 100 Trying | |
| |<--------------------| |
| | | |
| | |(3) GET |
| | |------------------->|
| | |(4) 200 OK [VXML] |
| | |<-------------------|
| | | |
| |(5) 200 OK [offer1] | |
| |<--------------------| |
| |(6) ACK [answer1:0] | |
|(7) INVITE |-------------------->| |
|<-------------------| | |
|(8) 200 OK [offer2] | | |
|------------------->|(9) INVITE [offer2'] | |
| |-------------------->| |
| |(10) 100 Trying | |
| |<--------------------| |
| |(11) 200 OK [answer2]| |
|(12) ACK [answer2] |<--------------------| |
|<-------------------|(13) ACK | |
| |-------------------->| (execute |
|(14) RTP/SRTP | VoiceXML |
|..........................................| application) |
| | | |
Implementation detail: offer2' is derived from offer2 -- it duplicates the m-lines and a-lines from offer2. However, offer2' differs from offer2 since it must contain the same o-line as used in answer1:0 but with the version number incremented. Also, if offer1 has more m-lines than offer2, then offer2' must be padded with extra (rejected) m-lines.
実装の詳細：offer2 'はoffer2から派生しています。MラインとAラインをoffer2から複製します2。ただし、offer2 'はoffer2とは異なります。これは、Answer1：0で使用されているのと同じOラインを含める必要があるが、バージョン番号が増加する必要があるからです。また、offer1がoffer2よりも多くのmラインを持っている場合、offer2 'に追加（拒否された）mラインでパディングする必要があります。
Media Resource Control Protocol (MRCP) [MRCPv2] is a protocol that enables clients such as a VoiceXML Media Server to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network.
Media Resource Control Protocol（MRCP）[MRCPV2]は、VoiceXMLメディアサーバーなどのクライアントが、ネットワーク上のサーバーに存在する識別子などのメディアサービスリソースを制御できるようにするプロトコルです。
The example below illustrates how a VoiceXML Media Server may establish an MRCP session in response to an initial INVITE.
以下の例は、VoiceXMLメディアサーバーが最初の招待に応じてMRCPセッションを確立する方法を示しています。
VoiceXML HTTP
User Media MRCPv2 Application
Agent Server Server Server
| | | |
|(1) INVITE [offer1] | | |
|------------------->| | |
|(2) 100 Trying | | |
|<-------------------|(3) GET | |
| |---------------------------------------->|
| | | |
| |(4) 200 OK [VXML] | |
| |<----------------------------------------|
| | | |
| |(5) INVITE [offer2] | |
| |--------------------->| |
| | | |
| |(6) 200 OK [answer2] | |
| |<---------------------| |
| | | |
| |(7) ACK | |
| |--------------------->| |
| | | |
| |(8) MRCP connection | |
| |<-------------------->| |
|(9) 200 OK [answer1]| | |
|<-------------------| | |
| | | |
|(10) ACK | | |
|------------------->| | |
| | | |
|(11) RTP/SRTP | | |
|...........................................| |
| | | |
In this example, the VoiceXML Media Server is responsible for establishing a session with the MRCPv2 Media Resource Server prior to sending the 200 OK response to the initial INVITE. The VoiceXML Media Server will perform the appropriate offer/answer with the MRCPv2 Media Resource Server based on the SDP capabilities of the Application Server and the MRCPv2 Media Resource Server. The VoiceXML Media Server will change the offer received from step 1 to establish an MRCPv2 session in step (5) and will re-write the SDP to include an m-line for each MRCPv2 resource to be used and other required SDP modifications as specified by MRCPv2. Once the VoiceXML Media Server performs the offer/answer with the MRCPv2 Media Resource Server, it will establish an MRCPv2 control channel in step (8). The MRCPv2 resource is deallocated when the VoiceXML Media Server receives or sends a BYE (not shown).
この例では、VoiceXML Media Serverは、最初の招待に200 OK応答を送信する前に、MRCPV2 Media Resource Serverとのセッションを確立する責任があります。VoiceXMLメディアサーバーは、アプリケーションサーバーとMRCPV2メディアリソースサーバーのSDP機能に基づいて、MRCPV2メディアリソースサーバーで適切なオファー/回答を実行します。VoiceXMLメディアサーバーは、ステップ1から受信したオファーを変更してステップ（5）でMRCPV2セッションを確立し、使用する各MRCPV2リソースのM-Lineおよびその他の必要なSDP変更のM-Lineを再作成して、指定したその他の必要なSDP変更を含めます。MRCPV2。VoiceXMLメディアサーバーがMRCPV2メディアリソースサーバーでオファー/回答を実行すると、ステップ（8）でMRCPV2制御チャネルを確立します。MRCPV2リソースは、VoiceXML Media ServerがByeを受信または送信したときに扱われます（図示せず）。
This section describes the mandatory and optional media support required by this interface.
このセクションでは、このインターフェイスで必要な必須およびオプションのメディアサポートについて説明します。
The VoiceXML Media Server MUST support the standard offer/answer mechanism of [RFC3264]. In particular, if an SDP offer is not present in the INVITE, the VoiceXML Media Server will make an offer in the 200 OK response listing its supported codecs.
VoiceXMLメディアサーバーは、[RFC3264]の標準的なオファー/回答メカニズムをサポートする必要があります。特に、招待状にSDPのオファーが存在しない場合、VoiceXMLメディアサーバーは、サポートされているコーデックをリストする200 OK応答でオファーを行います。
The VoiceXML Media Server MAY support early establishment of media streams as described in [RFC3960]. This allows the Application Server to establish media streams between a User Agent and the VoiceXML Media Server in parallel with the initial VoiceXML document being processed (which may involve dynamic VoiceXML page generation and interaction with databases or other systems). This is useful primarily for minimizing the delay in starting a VoiceXML Session, particularly in cases where a session with the User Agent already exists but the media stream associated with that session needs to be redirected to a VoiceXML Media Server.
[RFC3960]に記載されているように、VoiceXMLメディアサーバーは、メディアストリームの早期確立をサポートする場合があります。これにより、アプリケーションサーバーは、ユーザーエージェントとVoiceXMLメディアサーバーの間にメディアストリームを確立し、最初のVoiceXMLドキュメントが処理されていること（ダイナミックなVoiceXMLページの生成とデータベースまたはその他のシステムとの相互作用が含まれる場合があります）。これは、主にVoiceXMLセッションの開始の遅延を最小限に抑えるのに役立ちます。特に、ユーザーエージェントとのセッションが既に存在している場合、そのセッションに関連付けられたメディアストリームはVoiceXMLメディアサーバーにリダイレクトする必要があります。
The following flow demonstrates the use of early media (using the Gateway model defined in [RFC3960]):
次のフローは、初期メディアの使用を示しています（[RFC3960]で定義されたゲートウェイモデルを使用）：
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
|..(existing session)..| | |
| |(1) INVITE | |
| |------------------>| |
| | |(2) HTTP GET |
| | |------------------>|
| |(3) 183 [offer] | |
|(4) re-INVITE [offer] |<------------------| |
|<---------------------| | |
|(5) 200 OK [answer] | | |
|--------------------->| | |
|(6) ACK | | |
|<---------------------| | |
| | (7) PRACK [answer]| |
| |------------------>| |
| | (8) PRACK 200 OK | |
| |<------------------| |
|(9) RTP/SRTP | | |
|..........................................| |
| | |(10) 200 OK [VXML] |
| | |<------------------|
| | | |
| |(11) 200 OK | |
| |<------------------| |
| |(12) ACK | |
| |------------------>| (execute |
| | | VoiceXML |
| | | application) |
| | | |
Although [RFC3960] prefers the use of the Application Server model for early media over the Gateway model, the primary issue with the Gateway model -- forking -- is significantly less common when issuing requests to VoiceXML Media Servers. This is because VoiceXML Media Servers respond to all requests with 200 OK responses in the absence of unusual errors, and they typically do so within several hundred milliseconds. This makes them unlikely targets in forking scenarios, since alternative targets of the forking process would virtually never be able to respond more quickly than an automated system, unless they are themselves automated systems -- in which case, there is little point in setting up a response time race between two automated systems. Issues with ringing tone generation in the Gateway model are also mitigated, both by the typically quick 200 OK response time, and because this specification mandates that no media packets are generated until the receipt of an ACK (thus eliminating the need for the User Agent to perform media packet analysis).
[RFC3960]は、Gatewayモデルを介した初期メディアにアプリケーションサーバーモデルの使用を好むが、GateXMLメディアサーバーへのリクエストを発行する場合、ゲートウェイモデルの主要な問題（フォーキング）はあまり一般的ではない。これは、VoiceXMLメディアサーバーが異常なエラーがない場合に200のOK応答ですべてのリクエストに応答し、通常数百ミリ秒以内にそうするためです。フォーキングプロセスの代替ターゲットは、自動化されたシステムでない限り、自動化されたシステムよりも迅速に応答することはできないため、フォーキングシナリオではありそうもないターゲットになります。2つの自動システム間の応答時間レース。ゲートウェイモデルでのリンギングトーン生成の問題は、通常200 OK応答時間の両方によって、またこの仕様はACKの受領までメディアパケットが生成されないことを義務付けているため（したがって、ユーザーエージェントがユーザーエージェントが必要とすることを削除することが義務付けられているためメディアパケット分析を実行します）。
Note that the offer of early media by a VoiceXML Media Server does not imply that the referenced VoiceXML application can always be fetched and executed successfully. For instance, if the HTTP Application Server were to return a 4xx response in step 10 above, or if the provided VoiceXML content was not valid, the VoiceXML Media Server would still return a 500 response (as per Section 2.2). At this point, it would be the responsibility of the Application Server to tear down any media streams established with the media server.
VoiceXMLメディアサーバーによる初期メディアの提供は、参照されるVoiceXMLアプリケーションを常に正常にフェッチして実行できることを意味するものではないことに注意してください。たとえば、HTTPアプリケーションサーバーが上記のステップ10で4XX応答を返す場合、または提供されたVoiceXMLコンテンツが有効でない場合、VoiceXMLメディアサーバーは500応答を返します（セクション2.2に従って）。この時点で、メディアサーバーで確立されたメディアストリームを取り壊すことは、アプリケーションサーバーの責任です。
The VoiceXML Media Server MUST allow the media session to be modified via a re-INVITE and SHOULD support the UPDATE method [RFC3311] for the same purpose. In particular, it MUST be possible to change streams between sendrecv, sendonly, and recvonly as specified in [RFC3264].
VoiceXMLメディアサーバーは、メディアセッションを再インバイトを介して変更することを許可する必要があり、同じ目的で更新方法[RFC3311]をサポートする必要があります。特に、[RFC3264]で指定されているように、SendRecv、Sendonly、およびRecvonly間のストリームを変更することが可能である必要があります。
Unidirectional streams are useful for announcement- or listening-only (hotword). The preferred mechanism for putting the media session on hold is specified in [RFC3264], i.e., the UA modifies the stream to be sendonly and mutes its own stream. Modification of the media session does not affect VoiceXML application execution (except that recognition actions initiated while on hold will result in noinput timeouts).
一方向のストリームは、発表またはリスニングのみ（hotword）に役立ちます。メディアセッションを保留するための好ましいメカニズムは[RFC3264]で指定されています。つまり、UAはストリームをセンドンリーに変更し、独自のストリームをミュートします。メディアセッションの変更は、VoiceXMLアプリケーションの実行に影響しません（保留中に開始された認識アクションがノインップタイムアウトになります）。
For the purposes of achieving a basic level of interoperability, this section specifies a minimal subset of codecs and RTP [RFC3550] payload formats that MUST be supported by the VoiceXML Media Server.
相互運用性の基本レベルを達成する目的で、このセクションでは、bowiceXMLメディアサーバーでサポートする必要があるコーデックとRTP [RFC3550]ペイロード形式の最小限のサブセットを指定します。
For audio-only applications, G.711 mu-law and A-law MUST be supported using the RTP payload type 0 and 8 [RFC3551]. Other codecs and payload formats MAY be supported.
オーディオのみのアプリケーションの場合、G.711 MU-LAWおよびA-LAWをRTPペイロードタイプ0および8 [RFC3551]を使用してサポートする必要があります。他のコーデックとペイロード形式がサポートされる場合があります。
Video telephony applications, which employ a video stream in addition to the audio stream, are possible in VoiceXML 2.0/2.1 through the use of multimedia file container formats such as the .3gp [TS26244] and .mp4 formats [IEC14496-14]. Video support is optional for this specification. If video is supported then:
オーディオストリームに加えてビデオストリームを採用するビデオテレフォニーアプリケーションは、.3GP [TS26244]や.MP4形式[IEC14496-14]などのマルチメディアファイルコンテナ形式の使用を通じてVoiceXML 2.0/2.1で可能です。この仕様のビデオサポートはオプションです。ビデオがサポートされている場合は：
1. H.263 Baseline [RFC4629] MUST be supported. For legacy reasons, the 1996 version of H.263 MAY be supported using the RTP payload format defined in [RFC2190] (payload type 34 [RFC3551]).
1. H.263ベースライン[RFC4629]をサポートする必要があります。レガシーの理由から、H.263の1996バージョンは、[RFC2190]（ペイロードタイプ34 [RFC3551]）で定義されたRTPペイロード形式を使用してサポートできます。
2. Adaptive Multi-Rate (AMR) narrow band audio [RFC4867] SHOULD be supported.
2. 適応型マルチレート（AMR）ナローバンドオーディオ[RFC4867]をサポートする必要があります。
3. MPEG-4 video [RFC3016] SHOULD be supported.
3. MPEG-4ビデオ[RFC3016]をサポートする必要があります。
4. MPEG-4 Advanced Audio Coding (AAC) audio [RFC3016] SHOULD be supported.
4. MPEG-4高度なオーディオコーディング（AAC）オーディオ[RFC3016]をサポートする必要があります。
5. Other codecs and payload formats MAY be supported.
5. 他のコーデックとペイロード形式がサポートされる場合があります。
Video record operations carried out by the VoiceXML Media Server typically require receipt of an intra-frame before the recording can commence. The VoiceXML Media Server SHOULD use the mechanism described in [RFC4585] to request that a new intra-frame be sent.
VoiceXML Media Serverが実行するビデオレコード操作は、通常、録音が開始される前にフレーム内の受信を必要とします。[RFC4585]で説明されているメカニズムを使用して、新しいフレームを送信するように要求する必要があります。
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support Secure RTP (SRTP) [RFC3711] as discussed in Section 9.
一部のアプリケーションは機密情報を転送することを選択する可能性があるため、beowsXMLメディアサーバーはセクション9で説明したように、安全なRTP（SRTP）[RFC3711]をサポートする必要があります。
DTMF events [RFC4733] MUST be supported. When the User Agent does not indicate support for [RFC4733], the VoiceXML Media Server MAY perform DTMF detection using other means such as detecting DTMF tones in the audio stream. Implementation note: the reason only [RFC4733] telephone-events must be used when the User Agent indicates support of it is to avoid the risk of double detection of DTMF if detection on the audio stream was simultaneously applied.
DTMFイベント[RFC4733]をサポートする必要があります。ユーザーエージェントが[RFC4733]のサポートを示していない場合、VoiceXMLメディアサーバーは、オーディオストリームのDTMFトーンの検出など、他の手段を使用してDTMF検出を実行できます。実装注：ユーザーエージェントがそれをサポートすることを示す場合、[RFC4733]電話のイベントのみを使用する必要があります。オーディオストリームでの検出が同時に適用された場合、DTMFの二重検出のリスクを回避することです。
This section discusses the mechanisms for returning data (e.g., collected utterance or digit information) from the VoiceXML Media Server to the Application Server.
このセクションでは、VoiceXML Media Serverからアプリケーションサーバーへのデータを返すメカニズム（たとえば、発話または数字情報を収集した）について説明します。
At any time during the execution of the VoiceXML application, data can be returned to the Application Server via HTTP using standard VoiceXML elements such as <submit> or <subdialog>. Notably, the <data> element in VoiceXML 2.1 [VXML21] allows data to be sent to the Application Server efficiently without requiring a VoiceXML page transition and is ideal for short VoiceXML applications such as "prompt and collect".
VoiceXMLアプリケーションの実行中はいつでも、<shoct>や<subdialog>などの標準のVoiceXML要素を使用してHTTPを介してアプリケーションサーバーにデータを返すことができます。特に、VoiceXML 2.1 [VXML21]の<Data>要素により、VoiceXMLページの遷移を必要とせずにデータをアプリケーションサーバーに効率的に送信でき、「プロンプトと収集」などの短いVoiceXMLアプリケーションに最適です。
For most applications, it is necessary to correlate the information being passed over HTTP with a particular VoiceXML Session. One way this can be achieved is to include the SIP Call-ID (accessible in VoiceXML via the session.connection.protocol.sip.headers array) within the HTTP POST fields. Alternatively, a unique "POST-back URI" can be specified as an application-specific URI parameter in the Request-URI of the initial INVITE (accessible in VoiceXML via the session.connection.protocol.sip.requesturi array).
ほとんどのアプリケーションでは、HTTPを介して渡されている情報を特定のVoiceXMLセッションと相関させる必要があります。これを達成できる1つの方法は、HTTPポストフィールド内にSIPコールID（Session.connection.protocol.sip.headers Arrayを介してVoiceXMLにアクセス可能）を含めることです。あるいは、ユニークな「ポストバックURI」は、最初の招待のリクエスト-URIでアプリケーション固有のURIパラメーターとして指定できます（session.connection.connection.protocol.sip.requesturiアレイを介してVoicexmlでアクセスできます）。
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the https: scheme as discussed in Section 9.
一部のアプリケーションは機密情報を転送することを選択する場合があるため、beowsXMLメディアサーバーは、セクション9で説明したHTTPS：スキームをサポートする必要があります。
Data can be returned to the Application Server via the expr or namelist attribute on <exit> or the namelist attribute on <disconnect>. A VoiceXML Media Server MUST support encoding of the expr/namelist data in the message body of a BYE request sent from the VoiceXML Media Server as a result of encountering the <exit> or <disconnect> element. A VoiceXML Media Server MAY support inclusion of the expr/namelist data in the message body of the 200 OK message in response to a received BYE request (i.e., when the VoiceXML application responds to the connection.disconnect.hangup event and subsequently executes an <exit> element with the expr or namelist attribute specified).
データは、<Exit>のEXPRまたはNAMELIST属性または<Disconnect>のNAMELIST属性を介してアプリケーションサーバーに返すことができます。VoiceXMLメディアサーバーは、<Exit>または<Exitonect>要素に遭遇した結果として、VoiceXML Media Serverから送信されたBYEリクエストのメッセージ本文内のEXPR/NAMELISTデータのエンコードをサポートする必要があります。VoiceXMLメディアサーバーは、受信したBYEリクエストに応じて200 OKメッセージのメッセージ本文にEXPR/NAMELISTデータを含めることをサポートする場合があります（つまり、VoiceXMLアプリケーションがConnection.disconnect.hangupイベントに応答し、その後<an <を実行する場合EXPRまたはNAMELIST属性が指定されたExtent>要素）。
Note that sending expr/namelist data in the 200 OK response requires that the VoiceXML Media Server delay the final response to the received BYE request until the VoiceXML application's post-disconnect final processing state terminates. This mechanism is subject to the constraint that the VoiceXML Media Server must respond before the User Agent Client's (UAC's) timer F expires (defaults to 32 seconds). Moreover, for unreliable transports, the UAC will retransmit the BYE request according to the rules of [RFC3261]. The VoiceXML Media Server SHOULD implement the recommendations of [RFC4320] regarding when to send the 100 Trying provisional response to the BYE request.
200 OK応答でEXPR/NAMELISTデータを送信するには、VOICEXMLメディアサーバーが、VoiceXMLアプリケーションのポストディスコネクト最終処理状態が終了するまで、受信したBYEリクエストに対する最終的な応答を遅らせる必要があることに注意してください。このメカニズムには、ユーザーエージェントクライアント（UAC）タイマーFが失効する前に、VoiceXMLメディアサーバーが応答しなければならないという制約の対象となります（デフォルトは32秒になります）。さらに、信頼できない輸送の場合、UACは[RFC3261]のルールに従ってBYEリクエストを再送信します。VoiceXML Media Serverは、BYEリクエストに100の暫定的な応答をいつ送信するかについて、[RFC4320]の推奨事項を実装する必要があります。
If a VoiceXML application executes a <disconnect> [VXML21] and then subsequently executes an <exit> with namelist information, the namelist information from the <exit> element is discarded.
VoiceXMLアプリケーションがa <disconnect> [vxml21]を実行し、その後、namelist情報を使用して<Exit>を実行すると、<Exit>要素からのナメリスト情報が破棄されます。
Namelist variables are first converted to their "JSON value" equivalent [RFC4627] and encoded in the message body using the application/x-www-form-urlencoded format content type [HTML4]. The behavior resulting from specifying a recording variable in the namelist or an ECMAScript object with circular references is not defined. If the expr attribute is specified on the <exit> element instead of the namelist attribute, the reserved name __exit is used.
NAMELIST変数は、最初に「JSON値」等価[RFC4627]に変換され、アプリケーション/x-www-form-urlencodedフォーマットコンテンツタイプ[HTML4]を使用してメッセージ本文にエンコードされます。円形の参照を持つNAMELISTまたはECMAScriptオブジェクトの記録変数を指定することに起因する動作は定義されていません。expr属性がnamelist属性の代わりに<exit>要素に指定されている場合、予約名__exitが使用されます。
To allow the Application Server to differentiate between a BYE resulting from a <disconnect> from one resulting from an <exit>, the reserved name __reason is used, with a value of "disconnect" (without brackets) to reflect the use of VoiceXML's <disconnect> element, and a value of "exit" (without brackets) to an explicit <exit> in the VoiceXML document. If the session terminates for other reasons (such as the media server encountering an error), this parameter may be omitted, or may take on platform-specific values prefixed with an underscore.
<exit>から生じる<exnect>からのa <disconnect>の結果の結果をアプリケーションサーバーに区別できるようにするために、予約名__reasonが使用され、bowexmlの<の使用を反映するために「切断」（ブラケットなし）の値が使用されます。[boicexmlドキュメントの明示的な<Exit>への[exit]（bracketsなし）の値を切断します。セッションが他の理由で終了した場合（メディアサーバーがエラーに遭遇するなど）、このパラメーターが省略されるか、アンダースコアが付いたプラットフォーム固有の値を引き受ける場合があります。
This specification extends the application/x-www-form-urlencoded by replacing non-ASCII characters with one or more octets of the UTF-8 representation of the character, with each octet in turn replaced by %HH, where HH represents the uppercase hexadecimal notation for the octet value and % is a literal character. As a consequence, the Content-Type header field in a BYE message containing expr/namelist data MUST be set to application/x-www-form-urlencoded;charset=utf-8.
この仕様により、ASCII以外の文字をUTF-8表現の1つ以上のオクテットに置き換えることにより、アプリケーション/X-WWW-Form-UrlENCODEが拡張され、各オクテットは％HHに置き換えられます。Octet値と％の表記は文字通りの文字です。結果として、Expr/Namelistデータを含むBYEメッセージのコンテンツタイプのヘッダーフィールドは、Application/X-WWW-Form-Urlencoded; charset = utf-8に設定する必要があります。
The following table provides some examples of <exit> usage and the corresponding result content.
次の表には、<Exit>使用法と対応する結果コンテンツの例がいくつかあります。
+----------------------------------------------------------------+
|<exit> Usage | Result Content |
|------------------------------|---------------------------------|
|<exit/> | __reason=exit |
|<exit expr="5"/> | __exit=5&__reason=exit |
|<exit expr="'done'"/> | __exit="done"&__reason=exit |
|<exit expr="userAuthorized"/> | __exit=true&__reason=exit |
|<exit namelist="pin errors"/> | pin=1234&errors=0&__reason=exit |
+----------------------------------------------------------------+
assuming the following VoiceXML variables and values:
userAuthorized = true
pin = 1234
errors = 0
For example, consider the VoiceXML snippet:
たとえば、voicexmlスニペットを検討してください。
... <exit namelist="id pin"/> ...
... <exit nameList = "id pin"/> ...
If id equals 1234 and pin equals 9999, say, the BYE message would look similar to:
IDが1234に等しく、PINが9999に等しい場合、たとえば、さようならメッセージは次のように見えます。
BYE sip:user@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: sip:dialog@example.com;tag=a6c85cf
To: sip:user@example.com;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Content-Length: 30
id=1234&pin=9999&__reason=exit
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the S/MIME encoding of SIP message bodies as discussed in Section 9.
一部のアプリケーションは機密情報を転送することを選択する可能性があるため、beowsXMLメディアサーバーは、セクション9で説明したように、SIPメッセージ本体のS/MIMEエンコードをサポートする必要があります。
Outbound calls can be triggered via the Application Server using third-party call control [RFC3725].
アウトバウンドコールは、サードパーティのコールコントロール[RFC3725]を使用して、アプリケーションサーバーを介してトリガーできます。
Flow IV from [RFC3725] is recommended in conjunction with the VoiceXML Session preparation mechanism. This flow has several advantages over others, namely:
[RFC3725]のフローIVは、VoiceXMLセッションの準備メカニズムと併せて推奨されます。このフローには、他の人よりもいくつかの利点があります。
1. Selection of a VoiceXML Media Server and preparation of the VoiceXML application can occur before the call is placed to avoid the callee experiencing delays.
1. VoiceXMLメディアサーバーの選択とVoiceXMLアプリケーションの準備は、遅延が発生しているCalleeを避けるために通話が行われる前に発生する可能性があります。
2. Avoidance of timing difficulties that could occur with other flows due to the time taken to fetch and parse the initial VoiceXML document.
2. 最初のVoiceXMLドキュメントを取得して解析するのにかかったため、他のフローで発生する可能性のあるタイミングの難しさを回避します。
3. The flow is IPv6 compatible.
3. フローはIPv6互換です。
An example flow for an Application-Server-initiated outbound call is provided in Section 2.6.2.
アプリケーションサーバー開始のアウトバウンドコールのフローの例は、セクション2.6.2に記載されています。
While VoiceXML is at its core a dialog language, it also provides optional call transfer capability. VoiceXML's transfer capability is particularly suited to the PSTN IVR Service Node use case described in Section 1.1.2. It is NOT RECOMMENDED to use VoiceXML's call transfer capability in networks involving Application Servers. Rather, the Application Server itself can provide call routing functionality by taking signaling actions based on the data returned to it from the VoiceXML Media Server via HTTP or in the SIP BYE message.
VoiceXMLはそのコアにダイアログ言語ですが、オプションのコール転送機能も提供します。VoiceXMLの転送機能は、セクション1.1.2で説明されているPSTN IVRサービスノードの使用ケースに特に適しています。アプリケーションサーバーを含むネットワークでVoiceXMLのコール転送機能を使用することはお勧めしません。むしろ、アプリケーションサーバー自体は、HTTP経由またはSIP ByeメッセージでVoiceXML Media Serverから返されたデータに基づいて信号アクションを実行することにより、コールルーティング機能を提供できます。
If VoiceXML transfer is supported, the mechanism described in this section MUST be employed. The transfer flows specified here are selected on the basis that they provide the best interworking across a wide range of SIP devices. CCXML<->VoiceXML implementations, which require tight-coupling in the form of bidirectional eventing to support all transfer types defined in VoiceXML, may benefit from other approaches, such as the use of SIP event packages [RFC3265].
VoiceXML転送がサポートされている場合、このセクションで説明したメカニズムを使用する必要があります。ここで指定されている転送フローは、幅広いSIPデバイスで最高のインターワーキングを提供することに基づいて選択されます。CCXML <-> VoiceXMLの実装は、VoiceXMLで定義されたすべての転送タイプをサポートするために双方向イベントの形で緊密なカップリングを必要とするため、SIPイベントパッケージ[RFC3265]の使用など、他のアプローチの恩恵を受ける可能性があります。
In what follows, the provisional responses have been omitted for clarity.
以下では、暫定的な応答は明確に省略されています。
The blind-transfer sequence is initiated by the VoiceXML Media Server via a REFER message [RFC3515] on the original SIP dialog. The Refer-To header contains the URI for the called party, as specified via the dest or destexpr attributes on the VoiceXML <transfer> tag.
ブラインドトランスファーシーケンスは、元のSIPダイアログでの参照メッセージ[RFC3515]を介してVoiceXMLメディアサーバーによって開始されます。参照ヘッダーには、voicexml <Transfer>タグのDESTまたはDESTEXPR属性を介して指定されているように、呼び出されたパーティーのURIが含まれています。
If the REFER request is accepted, in which case the VoiceXML Media Server will receive a 2xx response, the VoiceXML Media Server throws the connection.disconnect.transfer event and will terminate the VoiceXML Session with a BYE message. For blind transfers, implementations MAY use [RFC4488] to suppress the implicit subscription associated with the REFER message.
参照要求が受け入れられた場合、その場合、VoiceXMLメディアサーバーは2XX応答を受信します。VoiceXMLメディアサーバーはConnection.Disconnect.Transferイベントをスローし、ByeメッセージでVoiceXMLセッションを終了します。ブラインド転送の場合、実装は[RFC4488]を使用して、紹介メッセージに関連付けられた暗黙のサブスクリプションを抑制する場合があります。
If the REFER request results in a non-2xx response, the <transfer>'s form item variable (or event raised) depends on the SIP response and is specified in the following table. Note that this indicates that the transfer request was rejected.
参照要求が非2XX応答を結果にする場合、<transfer>のフォームアイテム変数（または発生したイベント）はSIP応答に依存し、次の表に指定されています。これは、転送要求が拒否されたことを示していることに注意してください。
+-------------------------+-----------------------------------+
| SIP Response | <transfer> variable / event |
+-------------------------+-----------------------------------+
| 404 Not Found | error.connection.baddestination |
| 405 Method Not Allowed | error.unsupported.transfer.blind |
| 503 Service Unavailable | error.connection.noresource |
| (No response) | network_busy |
| (Other 3xx/4xx/5xx/6xx) | unknown |
+-------------------------+-----------------------------------+
An example is illustrated below (provisional responses and NOTIFY messages corresponding to provisional responses have been omitted for clarity).
例を以下に示します（暫定的な回答と暫定的な応答に対応するメッセージに通知することは、明確にするために省略されています）。
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0) RTP/SRTP | |
|.................| |
| | |
|(1) REFER | <transfer> |
|<----------------| |
|(2) 202 Accepted | |
|---------------->| |
|(3) BYE | |
|<----------------| |
|(4) 200 OK | |
|---------------->| |
| | Stop RTP (0) |
|(5) INVITE |
|---------------------------------->|
|(6) 200 OK |
|<----------------------------------|
|(7) NOTIFY | |
|---------------->| |
|(8) 200 OK | |
|<--------------- | |
|(9) ACK |
|---------------------------------->|
|(10) RTP/SRTP |
|...................................|
| | |
If the aai or aaiexpr attribute is present on <transfer>, it is appended to the Refer-To URI as a parameter named "aai" in the REFER method. Reserved characters are URL-encoded as required for SIP/SIPS URIs [RFC3261]. The mapping of values outside of the ASCII range is platform specific.
AAIまたはAAIEXPR属性が<Transfer>に存在する場合、参照メソッドの「AAI」という名前のパラメーターとしてURIに紹介されます。予約された文字は、SIP/SIPS URIS [RFC3261]に必要なURLエンコードです。ASCII範囲外の値のマッピングは、プラットフォーム固有です。
The bridge transfer function results in the creation of a small multi-party session involving the Caller, the VoiceXML Media Server, and the Callee. The VoiceXML Media Server invites the Callee to the session and will eject the Callee if the transfer is terminated.
ブリッジ転送機能により、発信者、VoiceXML Media Server、およびCalleeが関与する小さなマルチパーティセッションが作成されます。VoiceXMLメディアサーバーは、Calleeをセッションに招待し、転送が終了するとCalleeを排出します。
If the aai or aaiexpr attribute is present on <transfer>, it is appended to the Request-URI in the INVITE as a URI parameter named "aai". Reserved characters are URL-encoded as required for SIP/SIPS URIs [RFC3261]. The mapping of values outside of the ASCII range is platform specific.
AAIまたはAAIEXPR属性が<Transfer>に存在する場合、「AAI」という名前のURIパラメーターとして招待状のリクエスト-URIに追加されます。予約された文字は、SIP/SIPS URIS [RFC3261]に必要なURLエンコードです。ASCII範囲外の値のマッピングは、プラットフォーム固有です。
During the transfer attempt, audio specified in the transferaudio attribute of <transfer> is streamed to User Agent 1. A VoiceXML Media Server MAY play early media received from the Callee to the Caller if the transferaudio attribute is omitted.
転送の試行中、<転送>のTransferAudio属性で指定されたオーディオは、ユーザーエージェント1にストリーミングされます。BoiceXMLメディアサーバーは、TransferAudio属性が省略されている場合、CalleeからCalleeからCallerに受け取った早期のメディアを再生できます。
The bridge transfer sequence is illustrated below. The VoiceXML Media Server (acting as a UAC) makes a call to User Agent 2 with the same codecs used by User Agent 1. When the call setup is complete, RTP flows between User Agent 2 and the VoiceXML Media Server. This stream is mixed with User Agent 1's.
ブリッジ伝達シーケンスを以下に示します。VoiceXML Media Server（UACとして機能する）は、ユーザーエージェント1が使用するのと同じコーデックでユーザーエージェント2を呼び出します。呼び出しのセットアップが完了すると、RTPはユーザーエージェント2とVoiceXMLメディアサーバーの間に流れます。このストリームは、ユーザーエージェント1と混合されています。
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0)RTP/SRTP | |
|...................| |
| | |
| <transfer>|(1)INVITE [offer] |
| |------------------>|
| |(2) 200 OK [answer]|
| |<------------------|
| |(3) ACK |
| |------------------>|
| |(4) RTP/SRTP |
| mix |...................|
| (0)+(4)| |
If a final response is not received from User Agent 2 from the INVITE and the connecttimeout expires (specified as an attribute of <transfer>), the VoiceXML Media Server will issue a CANCEL to terminate the transaction and the <transfer>'s form item variable is set to noanswer.
招待からユーザーエージェント2から最終応答が受信され、ConnectTimeOutの有効期限が切れている場合（<転送>の属性として指定）、VoiceXMLメディアサーバーはキャンセルを発行してトランザクションと<Transfer>のフォームアイテムを終了します変数はNOANSWERに設定されています。
If INVITE results in a non-2xx response, the <transfer>'s form item variable (or event raised) depends on the SIP response and is specified in the following table.
Inviteが2xx以外の応答をもたらす場合、<transfer>のフォームアイテム変数（または発生したイベント）はSIP応答に依存し、次の表に指定されています。
+-------------------------+-----------------------------------+
| SIP Response | <transfer> variable / event |
+-------------------------+-----------------------------------+
| 404 Not Found | error.connection.baddestination |
| 405 Method Not Allowed | error.unsupported.transfer.bridge |
| 408 Request Timeout | noanswer |
| 486 Busy Here | busy |
| 503 Service Unavailable | error.connection.noresource |
| (No response) | network_busy |
| (Other 3xx/4xx/5xx/6xx) | unknown |
+-------------------------+-----------------------------------+
Once the transfer is established, the VoiceXML Media Server can "listen" to the media stream from User Agent 1 to perform speech or DTMF hotword, which when matched results in a near-end disconnect, i.e., the VoiceXML Media Server issues a BYE to User Agent 2 and the VoiceXML application continues with User Agent 1. A BYE will also be issued to User Agent 2 if the call duration exceeds the maximum duration specified in the maxtime attribute on <transfer>.
転送が確立されると、VoiceXMLメディアサーバーは、ユーザーエージェント1からメディアストリームを「聞く」ことができ、SpeechまたはDTMF HotWordを実行できます。これにより、一致すると、近い端の切断が発生します。ユーザーエージェント2およびVoiceXMLアプリケーションは、ユーザーエージェント1で継続されます。通話期間が<Transfer>のMaxtime属性で指定された最大期間を超えると、ユーザーエージェント2にさようならが発行されます。
If User Agent 2 issues a BYE during the transfer, the transfer terminates and the VoiceXML <transfer>'s form item variable receives the value far_end_disconnect. If User Agent 1 issues a BYE during the transfer, the transfer terminates and the VoiceXML event connection.disconnect.transfer is thrown.
ユーザーエージェント2が転送中にさようならを発行した場合、転送は終了し、VoiceXML <Transfer>のフォームアイテム変数は値FAR_END_DISCONNECTを受信します。ユーザーエージェント1が転送中にさようならを発行した場合、転送が終了し、voiceXMLイベントConnection.disconnect.transferがスローされます。
The consultation transfer (also called attended transfer [RFC5359]) is similar to a blind transfer except that the outcome of the transfer call setup is known and the Caller is not dropped as a result of an unsuccessful transfer attempt.
協議転送（出席転送[RFC5359]とも呼ばれる）は、転送コールのセットアップの結果が知られており、転送の失敗の結果として発信者が削除されないことを除いて、ブラインド転送に似ています。
Consultation transfer commences with the same flow as for bridge transfer except that the RTP streams are not mixed at step (4) and error.unsupported.transfer.consultation supplants error.unsupported.transfer.bridge. Assuming a new SIP dialog with User Agent 2 is created, the remainder of the sequence follows as illustrated below (provisional responses and NOTIFY messages corresponding to provisional responses have been omitted for clarity). Consultation transfer makes use of the Replaces: header [RFC3891] such that User Agent 1 calls User Agent 2 and replaces the latter's SIP dialog with the VoiceXML Media Server with a new SIP dialog between the Caller and Callee.
RTPストリームがステップ（4）とunsupported.transfer.consultation Supplants error.unsupported.transfer.bridgeで混合されないことを除いて、ブリッジ転送と同じフローで相談の転送が開始されます。ユーザーエージェント2を使用した新しいSIPダイアログが作成されると仮定すると、以下に示すように、シーケンスの残りが続きます（暫定的な応答と暫定的な応答に対応するメッセージの通知は明確に省略されています）。相談の転送では、ユーザーエージェント1がユーザーエージェント2を呼び出し、後者のSIPダイアログを発信者とCalleeの間の新しいSIPダイアログに置き換えるように、交換：Header [RFC3891]を使用します。
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0) RTP/SRTP | |
|.................|(4) RTP/SRTP |
| |.................|
|(5) REFER | |
|<----------------| |
|(6) 202 Accepted | |
|---------------->| |
|(7) INVITE Replaces:ms1.example.com|
|---------------------------------->|
|(8) 200 OK |
|<----------------------------------|
|(9) ACK |
|---------------------------------->|
|(10) RTP/SRTP |
|...................................|
| |(11) BYE |
| |<----------------|
| |(12) 200 OK |
| |---------------->| Stop
|(13) NOTIFY | | RTP (4)
|---------------->| |
|(14) 200 OK | |
|<----------------| |
|(15) BYE | |
|<----------------| |
|(16) 200 OK | |
|---------------->| Stop |
| | RTP (0) |
If a response other than 202 Accepted is received in response to the REFER request sent to User Agent 1, the transfer terminates and an error.unsupported.transfer.consultation event is raised. In addition, a BYE is sent to User Agent 2 to terminate the established outbound leg.
202以外の応答がユーザーエージェント1に送信された参照要求に応じて受信された場合、転送が終了し、エラーが終了します。さらに、BYEがユーザーエージェント2に送信され、確立されたアウトバウンドレッグを終了します。
The VoiceXML Media Server uses receipt of a NOTIFY message with a sipfrag message of 200 OK to determine that the consultation transfer has succeeded. When this occurs, the connection.disconnect.transfer event will be thrown to the VoiceXML application, and a BYE is sent to User Agent 1 to terminate the session. A NOTIFY message with a non-2xx final response sipfrag message body will result in the transfer terminating and the associated VoiceXML input item variable being set to 'unknown'. Note that as a consequence of this mechanism, implementations MUST NOT use [RFC4488] to suppress the implicit subscription associated with the REFER message for consultation transfers.
VoiceXML Media Serverは、200 OKのSIPFRAGメッセージを含むNotifyメッセージの受信を使用して、相談の転送が成功したことを判断します。これが発生すると、connection.disconnect.transferイベントがvoicexmlアプリケーションにスローされ、BYEがユーザーエージェント1に送信されてセッションが終了します。非2XX最終応答SIPFRAGメッセージ本文を使用した通知メッセージは、転送終了を行い、関連するVoiceXML入力アイテム変数が「不明」に設定されます。このメカニズムの結果として、実装は[RFC4488]を使用して、相談の紹介メッセージに関連付けられた暗黙のサブスクリプションを抑制してはならないことに注意してください。
The bulk of the early work for this effort was carried out on weekly teleconferences and over email. The authors would particularly like to recognize the contributions of R. J. Auburn (Voxeo), Jeff Haynie (Hakano), and Scott McGlashan (Hewlett-Packard).
この取り組みの初期の作業の大部分は、毎週の電子会議と電子メールで行われました。著者は、特にR. J.オーバーン（ヴォクセオ）、ジェフ・ヘイニー（ハカノ）、スコット・マクグラシャン（ヒューレット・パッカード）の貢献を認識したいと考えています。
This document owes its genesis to, "A SIP Interface to VoiceXML Dialog Servers", authored by J. Rosenberg, P. Mataga, and D. Ladd. The following people had input to the current document:
このドキュメントには、J。Rosenberg、P。Mataga、およびD. Laddが作成した「VoiceXMLダイアログサーバーへのSIPインターフェイス」の創世記を負っています。次の人々は現在の文書に入力しました。
R. J. Auburn (Voxeo)
R. J.オーバーン（ヴォクセオ）
Hans Bjurstrom (Hewlett-Packard)
Hans Bjurstrom（Hewlett-Packard）
Emily Candell (Comverse)
エミリー・キャンデル（comverse）
Peter Danielsen (Lucent)
ピーターダニエルセン（ルーセント）
Brian Frasca (Tellme)
ブライアン・フラスカ（テルメ）
Jeff Haynie (Hakano)
ジェフ・ヘイニー（ハカノ）
Scott McGlashan (Hewlett-Packard)
スコット・マクグラシャン（ヒューレット・パッカード）
Matt Oshry (Tellme)
マット・オシュリー（テルメ）
Rao Surapaneni (Tellme)
ラオ・サラパネニ（テルメ）
The authors would like to acknowledge the support of Cullen Jennings and the Mediactrl chairs, Eric Burger and Spencer Dawkins.
著者は、カレン・ジェニングスとメディアクルトルの椅子、エリック・バーガー、スペンサー・ドーキンスの支援を認めたいと考えています。
Exposing a VoiceXML media service with a well-known address may enhance the possibility of exploitation (for example, an invoked network service may trigger a billing event). The VoiceXML Media Server is RECOMMENDED to use standard SIP mechanisms [RFC3261] to authenticate requesting endpoints and authorize per local policy.
よく知られているアドレスでVoiceXMLメディアサービスを公開すると、搾取の可能性が高まる可能性があります（たとえば、呼び出されたネットワークサービスは請求イベントをトリガーする場合があります）。VoiceXMLメディアサーバーは、標準のSIPメカニズム[RFC3261]を使用して、要求のエンドポイントを認証し、ローカルポリシーごとに認証することをお勧めします。
Some applications may choose to transfer confidential information to or from the VoiceXML Media Server. To provide data confidentiality, the VoiceXML Media Server MUST implement the sips: and https: schemes in addition to S/MIME message body encoding as described in [RFC3261].
一部のアプリケーションでは、機密情報をVoiceXML Media Serverとの間で転送することを選択する場合があります。データの機密性を提供するには、[RFC3261]で説明されているように、S/MIMEメッセージ本文エンコードに加えて、SIPS：およびHTTPS：スキームを実装する必要があります。
The VoiceXML Media Server MUST support Secure RTP (SRTP) [RFC3711] to provide confidentiality, authentication, and replay protection for RTP media streams (including RTCP control traffic).
VoiceXMLメディアサーバーは、RTPメディアストリーム（RTCP制御トラフィックを含む）の機密性、認証、およびリプレイ保護を提供するために、Secure RTP（SRTP）[RFC3711]をサポートする必要があります。
To mitigate the possibility of denial-of-service attacks, the VoiceXML Media Server is RECOMMENDED (in addition to authenticating and authorizing endpoints described above) to provide mechanisms for implementing local policies such as the time-limiting of VoiceXML application execution.
サービス拒否攻撃の可能性を緩和するために、VoiceXMLアプリケーションの実行の時間制限などのローカルポリシーを実装するためのメカニズムを提供するために、VoiceXMLメディアサーバーが（上記のエンドポイントを認証および承認することに加えて）推奨されます。
IANA has registered the following parameters in the SIP/SIPS URI Parameters registry, following the Specification Required policy of [RFC3969]:
IANAは、[RFC3969]の必要なポリシーに従って、SIP/SIPS URIパラメータレジストリに次のパラメーターを登録しています。
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
maxage No RFC 5552
maxstale No RFC 5552
method "get" / "post" RFC 5552
postbody No RFC 5552
ccxml No RFC 5552
aai No RFC 5552
[HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C Recommendation, Dec 1999.
[HTML4] Raggett、D.、Le Hors、A。、およびI. Jacobs、「HTML 4.01仕様」、W3C推奨、1999年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams", RFC 3016, November 2000.
[RFC3016] Kikuchi、Y.、Nomura、T.、Fukunaga、S.、Matsui、Y.、およびH. kimata、「MPEG-4オーディオ/ビジュアルストリームのRTPペイロード形式」、RFC 3016、2000年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコルの理由ヘッダーフィールド（SIP）」、RFC 3326、2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」は「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244] Barnes、M。、「リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張」、RFC 4244、2005年11月。
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[RFC4320] Sparks、R。、「セッション開始プロトコル（SIP）非インバイトトランザクションで特定された問題に対処するアクション」、RFC 4320、2006年1月。
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006.
[RFC4488] Levin、O。、「セッション開始プロトコルの抑制（SIP）メソッドを参照する暗示サブスクリプション」、RFC 4488、2006年5月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル"、RFC 4585、2006年7月。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627] Crockford、D。、「JavaScriptオブジェクト表記（JSON）のアプリケーション/JSONメディアタイプ」、RFC 4627、2006年7月。
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. Even, "RTP Payload Format for ITU-T Rec", RFC 4629, January 2007.
[RFC4629] Ott、H.、Bormann、C.、Sullivan、G.、Wenger、S。、およびR.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733] Schulzrinne、H。およびT. Taylor、「DTMFディジット、テレフォニートーン、テレフォニー信号のRTPペイロード」、RFC 4733、2006年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[RFC4867] Sjoberg、J.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、 "RTPペイロード形式および適応マルチレート（AMR）およびアダプティブマルチレート広帯域のファイルストレージ形式（AMR-WBB）Audio Codecs」、RFC 4867、2007年4月。
[VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P., Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K., and S. Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C Recommendation, March 2004.
[VXML20] McGlashan、S.、Burnett、D.、Carter、J.、Danielsen、P.、Ferrans、J.、Hunt、A.、Lucas、B.、Porter、B.、Rehor、K。、およびS。Tryphonas、「Voice Extensible Markup Language（VoiceXML）バージョン2.0」、W3C推奨、2004年3月。
[VXML21] Oshry, M., Auburn, R J., Baggia, P., Bodell, M., Burke, D., Burnett, D., Candell, E., Kilic, H., McGlashan, S., Lee, A., Porter, B., and K. Rehor, "Voice Extensible Markup Language (VoiceXML) Version 2.1", W3C Candidate Recommendation, June 2005.
[VXML21] Oshry、M.、Auburn、R J.、Baggia、P.、Bodell、M.、Burke、D.、Burnett、D.、Candell、E.、Kilic、H.、McGlashan、S.、Lee、A.、Porter、B。、およびK. Rehor、「Voice Extensible Markup Language（VoiceXML）バージョン2.1」、W3C候補の推奨、2005年6月。
[CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version 1.0", W3C Working Draft, June 2005.
[CCXML10] Auburn、R J.、「音声ブラウザーコールコントロール：CCXMLバージョン1.0」、W3Cワーキングドラフト、2005年6月。
[IEC14496-14] "Information technology. Coding of audio-visual objects. MP4 file format", ISO/IEC ISO/IEC 14496- 14:2003, October 2003.
[IEC14496-14]「情報技術。オーディオビジュアルオブジェクトのコーディング。MP4ファイル形式」、ISO/IEC ISO/IEC 14496- 14：2003、2003年10月。
[MRCPv2] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol Version 2 (MRCPv2)", Work in Progress, November 2008.
[MRCPV2] Shanmugham、S。およびD. Burnett、「メディアリソース制御プロトコルバージョン2（MRCPV2）」、2008年11月、進行中の作業。
[RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190, September 1997.
[RFC2190] Zhu、C。、「H.263ビデオストリームのRTPペイロード形式」、RFC 2190、1997年9月。
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[RFC3960] Camarillo、G。およびH. Schulzrinne、「セッション開始プロトコル（SIP）の初期メディアとリンギングトーン生成」、RFC 3960、2004年12月。
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[RFC3969] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）の数字権機関（IANA）ユニフォームリソース識別子（URI）パラメーターレジストリ」、BCP 99、RFC 3969、2004年12月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240] Burger、E.、van Dyke、J。、およびA. Spitzer、「SIP付きベーシックネットワークメディアサービス」、RFC 4240、2005年12月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359] Johnston、A.、Sparks、R.、Cunningham、C.、Donovan、S。、およびK. Summers、「セッション開始プロトコルサービスの例」、BCP 144、RFC 5359、2008年10月。
[TS23002] "3rd Generation Partnership Project: Network architecture (Release 6)", 3GPP TS 23.002 v6.6.0, December 2004.
[TS23002]「第3世代パートナーシッププロジェクト：ネットワークアーキテクチャ（リリース6）」、3GPP TS 23.002 V6.6.0、2004年12月。
[TS26244] "Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244 v6.4.0, December 2004.
[TS26244]「透明なエンドツーエンドパケットスイッチ型ストリーミングサービス（PSS）; 3GPPファイル形式（3GP）」、3GPP TS 26.244 V6.4.0、2004年12月。
We make a "downref" normative reference to [RFC4627] -- an Informational document describing a proprietary (but extremely popular) format.
[RFC4627]への「DownRef」規範的参照を作成します。これは、独自の（しかし非常に人気のある）形式を説明する情報文書です。
Authors' Addresses
著者のアドレス
Dave Burke Google Belgrave House, 76 Buckingham Palace Road London SW1W 9TQ United Kingdom
デイブバークグーグルベルグレイブハウス、76バッキンガムパレスロードロンドンSW1W 9TQイギリス
EMail: daveburke@google.com
Mark Scott Genesys 1120 Finch Avenue West, 8th floor Toronto, Ontario M3J 3H7 Canada
マークスコットジェネシーズ1120フィンチアベニューウェスト、8階トロント、オンタリオM3J 3H7カナダ
EMail: Mark.Scott@genesyslab.com