Network Working Group D. Burke
Request for Comments: 5552 Google
Category: Standards Track M. Scott
Genesys
May 2009
SIP Interface to VoiceXML Media Services
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
このドキュメントは、VoiceXMLのメディアサービスへのSIPインタフェースを記述します。一般的に、メディアサーバーを制御するアプリケーションサーバは、純粋のVoiceXML処理能力のために、このプロトコルを使用しています。このプロトコルは、完全なMEDIACTRLプロトコルとパッケージメカニズムの補助です。
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）キー入力の認識、音声の録音を備え、オーディオとビデオのダイアログを作成するための標準的なワールド・ワイド・ウェブ・コンソーシアム（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.
このドキュメントは、VoiceXMLのメディアサービスへのSIP [RFC3261]インタフェースについて説明します。一般的に、メディアサーバーを制御するアプリケーションサーバは、純粋のVoiceXML処理能力のために、このプロトコルを使用しています。 SIPは、VoiceXMLのメディアサーバーにメディア・セッションを開始し、同時に指定されたVoiceXMLアプリケーションの実行をトリガする責任があります。このプロトコルは、完全なMEDIACTRLプロトコルとパッケージメカニズムの補助です。
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.
Application Serverはまた、HTTPをサポートして仮定すると、VoiceXMLアプリケーションは、その上にホストされ、HTTP [RFC2616]を経由してまで提供することができます。ウェブモデルはVoiceXMLアプリケーションは、本明細書を介してVoiceXMLのメディアサーバと相互作用（SIP）アプリケーションサーバから別（HTTP）アプリケーションサーバ上でホストされることを可能にすること、しかし、注意してください。静的VoiceXMLアプリケーションを動的挙動が要求される場合にウェブ/アプリケーションサーバーと対話するためのVoiceXML 2.1 [VXML21 <データ>メカニズムを活用する、VoiceXMLのメディアサーバ上にローカルに格納することも可能です。静的VoiceXMLアプリケーションの生存率は、さらにアプリケーションサーバーは、VoiceXMLのセッション・コンテキスト内のセッション固有の情報を利用可能にすることができ、それを通して、セクション2.4で定義されたメカニズムによって強化されます。
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.
この文書で説明するアプローチは、時々「委任モデル」と呼ばれる - Application Serverは、本質的にVoiceXMLのメディアサーバー上で実行している1つ以上のVoiceXMLドキュメントへのヒューマン・マシン・インタラクションのプログラムで制御を委任されます。人間と機械との対話中に、Application Serverは、シグナリングパスに残り、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ダイアログの起動と終了を超えて、REFER使用して着信転送のために定義された意味論が標準と互換性があることが意図されている、既存の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).
3GPP（3rd Generation Partnership Project）の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アーキテクチャに関して説明されるが、3GPP IMS規格に収束さ3GPP2、次世代ネットワーク（NGN）、およびPacketCableアーキテクチャにも適用可能であることが意図されます。
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.
1.0 [CCXML10]のアプリケーションは主に接続、会議、およびダイアログの間の相互作用を制御することにより、サービスを提供するコントロール拡張マークアップ言語（CCXML）を呼び出します。 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.
本書では説明インターフェイスはVoiceXMLのメディアサーバーを制御するCCXML 1.0実装で使用することができます。いくつかの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.
IPベースの構内交換機/自動着信呼分配（PBX / ACD）の補助としてVoiceXMLのメディアサーバーの1.は、おそらくボイスメール/メッセージング、自動応答、または他の機能を提供します。
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セッションを終了させることによって、特に、サービスを実行します。 Application Serverは、メディアサーバとの相互作用に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のメディアサーバー：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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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リクエスト-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のMedia Serverは、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の初期のVoiceXML文書のURIを取得します。これは通常、HTTP URIが含まれていますが、ローカル、静的VoiceXMLドキュメントを参照するために、例えば、他のURIスキームを使用することができます。 「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：VoiceXMLドキュメントと一緒にキャッシュ制御ヘッダのMAXAGE値を設定するために使用する[RFC2616]に従って、HTTPを使用してフェッチ。省略した場合、VoiceXMLのMedia Serverはデフォルト値を使用します。
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：VoiceXMLドキュメントと一緒にキャッシュ制御ヘッダーのmaxstale値を設定するために使用する[RFC2616]に従って、HTTPを使用してフェッチ。省略した場合、VoiceXMLのMedia Serverはデフォルト値を使用します。
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： "ポスト" 要求（またはそうでなければ無視される）のためのアプリケーション/ x-www-form-urlencodedでエンコードされた[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：「JSON値」session.connection.aaiのVoiceXMLセッション変数にマッピングされている[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).
他のアプリケーション固有のパラメータは、Request-URIに追加することができるとの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には固定ユーザー部「ダイアログ」を持っています。七個の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]
ダイアログ-PARAM = "のVoiceXML =" VXML-URL; VXML-urlはURIに従います。 [RFC3986] MAXAGE-PARAM = "MAXAGE =" 1 * DIGITのmaxstale-PARAM = "maxstale =" 1 * DIGIT方法-PARAM = "メソッド="（ "GET" / "POST"）postbody-PARAMに定義された構文= " postbody =」トークンCCXML-PARAM = "CCXML =" JSON値AAI-PARAM = "AAI =" JSON値JSON値=偽/ヌル/真/オブジェクト/配列/番号/文字列; [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.
その後の再のINVITE中のRequest-URIのパラメータは無視されます。このことの1つの結果は、VoiceXMLのMedia Serverが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.
ダイアログ-PARAM、postbody-PARAM、CCXML-PARAM、およびAAI-のparam値はURLエンコード例えば、SIP URI構文で必要とされる、（ "エスケープ"）でなければならないに含まれる特殊文字 '？' （％の3F）、 '='（％が3D）、および ';' （％の3B）。 VoiceXMLのMedia Serverは、したがって、それらを利用するか、VoiceXMLアプリケーションを実行するにそれらを暴露する前に、これらのパラメータ値をアンエスケープしなければなりません。希望のVoiceXML URI値自体は、たとえば、URLエンコードする可能性があるためVoiceXMLのMedia Serverは一度だけパラメータ値をエスケープ解除することが重要です。
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the sips: scheme as discussed in Section 9.
第9節で述べたようにスキーム：一部のアプリケーションでは、機密情報を転送することもできますので、VoiceXMLのMedia ServerはSIPをサポートしなければなりません。
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.
有益な注意：アプリケーション/ x-www-form-urlencodedでコンテンツ自体は％HH置換を挿入することにより、非英数字をエスケープするためpostbody-PARAM値に対して、上記エスケープルールがさらにある「％」文字をもたらすであろう「＆」と「=」の名前/値の区切りに加えて脱出しました。
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 Request-URIが最大エージング/ MAX-をフェッチする、初期VoiceXMLドキュメントとして「http://appserver.example.com/promptcollect.vxml」で、VoiceXMLのメディアサービスの利用を特定しますそれぞれ3600/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:
VoiceXMLのセッションは、SIP INVITEを使用して、アプリケーション・サーバーを経由して開始されます。一般的に、Application Serverは、VoiceXMLのサービスを提供に特化されます。最低でも、アプリケーションサーバは、Request-URIを書き換えることにより、単純なプロキシとして振る舞うことのRequest-URIのVoiceXMLメディアサーバー（セクション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:
Application Serverは、ののRequest-URIとVoiceXMLのメディアサーバー上のディレクトリアシスタントアプリケーションにマップすることを：
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のメディアサーバーへのINVITEメッセージ内の特定のヘッダ値は、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.
INVITEを受信すると、VoiceXMLのMedia Serverは、暫定応答を発行し100はしようと、初期VoiceXMLドキュメントのフェッチを開始します。 200 OK応答は、VoiceXMLドキュメントがフェッチされ、正しく解析され、実行のための準備ができていることを示しています。アプリケーションの実行は、（セクション2.3で指定されたダイアログが準備されている場合を除く）、ACKを受信したときに始まります。 100 Trying応答は、通常、VoiceXMLのMedia Serverが初期フェッチすることを一般保証に200ミリ秒未満で完了しますことができないので、[RFC3261]に従って、INVITEの受信時に送信されることに注意してください。しかし、特定の実装では、最初のINVITEへの応答時間を保証することができるかもしれので、100 Trying応答を送信する必要はないかもしれません。
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:
VoiceXMLのMedia Serverは、任意のSIPユーザエージェントのように、さまざまな理由のためのINVITE要求を受け入れることができない場合があります。例えば、INVITEに含まれるセッション記述プロトコル（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.リクエスト-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.
要求URIでURIパラメータが繰り返された場合2.は、その要求は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.要求URIが「VoiceXMLの」パラメータを含んでいない、とVoiceXMLのMedia Serverは、デフォルトのページを使用することを選択しない場合は、VoiceXMLのMedia Serverは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サーバ内部エラーの最終的な応答を返す必要があり、399の3桁のコードと人間が読めるエラーメッセージで警告ヘッダを含むべきです。
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).
有益な注意：特定のアプリケーションが要求URIパラメータの形式でVoiceXMLダイアログに大量のデータを渡すことができます。これは、INVITE要求の合計サイズが基盤となるネットワークのMTUを超過する可能性があります。このような場合、アプリケーション/実装のいずれか世話をしなければならない（例えばTCPのような）これらのより大きなメッセージに適切なトランスポートを使用するか（例えば、初期に一意のセッション識別子を供給するようにVoiceXMLダイアログに必要な情報を渡すことの代替手段を使用することHTTPサーバーからデータを取得するための鍵として、その識別子を使用してVoiceXMLのURI以降）。
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セッションを準備することが有益です。先に調製したVoiceXMLセッションは、そうするように指示された場合、最小限の遅延で実行することが期待されます。
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.
メディアレスSIPダイアログはVoiceXMLのMedia Serverに最初のINVITEで確立されている場合は、VoiceXMLアプリケーションは、ACKの受信後に実行されません。 VoiceXMLアプリケーションを実行するには、アプリケーションサーバ（AS）は、メディアセッションを確立するために、INVITE再発行する必要があります。
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ダイアログは、INVITE初期にはメディア行を含まないSDPを送信することによって確立することができます。何SDPが最初のINVITEに送信されない場合は別の方法として、VoiceXMLのMedia Serverは0に設定され、メディアポート（複数可）とACKでの回答で応答することができます200 OKメッセージで提供が含まれます。
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アプリケーションが実行されると、再INVITEことは、メディアストリーム（すなわち、0にポートを設定する）それ以外（メディアストリームが無効になっている間に開始という認識アクションがNOINPUTタイムアウトになります除く）で実行されるアプリケーションには影響しません無効にします。
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：SIP URIに評価をするには指定された初期のヘッダは、INVITE。
session.connection.remote.uri: Evaluates to the SIP URI specified in the From: header of the initial INVITE.
session.connection.remote.uri：初期のヘッダ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：この配列は、最初のINVITEに履歴-INFO [RFC4244]のヘッダに含まれる情報によって移入またはそうでなければ不定です。履歴-Infoヘッダ内の各エントリ（HI-エントリ）はsession.connection.redirect配列の要素に、逆の順序で、マッピングされています。次のようにアレイの各素子の特性が決定されます。
* uri - Set to the hi-targeted-to-uri value of the History-Info entry
* URI - 歴史 - インフォメーションエントリーのHI-対象-に-URIの値に設定
* pi - Set to 'true' if hi-targeted-to-uri contains a "Privacy=history" parameter, or if the INVITE Privacy header includes 'history'; 'false' otherwise
*パイ - HI-対象-に-URIは「プライバシー=歴史」のパラメータが含まれている場合、またはプライバシーヘッダーを招待した場合は「歴史」を含む「真」に設定します。そうでない場合は「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
*理由 - HI-対象-に-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を介してアクセスまたは手順をSIPSれたかどうかを区別しないことに留意されたいです。
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ヘッダの非コンパクト名で小文字に変換INVITE連想配列は、（ケース変換はヘッダ値には適用されない注意され）。同じフィールド名の複数のヘッダフィールドが存在する場合、値が単一のカンマ区切り値に結合されます。実装は、最低限のCall-IDヘッダを含まなければならないし、他のヘッダを含むかもしれません。例えば、session.connection.protocol.sip.headersは、[ "Call-IDを"]はSIPダイアログのコール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：これは配列のキーと値が初期のリクエストURIは、SIP INVITEにURIパラメータから形成される連想配列です。配列のキーは、小文字に変換URIパラメータ名（パラメータ値には適用されない場合の変換に注意してください）です。対応する配列の値がCCXML-PARAMとAAI-PARAM値の場合には、それ以外の文字列として「JSON値」[RFC4627]をURIパラメータ値を評価することによって得られます。また、アレイのtoString（）関数は、完全なSIPリクエストURIを返します。例えば、SIPのリクエストURIを想定：ダイアログ@ example.com、VoiceXMLの= HTTP：//example.com; AAI =％7B "X"：1％2C "Y"：真％7dを次にsession.connectionを。 protocol.sip.requesturi [ "VoiceXMLは"]に "http://example.com"、session.connection.protocol.sip.requesturi [ "AAI"]。xは1（種別番号）に評価、session.connectionを評価します。 protocol.sip.requesturi [ "AAI"] yは真（Boolean型）と評価され、session.connection.protocol.sip.requesturiは完全な要求URI（String型）「一口に評価されます。ダイアログ@ example.com。 VoiceXMLの= HTTP：//example.com; AAI = { "X"：1、 "Y"：真}」。
session.connection.aai: Evaluates to session.connection.protocol.sip.requesturi["aai"].
session.connection.aaiは：[ "AAI"] session.connection.protocol.sip.requesturiに評価されます。
session.connection.ccxml: Evaluates to session.connection.protocol.sip.requesturi["ccxml"].
session.connection.ccxmlは：[ "CCXMLを"] session.connection.protocol.sip.requesturiに評価されます。
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に対する媒体の方向性を示します。定義された値は、sendonlyで、がrecvonly、および非アクティブSENDRECVです。
* 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.
*フォーマット： - このプロパティはオプションです。定義されている場合、プロパティの値が配列です。各配列要素には、メディアの一の形式（Mラインの各ペイロードタイプの配列要素がある）に関する情報を指定するオブジェクトです。オブジェクトは、その値（MIMEサブタイプは、[RFC4855]に登録されている）メディアフォーマットのMIMEサブタイプである「名前」と呼ばれる少なくとも1つの特性を含んでいます。他のプロパティは、文字列値で定義することができます。これらは、フォーマットの必要と、定義されている場合、オプションのパラメータに対応します。
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線に対するsession.connection.protocol.sip.mediaの配列エントリがあります。 VoiceXMLのセッションのためのメディアセッションの特性が変更された場合、このセッション変数が更新されることに注意してください（起因する、すなわち再INVITE）。例えば、8 kHzでサンプリングされた双方向とG.711 mu-law、「オーディオ」との接続を考慮してください。この場合、session.connection.protocol.sip.media [0] .TYPEは、 "オーディオ"、session.connection.protocol.sip.media [0] .directionに "SENDRECV"、session.connection.protocol.sip評価します.media [0] [0] .nameのが "オーディオ/ PCMU" を、評価.formatとsession.connection.protocol.sip.media [0] [0] .rateが評価.format "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上記定義session.connection.protocol.sip.requesturi連想配列を介してSIPヘッダーとRequest-URIパラメータにアクセスする場合、アプリケーションは、配列に言及二意味的に同等の方法の間で選択できることに注意してください。たとえば、次のいずれかが「foo」という名前の要求URIパラメータにアクセスするために使用することができます。
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ヘッダ名またはリクエストURIパラメータ名が有効なECMAScript識別子であり、そのようなものとして、最初のフォーム（配列表記）を使用してアクセスすることができることに留意することが重要です。例えば、コールIDヘッダのみ[「Call-IDを」] session.connection.protocol.sip.headersとしてアクセスすることができます。 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セッションのコンテキストでBYEを受信すると、VoiceXMLのメディアサーバーは、200 OK応答を送らなければなりませんし、VoiceXMLアプリケーションに「connection.disconnect.hangup」イベントをスローする必要があります。 Reasonヘッダ[RFC3326]はBYE要求に存在する場合、Reasonヘッダの値は、キャッチ要素の匿名の可変範囲「_Message」変数を介してそのまま提供されます。
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のMedia Serverはまた、BYE要求を発行することによって、セッションの終了を開始することができます。これは、典型的に、または起因VoiceXMLアプリケーション内の未処理のエラーのために完了するまで実行による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セッションを設定するApplication Serverを示しています。
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行及びoffer2からラインを複製します。 0しかしインクリメントバージョン番号：ANSWER1に使用されるように、それは同じOラインを含まなければならないので、offer2' はoffer2異なります。 offer1がoffer2以上メートルラインを持っている場合も、その後、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.
メディアリソース制御プロトコル（MRCP）は[MRCPv2】このような音声合成、認識装置、検証、およびネットワーク上のサーバに存在する識別子としてのメディアサービスリソースを制御するために、このようなVoiceXMLのメディアサーバーなどのクライアントを可能にするプロトコルです。
The example below illustrates how a VoiceXML Media Server may establish an MRCP session in response to an initial INVITE.
以下の例では、VoiceXMLのMedia Serverが初期INVITEに応じて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は前に最初のINVITEに対する200 OK応答を送信するMRCPv2メディアリソースサーバとのセッションを確立する責任があります。 VoiceXMLのMedia Serverは、Application ServerとMRCPv2メディアリソースサーバのSDP機能に基づいてMRCPv2メディアリソースサーバとの適切なオファー/アンサーを実行します。によって指定された各MRCPv2リソースが使用され、他の必要なSDP修正するためにVoiceXMLのメディアサーバーは、m行を含むように（5）の工程でMRCPv2セッションを確立するために、ステップ1から受信したオファーを変更し、SDPを再度書き込みますMRCPv2。 VoiceXMLのMedia ServerはMRCPv2メディアリソースサーバとのオファー/アンサーを実行したら、それはステップでMRCPv2制御チャネルを確立します（8）。 VoiceXMLのメディアサーバーが受信またはBYE（図示せず）を送信するときMRCPv2リソースの割り当てが解除されます。
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のMedia Serverは、[RFC3264]の標準オファー/アンサー・メカニズムをサポートしなければなりません。 SDPオファーがINVITE中に存在していない場合は特に、VoiceXMLのMedia Serverは、サポートされるコーデックをリスト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のMedia Serverは、メディアストリームの早期確立をサポートするかもしれません。これは、Application Serverが（データベースや他のシステムとダイナミックの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]は、ゲートウェイのモデルよりも早いメディアのApplication Serverモデルを使用することを好むが、ゲートウェイモデルとの主な問題 - フォークは - VoiceXMLのメディアサーバーへのリクエストを発行する際に大幅にあまり一般的です。 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 Application Serverの場合は、上記ステップ10で4XXレスポンスを返すように、または提供のVoiceXMLコンテンツが有効でなかった場合、VoiceXMLのメディアサーバーが（2.2節に従って）500応答を返すことになるました。この時点で、メディアサーバとの間で確立任意のメディアストリームを取り壊すためにアプリケーションサーバの責任になります。
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のメディアサーバは、メディアセッション再INVITEと同じ目的のためにUPDATEメソッド[RFC3311]をサポートすべきである介して変更することを許容しなければなりません。特に、sendonlyで、がrecvonly [RFC3264]で指定されるように、SENDRECV間ストリームを変更することが可能でなければなりません。
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).
単方向ストリームはannouncement-やリスニング専用（ホットワード）のために便利です。保留中のメディアセッションを置くための好ましい機構はすなわち、UAはsendonlyのするストリームを修正し、独自のストリームをミュート、[RFC3264]で指定されています。メディアセッションの変更は、（NOINPUTタイムアウトになり保留しながら、開始という認識アクションを除く）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.
相互運用性の基本的なレベルを達成するために、このセクションでは、VoiceXMLのメディアサーバーでサポートしなければならないコーデックおよび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ようなマルチメディアファイルコンテナフォーマットの使用を介してのVoiceXML 2.0 / 2.1が可能である[TS26244]とのMP4フォーマット[IEC14496-14]。ビデオのサポートは、この仕様ではオプションです。ビデオはその後、サポートされている場合：
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]はサポートされる必要があります。
4. MPEG-4 Advanced Audio Coding (AAC) audio [RFC3016] SHOULD be supported.
4. MPEG-4アドバンストオーディオコーディング（AAC）オーディオ[RFC3016]はサポートされる必要があります。
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のメディアサーバーによって実行されるビデオレコード操作は、通常、イントラフレームの受信を必要としています。 VoiceXMLのメディアサーバは、新たなイントラフレームを送信することを要求するために[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.
一部のアプリケーションでは、機密情報を転送することを選択することができるので、セクション9で説明したように、VoiceXMLのメディアサーバは、セキュア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のMedia Serverは、オーディオストリームでDTMFトーンを検出するなど、他の手段を使用してDTMF検出を行うことができます。実装上の注意：ユーザー・エージェントは、それのサポートがオーディオストリーム上での検出が同時に適用された場合にはDTMFの二重検出のリスクを避けるためであることを示しているときのみ、[RFC4733]電話のイベントを使用しなければならない理由。
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メディアサーバからデータ（例えば、収集された発話または数字情報）を返すための機構を議論します。
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アプリケーションの実行中はいつでも、データは、<提出>または<サブダイアログ>などの標準のVoiceXML要素を使用してHTTP経由でアプリケーションサーバに戻すことができます。特に、VoiceXMLの2.1 <データ>要素は[VXML21】データの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セッションとHTTPを介して渡される情報を相関させる必要があります。これを達成することができる一つの方法は、アクセス可能でSIPコールIDを（含めることです
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 POSTフィールド内session.connection.protocol.sip.headersアレイを介してボイスXML）。代替的に、独自の「POSTバックURI」のRequest-URI初期INVITE（session.connection.protocol.sip.requesturiアレイを介してボイスXMLでアクセス）の中にアプリケーション固有のURIパラメータとして指定することができます。
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the https: scheme as discussed in Section 9.
第9節で述べたようにスキーム：一部のアプリケーションでは、機密情報を転送することもできますので、VoiceXMLのMedia Serverは、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).
データは<終了>または<切断>の名前リスト属性の式exprまたは名前リスト属性を経由してアプリケーションサーバに戻すことができます。 VoiceXMLのメディアサーバは、<終了>または<切断>要素に遭遇した結果として、VoiceXMLのメディアサーバから送信されたBYE要求のメッセージボディにはexpr /名前リストデータの符号化をサポートしなければなりません。 VoiceXMLのMedia Serverは、VoiceXMLアプリケーションがconnection.disconnect.hangupイベントに応答し、その後実行する受信BYE要求（すなわち、に応答して200 OKメッセージのメッセージボディにはexpr /名前リストデータの包含をサポートするかもしれ<指定された式exprまたは名前リスト属性を持つ終了>要素）。
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応答式/名前リストのデータを送信することはVoiceXMLアプリケーションのポスト切断、最終的な処理状態が終了するまでのVoiceXML Media Serverが受け取ったBYE要求への最終応答を遅らせることを必要とすることに注意してください。このメカニズムは、VoiceXMLのMedia Serverがエージェントクライアント（UACの）タイマFは（32秒デフォルト）有効期限が切れる前にユーザー応答しなければならないという制約を受けています。また、信頼性の低いトランスポートのために、UACは、[RFC3261]のルールに従って、BYE要求を再送します。 BYE要求に100試みる暫定応答を送信する際のVoiceXML Media Serverは、[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アプリケーションが<切断が> [VXML21]、その後名前リスト情報と<終了>を実行する実行した場合、<出口>から名前リスト情報要素が破棄されます。
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.
ネームリスト変数は、最初にその「JSON値」等価[RFC4627]に変換され、[HTML4]アプリケーション/ x-www-form-urlencoded形式のコンテンツタイプを使用して、メッセージ本体に符号化されます。名前リストまたは循環参照とのECMAScriptオブジェクトに記録変数を指定から生じる挙動が定義されていません。 exprの属性は、<終了>要素の代わりに、名前リスト属性に指定されている場合は、予約名__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.
アプリケーションサーバは、<出口>から生じる1つから<切断>から生じるBYEを区別できるようにするために、予約名__reasonは、<VoiceXMLの者の使用を反映するように（括弧なし）「切断」の値が、使用されています切断>要素、およびVoiceXML文書において明示<出口に（括弧なし）「出口」>の値。セッションが（このようなエラーに遭遇したメディアサーバーのような）他の理由のために終了した場合、このパラメータは省略されてもよい、または下線が付いプラットフォーム固有の値をとることができます。
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.
この仕様では、アプリケーション/ HH大文字進数を表す％HHで置換順番に各オクテットと、文字のUTF-8表現の一つ以上のオクテットで非ASCII文字を置換することによって、x-www-form-urlencodedで延びていますオクテット値と％のための表記はリテラル文字です。その結果、式expr /名前リストデータを含むBYEメッセージのContent-Typeヘッダフィールドには、アプリケーション/ x-www-form-urlencodedでに設定しなければならない;のcharset = UTF-8。
The following table provides some examples of <exit> usage and the corresponding result content.
以下の表は、<終了>使用し、対応する結果の内容のいくつかの例を提供します。
+----------------------------------------------------------------+
|<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"/>
...
If id equals 1234 and pin equals 9999, say, the BYE message would look similar to:
idは1234に等しく、ピンが9999に等しい場合は、たとえば、BYEメッセージは次のようになります。
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
BYEのSIP：user@pc33.example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.4;ブランチ= z9hG4bKnashds10マックス・フォワード：70から：SIP：dialog@example.com;タグ= a6c85cfへ：SIP：ユーザー@ example.com;タグは= 1928301774のCall-ID：a84b4c76e66710のCSeq：231 BYEコンテンツタイプ：application / x-www-form-urlencodedで;のcharset = UTF-8のContent-Length：30
id=1234&pin=9999&__reason=exit
ID = 1234＆ピン= 9999＆__理由=終了
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.
一部のアプリケーションでは、機密情報を転送することを選択することができるので、セクション9で説明したように、VoiceXMLのメディアサーバは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.
コールが遅延を経験して呼び出し先を回避するために配置される前に、VoiceXMLアプリケーションのVoiceXMLのMedia Serverと準備1.選択が発生する可能性があります。
2. Avoidance of timing difficulties that could occur with other flows due to the time taken to fetch and parse the initial VoiceXML document.
初期VoiceXMLドキュメントをフェッチし、解析するのにかかった時間のために他のフローで発生する可能性があり、タイミングの難しさの2回避。
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の着信転送機能を使用することが推奨されていません。むしろ、それ自体がデータに基づいて、シグナリング行動をとることで、コールルーティング機能を提供することができApplication Serverは、HTTPを介して、またはSIP BYEメッセージにVoiceXMLのメディアサーバーから、それに戻りました。
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 < - >ボイスXMLで定義されているすべての転送タイプをサポートするために、双方向イベンティングの形態の密結合を必要と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ダイアログにREFERメッセージ[RFC3515]を経由してVoiceXMLのメディアサーバーによって開始されます。 DESTまたはdestexpr VoiceXMLの<転送>タグに属性を経由して指定されている参照してください-Toヘッダーは、被呼側のための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.
REFER要求が受け入れられた場合、VoiceXMLのMedia Serverは2xx応答を受け取ることになります。その場合には、VoiceXMLのMedia Serverはconnection.disconnect.transferイベントを投げると、BYEメッセージでのVoiceXMLセッションを終了します。ブラインド転送の場合、実装は、REFERメッセージに関連付けられた暗黙的加入を抑制するために、[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応答して、要求の結果を参照する場合、<転写>のフォーム項目変数（またはイベント隆起）が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).
例は（明確にするために省略されている暫定的な応答と暫定応答に対応するNOTIFYメッセージ）を以下に示します。
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属性は、<転送>上に存在する場合、それが参照してください-にURI REFERメソッドで「AAI」という名前のパラメータとして追加されます。 SIP / SIPS URIを[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のメディアサーバー、および呼び出し先を含む小型マルチパーティセッションの作成になります。 VoiceXMLのMedia Serverは、セッションへの呼び出し先を招待し、転送が終了した場合に呼び出し先が排出されます。
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属性は、<転送>上に存在する場合は、名前のURIパラメータとしてINVITE「AAI」でのRequest-URIに追加されます。 SIP / SIPS URIを[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属性で指定された音声がtransferaudio属性が省略されている場合、早期メディアが発信者に呼び出し先から受信し再生することができるユーザエージェント1. A VoiceXMLのメディアサーバーにストリーミングされます。
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のメディアサーバー（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.
最終応答が（<転送>の属性として指定）INVITEとのconnecttimeoutの有効期限が切れるからユーザーエージェント2から受信されていない場合は、VoiceXMLのMedia Serverはトランザクションと<転送>のフォーム項目を終了するにはCANCELを発行します。変数が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.
非2XX応答結果をINVITE場合、<転写>の（上昇またはイベント）フォーム項目変数は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のMedia Serverは、スピーチやDTMFのホットワードを実行するためにユーザエージェント1からのメディアストリームを「聞く」ことができ、VoiceXMLのMedia ServerはにBYEを発行します通話時間は、<転送>上MAXTIME属性で指定された最大期間を超えた場合、ユーザーエージェント1. A BYEもユーザーエージェント2に発行されるとユーザーエージェント2とVoiceXMLアプリケーションは継続します。
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は、転送中にBYEを発行した場合、転送が終了し、VoiceXMLの<転送>のフォーム項目変数は値far_end_disconnectを受けます。ユーザエージェント1は、転送中にBYEを発行した場合、転送が終了し、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）で混合されていないことを除いて、ブリッジの転送と同じ流れで始まり、error.unsupported.transfer.consultationはerror.unsupported.transfer.bridgeに取って代わります。 （暫定的な応答に対応する暫定応答とNOTIFYメッセージを明確にするために省略されている）以下に示すように、ユーザエージェント2との新たなSIPダイアログが作成されると仮定すると、配列の残りは以下の通りです。打診転送のように置き換えを使用する：ユーザエージェント1は、エージェント2ユーザーを呼び出し、呼び出し元と呼び出し先の間に新しいSIPダイアログとVoiceXMLのメディアサーバーで、後者のSIPダイアログを置き換えるヘッダー[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に送信されたREFERリクエストに応答して受信された場合、転送が終了し、error.unsupported.transfer.consultationイベントが発生します。また、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メッセージ本体とNOTIFYメッセージは、転送終了をもたらすであろうと、関連するVoiceXMLの入力項目変数が「不明」に設定されています。この機構の結果として、実装が相談転送のためREFERメッセージに関連付けられた暗黙的加入を抑制するために、[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.オーバーン（Voxeo社）、ジェフHaynie（Hakano）、スコットMcGlashan（ヒューレット・パッカード）の寄与を認識したいです。
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.ローゼンバーグ、P. Mataga、およびD.ラッド著、「VoiceXMLのダイアログ・サーバーへのSIPインタフェース」にその起源を負っています。次の人は、現在のドキュメントへの入力を持っていました：
R. J. Auburn (Voxeo)
R. J.オーバーン（Voxeo社）
Hans Bjurstrom (Hewlett-Packard)
彼のBjurstrøm（ヒューレット・パッカード）
Emily Candell (Comverse)
エミリーCandell（コンバース）
Peter Danielsen (Lucent)
ピーターDanielsen（ルーセント）
Brian Frasca (Tellme)
ブライアン・フラスカ（Tellmeの）
Jeff Haynie (Hakano)
ジェフnyní（まだ）
Scott McGlashan (Hewlett-Packard)
スコットMcGlashan（ヒューレット・パッカード）
Matt Oshry (Tellme)
マット・Oshry（Tellmeの）
Rao Surapaneni (Tellme)
ラオSurapaneni（Tellmeの）
The authors would like to acknowledge the support of Cullen Jennings and the Mediactrl chairs, Eric Burger and Spencer Dawkins.
著者は、カレンジェニングスとMediactrlチェア、エリックバーガーとスペンサードーキンスの支援を承認したいと思います。
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メッセージ本文のエンコーディングに加えて、スキーム：およびhttps：データの機密性を提供するために、VoiceXMLのメディアサーバーは、SIPを実装しなければなりません。
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のMedia Serverは、（RTCP制御トラフィックを含む）RTPメディアストリームの機密性、認証、および再生保護を提供するために、セキュア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は、SIPに次のパラメータを登録している/ [RFC3969]の仕様が必要で政策以下、URIパラメータのレジストリをSIPS：
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.、ル・オードブル、A.、およびI.ジェイコブス、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]菊池、Y.、野村、T.、福永、S.、松井、Y.、およびH.木全、 "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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、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.、オラン、D.、およびG.カマリロ、RFC 3326 "セッション開始プロトコル（SIP）理由ヘッダーフィールド" 2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、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.、フレデリック、R.、およびV.ヤコブソン、 "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.、マグリュー、D.、Naslund、M.、カララ、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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]マーイ、R.、ビッグス、B.、およびR.ディーン、 "セッション開始プロトコル（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]バーナーズ - リー、T.、フィールディング、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]バーンズ、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]スパークス、R.、RFC 4320、2006年1月 "セッション開始プロトコル（SIP）非INVITEトランザクションと特定された問題への対処アクション"。
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006.
[RFC4488]レヴィン、O.、RFC 4488、2006年5月 "セッション開始プロトコル（SIP）の抑制は、メソッドの暗黙の契約をREFER"。
[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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル」、RFC 4585、2006年7月。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627]クロックフォード、D.、RFC 4627、2006年7月 "JavaScriptのObject Notation（JSON）形式のためのアプリケーション/ JSONのメディアタイプ"。
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. Even, "RTP Payload Format for ITU-T Rec", RFC 4629, January 2007.
でも、[RFC4629]オット、H.、ボルマン、C.、サリバン、G.、ウェンガー、S.、およびR.、 "ITU-T勧告のためのRTPペイロードフォーマット"、RFC 4629、2007年1月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733] Schulzrinneと、H.、およびT.テイラー、 "DTMFケタ、電話トーン、およびテレフォニーシグナルのためのRTPペイロード"、RFC 4733、2006年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。
[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.、ウェスター、M.、Lakaniemi、A.、およびQ.謝、「RTPペイロード形式と適応マルチレート（AMR）と適応マルチレート広帯域（AMR-WBのためのストレージ・ファイル形式）オーディオコーデック」、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.、バーネット、D.、カーター、J.、Danielsen、P.、Ferrans、J.、ハント、A.、ルーカス、B.、ポーター、B.、Rehor、K.、およびS 。Tryphonas、 "音声拡張マークアップ言語（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.、オーバーン、R J.、Baggia、P.、Bodell、M.、バーク、D.、バーネット、D.、Candell、E.、Kilic、H.、McGlashan、S.、リー、A.、ポーター、B.、およびK. Rehor、 "音声拡張マークアップ言語（VoiceXMLの）バージョン2.1"、W3C勧告候補、2005年6月。
[CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version 1.0", W3C Working Draft, June 2005.
[CCXML10]オーバーン、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.バーネット、 "メディアリソース制御プロトコルバージョン2（MRCPv2）"、進歩、2008年11月での作業。
[RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190, September 1997.
[RFC2190]朱、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]キャマリロ、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]キャマリロ、G.、BCP 99、RFC 3969、2004月 "セッション開始プロトコル（SIP）のための番号機関（IANA）のURI（Uniform Resource Identifier）パラメータレジストリの割り当てインターネット"。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]バーガー、E.、ヴァン・ダイク、J.、およびA.スピッツァー、 "SIPを使用した基本的なネットワークメディアサービス"、RFC 4240、2005年12月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359]ジョンストン、A.、スパークス、R.、カニンガム、C.、ドノバン、S.、およびK.サマーズ、 "セッション開始プロトコルサービス例"、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月に。
Appendix A. Notes on Normative References
引用規格の付録A.ノート
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
デイブ・バークGoogleのベルグレイヴハウス、76バッキンガムパレスロードロンドンSW1W 9TQイギリス
EMail: daveburke@google.com
メールアドレス：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
メールアドレス：Mark.Scott@genesyslab.com