Network Working Group J. Rosenberg
Request for Comments: 5629 Cisco Systems
Category: Standards Track October 2009
A Framework for Application Interaction
in the Session Initiation Protocol (SIP)
Abstract
抽象
This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi-Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework.
この文書は、ユーザーおよびセッション開始プロトコル（SIP）ベースのアプリケーション間の相互作用のためのフレームワークについて説明します。アプリケーションと相互作用することにより、ユーザーは、それらが動作する方法を導くことができます。このフレームワークの焦点は、ユーザエージェント（UA）は、そのアプリケーションのセマンティクスの知識なしにアプリケーションと対話することを可能にする刺激シグナルです。刺激信号は、メディアストリームを介して、クライアントにローカルに実行するユーザーインターフェース、または遠隔ユーザインターフェースに発生する可能性があります。刺激信号は、従来のデュアルトーン多重周波数（DTMF）入力に、押しボタンに、ハイパーリンクをクリックすることに至るまで、機構の広い範囲を包含する。すべての場合において、刺激シグナル伝達は、この枠組みの中で重要な役割を果たしているマークアップ言語の使用によってサポートされています。
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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow
この材料の一部がIETFトラストを許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいです
modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
IETF標準化過程外部ような材料の変形。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. A Model for Application Interaction . . . . . . . . . . . . . 7
4.1. Functional vs. Stimulus . . . . . . . . . . . . . . . . . 9
4.2. Real-Time vs. Non-Real-Time . . . . . . . . . . . . . . . 10
4.3. Client-Local vs. Client-Remote . . . . . . . . . . . . . . 10
4.4. Presentation-Capable vs. Presentation-Free . . . . . . . . 11
5. Interaction Scenarios on Telephones . . . . . . . . . . . . . 11
5.1. Client Remote . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Client Local . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 13
7. Deployment Topologies . . . . . . . . . . . . . . . . . . . . 16
7.1. Third-Party Application . . . . . . . . . . . . . . . . . 16
7.2. Co-Resident Application . . . . . . . . . . . . . . . . . 17
7.3. Third-Party Application and User Device Proxy . . . . . . 18
7.4. Proxy Application . . . . . . . . . . . . . . . . . . . . 19
8. Application Behavior . . . . . . . . . . . . . . . . . . . . . 19
8.1. Client-Local Interfaces . . . . . . . . . . . . . . . . . 20
8.1.1. Discovering Capabilities . . . . . . . . . . . . . . . 20
8.1.2. Pushing an Initial Interface Component . . . . . . . . 20
8.1.3. Updating an Interface Component . . . . . . . . . . . 22
8.1.4. Terminating an Interface Component . . . . . . . . . . 22
8.2. Client-Remote Interfaces . . . . . . . . . . . . . . . . . 23
8.2.1. Originating and Terminating Applications . . . . . . . 23
8.2.2. Intermediary Applications . . . . . . . . . . . . . . 24
9. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 24
9.1. Advertising Capabilities . . . . . . . . . . . . . . . . . 24
9.2. Receiving User Interface Components . . . . . . . . . . . 25
9.3. Mapping User Input to User Interface Components . . . . . 26
9.4. Receiving Updates to User Interface Components . . . . . . 27
9.5. Terminating a User Interface Component . . . . . . . . . . 27
10. Inter-Application Feature Interaction . . . . . . . . . . . . 27
10.1. Client-Local UI . . . . . . . . . . . . . . . . . . . . . 28
10.2. Client-Remote UI . . . . . . . . . . . . . . . . . . . . . 29
11. Intra Application Feature Interaction . . . . . . . . . . . . 29
12. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . . 37
The Session Initiation Protocol (SIP) [2] provides the ability for users to initiate, manage, and terminate communications sessions. Frequently, these sessions will involve a SIP application. A SIP application is defined as a program running on a SIP-based element (such as a proxy or user agent) that provides some value-added function to a user or system administrator. Examples of SIP applications include prepaid calling card calls, conferencing, and presence-based [12] call routing.
セッション開始プロトコル（SIP）は、[2]ユーザーは、開始、管理、および通信セッションを終了するための能力を提供します。多くの場合、これらのセッションは、SIPアプリケーションを伴います。 SIPアプリケーションは、ユーザまたはシステム管理者にいくつかの付加価値機能を提供する（例えば、プロキシやユーザエージェントのような）SIPベース要素上で動作するプログラムとして定義されます。 SIPアプリケーションの例としては、プリペイドコーリングカード通話、会議、およびプレゼンスベース[12]コールルーティングを含みます。
In order for most applications to properly function, they need input from the user to guide their operation. As an example, a prepaid calling card application requires the user to input their calling card number, their PIN code, and the destination number they wish to reach. The process by which a user provides input to an application is called "application interaction".
ほとんどのアプリケーションが正しく機能するためには、彼らは彼らの操作をガイドするために、ユーザからの入力を必要とします。例として、プリペイドカードのアプリケーションは、入力彼らのコーリングカード番号、そのPINコード、および彼らが到達したい宛先番号にユーザーが必要です。ユーザがアプリケーションに入力を提供するプロセスは、「アプリケーションとの対話」と呼ばれます。
Application interaction can be either functional or stimulus. Functional interaction requires the user device to understand the semantics of the application, whereas stimulus interaction does not. Stimulus signaling allows for applications to be built without requiring modifications to the user device. Stimulus interaction is the subject of this framework. The framework provides a model for how users interact with applications through user interfaces, and how user interfaces and applications can be distributed throughout a network. This model is then used to describe how applications can instantiate and manage user interfaces.
アプリケーションの相互作用は、機能や刺激のいずれかになります。機能的相互作用は、刺激の相互作用がない一方で、アプリケーションの意味を理解するために、ユーザ装置が必要です。アプリケーションは、ユーザデバイスへの変更を必要とせずに構築するための刺激シグナルを可能にします。刺激の相互作用は、このフレームワークの主題です。フレームワークは、ユーザがユーザインタフェースを介してアプリケーションと対話する方法、およびユーザ・インターフェースとアプリケーションがネットワーク全体に分散させることができる方法のためのモデルを提供します。このモデルは、その後のアプリケーションは、ユーザ・インタフェースをインスタンス化して管理する方法を記述するために使用されます。
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 [1]
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されるべき
SIP Application: A SIP application is defined as a program running on a SIP-based element (such as a proxy or user agent) that provides some value-added function to a user or system administrator. Examples of SIP applications include prepaid calling card calls, conferencing, and presence-based [12] call routing.
SIPアプリケーション：SIPアプリケーションがユーザまたはシステム管理者にいくつかの付加価値機能を提供する（例えば、プロキシやユーザエージェントのような）SIPベース要素上で動作するプログラムとして定義されます。 SIPアプリケーションの例としては、プリペイドコーリングカード通話、会議、およびプレゼンスベース[12]コールルーティングを含みます。
Application Interaction: The process by which a user provides input to an application.
アプリケーションの相互作用：ユーザがアプリケーションに入力を提供するプロセス。
Real-Time Application Interaction: Application interaction that takes place while an application instance is executing. For example, when a user enters their PIN number into a prepaid calling card application, this is real-time application interaction.
リアルタイムアプリケーションの相互作用：アプリケーションの相互作用アプリケーション・インスタンスの実行中に行われます。ユーザーはプリペイドカードアプリケーションに自分のPIN番号を入力したときに、例えば、これはリアルタイムアプリケーションの相互作用です。
Non-Real-Time Application Interaction: Application interaction that takes place asynchronously with the execution of the application. Generally, non-real-time application interaction is accomplished through provisioning.
非リアルタイムアプリケーションの相互作用：アプリケーションの実行とは非同期に行われるアプリケーションの相互作用。一般的に、非リアルタイムアプリケーションとの相互作用は、プロビジョニングを介して行われます。
Functional Application Interaction: Application interaction is functional when the user device has an understanding of the semantics of the interaction with the application.
機能アプリケーションの相互作用：ユーザデバイスがアプリケーションとの相互作用の意味の理解を持っている場合、アプリケーションの相互作用が機能しています。
Stimulus Application Interaction: Application interaction is stimulus when the user device has no understanding of the semantics of the interaction with the application.
刺激印加の相互作用：ユーザデバイスがアプリケーションとの相互作用の意味のない理解を持っていないときに、アプリケーションの相互作用が刺激です。
User Interface (UI): The user interface provides the user with context to make decisions about what they want. The user interacts with the device, which conveys the user input to the user interface. The user interface interprets the information and passes it to the application.
ユーザーインターフェイス（UI）：ユーザーインターフェースは、彼らが望むものについての意思決定を行うためにコンテキストをユーザに提供します。ユーザは、ユーザインターフェースへのユーザ入力を伝達デバイスと相互作用します。ユーザインターフェースは、情報を解釈し、アプリケーションに渡します。
User Interface Component: A piece of user interface that operates independently of other pieces of the user interface. For example, a user might have two separate web interfaces to a prepaid calling card application: one for hanging up and making another call, and another for entering the username and PIN.
ユーザインタフェース・コンポーネント：独立したユーザインターフェースの他の部分の操作するユーザインタフェースの一部。ユーザ名とPINを入力するためのハングアップし、別の呼び出しを行うための1、および他：たとえば、ユーザーは、2つの別々のウェブプリペイドカードアプリケーションへのインタフェースを持っているかもしれません。
User Device: The software or hardware system that the user directly interacts with to communicate with the application. An example of a user device is a telephone. Another example is a PC with a web browser.
ユーザ装置：ユーザが直接アプリケーションと通信すると対話するソフトウェアまたはハードウェアシステム。ユーザ装置の例は電話です。別の例は、ウェブブラウザを搭載したPCです。
User Device Proxy: A software or hardware system that a user indirectly interacts through to communicate with the application. This indirection can be through a network. An example is a gateway from IP to the Public Switched Telephone Network (PSTN). It acts as a user device proxy, acting on behalf of the user on the circuit network.
ユーザデバイスプロキシ：ユーザが間接的アプリケーションと通信するために介して対話するソフトウェアまたはハードウェアシステム。この間接は、ネットワークを介して行うことができます。例は、電話網（PSTN）公衆にIPゲートウェイからです。これは、回路網上のユーザのために行動する、ユーザデバイスのプロキシとして動作します。
User Input: The "raw" information passed from a user to a user interface. Examples of user input include a spoken word or a click on a hyperlink.
ユーザー入力：ユーザインタフェースに、ユーザから渡された「生」の情報。ユーザー入力の例としては、話し言葉やハイパーリンクをクリックします。
Client-Local User Interface: A user interface that is co-resident with the user device.
クライアントのローカルユーザインタフェース：ユーザデバイスとの共存であるユーザーインターフェース。
Client-Remote User Interface: A user interface that executes remotely from the user device. In this case, a standardized interface is needed between the user device and the user interface. Typically, this is done through media sessions: audio, video, or application sharing.
クライアントのリモートユーザインタフェース：ユーザ装置からリモート実行するユーザインタフェース。この場合には、標準化されたインタフェースは、ユーザデバイスとユーザインタフェースとの間に必要とされます。オーディオ、ビデオ、またはアプリケーション共有：通常、これは、メディアセッションを介して行われます。
Markup Language: A markup language describes a logical flow of presentation of information to the user, collection of information from the user, and transmission of that information to an application.
マークアップ言語：マークアップ言語は、利用者、利用者からの情報の収集、およびアプリケーションへの情報の送信に情報の提示の論理的な流れを説明しています。
Media Interaction: A means of separating a user and a user interface by connecting them with media streams.
メディアインタラクション：メディアストリームとそれらを接続することで、ユーザーとユーザー・インターフェースを分離する手段。
Interactive Voice Response (IVR): An IVR is a type of user interface that allows users to speak commands to the application, and hear responses to those commands prompting for more information.
対話型音声応答（IVR）：IVRは、ユーザーがアプリケーションにコマンドを話す、そしてより多くの情報の入力を求めるこれらのコマンドへの応答を聞くことができますユーザ・インタフェースのタイプです。
Prompt-and-Collect: The basic primitive of an IVR user interface. The user is presented with a voice option, and the user speaks their choice.
プロンプト・アンド・コレクト：IVRユーザインタフェースの基本的なプリミティブ。ユーザーは、音声オプションを提示し、ユーザーが自分の好みを話すされます。
Barge-In: The act of entering information into an IVR user interface prior to the completion of a prompt requesting that information.
バージイン：事前にその情報を要求するプロンプトが完了するIVRユーザインターフェースに情報を入力する行為。
Focus: A user interface component has focus when user input is provided to it, as opposed to any other user interface components. This is not to be confused with the term "focus" within the SIP conferencing framework, which refers to the center user agent in a conference [14].
フォーカス：ユーザ・インターフェース・コンポーネントは、他のユーザ・インターフェース・コンポーネントとは対照的に、ユーザ入力が、それに提供されたときにフォーカスがあります。これは、会議に中心のユーザエージェントを指すSIP会議フレームワーク、[14]内の用語「フォーカス」と混同されるべきではありません。
Focus Determination: The process by which the user device determines which user interface component will receive the user input.
フォーカス決意：ユーザ装置は、ユーザ入力を受け取るどのユーザインタフェースコンポーネントを判断するプロセス。
Focusless Device: A user device that has no ability to perform focus determination. An example of a focusless device is a telephone with a keypad.
Focuslessデバイス：フォーカス決意を実行する能力を持っていないユーザ装置。 focuslessデバイスの例は、キーパッドとの電話です。
Presentation-Capable UI: A user interface that can prompt the user with input, collect results, and then prompt the user with new information based on those results.
プレゼンテーション可能なUI：、入力をユーザに促す結果を収集し、それらの結果に基づいて、新たな情報をユーザに促すことができるユーザインタフェース。
Presentation-Free UI: A user interface that cannot prompt the user with information.
プレゼンテーションフリーUI：情報をユーザーにプロンプトを表示することができないユーザーインターフェース。
Feature Interaction: A class of problems that result when multiple applications or application components are trying to provide services to a user at the same time.
機能の相互作用：複数のアプリケーションまたはアプリケーション・コンポーネントが同時に利用者にサービスを提供しようとしているときに生じる問題のクラス。
Inter-Application Feature Interaction: Feature interactions that occur between applications.
アプリケーション間の機能の相互作用：アプリケーション間で起こる機能の相互作用。
DTMF: Dual-Tone Multi-Frequency. DTMF refers to a class of tones generated by circuit-switched telephony devices when the user presses a key on the keypad. As a result, DTMF and keypad input are often used synonymously, when in fact one of them (DTMF) is merely a means of conveying the other (the keypad input) to a client-remote user interface (the switch, for example).
DTMF：デュアルトーン多重周波数。 DTMFは、ユーザがキーパッド上のキーを押したときに回線交換テレフォニーデバイスによって生成されたトーンのクラスを指します。実際には、それら（DTMF）の一つは、単にクライアントのリモートユーザインタフェース（例えばスイッチ）に（キーパッド入力）他の搬送手段である場合、結果として、DTMFキーパッド入力は、多くの場合、同義的に使用されます。
Application Instance: A single execution path of a SIP application.
アプリケーションインスタンス：SIPアプリケーションの単一の実行パス。
Originating Application: A SIP application that acts as a User Agent Client (UAC), making a call on behalf of the user.
元のアプリケーション：ユーザーに代わって電話をかける、ユーザエージェントクライアント（UAC）として動作するSIPアプリケーションです。
Terminating Application: A SIP application that acts as a User Agent Server (UAS), answering a call generated by a user. IVR applications are terminating applications.
終了アプリケーション：ユーザエージェントサーバ（UAS）として動作するSIPアプリケーション、ユーザーによって生成されたコールに答えます。 IVRアプリケーションは、アプリケーションを終了しています。
Intermediary Application: A SIP application that is neither the caller or callee, but rather a third party involved in a call.
中間アプリケーション：発信者または呼び出し先ではなく、コールに関与第三者でもないSIPアプリケーション。
+---+ +---+ +---+ +---+
| | | | | | | |
| | | U | | U | | A |
| | Input | s | Input | s | Results | p |
| | ---------> | e | ---------> | e | ----------> | p |
| U | | r | | r | | l |
| s | | | | | | i |
| e | | D | | I | | c |
| r | Output | e | Output | f | Update | a |
| | <--------- | v | <--------- | a | <.......... | t |
| | | i | | c | | i |
| | | c | | e | | o |
| | | e | | | | n |
| | | | | | | |
+---+ +---+ +---+ +---+
Figure 1: Model for Real-Time Interactions
図1：リアルタイムの相互作用のためのモデル
Figure 1 presents a general model for how users interact with applications. Generally, users interact with a user interface through a user device. A user device can be a telephone, or it can be a PC with a web browser. Its role is to pass the user input from the user to the user interface. The user interface provides the user with context in order to make decisions about what they want. The user interacts with the device, causing information to be passed from the device to the user interface. The user interface interprets the information, and passes it as a user interface event to the application. The application may be able to modify the user interface based on this event. Whether or not this is possible depends on the type of user interface.
図1は、ユーザーがアプリケーションと対話する方法のための一般的なモデルを提示します。一般的に、ユーザは、ユーザデバイスを介してユーザ・インターフェースと対話します。ユーザ装置は、電話することができ、またはそれは、Webブラウザを搭載したPCすることができます。その役割は、ユーザインタフェースに、ユーザからのユーザ入力を渡すことです。ユーザーインターフェースは、彼らが望むものについての決定を行うためのコンテキストをユーザに提供します。ユーザ情報は、ユーザインタフェースに装置から渡される原因と、デバイスと相互作用します。ユーザインターフェースは、情報を解釈し、アプリケーションへのユーザインタフェースイベントとして渡します。アプリケーションは、このイベントに基づいて、ユーザインタフェースを変更することができるかもしれません。これが可能であるかどうかは、ユーザーインターフェースの種類によって異なります。
User interfaces are fundamentally about rendering and interpretation. Rendering refers to the way in which the user is provided context. This can be through hyperlinks, images, sounds, videos, text, and so on. Interpretation refers to the way in which the user interface takes the "raw" data provided by the user, and returns the result to the application as a meaningful event, abstracted from the particulars of the user interface. As an example, consider a prepaid calling card application. The user interface worries about details such as what prompt the user is provided, whether the voice is male or female, and so on. It is concerned with recognizing the speech that the user provides, in order to obtain the desired information. In this case, the desired information is the calling card number, the PIN code, and the destination number. The application needs that data, and it doesn't matter to the application whether it was collected using a male prompt or a female one.
ユーザー・インターフェースは、レンダリングおよび解釈については基本的にしています。レンダリングは、ユーザがコンテキストを提供される方法を指します。これには、ハイパーリンク、画像、サウンド、ビデオ、テキスト、およびを介して行うことができます。解釈は、ユーザインタフェースは、ユーザによって提供される「生」データを取得する方法を参照し、ユーザインタフェースの詳細から抽出意味のあるイベントとしてアプリケーションに結果を返します。例として、プリペイドカードのアプリケーションを考えてみます。このようユーザーに促したものと内容についてのユーザインターフェースの心配は声がそうで男性か女性、そしてあるかどうか、提供されます。これは、ユーザが所望の情報を得るために、提供音声認識に関するものです。この場合には、所望の情報は、コーリングカード番号、PINコード、および宛先番号です。アプリケーションは、そのデータを必要とし、それが男性プロンプトまたは女性のいずれかを使用して収集されたかどうかのアプリケーションには関係ありません。
User interfaces generally have real-time requirements towards the user. That is, when a user interacts with the user interface, the user interface needs to react quickly, and that change needs to be propagated to the user right away. However, the interface between the user interface and the application need not be that fast. Faster is better, but the user interface itself can frequently compensate for long latencies between the user interface and the application. In the case of a prepaid calling card application, when the user is prompted to enter their PIN, the prompt should generally stop immediately once the first digit of the PIN is entered. This is referred to as "barge-in". After the user interface collects the rest of the PIN, it can tell the user to "please wait while processing". The PIN can then be gradually transmitted to the application. In this example, the user interface has compensated for a slow UI to application interface by asking the user to wait.
ユーザー・インタフェースは、一般ユーザーに向けたリアルタイム要件を持っています。すなわち、ユーザは、ユーザインターフェースと対話する際に、ユーザーインターフェースは、迅速に対応する必要があり、その変更はすぐにユーザーに伝播する必要があります。しかし、ユーザーインターフェースとアプリケーション間のインタフェースは、高速である必要はありません。高速優れているが、ユーザインタフェース自体は、しばしばユーザインターフェースとアプリケーションとの間の長い待ち時間を補償することができます。ユーザーが自分のPINを入力するように指示されたプリペイドコーリングカードのアプリケーションの場合は、プロンプトは、一般的にPINの最初の数字が入力されたら、すぐに停止する必要があります。これは「バージ・イン」と呼ばれています。ユーザーインターフェースは、PINの残りの部分を収集した後、それが「処理中にお待ちください」するようにユーザーに伝えることができます。 PINは徐々にアプリケーションに送信することができます。この例では、ユーザインタフェースは、待機するようにユーザに求めることによって、アプリケーション・インターフェースに遅いUIを補償しています。
The separation between user interface and application is absolutely fundamental to the entire framework provided in this document. Its importance cannot be overstated.
ユーザーインターフェースとアプリケーションとの間の分離は、この文書で提供さ全体フレームワークに絶対基本です。その重要性は誇張することはできません。
With this basic model, we can begin to taxonomize the types of systems that can be built.
この基本的なモデルでは、我々を構築することができるシステムの種類をtaxonomizeし始めることができます。
The first way to taxonomize the system is to consider the interface between the UI and the application. There are two fundamentally different models for this interface. In a functional interface, the user interface has detailed knowledge about the application and is, in fact, specific to the application. The interface between the two components is through a functional protocol, capable of representing the semantics that can be exposed through the user interface. Because the user interface has knowledge of the application, it can be optimally designed for that application. As a result, functional user interfaces are almost always the most user friendly, the fastest, and the most responsive. However, in order to allow interoperability between user devices and applications, the details of the functional protocols need to be specified in standards. This slows down innovation and limits the scope of applications that can be built.
システムをtaxonomizeする最初の方法は、UIとアプリケーションとの間のインターフェースを考慮することです。このインターフェイスには2つの根本的に異なるモデルがあります。機能インタフェースでは、ユーザインターフェースは、アプリケーションに関する知識を詳述しており、実際には、アプリケーションに固有です。 2つの構成要素間のインターフェースは、機能的なプロトコルを介してユーザインタフェースを介して露光することができる意味を表すことが可能です。ユーザーインターフェースは、アプリケーションの知識を持っているので、それが最適なそのアプリケーションのために設計することができます。その結果、機能的なユーザーインターフェイスは、ほとんどの場合、ほとんどのユーザーフレンドリーな、最速、そして最も応答性です。ただし、ユーザーデバイスとアプリケーション間の相互運用性を可能にするために、機能のプロトコルの詳細については、標準規格で指定する必要があります。これは、技術革新の速度が低下して構築することができるアプリケーションの範囲を制限します。
An alternative is a stimulus interface. In a stimulus interface, the user interface is generic -- that is, totally ignorant of the details of the application. Indeed, the application may pass instructions to the user interface describing how it should operate. The user interface translates user input into "stimulus", which are data understood only by the application, and not by the user interface. Because they are generic, and because they require communications with the application in order to change the way in which they render information to the user, stimulus user interfaces are usually slower, less user friendly, and less responsive than a functional counterpart. However, they allow for substantial innovation in applications, since no standardization activity is needed to build a new application, as long as it can interact with the user within the confines of the user interface mechanism. The web is an example of a stimulus user interface to applications.
代替は、刺激のインタフェースです。刺激インターフェースでは、ユーザインタフェースは、汎用である - 、アプリケーションの詳細を全く無知です。実際に、アプリケーションは、それが動作すべき方法を記述するユーザ・インターフェースに命令を渡すことができます。ユーザインタフェースは、ユーザインタフェースによってのみアプリケーションによって理解データ、およびない「刺激」にユーザ入力を変換します。彼らは一般的なものであり、彼らは、ユーザーに情報をレンダリングする方法を変更するために、アプリケーションとの通信を必要とするため、刺激のユーザインタフェースは、通常はあまりユーザーフレンドリー、かつ機能的対応よりも少ない応答性の遅いので。何の標準化活動は、それがユーザ・インタフェース機構の範囲内でユーザと対話することができます限り、新しいアプリケーションを構築するために必要としないので、しかし、彼らは、アプリケーションの大幅な技術革新を可能にします。ウェブアプリケーションに刺激ユーザインタフェースの一例です。
In SIP systems, functional interfaces are provided by extending the SIP protocol to provide the needed functionality. For example, the SIP caller preferences specification [15] provides a functional interface that allows a user to request applications to route the call to specific types of user agents. Functional interfaces are important, but are not the subject of this framework. The primary goal of this framework is to address the role of stimulus interfaces to SIP applications.
SIPシステムでは、機能的なインターフェイスは、必要な機能を提供するために、SIPプロトコルを拡張することによって提供されます。例えば、SIP発信者プリファレンス仕様[15]ユーザがルートにユーザエージェントの特定タイプの呼び出しをアプリケーションが要求することを可能にする機能のインターフェースを提供します。機能インタフェースが重要であるが、このフレームワークの対象ではありません。このフレームワークの主な目標は、SIPアプリケーションへの刺激のインターフェースの役割を対処することです。
Application interaction systems can also be real-time or non-real-time. Non-real-time interaction allows the user to enter information about application operation asynchronously with its invocation. Frequently, this is done through provisioning systems. As an example, a user can set up the forwarding number for a call-forward on no-answer application using a web page. Real-time interaction requires the user to interact with the application at the time of its invocation.
アプリケーションの相互作用システムは、リアルタイムまたは非リアルタイムことができます。非リアルタイムの相互作用は、ユーザーがその呼び出しと非同期アプリケーションの操作に関する情報を入力することができます。しばしば、これは、プロビジョニング・システムを介して行われます。例として、ユーザは、Webページを使用して無応答アプリケーションのコールフォワードのための転送番号を設定することができます。リアルタイムの相互作用は、その呼び出し時にアプリケーションと対話するためにユーザが必要となります。
Another axis in the taxonomization is whether the user interface is co-resident with the user device (which we refer to as a client-local user interface), or the user interface runs in a host separated from the client (which we refer to as a client-remote user interface). In a client-remote user interface, there exists some kind of protocol between the client device and the UI that allows the client to interact with the user interface over a network.
taxonomizationにおける別の軸は、ユーザインタフェースは、（我々は、クライアントのローカルユーザインターフェースと呼ぶ）は、ユーザ装置との共存で、又はユーザーインターフェースは、我々はと呼ぶクライアント（から分離ホストで実行されるかどうかでありますクライアント・リモート・ユーザー・インターフェース）。クライアント・リモート・ユーザ・インターフェースにおいて、クライアント装置と、クライアントがネットワークを介してユーザインターフェースと対話できるようにするUIの間のプロトコルのいくつかの種類が存在します。
The most important way to separate the UI and the client device is through media interaction. In media interaction, the interface between the user and the user interface is through media: audio, video, messaging, and so on. This is the classic mode of operation for VoiceXML [5], where the user interface (also referred to as the voice browser) runs on a platform in the network. Users communicate with the voice browser through the telephone network (or using a SIP session). The voice browser interacts with the application using HTTP to convey the information collected from the user.
UIおよびクライアント・デバイスを分離するための最も重要な方法は、メディアの相互作用を介してです。ように、オーディオ、ビデオ、メッセージング：メディアインタラクションでは、ユーザーとユーザー・インターフェースとの間のインタフェースは、メディアを通じてです。これは、（また、音声ブラウザと呼ぶ）は、ユーザ・インターフェースは、ネットワーク内のプラットフォーム上で動作するのVoiceXML [5]のための動作の古典的なモードです。ユーザは、電話網を介して音声ブラウザと通信する（またはSIPセッションを使用して）。音声ブラウザは、ユーザーから収集した情報を伝えるためにHTTPを使用してアプリケーションと対話します。
In the case of a client-local user interface, the user interface runs co-located with the user device. The interface between them is through the software that interprets the user's input and passes it to the user interface. The classic example of this is the Web. In the Web, the user interface is a web browser, and the interface is defined by the HTML document that it's rendering. The user interacts directly with the user interface running in the browser. The results of that user interface are sent to the application (running on the web server) using HTTP.
クライアントローカルユーザインタフェースの場合、ユーザインターフェースは、ユーザデバイスと同じ場所に配置走ります。それらの間のインタフェースは、ユーザの入力を解釈し、ユーザーインターフェースに渡しソフトウェアです。この古典的な例は、Webです。ウェブでは、ユーザー・インターフェースは、Webブラウザで、インターフェイスは、それがレンダリングのHTML文書で定義されています。ユーザーがブラウザで実行しているユーザーインターフェースと直接対話します。そのユーザインタフェースの結果は、HTTPを使用して（ウェブサーバ上で実行されている）アプリケーションに送信されます。
It is important to note that whether or not the user interface is local or remote (in the case of media interaction) is not a property of the modality of the interface, but rather a property of the system. As an example, it is possible for a Web-based user interface to be provided with a client-remote user interface. In such a scenario, video- and application-sharing media sessions can be used between the user and the user interface. The user interface, still guided by HTML, now runs "in the network", remote from the client. Similarly, a VoiceXML document can be interpreted locally by a client device, with no media streams at all. Indeed, the VoiceXML document can be rendered using text, rather than media, with no impact on the interface between the user interface and the application.
ユーザインタフェースは、（メディア相互作用の場合）ローカルまたはリモートであるか否かインターフェイスのモダリティの性質ではなく、システムの特性ではないことに留意することが重要です。一例として、これは、クライアントのリモートユーザインタフェースを提供するWebベースのユーザインタフェースのために可能です。そのようなシナリオでは、ビデオ - およびアプリケーション共有メディアセッションは、ユーザとユーザインタフェースとの間で使用することができます。まだHTMLによって導かれたユーザー・インターフェースは、現在リモートクライアントから、「ネットワークに」実行されます。同様に、VoiceXML文書は全くメディアストリームと、クライアントデバイスによってローカルに解釈することができます。実際、VoiceXMLドキュメントは、ユーザインタフェースとアプリケーションとの間の界面に影響を与えずに、むしろメディアよりも、テキストを使用してレンダリングすることができます。
It is also important to note that systems can be hybrid. In a hybrid user interface, some aspects of it (usually those associated with a particular modality) run locally, and others run remotely.
システムがハイブリッドでできることに注意することも重要です。ハイブリッドユーザインタフェースに、それのいくつかの局面（特にモダリティに関連した通常のもの）をローカルで実行し、他のものは、リモートで実行します。
A user interface can be capable of presenting information to the user (a presentation-capable UI), or it can be capable only of collecting user input (a presentation-free UI). These are very different types of user interfaces. A presentation-capable UI can provide the user with feedback after every input, providing the context for collecting the next input. As a result, presentation-capable user interfaces require an update to the information provided to the user after each input. The Web is a classic example of this. After every input (i.e., a click), the browser provides the input to the application and fetches the next page to render. In a presentation-free user interface, this is not the case. Since the user is not provided with feedback, these user interfaces tend to merely collect information as it's entered, and pass it to the application.
ユーザインタフェースは、ユーザ（プレゼンテーション可能なUI）に情報を提示することが可能であることができる、又はそれは、ユーザ入力（プレゼンテーションフリーUI）を収集することが可能であることができます。これらは、ユーザーインターフェースの非常に異なる種類があります。プレゼンテーション可能なUIは、次の入力を収集するためのコンテキストを提供し、すべての入力後、フィードバックをユーザに提供することができます。結果として、提示できるユーザ・インターフェースは、各入力後にユーザに提供される情報の更新を必要とします。ウェブは、この古典的な例です。すべての入力（すなわち、クリック）した後、ブラウザがアプリケーションに入力を提供してレンダリングするために、次のページをフェッチします。プレゼンテーションのないユーザーインターフェースでは、このケースではありません。ユーザはフィードバックを備えていないので、これらのユーザインターフェースは、単にそれが入力されていますなどの情報を収集し、アプリケーションに渡す傾向があります。
Another difference is that a presentation-free user interface cannot easily support the concept of a focus. Selection of a focus usually requires a means for informing the user of the available applications, allowing the user to choose, and then informing them about which one they have chosen. Without the first and third steps (which a presentation-free UI cannot provide), focus selection is very difficult. Without a selected focus, the input provided to applications through presentation-free user interfaces is more of a broadcast or notification operation.
もう一つの違いは、プレゼンテーションのないユーザーインターフェースを簡単にフォーカスの概念をサポートすることができないということです。焦点の選択は通常、利用可能なアプリケーションをユーザに知らせる、ユーザが選択できるようにして、彼らが選択している1についてのそれらを知らせるための手段を必要とします。 （プレゼンテーションのないUIを提供することはできません）第一および第三のステップがなければ、焦点の選択は非常に困難です。選択された焦点ことなく、プレゼンテーションを含まないユーザインターフェースを介してアプリケーションに提供される入力は、ブロードキャストまたは通知動作の詳細です。
In this section, we apply the model of Section 4 to telephones.
このセクションでは、電話に第4のモデルを適用します。
In a traditional telephone, the user interface consists of a 12-key keypad, a speaker, and a microphone. Indeed, from here forward, the term "telephone" is used to represent any device that meets, at a minimum, the characteristics described in the previous sentence. Circuit-switched telephony applications are almost universally client-remote user interfaces. In the Public Switched Telephone Network (PSTN), there is usually a circuit interface between the user and the user interface. The user input from the keypad is conveyed using Dual-Tone Multi-Frequency (DTMF), and the microphone input as Pulse Code Modulated (PCM) encoded voice.
従来の電話では、ユーザインターフェースは、12キーのキーパッド、スピーカ、およびマイクロフォンから成ります。実際、ここから前方に、用語「電話」は、最低でも、前の文章に記載した特徴を満たす任意の装置を表すために使用されます。回線交換電話アプリケーションは、ほとんど例外なく、クライアントのリモートユーザインタフェースです。公衆交換電話網（PSTN）において、ユーザとユーザインターフェースとの間の回線インタフェースが通常存在します。キーパッドからのユーザ入力は、デュアルトーン多重周波数（DTMF）、パルス符号変調（PCM）符号化音声としてマイクロホン入力を使用して搬送されます。
In an IP-based system, there is more variability in how the system can be instantiated. Both client-remote and client-local user interfaces to a telephone can be provided.
IPベースのシステムでは、システムをインスタンス化することができる方法で、よりばらつきがあります。電話のクライアントのリモートクライアントとローカルユーザーインターフェイスの両方を提供することができます。
In this framework, a PSTN gateway can be considered a User Device Proxy. It is a proxy for the user because it can provide, to a user interface on an IP network, input taken from a user on a circuit-switched telephone. The gateway may be able to run a client-local user interface, just as an IP telephone might.
このフレームワークでは、PSTNゲートウェイは、ユーザデバイスプロキシと考えることができます。それは提供することができるので、IPネットワーク上のユーザインタフェースに、入力は、回線交換電話上のユーザから採取されたユーザの代理です。ゲートウェイは、単にIP電話かもしれませんが、クライアントのローカルユーザーインタフェースを実行することができるかもしれません。
The most obvious instantiation is the "classic" circuit-switched telephony model. In that model, the user interface runs remotely from the client. The interface between the user and the user interface is through media, which is set up by SIP and carried over the Real Time Transport Protocol (RTP) [18]. The microphone input can be carried using any suitable voice-encoding algorithm. The keypad input can be conveyed in one of two ways. The first is to convert the keypad input to DTMF, and then convey that DTMF using a suitable encoding algorithm (such as PCMU). An alternative, and generally the preferred approach, is to transmit the keypad input using RFC 4733 [19], which provides an encoding mechanism for carrying keypad input within RTP.
最も明白なインスタンス化は「クラシック」の回線交換電話モデルです。そのモデルでは、ユーザーインターフェイスは、クライアントからリモートで実行されます。ユーザとユーザインタフェースとの間のインターフェースは、SIPによって設定し、リアルタイムトランスポートプロトコル（RTP）[18]を介して搬送される媒体を介してです。マイク入力は、任意の適切な音声符号化アルゴリズムを使用して実施することができます。キーパッド入力は、2つの方法のいずれかで搬送することができます。最初は、DTMFキーパッド入力を変換し、その後、（例えばPCMUなど）の適切な符号化アルゴリズムを使用してそのDTMFを伝えることです。別の、そして一般的に好ましいアプローチは、RTP内のキーパッド入力を搬送するための符号化機構を提供するRFC 4733 [19]を使用して、キーパッド入力を送信することです。
In this classic model, the user interface would run on a server in the IP network. It would perform speech recognition and DTMF recognition to derive the user intent, feed them through the user interface, and provide the result to an application.
この古典的なモデルでは、ユーザー・インターフェースは、IPネットワーク内のサーバ上で実行します。これは、ユーザーの意図を導き出すのユーザインタフェースを介してそれらを養う、およびアプリケーションに結果を提供するために、音声認識とDTMF認識を実行することになります。
An alternative model is for the entire user interface to reside on the telephone. The user interface can be a VoiceXML browser, running speech recognition on the microphone input, and feeding the keypad input directly into the script. As discussed above, the VoiceXML script could be rendered using text instead of voice, if the telephone has a textual display.
ユーザーインターフェイス全体が電話に常駐するための代替モデルがあります。ユーザーインターフェースは、マイク入力に音声認識を実行し、スクリプトに直接キーパッド入力を供給し、VXMLブラウザとすることができます。上述のように電話がテキスト表示されている場合、VoiceXMLのスクリプトは、代わりに音声のテキストを使用してレンダリングすることができます。
For simpler phones without a display, the user interface can be described by a Keypad Markup Language request document [8]. As the user enters digits in the keypad, they are passed to the user interface, which generates user interface events that can be transported to the application.
表示せずに簡単電話のユーザインタフェースは、キーパッドマークアップ言語要求文書によって記述することができる[8]。ユーザは、キーパッドの桁に入ると、それらはアプリケーションに搬送することができるユーザインターフェースイベントを発生させるユーザインタフェースに渡されます。
A middle-ground approach is to flip back and forth between a client-local and client-remote user interface. Many voice applications are of the type that listen to the media stream and wait for some specific trigger that kicks off a more complex user interaction. The long pound in a prepaid calling card application is one example. Another example is a conference recording application, where the user can press a key at some point in the call to begin recording. When the key is pressed, the user hears a whisper to inform them that recording has started.
中間グランドアプローチは、クライアントのローカルおよびクライアントのリモートユーザインタフェースとの間で前後に反転することにあります。多くの音声アプリケーションは、メディアストリームに耳を傾け、より複雑なユーザインタラクションをキックオフいくつかの特定のトリガを待つタイプです。プリペイドカードのアプリケーションで長いポンドは一例です。別の例では、ユーザが録画を開始するための呼び出しの中でいくつかの点でキーを押すことができ、会議録音アプリケーションです。キーが押された場合、ユーザーは、録画が開始されたことを通知するためにささやきを聞きます。
The ideal way to support such an application is to install a client-local user interface component that waits for the trigger to kick off the real interaction. Once the trigger is received, the application connects the user to a client-remote user interface that can play announcements, collect more information, and so on.
そのようなアプリケーションをサポートするための理想的な方法は、実際の相互作用をキックオフするためのトリガを待つクライアントローカルユーザ・インターフェース・コンポーネントをインストールすることです。トリガが受信されると、アプリケーションはその上、アナウンスを再生するより多くの情報を収集し、できるクライアント・リモート・ユーザー・インターフェースにユーザーを接続します。
The benefit of flip-flopping between a client-local and client-remote user interface is cost. The client-local user interface will eliminate the need to send media streams into the network just to wait for the user to press the pound key on the keypad.
クライアントのローカルおよびクライアント・リモート・ユーザー・インターフェース間のフリップばたつきの利点はコストです。クライアントのローカルユーザーインターフェースは、単にキーパッド上のシャープキーを押して、ユーザーを待つためにネットワークへのメディアストリームを送信する必要がなくなります。
The Keypad Markup Language (KPML) was designed to support exactly this kind of need [8]. It models the keypad on a phone and allows an application to be informed when any sequence of keys has been pressed. However, KPML has no presentation component. Since user interfaces generally require a response to user input, the presentation will need to be done using a client-remote user interface that gets instantiated as a result of the trigger.
キーパッドのマークアップ言語（KPML）が必要[8]の、まさにこのようなものをサポートするように設計されました。それは携帯電話の機種のキーパッドをし、キーの任意のシーケンスが押されたときにアプリケーションに通知することができます。しかし、KPMLには、プレゼンテーション・コンポーネントを持っていません。ユーザインターフェースは、一般的にユーザ入力に応答を必要とするので、プレゼンテーションは、トリガの結果としてインスタンス化されますクライアントのリモートユーザインターフェースを使用して行われる必要があります。
It is tempting to use a hybrid model, where a prompt-and-collect application is implemented by using a client-remote user interface that plays the prompts, and a client-local user interface, described by KPML, that collects digits. However, this only complicates the application. Firstly, the keypad input will be sent to both the media stream and the KPML user interface. This requires the application to sort out which user inputs are duplicates, a process that is very complicated. Secondly, the primary benefit of KPML is to avoid having a media stream towards a user interface. However, there is already a media stream for the prompting, so there is no real savings.
数字を収集KPMLによって記載収集プロンプト・アンド・アプリケーションがプロンプトを果たし、クライアントのリモートユーザインターフェイスを使用して実現されるハイブリッドモデル、およびクライアントローカルユーザインタフェースを使用したくています。しかし、これが唯一のアプリケーションを複雑にしています。まず、キーパッド入力は、メディア・ストリームとKPMLのユーザインターフェースの両方に送られます。これは、入力が重複しているどのユーザー非常に複雑なプロセスを整理するためのアプリケーションが必要です。第二に、KPMLの主な利点は、ユーザインターフェースに向かってメディアストリームを回避することです。しかし、促すためのメディアストリームがすでに存在しているので、本当の節約はありません。
In this framework, we use the term "SIP application" to refer to a broad set of functionality. A SIP application is a program running on a SIP-based element (such as a proxy or user agent) that provides some value-added function to a user or system administrator. SIP applications can execute on behalf of a caller, a called party, or a multitude of users at once.
このフレームワークでは、我々は、機能の広範なセットを参照するために用語「SIPアプリケーション」を使用します。 SIPアプリケーションは、ユーザまたはシステム管理者にいくつかの付加価値機能を提供する（例えば、プロキシやユーザエージェントのような）SIPベース要素上で動作するプログラムです。 SIPアプリケーションは、発信者、被呼加入者、または一度に多数のユーザに代わって実行することができます。
Each application has a number of instances that are executing at any given time. An instance represents a single execution path for an application. It is established as a result of some event. That event can be a SIP event, such as the reception of a SIP INVITE request, or it can be a non-SIP event, such as a web form post or even a timer. Application instances also have an end time. Some instances have a lifetime that is coupled with a SIP transaction or dialog. For example, a proxy application might begin when an INVITE arrives, and terminate when the call is answered. Other applications have a lifetime that spans multiple dialogs or transactions. For example, a conferencing application instance may exist so long as there are dialogs connected to it. When the last dialog terminates, the application instance terminates. Other applications have a lifetime that is completely decoupled from SIP events.
各アプリケーションは、任意の時点で実行しているインスタンスの数を有しています。インスタンスは、アプリケーションのための単一の実行経路を表します。これは、いくつかのイベントの結果として確立されています。そのイベントは、SIPの受信INVITE要求のようなSIPイベントとすることができる、またはそれは、ウェブフォームポストあるいはタイマーなどの非SIPイベントとすることができます。アプリケーションインスタンスも終了時間を持っています。いくつかの例では、SIPトランザクションまたはダイアログに連結されている寿命を持っています。たとえば、プロキシアプリケーションは、INVITEが到着したときに始まり、コールが応答されたときに終了することがあります。他のアプリケーションは、複数のダイアログやトランザクションにまたがる寿命を持っています。例えば、会議アプリケーションインスタンスは、それに接続されたダイアログが存在する限り存在してもよいです。最後のダイアログが終了すると、アプリケーションインスタンスが終了します。他のアプリケーションは完全にSIPイベントから分離された寿命を持っています。
It is fundamental to the framework described here that multiple application instances may interact with a user during a single SIP transaction or dialog. Each instance may be for the same application, or different applications. Each of the applications may be completely independent, in that each may be owned by a different provider, and may not be aware of each other's existence. Similarly, there may be application instances interacting with the caller, and instances interacting with the callee, both within the same transaction or dialog.
これは、複数のアプリケーションインスタンスを単一のSIPトランザクションまたはダイアログの間にユーザと対話することをここで説明するフレームワークの基本です。各インスタンスは、同じアプリケーション、または異なる用途のためであってもよいです。アプリケーションのそれぞれは、それぞれが別のプロバイダによって所有され、互いの存在を認識しないかもしれないということで、完全に独立していてもよいです。同様に、両方とも同じトランザクションまたはダイアログ内で、被呼者と対話アプリケーションの発信者と対話インスタンス、およびインスタンスがあってもよいです。
The first step in the interaction with the user is to instantiate one or more user interface components for the application instance. A user interface component is a single piece of the user interface that is defined by a logical flow that is not synchronously coupled with any other component. In other words, each component runs independently.
ユーザとの対話の最初のステップは、アプリケーションインスタンスのための1つ以上のユーザインターフェースコンポーネントをインスタンス化することです。ユーザ・インターフェース・コンポーネントは、同期他のコンポーネントと結合されていない論理フローによって定義されたユーザインターフェースの単一片です。換言すれば、各成分が独立に実行されます。
A user interface component can be instantiated in one of the user agents in a dialog (for a client-local user interface), or within a network element (for a client-remote user interface). If a client-local user interface is to be used, the application needs to determine whether or not the user agent is capable of supporting a client-local user interface, and in what format. In this framework, all client-local user interface components are described by a markup language. A markup language describes a logical flow of presentation of information to the user, a collection of information from the user, and a transmission of that information to an application. Examples of markup languages include HTML, Wireless Markup Language (WML), VoiceXML, and the Keypad Markup Language (KPML) [8].
ユーザ・インターフェース・コンポーネントは、（クライアントローカルユーザインタフェースの場合）、またはネットワーク要素内（クライアントのリモートユーザインタフェースの場合）ダイアログのユーザエージェントのいずれかでインスタンス化することができます。クライアントローカルユーザインタフェースを使用する場合、アプリケーションは、ユーザエージェントは、クライアントのローカルユーザインタフェースをサポートすることができる、どのようなフォーマットであるか否かを判断する必要があります。このフレームワークでは、すべてのクライアント・ローカル・ユーザー・インターフェース・コンポーネントは、マークアップ言語で記述されています。マークアップ言語は、ユーザへの情報の提示の論理フローは、ユーザからの情報の収集、およびアプリケーションへの情報の伝達を記述する。マークアップ言語の例は、HTML、ワイヤレスマークアップ言語（WML）、ボイスXML、およびキーパッドマークアップ言語（KPML）[8]を含みます。
Unlike an application instance, which has a very flexible lifetime, a user interface component has a very fixed lifetime. A user interface component is always associated with a dialog. The user interface component can be created at any point after the dialog (or early dialog) is created. However, the user interface component terminates when the dialog terminates. The user interface component can be terminated earlier by the user agent, and possibly by the application, but its lifetime never exceeds that of its associated dialog.
非常に柔軟な寿命を有するアプリケーションインスタンスとは異なり、ユーザ・インターフェース・コンポーネントは、非常に固定された寿命を有します。ユーザ・インターフェース・コンポーネントは、常にダイアログに関連付けられています。ユーザ・インターフェース・コンポーネントが作成されるダイアログ（または早期ダイアログ）の後の任意の時点で作成することができます。ダイアログが終了したときただし、ユーザー・インタフェース・コンポーネントは終了します。ユーザ・インターフェース・コンポーネントは、ユーザーエージェントによって、そしておそらくアプリケーションにより早期に終了することができますが、その寿命は、その関連するダイアログのそれを超えることはありません。
There are two ways to create a client-local interface component. For interface components that are presentation capable, the application sends a REFER [7] request to the user agent. The Refer-To header field contains an HTTP URI that points to the markup for the user interface, and the REFER contains a Target-Dialog header field [10] which identifies the dialog associated with the user interface component. For user interface components that are presentation free (such as those defined by KPML), the application sends a SUBSCRIBE request to the user agent. The body of the SUBSCRIBE request contains a filter, which, in this case, is the markup that defines when information is to be sent to the application in a NOTIFY. The SUBSCRIBE does not contain the Target-Dialog header field, since equivalent information is conveyed in the Event header field.
クライアントのローカルインタフェースコンポーネントを作成するには、2つの方法があります。プレゼンテーション可能なインターフェース・コンポーネントは、アプリケーションは、ユーザエージェントを参照し[7]のリクエストを送信します。参照のために、ヘッダーフィールドは、ユーザインタフェースのためのマークアップを指すHTTP URIを含み、REFERユーザ・インターフェース・コンポーネントに関連付けられた対話を識別するターゲット対話ヘッダフィールド[10]を含んでいます。プレゼンテーションフリー（KPMLによって定義されたものなど）は、ユーザ・インターフェース・コンポーネントのために、アプリケーションは、ユーザエージェントにSUBSCRIBEリクエストを送信します。 SUBSCRIBEリクエストのボディには、この場合には、情報がNOTIFYアプリケーションに送信するときに定義するマークアップされたフィルタを含んでいます。同等の情報は、イベントヘッダフィールドで搬送されるので、ターゲット対話ヘッダフィールドを含んでいないSUBSCRIBE。
If a user interface component is to be instantiated in the network, there is no need to determine the capabilities of the device on which the user interface is instantiated. Presumably, it is on a device on which the application knows a UI can be created. However, the application does need to connect the user device to the user interface. This will require manipulation of media streams in order to establish that connection.
ユーザ・インターフェース・コンポーネントは、ネットワーク内でインスタンス化される場合、ユーザ・インターフェースがインスタンス化されたデバイスの機能を決定する必要はありません。おそらく、それは、アプリケーションがUIを作成することができます知っている上でデバイス上にあります。ただし、アプリケーションは、ユーザインタフェースにユーザデバイスを接続する必要がありません。これは、その接続を確立するために、メディアストリームの操作が必要になります。
The interface between the user interface component and the application depends on the type of user interface. For presentation-capable user interfaces, such as those described by HTML and VoiceXML, HTTP form POST operations are used. For presentation-free user interfaces, a SIP NOTIFY is used. The differing needs and capabilities of these two user interfaces, as described in Section 4.4, are what drives the different choices for the interactions. Since presentation-capable user interfaces require an update to the presentation every time user data is entered, they are a good match for HTTP. Since presentation-free user interfaces merely transmit user input to the application, a NOTIFY is more appropriate.
ユーザ・インターフェース・コンポーネントとアプリケーションとの間のインタフェースは、ユーザインタフェースの種類に依存します。このようなHTMLとのVoiceXMLによって記載されたものとして提示できるユーザ・インターフェースについては、HTTPフォームPOST操作が使用されています。プレゼンテーションフリーユーザインターフェースは、SIP NOTIFYが使用されます。セクション4.4で説明したように、これらの2つのユーザインターフェイスの異なるニーズ及び機能は、相互作用のための異なる選択肢を駆動するものです。プレゼンテーション対応のユーザーインターフェイスは毎回のユーザデータが入力されているプレゼンテーションへの更新を必要とするので、彼らは、HTTPのために良い試合です。プレゼンテーションフリーユーザインターフェースは、単にアプリケーションへのユーザ入力を送信するので、NOTIFYがより適切です。
Indeed, for presentation-free user interfaces, there are two different modalities of operation. The first is called "one shot". In the one-shot role, the markup waits for a user to enter some information and, when they do, reports this event to the application. The application then does something, and the markup is no longer used. In the other modality, called "monitor", the markup stays permanently resident, and reports information back to an application until termination of the associated dialog.
確かに、プレゼンテーションのないユーザインタフェースのために、操作の二つの異なる様式があります。最初は、「ワンショット」と呼ばれています。ワンショットの役割では、マークアップは、彼らが行うときに、アプリケーションにこのイベントを報告し、ユーザーは、いくつかの情報を入力するのを待ちます。次に、アプリケーションは、何かをしていない、とマークアップはもはや使用されています。 「モニター」と呼ばれる他のモダリティでは、マークアップは、恒久的に常駐のままで、関連するダイアログの終了まで戻ってアプリケーションに情報を報告します。
This section presents some of the network topologies in which this framework can be instantiated.
このセクションでは、このフレームワークがインスタンス化することが可能なネットワークトポロジのいくつかを紹介します。
+-------------+
/---| Application |
/ +-------------+
/
SUB/ / REFER/
NOT / HTTP
/
+--------+ SIP (INVITE) +-----+
| UI A--------------------X |
|........| | SIP |
| User | RTP | UA |
| Device B--------------------Y |
+--------+ +-----+
Figure 2: Third-Party Topology
図2：サードパーティのトポロジ
In this topology, the application that is interested in interacting with the users exists outside of the SIP dialog between the user agents. In that case, the application learns about the initiation and termination of the dialog, along with the dialog identifiers, through some out-of-band means. One such possibility is the dialog event package [16]. Dialog information is only revealed to trusted parties, so the application would need to be trusted by one of the users in order to obtain this information.
このトポロジでは、ユーザとの相互作用に関心があるアプリケーションは、ユーザエージェント間のSIPダイアログの外部に存在します。その場合、アプリケーションは、いくつかのアウトオブバンドの手段を通じて、ダイアログ識別子とともに、対話の開始と終了について学習します。そのような可能性は、ダイアログイベントパッケージ[16]です。アプリケーションがこの情報を得るために、ユーザーの一人から信頼される必要があるであろうように、ダイアログ情報にのみ、信頼できる関係者に明らかにされています。
At any point during the dialog, the application can instantiate user interface components on the user device of the caller or callee. It can do this using either SUBSCRIBE or REFER, depending on the type of user interface (presentation capable or presentation free).
ダイアログ中の任意の時点で、アプリケーションは、発呼者又は被呼者のユーザ装置上のユーザインターフェースコンポーネントをインスタンス化することができます。これは、ユーザ・インタフェースの種類（プレゼンテーション能力やプレゼンテーション無料）に応じて、どちらかSUBSCRIBEまたはREFER使用してこれを行うことができます。
+--------+ SIP (INVITE) +-----+
| User A--------------------X SIP |
| Device | RTP | UA |
|........B--------------------Y |
| | SUB/NOT | App)|
| UI A'-------------------X' |
+--------+ REFER/HTTP +-----+
Figure 3: Co-Resident Topology
図3：共存トポロジ
In this deployment topology, the application is co-resident with one of the user agents (the one on the right in the picture above). This application can install client-local user interface components on the other user agent, which is acting as the user device. These components can be installed using either SUBSCRIBE, for presentation-free user interfaces, or REFER, for presentation-capable ones. This situation typically arises when the application wishes to install UI components on a presentation-capable user interface. If the only user input is via keypad input, the framework is not needed per se, because the UA/application will receive the input via RFC 4733 in the RTP stream.
この展開トポロジでは、アプリケーションは、ユーザエージェント（上記画像の右側に1つずつ）の1つと共存あります。このアプリケーションは、ユーザデバイスとして動作している他のユーザエージェント、上のクライアントローカルユーザインタフェースコンポーネントをインストールすることができます。これらのコンポーネントは、プレゼンテーション可能なもののために、プレゼンテーションを含まないユーザインタフェースに、SUBSCRIBE、又はREFERいずれかを使用してインストールすることができます。アプリケーションが提示可能なユーザインタフェースにUIコンポーネントをインストールしたい場合、この状況は、典型的に生じます。唯一のユーザ入力は、キーパッド入力を介して行われる場合、フレームワークは、それ自体が必要とされない、UA /アプリケーションは、RTPストリームにRFC 4733を介して入力を受信することになるからです。
If the application resides in the called party, it is called a "terminating application". If it resides in the calling party, it is called an "originating application".
アプリケーションは、着信側にある場合、それは「終了アプリケーション」と呼ばれています。それは発信側にある場合、それは「元のアプリケーション」と呼ばれています。
This kind of topology is common in protocol converter and gateway applications.
トポロジーのこの種は、プロトコル変換器とゲートウェイアプリケーションで一般的です。
+-------------+
/---| Application |
/ +-------------+
/
SUB/ / REFER/
NOT / HTTP
/
+-----+ SIP +---M----+ SIP +-----+
| V--------------------C A--------------------X |
| SIP | | UI | | SIP |
| UAa | RTP | | RTP | UAb |
| W--------------------D B--------------------Y |
+-----+ +--------+ +-----+
User User
Device Device
Proxy
Figure 4: User Device Proxy Topology
図4：ユーザデバイスプロキシトポロジー
In this deployment topology, there is a third-party application as in Section 7.1. However, instead of installing a user interface component on the end user device, the component is installed in an intermediate device, known as a User Device Proxy. From the perspective of the actual user device (on the left), the User Device Proxy is a client remote user interface. As such, media, typically transported using RTP (including RFC 4733 for carrying user input), is sent from the user device to the client remote user interface on the User Device Proxy. As far as the application is concerned, it is installing what it thinks is a client-local user interface on the user device, but it happens to be on a user device proxy that looks like the user device to the application.
この展開トポロジでは、7.1節のように、サードパーティ製のアプリケーションがあります。しかし、代わりにエンドユーザデバイス上のユーザ・インターフェース・コンポーネントをインストールする、コンポーネントは、ユーザデバイスのプロキシとして知られている中間デバイスにインストールされています。 （左側の）実際のユーザ装置の観点から、ユーザデバイスプロキシは、クライアントのリモートユーザインタフェースです。例えば、媒体は、典型的には、（ユーザ入力を搬送するためのRFC 4733を含む）RTPを使用して搬送されるように、ユーザデバイスプロキシにクライアントのリモートユーザインタフェースに、ユーザ装置から送信されます。限り、アプリケーションが懸念しているとして、何を考えて設置されると、ユーザーのデバイス上のクライアント・ローカルユーザインタフェースであるが、アプリケーションにユーザーデバイスのように見えるのユーザデバイスプロキシであることを起こります。
The user device proxy will need to terminate and re-originate both signaling (SIP) and media traffic towards the actual peer in the conversation. The User Device Proxy is a media relay in the terminology of RFC 3550 [18]. The User Device Proxy will need to monitor the media streams associated with each dialog, in order to convert user input received in the media stream to events reported to the user interface. This can pose a challenge in multi-media systems, where it may be unclear on which media stream the user input is being sent. As discussed in RFC 3264 [20], if a user agent has a single media source and is supporting multiple streams, it is supposed to send that source to all streams. In cases where there are multiple sources, the mapping is a matter of local policy. In the absence of a way to explicitly identify or request which sources map to which streams, the user device proxy will need to do the best job it can. This specification RECOMMENDS that the User Device Proxy monitor the first stream (defined in terms of ordering of media sessions within a session description). As such, user agents SHOULD send their user input on the first stream, absent a policy to direct it otherwise.
ユーザデバイスプロキシは終了し、会話における実際のピアに向けてシグナリング（SIP）とメディアトラフィックの両方を再発信する必要があります。ユーザデバイスプロキシは、RFC 3550 [18]の用語でメディアリレーです。ユーザデバイスプロキシは、ユーザインタフェースに報告イベントにメディア・ストリーム内に受信したユーザ入力を変換するために、各ダイアログに関連付けられたメディア・ストリームを監視する必要があります。これは不明確することができる、メディアは、ユーザー入力が送信されているストリーミングマルチメディアシステム、で挑戦を提起することができます。 [20] RFC 3264で説明したように、ユーザエージェントは、単一のメディアソースと複数のストリームをサポートしているがある場合、すべてのストリームにそのソースを送信するようになっています。複数のソースがある場合には、マッピングは、ローカルポリシーの問題です。明示的に識別するための方法またはストリームにマップをソース要求がない場合には、ユーザーデバイスプロキシは、それができる最高の仕事を行う必要があります。この仕様は、ユーザデバイスプロキシ（セッション記述の中にメディアセッションの順序で定義）第一の流れを監視することをお勧めします。このように、ユーザーエージェントは、最初のストリーム上でそのユーザ入力を送るべきで、そうでなければそれを指示するポリシーを欠きます。
+----------+
SUB/NOT | App | SUB/NOT
+--------------->| |<-----------------+
| REFER/HTTP |..........| REFER/HTTP |
| | SIP | |
| | Proxy | |
| +----------+ |
V ^ | V
+----------+ | | +----------+
| UI | INVITE | | INVITE | UI |
| |------------+ +------------>| |
|......... | |..........|
| SIP |...................................| SIP |
| UA | | UA |
+----------+ RTP +----------+
User Device User Device
Figure 5: Proxy Application Topology
図5：プロキシアプリケーションのトポロジ
In this topology, the application is co-resident with a transaction stateful, record-routing proxy server on the call path between two user devices. The application uses SUBSCRIBE or REFER to install user interface components on one or both user devices.
このトポロジでは、アプリケーションがトランザクションステートフル、2つのユーザデバイス間の通話パス上のレコードルーティングプロキシサーバとの共存です。アプリケーションは、1つまたは両方のユーザ装置上のユーザ・インターフェース・コンポーネントをインストールするためにSUBSCRIBEまたはREFER使用します。
This topology is common in routing applications, such as a web-assisted call-routing application.
このトポロジでは、このようなウェブ補助コールルーティングアプリケーションなどのルーティングアプリケーションで一般的です。
The behavior of an application within this framework depends on whether it seeks to use a client-local or client-remote user interface.
このフレームワーク内のアプリケーションの動作が、それは、クライアントのローカルまたはクライアント・リモート・ユーザー・インターフェースを使用しようとするかどうかに依存します。
One key component of this framework is support for client-local user interfaces.
このフレームワークの一つの重要なコンポーネントは、クライアントのローカルユーザインタフェースのサポートです。
A client-local user interface can only be instantiated on a user agent if the user agent supports that type of user interface component. Support for client-local user interface components is declared by both the UAC and UAS in their Allow, Accept, Supported, and Allow-Event header fields of dialog-initiating requests and responses. If the Allow header field indicates support for the SIP SUBSCRIBE method, and the Allow-Event header field indicates support for the KPML package [8], and the Supported header field indicates support for the Globally Routable UA URI (GRUU) [9] specification (which, in turn, means that the Contact header field contains a GRUU), it means that the UA can instantiate presentation-free user interface components. In this case, the application can push presentation-free user interface components according to the rules of Section 8.1.2. The specific markup languages that can be supported are indicated in the Accept header field.
ユーザエージェントは、ユーザ・インターフェース・コンポーネントの種類をサポートしている場合、クライアントのローカルユーザーインターフェースは、ユーザー・エージェント上でインスタンス化することができます。クライアントのローカルユーザー・インターフェース・コンポーネントのサポートは、その許可にUACとUASの両方で宣言受諾、サポート、およびダイアログ開始要求と応答のヘッダフィールド・イベントを許可されます。許可ヘッダフィールドは、SIPメソッドをSUBSCRIBE、および許可イベントヘッダフィールドは、[8] KPMLパッケージのサポートを示し、Supportedヘッダーフィールドは、グローバルにルーティング可能なUA URI（GRUU）のサポートを示している[9]仕様のサポートを示す場合（これは、Contactヘッダフィールドは、GRUUが含まれていることを意味する）は、UAがプレゼンテーションフリーユーザ・インターフェース・コンポーネントをインスタンス化することができることを意味します。この場合、アプリケーションは、セクション8.1.2の規則に従って提示フリーユーザ・インタフェース・コンポーネントをプッシュすることができます。サポートすることができる特定のマークアップ言語は、Acceptヘッダーフィールドに示されています。
If the Allow header field indicates support for the SIP REFER method, and the Supported header field indicates support for the Target-Dialog header field [10], and the Contact header field contains UA capabilities [6] that indicate support for the HTTP URI scheme, it means that the UA supports presentation-capable user interface components. In this case, the application can push presentation-capable user interface components to the client according to the rules of Section 8.1.2. The specific markups that are supported are indicated in the Accept header field.
許可ヘッダフィールドは、SIPのサポートを示す場合の方法を参照し、サポートされているヘッダフィールドは、ターゲット対話ヘッダフィールド[10]のためのサポートを示し、Contactヘッダフィールドが含まれているUA機能[6] HTTP URIスキームのサポートを示すこと、それは、UAは、プレゼンテーション可能なユーザー・インターフェース・コンポーネントをサポートすることを意味します。この場合、アプリケーションは、セクション8.1.2の規則に従って、クライアントに提示できるユーザ・インターフェース・コンポーネントをプッシュすることができます。サポートされている特定のマークアップは、Acceptヘッダーフィールドに示されています。
A third-party application that is not present on the call path will not be privy to these header fields in the dialog-initiating requests that pass by. As such, it will need to obtain this capability information in other ways. One way is through the registration event package [21], which can contain user agent capability information provided in REGISTER requests [6].
コールパス上に存在していないサードパーティ製のアプリケーションが通り過ぎるダイアログ開始要求でこれらのヘッダフィールドへの関与はありません。このように、それは他の方法でこの機能情報を取得する必要があります。一つの方法は、REGISTERリクエスト[6]に提供されたユーザエージェント能力情報を含むことができ、登録イベントパッケージ[21]によるものです。
Generally, we anticipate that interface components will need to be created at various different points in a SIP session. Clearly, they will need to be pushed during session setup, or after the session is established. A user interface component is always associated with a specific dialog, however.
一般的に、我々は、インタフェースコンポーネントは、SIPセッションでは、様々な異なるポイントで作成する必要がありますことを期待しています。明らかに、彼らはセッションのセットアップ時にプッシュする、またはセッションが確立された後に必要になります。ユーザ・インターフェース・コンポーネントは、常にしかし、特定のダイアログに関連付けられています。
An application MUST NOT attempt to push a user interface component to a user agent until it has determined that the user agent has the necessary capabilities and a dialog has been created. In the case of a UAC, this means that an application MUST NOT push a user interface component for an INVITE-initiated dialog until the application has seen a request confirming the receipt of a dialog-creating response. This could be an ACK for a 200 OK, or a PRACK for a provisional response [3]. For SUBSCRIBE-initiated dialogs, the application MUST NOT push a user interface component until the application has seen a 200 OK to the NOTIFY request. For a user interface component on a UAS, the application MUST NOT push a user interface component for an INVITE-initiated dialog until it has seen a dialog-creating response from the UAS. For a SUBSCRIBE-initiated dialog, it MUST NOT push a user interface component until it has seen a NOTIFY request from the notifier.
アプリケーションは、ユーザエージェントは、必要な機能を持っていると、ダイアログが作成されたと判断するまで、ユーザエージェントへのユーザー・インターフェース・コンポーネントをプッシュするのを試みてはいけません。 UACの場合には、これは、アプリケーションがダイアログ作成応答の受信を確認する要求を見ているまで、アプリケーションは、INVITEが開始ダイアログのユーザインターフェースコンポーネントを押してはならないことを意味します。これは、200 OKに対するACK、または暫定的な応答のためにPRACK [3]とすることができます。アプリケーションはNOTIFYリクエストにOK 200を見てまで、SUBSCRIBE-開始のダイアログでは、アプリケーションは、ユーザ・インターフェース・コンポーネントをプッシュしてはなりません。それはUASからダイアログ作成応答を見までUAS上のユーザ・インターフェース・コンポーネントは、アプリケーションは、INVITEが開始ダイアログのユーザインターフェースコンポーネントを押してはいけません。それは通知からNOTIFYリクエストを見ているまでSUBSCRIBE-開始ダイアログの場合は、ユーザー・インタフェース・コンポーネントをプッシュしてはなりません。
To create a presentation-capable UI component on the UA, the application sends a REFER request to the UA. This REFER MUST be sent to the GRUU [9] advertised by that UA in the Contact header field of the dialog-initiating request or response sent by that UA. Note that this REFER request creates a separate dialog between the application and the UA. The Refer-To header field of the REFER request MUST contain an HTTP URI that references the markup document to be fetched.
UAのプレゼンテーション対応のUIコンポーネントを作成するには、アプリケーションは、UAを参照する要求を送信します。これは、UAによって送信されたダイアログ開始要求または応答のContactヘッダフィールドにそのUAによってアドバタイズGRUU [9]に送信する必要がありREFER。このREFER要求は、アプリケーションとUAの間に別のダイアログを作成することに注意してください。 REFER要求の参照のために、ヘッダーフィールドは、フェッチされるマークアップ文書を参照するHTTP URIを含まなければなりません。
Furthermore, it is essential for the REFER request to be correlated with the dialog to which the user interface component will be associated. This is necessary for authorization and for terminating the user interface components when the dialog terminates. To provide this context, the REFER request MUST contain a Target-Dialog header field identifying the dialog with which the user interface component is associated. As discussed in [10], this request will also contain a Require header field with the tdialog option tag.
また、ユーザ・インターフェース・コンポーネントは、関連されるダイアログと相関することがREFER要求のために不可欠です。これは、承認のため、ダイアログが終了したときに、ユーザー・インタフェース・コンポーネントを終了するために必要です。このコンテキストを提供するために、REFER要求は、ユーザ・インターフェース・コンポーネントが関連付けられている対話を識別するターゲット対話ヘッダフィールドを含まなければなりません。 [10]で論じたように、この要求はまたtdialogオプションタグを要求ヘッダーフィールドを含むことになります。
To create a presentation-free user interface component, the application sends a SUBSCRIBE request to the UA. The SUBSCRIBE MUST be sent to the GRUU advertised by the UA. This SUBSCRIBE request creates a separate dialog. The SUBSCRIBE request MUST use the KPML [8] event package. The body of the SUBSCRIBE request contains the markup document that defines the conditions under which the application wishes to be notified of user input.
プレゼンテーションのないユーザー・インターフェース・コンポーネントを作成するには、アプリケーションは、UAにSUBSCRIBEリクエストを送信します。 SUBSCRIBE UAによってアドバタイズGRUUに送らなければなりません。このSUBSCRIBEリクエストは、別のダイアログを作成します。 SUBSCRIBEリクエストはKPML [8]イベントパッケージを使用しなければなりません。 SUBSCRIBEリクエストのボディは、アプリケーションがユーザ入力を通知することを希望する条件を定義するマークアップ文書を含みます。
In both cases, the REFER or SUBSCRIBE request SHOULD include a display name in the From header field that identifies the name of the application. For example, a prepaid calling card might include a From header field that looks like:
両方の場合において、REFERまたはSUBSCRIBEリクエストは、アプリケーションの名前を識別するヘッダからフィールドの表示名を含むべきです。例えば、プリペイドカードは次のようになりますFromヘッダーフィールドが含まれる場合があります。
From: "Prepaid Calling Card" <sip:prepaid@example.com>
From：「プリペイドカード」<一口：prepaid@example.com>
Any of the SIP identity assertion mechanisms that have been defined, such as [11] and [13], are applicable to these requests as well.
このような[11]及び[13]のように定義されたSIP IDアサーションメカニズムのいずれも、これらの要求にも適用可能です。
Once a user interface component has been created on a client, it can be updated. The means for updating it depends on the type of UI component.
ユーザー・インターフェース・コンポーネントは、クライアント上で作成された後、それを更新することができます。それを更新するための手段は、UIコンポーネントの種類によって異なります。
Presentation-capable UI components are updated using techniques already in place for those markups. In particular, user input will cause an HTTP POST operation to push the user input to the application. The result of the POST operation is a new markup that the UI is supposed to use. This allows the UI to be updated in response to user action. Some markups, such as HTML, provide the ability to force a refresh after a certain period of time, so that the UI can be updated without user input. Those mechanisms can be used here as well. However, there is no support for an asynchronous push of an updated UI component from the application to the user agent. A new REFER request to the same GRUU would create a new UI component rather than update any components already in place.
プレゼンテーション対応のUIコンポーネントは、これらのマークアップのための場所で既に技術を使用して更新されます。特に、ユーザ入力は、HTTP POST操作はアプリケーションへのユーザ入力をプッシュします。 POST操作の結果は、UIを使用することになっている新しいマークアップです。これは、UIは、ユーザーのアクションに応じて更新することができます。 HTMLなどのいくつかのマークアップは、UIは、ユーザーの入力なしで更新できるように、一定時間後にリフレッシュを強制する機能を提供します。これらのメカニズムは、ここで使用することもできます。しかし、ユーザーエージェントへのアプリケーションから更新されたUIコンポーネントの非同期プッシュのためのサポートはありません。新しいは新しいUIコンポーネントを作成するのではなく場所にすでに任意のコンポーネントを更新するのと同じGRUUへの要求を参照してください。
For presentation-free UI, the story is different. The application MAY update the filter at any time by generating a SUBSCRIBE refresh with the new filter. The UA will immediately begin using this new filter.
プレゼンテーションのないUIの場合、話は違います。アプリケーションは、新しいフィルタでリフレッシュSUBSCRIBE発生させることにより、いつでもフィルタを更新することができます。 UAは、すぐにこの新しいフィルタを使用して開始します。
User interface components have a well-defined lifetime. They are created when the component is first pushed to the client. User interface components are always associated with the SIP dialog on which they were pushed. As such, their lifetime is bound by the lifetime of the dialog. When the dialog ends, so does the interface component.
ユーザーインターフェイスコンポーネントは、明確に定義された寿命を持っています。コンポーネントは、最初のクライアントにプッシュされたとき、彼らが作成されます。ユーザー・インタフェース・コンポーネントは、常に彼らがプッシュされた上でSIPダイアログに関連付けられています。そのため、彼らの寿命は、ダイアログの寿命に拘束されています。ダイアログが終了すると、そのインターフェイスコンポーネントがありません。
However, there are some cases where the application would like to terminate the user interface component before its natural termination point. For presentation-capable user interfaces, this is not possible. For presentation-free user interfaces, the application MAY terminate the component by sending a SUBSCRIBE with Expires equal to zero. This terminates the subscription, which removes the UI component.
ただし、アプリケーションがその天然の終点前に、ユーザ・インターフェース・コンポーネントを終了したい場合があります。提示可能なユーザインタフェースのため、これは不可能です。プレゼンテーションフリーユーザインターフェースのため、アプリケーションは、ゼロに等しい有効期限とSUBSCRIBEを送信することによって、コンポーネントを終了することができます。これは、UIコンポーネントを削除するサブスクリプションを、終了します。
A client can remove a UI component at any time. For presentation-capable UI, this is analogous to the user dismissing the web form window. There is no mechanism provided for reporting this kind of event to the application. The application MUST be prepared to time out and never receive input from a user. The duration of this timeout is application dependent. For presentation-free user interfaces, the UA can explicitly terminate the subscription. This will result in the generation of a NOTIFY with a Subscription-State header field equal to "terminated".
クライアントは、いつでもUIコンポーネントを削除することができます。プレゼンテーション可能なUIの場合、これは、ウェブフォームウィンドウを却下ユーザーに似ています。アプリケーションにこのようなイベントを報告するために提供メカニズムはありません。アプリケーションがタイムアウトして、ユーザからの入力を受信しないように準備しなければなりません。このタイムアウトの期間はアプリケーションに依存します。プレゼンテーションのないユーザーインターフェイスでは、UAは、明示的にサブスクリプションを終了することができます。これは、「終了」に等しいSubscription-StateヘッダフィールドとNOTIFYの生成をもたらすであろう。
As an alternative to, or in conjunction with client-local user interfaces, an application can make use of client-remote user interfaces. These user interfaces can execute co-resident with the application itself (in which case no standardized interfaces between the UI and the application need to be used), or they can run separately. This framework assumes that the user interface runs on a host that has a sufficient trust relationship with the application. As such, the means for instantiating the user interface is not considered here.
代替として、またはクライアントのローカルユーザインタフェースに関連して、アプリケーションは、クライアントのリモートユーザインタフェースを利用することができました。これらのユーザインタフェースは、アプリケーション自体（この場合、UIとアプリケーションの間に標準インターフェースを使用する必要はない）と共存を実行することができ、またはそれらは別々に実行することができます。このフレームワークは、ユーザーインターフェイスは、アプリケーションとの十分な信頼関係を持っているホスト上で実行されることを前提としています。そのため、ユーザー・インターフェースをインスタンス化するための手段はここでは考慮されていません。
The primary issue is to connect the user device to the remote user interface. Doing so requires the manipulation of media streams between the client and the user interface. Such manipulation can only be done by user agents. There are two types of user agent applications within this framework: originating/terminating applications, and intermediary applications.
主な問題は、リモート・ユーザ・インタフェースにユーザデバイスを接続することです。そうすることで、クライアントとユーザーインターフェース間のメディアストリームの操作が必要です。このような操作は、ユーザエージェントによって行うことができます。発信元/終了アプリケーション、および仲介アプリケーション：ユーザー・エージェント・このフレームワーク内のアプリケーションの2つのタイプがあります。
Originating and terminating applications are applications that are themselves the originator or the final recipient of a SIP invitation. They are "pure" user agent applications, not back-to-back user agents. The classic example of such an application is an interactive voice response (IVR) application, which is typically a terminating application. It is a terminating application because the user explicitly calls it; i.e., it is the actual called party. An example of an originating application is a wakeup call application, which calls a user at a specified time in order to wake them up.
発信および着信アプリケーションは、発信またはSIP招待の最終的な受信者自身であるアプリケーションです。彼らは、「純粋な」ユーザーエージェントアプリケーションではなく、バックツーバックユーザエージェントです。そのようなアプリケーションの典型的な例は、典型的には、終端アプリケーションで対話型音声応答（IVR）アプリケーションです。ユーザーが明示的に呼び出すためには、終端アプリケーションです。すなわち、それは実際と呼ばれるパーティです。元のアプリケーションの例としては、それらをウェイクアップするために、指定された時にユーザーを呼び出すウェイクアップコール・アプリケーション、です。
Because originating and terminating applications are a natural termination point of the dialog, manipulation of the media session by the application is trivial. Traditional SIP techniques for adding and removing media streams, modifying codecs, and changing the address of the recipient of the media streams can be applied.
発信元と着信アプリケーションは、ダイアログの自然の終端点であるため、アプリケーションによってメディアセッションの操作は簡単です。追加および削除メディアストリームを、コーデックの変更、メディアストリームの受信者のアドレスを変更するための従来のSIP技術を適用することができます。
Intermediary applications are, at the same time, more common than originating/terminating applications and more complex. Intermediary applications are applications that are neither the actual caller nor the called party. Rather, they represent a "third party" that wishes to interact with the user. The classic example is the ubiquitous prepaid calling card application.
仲介アプリケーションは、同時に、アプリケーション、およびより複雑なを終了/発信さよりも一般的です。仲介アプリケーションは、実際の呼び出し側も呼ばれるパーティでもないアプリケーションです。むしろ、彼らは、ユーザーと対話することを希望する「第三者」を表します。古典的な例は、ユビキタスプリペイドカードのアプリケーションです。
In order for the intermediary application to add a client-remote user interface, it needs to manipulate the media streams of the user agent to terminate on that user interface. This also introduces a fundamental feature interaction issue. Since the intermediary application is not an actual participant in the call, the user will need to interact with both the intermediary application and its peer in the dialog. Doing both at the same time is complicated and is discussed in more detail in Section 10.
クライアント・リモート・ユーザ・インターフェースを追加するために、中間アプリケーションのために、そのユーザーインターフェースで終端するユーザエージェントのメディアストリームを操作する必要があります。また、これは基本的な機能の相互作用の問題を紹介します。中間アプリケーションは、コールの実際の参加者ではないので、ユーザーは中間アプリケーションやダイアログでそのピアの両方と相互作用する必要があります。同時に両方を行うことは複雑であり、第10節で詳しく説明します。
In order to participate in applications that make use of stimulus interfaces, a user agent needs to advertise its interaction capabilities.
刺激インターフェースを使用するアプリケーションに参加するためには、ユーザーエージェントは、その相互作用の機能を通知する必要があります。
If a user agent supports presentation-capable user interfaces, it MUST support the REFER method. It MUST include, in all dialog-initiating requests and responses, an Allow header field that includes the REFER method. The user agent MUST support the target dialog specification [10], and MUST include the "tdialog" option tag in the Supported header field of dialog-forming requests and responses. Furthermore, the UA MUST support the SIP user agent capabilities specification [6]. The UA MUST be capable of being REFERed to an HTTP URI. It MUST include, in the Contact header field of its dialog-initiating requests and responses, a "schemes" Contact header field parameter that includes the HTTP URI scheme. The UA MUST include, in all dialog-initiating requests and responses, an Accept header field listing all of those markups supported by the UA. It is RECOMMENDED that all user agents that support presentation-capable user interfaces support HTML.
ユーザエージェントは、プレゼンテーション可能なユーザインタフェースをサポートしている場合、それはREFERメソッドをサポートしなければなりません。それは、すべてのダイアログ-開始要求と応答では、REFER方法を含むAllowヘッダーフィールドを含まなければなりません。ユーザエージェントは、ターゲット・ダイアログ仕様[10]をサポートしなければなりません、そしてダイアログ形成要求と応答のSupportedヘッダーフィールドに「tdialog」オプションタグを含まなければなりません。また、UAは、SIPユーザエージェント機能仕様をサポートしなければならない[6]。 UAは、HTTP URIに参照されていることができなければなりません。それは、そのダイアログ開始要求と応答のContactヘッダーフィールド、HTTP URIスキームを含む「スキーム」Contactヘッダーフィールドパラメータに含まなければなりません。 UAは、すべてのダイアログ-開始要求と応答では、UAによってサポートされているマークアップのすべてをリストAcceptヘッダーフィールドを含まなければなりません。プレゼンテーションが可能なユーザインタフェースをサポートするすべてのユーザーエージェントがHTMLをサポートすることが推奨されます。
If a user agent supports presentation-free user interfaces, it MUST support the SUBSCRIBE [4] method. It MUST support the KPML [8] event package. It MUST include, in all dialog-initiating requests and responses, an Allow header field that includes the SUBSCRIBE method. It MUST include, in all dialog-initiating requests and responses, an Allow-Events header field that lists the KPML event package. The UA
ユーザエージェントはプレゼンテーションフリーユーザインターフェースをサポートしている場合、それはSUBSCRIBE [4]メソッドをサポートしなければなりません。それはKPML [8]イベントパッケージをサポートしなければなりません。それは、すべてのダイアログ-開始要求と応答では、SUBSCRIBE方法を含むAllowヘッダーフィールドを含まなければなりません。これは、許可 - イベントがKPMLイベントパッケージを一覧表示フィールドをヘッダー、すべてのダイアログ開始要求と応答に含まなければなりません。 UA
MUST include, in all dialog-initiating requests and responses, an Accept header field listing those event filters it supports. At a minimum, a UA MUST support the "application/kpml-request+xml" MIME type.
、すべてのダイアログ開始要求と応答では、それがサポートするこれらのイベントフィルタをリストAcceptヘッダーフィールドを含まなければなりません。最低でも、UAは、「アプリケーション/ KPML要求+ XML」MIMEタイプをサポートしなければなりません。
For either presentation-free or presentation-capable user interfaces, the user agent MUST support the GRUU [9] specification. The Contact header field in all dialog-initiating requests and responses MUST contain a GRUU. The UA MUST include a Supported header field that contains the "gruu" option tag and the "tdialog" option tag.
プレゼンテーション遊離または提示できるユーザ・インターフェースのいずれかのために、ユーザエージェントがGRUU [9]の仕様をサポートしなければなりません。すべてのダイアログ開始要求と応答におけるContactヘッダーフィールドは、GRUUを含まなければなりません。 UAは「GRUU」オプションタグと「tdialog」オプションタグが含まれているサポートされているヘッダフィールドを含まなければなりません。
Because these headers are examined by proxies that may be executing applications, a UA that wishes to support client-local user interfaces should not encrypt them.
これらのヘッダは、アプリケーションを実行することができるプロキシによって検査されるので、希望するUAは、それらを暗号化してはならないクライアントのローカルユーザインタフェースをサポートします。
Once the UA has created a dialog (in either the early or confirmed states), it MUST be prepared to receive a SUBSCRIBE or REFER request against its GRUU. If the UA receives such a request prior to the establishment of a dialog, the UA MUST reject the request.
UAが（どちらか早いかを確認した状態で）、ダイアログを作成したら、そのGRUUに対してSUBSCRIBEまたはREFER要求を受信するために準備しなければなりません。 UAは、ダイアログの設立に先立ち、このような要求を受信した場合、UAは要求を拒絶しなければなりません。
A user agent SHOULD attempt to authenticate the sender of the request. The sender will generally be an application; therefore, the user agent is unlikely to ever have a shared secret with it, making digest authentication useless. However, authenticated identities can be obtained through other means, such as the Identity mechanism [11].
ユーザエージェントは、要求の送信者を認証しようとすべきです。送信者は、一般的に適用されます。そのため、ユーザエージェントは、これまで無駄にダイジェスト認証を作り、それを共有秘密を持つことはほとんどありません。ただし、認証されたアイデンティティは、アイデンティティ機構[11]のように、他の手段によって得ることができます。
A user agent MAY have pre-defined authorization policies that permit applications which have authenticated themselves with a particular identity to push user interface components. If such a set of policies is present, it is checked first. If the application is authorized, processing proceeds.
ユーザエージェントは、ユーザインタフェースコンポーネントをプッシュするために、特定のアイデンティティと自分自身を認証されたアプリケーションを許可する事前定義された認可ポリシーを持っているかもしれません。政策のようなセットが存在する場合、それは最初にチェックされます。アプリケーションが許可されている場合は、処理を進めます。
If the application has authenticated itself but is not explicitly authorized or blocked, this specification RECOMMENDS that the application be automatically authorized if it can prove that it was either on the call path, or is trusted by one of the elements on the call path. An application proves this to the user agent by demonstrating that it knows the dialog identifiers. That occurs by including them in a Target-Dialog header field for REFER requests, or in the Event header field parameters of the KPML SUBSCRIBE request.
アプリケーション自体を認証したが、明示的に許可またはブロックされていない場合は、この仕様は、それがいずれかのコールパスにあった、またはコールパス上の要素の一つに信頼されていることを証明できる場合は、アプリケーションが自動的に承認されることをお勧めします。アプリケーションは、ダイアログ識別子を知っていることを示すことによって、ユーザーエージェントにこれを証明しています。それは、要求を参照するか、KPMLのイベントヘッダフィールドパラメータにSUBSCRIBEリクエストをするためのターゲット対話ヘッダフィールドに含めることによって起こります。
Because the dialog identifiers serve as a tool for authorization, a user agent compliant to this framework SHOULD use dialog identifiers that are cryptographically random, with at least 128 bits of randomness. It is recommended that this randomness be split between the Call-ID and From header field tags in the case of a UAC.
ダイアログ識別子は、認可のためのツールとして機能しているので、このフレームワークに準拠したユーザエージェントは、ランダム性の少なくとも128ビットで、暗号的にランダムでダイアログの識別子を使用すべきです。このランダム性は、コールIDとUACの場合のヘッダフィールドのタグからの間で分割することをお勧めします。
Furthermore, to ensure that only applications resident in or trusted by on-path elements can instantiate a user interface component, a user agent compliant to this specification SHOULD use the Session Initiation Protocol Secure (SIPS) URI scheme for all dialogs it initiates. This will guarantee secure links between all the elements on the signaling path.
さらに、上のパス要素は、ユーザ・インターフェース・コンポーネントをインスタンス化することができる唯一のアプリケーション常駐こと等により信頼を保証するために、この仕様に準拠したユーザエージェントは、それが開始するすべてのダイアログのためのセッション開始プロトコルセキュア（SIPS）URIスキームを使用すべきです。これは、信号経路上のすべての要素の間に安全なリンクを保証します。
If the dialog was not established with a SIPS URI, or the user agent did not choose cryptographically random dialog identifiers, then the application MUST NOT automatically be authorized, even if it presented valid dialog identifiers. A user agent MAY apply any other policies in addition to (but not instead of) the ones specified here in order to authorize the creation of the user interface component. One such mechanism would be to prompt the user, informing them of the identity of the application and the dialog it is associated with. If an authorization policy requires user interaction, the user agent SHOULD respond to the SUBSCRIBE or REFER request with a 202. In the case of SUBSCRIBE, if authorization is not granted, the user agent SHOULD generate a NOTIFY to terminate the subscription. In the case of REFER, the user agent MUST NOT act upon the URI in the Refer-To header field until user authorization is obtained.
ダイアログが暗号的にランダムなダイアログ識別子を選択しなかったSIPS URI、またはユーザエージェントとの間で確立されていなかった場合、アプリケーションは自動的にそれが有効なダイアログ識別子を提示した場合でも、許可されてはなりません。ユーザエージェントは、ユーザ・インターフェース・コンポーネントの作成を許可するために、ここで指定したもの（ただし、その代わりに）に加えて、他のポリシーが適用される場合があります。そのような機構の1つは、アプリケーションのIDとそれが関連付けられているダイアログを知らせる、ユーザを促すことであろう。認可ポリシーがユーザーの操作を必要とする場合、ユーザエージェントは、SUBSCRIBEの場合は202とSUBSCRIBEまたはREFERリクエストに応答すべき認可が付与されていない場合、ユーザエージェントは、サブスクリプションを終了するためにNOTIFY生成する必要があります。 REFERの場合、ユーザエージェントは、参照のために、ユーザ認証が得られるまでフィールドをヘッダにURIに作用してはいけません。
If an application does not present a valid dialog identifier in its REFER or SUBSCRIBE request, the user agent MUST reject the request with a 403 response.
アプリケーションが参照するか、SUBSCRIBEリクエストに有効なダイアログ識別子を提示しない場合、ユーザエージェントは403応答で要求を拒絶しなければなりません。
If a REFER request to an HTTP URI is authorized, the UA executes the URI and fetches the content to be rendered to the user. This instantiates a presentation-capable user interface component. If a SUBSCRIBE was authorized, a presentation-free user interface component is instantiated.
HTTP URIを参照して、要求が許可される場合、UAはURIを実行し、ユーザにレンダリングされるコンテンツをフェッチします。これは、提示可能なユーザ・インターフェース・コンポーネントをインスタンス化します。承認されたSUBSCRIBE場合は、プレゼンテーションのないユーザ・インターフェース・コンポーネントがインスタンス化されます。
Once the user interface components are instantiated, the user agent must direct user input to the appropriate component. In the case of presentation-capable user interfaces, this process is known as focus selection. It is done by means that are specific to the user interface on the device. In the case of a PC, for example, the window manager would allow the user to select the appropriate user interface component to which their input is directed.
ユーザ・インターフェース・コンポーネントがインスタンス化されると、ユーザエージェントは、適切なコンポーネントへのユーザ入力を指示しなければなりません。提示可能なユーザインタフェースの場合、このプロセスは、フォーカス選択として知られています。これは、デバイス上のユーザインタフェースに固有のものによって行われます。 PCの場合には、例えば、ウィンドウマネージャは、ユーザが入力を対象とする適切なユーザ・インターフェース・コンポーネントを選択することを可能にします。
For presentation-free user interfaces, the situation is more complicated. In some cases, the device may support a mechanism that allows the user to select a "line", and thus the associated dialog. Any user input on the keypad while this line is selected are fed to the user interface components associated with that dialog.
プレゼンテーションのないユーザーインターフェイスでは、状況はより複雑です。いくつかのケースでは、デバイスは、ユーザが「ライン」を選択することを可能にするメカニズム、及び従って関連するダイアログをサポートすることができます。この行が選択されている間、キーパッド上の任意のユーザ入力は、そのダイアログに関連付けられたユーザ・インターフェース・コンポーネントに供給されます。
Otherwise, for client-local user interfaces, the user input is assumed to be associated with all user interface components. For client-remote user interfaces, the user device converts the user input to media, typically conveyed using RFC 4733, and sends this to the client-remote user interface. This user interface then needs to map user input from potentially many media streams into user interface events. The process for doing this is described in Section 7.3.
そうでない場合は、クライアントのローカルユーザインターフェイスの場合、ユーザ入力は、すべてのユーザ・インターフェース・コンポーネントに関連付けされているものとします。クライアントのリモートユーザインタフェースは、ユーザ装置は、典型的には、RFC 4733を使用して搬送され、メディアへのユーザ入力を変換し、クライアント遠隔ユーザインターフェースに送信します。このユーザインタフェースは、ユーザインタフェースイベントに潜在的に多くのメディアストリームからのユーザ入力をマッピングする必要があります。これを実行するためのプロセスは、セクション7.3に記載されています。
For presentation-capable user interfaces, updates to the user interface occur in ways specific to that user interface component. In the case of HTML, for example, the document can tell the client to fetch a new document periodically. However, this framework does not provide any additional machinery to asynchronously push a new user interface component to the client.
提示可能なユーザインタフェースのための、ユーザーインターフェースへの更新は、ユーザ・インターフェース・コンポーネントに特定の方法で起こります。 HTMLの場合、例えば、文書は定期的に新しいドキュメントを取得するためにクライアントを伝えることができます。しかし、このフレームワークは非同期クライアントに新しいユーザーインターフェイスコンポーネントをプッシュする追加の機械を提供していません。
For presentation-free user interfaces, an application can push an update to a component by sending a SUBSCRIBE refresh with a new filter. The user agent will process these according to the rules of the event package.
プレゼンテーションフリーユーザインターフェースのため、アプリケーションは、新しいフィルタとSUBSCRIBEリフレッシュを送信することによって、コンポーネントの更新をプッシュすることができます。ユーザエージェントは、これらのイベントパッケージのルールに従って処理されます。
Termination of a presentation-capable user interface component is a trivial procedure. The user agent merely dismisses the window (or its equivalent). The fact that the component is dismissed is not communicated to the application. As such, it is purely a local matter.
提示可能なユーザ・インターフェース・コンポーネントの終了は簡単な手順です。ユーザエージェントは、単にウィンドウ（またはそれに相当）を解任します。却下されたコンポーネントをアプリケーションに通知されていないという事実。このように、それは純粋にローカルの問題です。
In the case of a presentation-free user interface, the user might wish to cease interacting with the application. However, most presentation-free user interfaces will not have a way for the user to signal this through the device. If such a mechanism did exist, the UA SHOULD generate a NOTIFY request with a Subscription-State header field equal to "terminated" and a reason of "rejected". This tells the application that the component has been removed and that it should not attempt to re-subscribe.
プレゼンテーションのないユーザ・インタフェースの場合は、ユーザーがアプリケーションと対話を中止したい場合があります。しかし、多くの提示のないユーザーインターフェースは、ユーザーがデバイスを介してこれを通知するための方法を持っていません。そのような機構が存在しなかった場合、UAは、「終了」に等しいSubscription-Stateヘッダフィールドと「拒否」の理由とNOTIFYリクエストを生成する必要があります。これは、コンポーネントが削除され、それが再サブスクライブを試みるべきではないということであったことをアプリケーションに通知します。
The inter-application feature interaction problem is inherent to stimulus signaling. Whenever there are multiple applications, there are multiple user interfaces. The system has to determine to which user interface any particular input is destined. That question is the essence of the inter-application feature interaction problem.
アプリケーション間の機能的相互作用の問題は、刺激のシグナル伝達に固有のものです。複数のアプリケーションがあるときはいつでも、複数のユーザーインタフェースがあります。システムは、ユーザインタフェースの任意の特定の入力を宛先としているかを決定しなければなりません。その質問は、アプリケーション間の機能的相互作用の問題の本質です。
Inter-application feature interaction is not an easy problem to resolve. For now, we consider separately the issues for client-local and client-remote user interface components.
アプリケーション間の機能の相互作用は、解決するための簡単な問題ではありません。今のところ、私たちは、クライアントのローカルおよびクライアント・リモート・ユーザー・インターフェース・コンポーネントの個別の問題を検討します。
When the user interface itself resides locally on the client device, the feature interaction problem is actually much simpler. The end device knows explicitly about each application, and therefore can present the user with each one separately. When the user provides input, the client device can determine to which user interface the input is destined. The user interface to which input is destined is referred to as the "application in focus", and the means by which the focused application is selected is called "focus determination".
ユーザーインターフェース自体は、クライアントデバイス上でローカルに存在する場合には、機能の相互作用の問題は、実際にははるかに簡単です。エンドデバイスは、各アプリケーションに関する明示的知っているので、別々にそれぞれをユーザに提示することができます。ユーザが入力を提供する場合、クライアントデバイスは、ユーザインタフェース入力を宛先としているかを決定することができます。入力が宛てられたユーザインターフェースは、「焦点のアプリケーション」と呼ばれ、集束アプリケーションが選択される手段「は決意を集中」と呼ばれます。
Generally speaking, focus determination is purely a local operation. In the PC universe, focus determination is provided by window managers. Each application does not know about focus; it merely receives the user input that has been targeted to it when it's in focus. This basic concept applies to SIP-based applications as well.
一般的に言えば、フォーカス決意は、純粋にローカルな操作です。 PCの世界では、フォーカス決意はウィンドウマネージャによって提供されます。各アプリケーションは、フォーカスを知りません。それは単にそれに焦点が合っていたときに、それをターゲットにされたユーザ入力を受け取ります。この基本的な考え方は、同様にSIPベースのアプリケーションに適用されます。
Focus determination will frequently be trivial, depending on the user interface type. Consider a user that makes a call from a PC. The call passes through a prepaid calling card application and a call-recording application. Both of these wish to interact with the user. Both push an HTML-based user interface to the user. On the PC, each user interface would appear as a separate window. The user interacts with the call-recording application by selecting its window, and with the prepaid calling card application by selecting its window. Focus determination is literally provided by the PC window manager. It is clear to which application the user input is targeted.
焦点決意は、しばしばユーザインターフェースの種類に応じて、自明であろう。 PCからの呼び出しを行うユーザーを考えてみましょう。コールは、プリペイドカードのアプリケーションおよびコール・録画アプリケーションを通過します。これらの両方は、ユーザと対話したいです。どちらも、ユーザーにHTMLベースのユーザー・インターフェースを押してください。 PC上では、各ユーザー・インタフェースは、別のウィンドウとして表示されます。ユーザーは、そのウィンドウを選択することにより、およびプリペイドカードアプリケーションとのウィンドウを選択することにより、通話記録アプリケーションと対話します。焦点決意は文字通りPCのウィンドウマネージャによって提供されます。これは、ユーザ入力が目標とされているアプリケーションには明らかです。
As another example, consider the same two applications, but on a "smart phone" that has a set of buttons, and next to each button, there is an LCD display that can provide the user with an option. This user interface can be represented using the Wireless Markup Language (WML), for example.
別の例として、同じ2つのアプリケーションを検討しますが、ボタンのセットを持っている「スマートフォン」、及び各ボタンの横に、オプションをユーザに提供することができるLCDディスプレイがあります。このユーザインタフェースは、例えば、ワイヤレスマークアップ言語（WML）を使用して表すことができます。
The phone would allocate some number of buttons to each application. The prepaid calling card would get one button for its "hangup" command, and the recording application would get one for its "start/ stop" command. The user can easily determine which application to interact with by pressing the appropriate button. Pressing a button determines focus and provides user input, both at the same time.
携帯電話は、各アプリケーションにボタンのいくつかの数を割り当てます。プリペイドカードは、その「ハングアップ」コマンドのための1つのボタンになるだろう、と記録アプリケーションは、「スタート/ストップ」コマンドのための1つになるだろう。ユーザーが簡単に適切なボタンを押して、と対話するアプリケーションを決定することができます。ボタンを押すと、同時に両方、フォーカスを決定し、ユーザ入力を提供します。
Unfortunately, not all devices will have these advanced displays. A PSTN gateway, or a basic IP telephone, may only have a 12-key keypad. The user interfaces for these devices are provided through the Keypad
残念ながら、すべてのデバイスは、これらの高度なディスプレイを持つことになります。 PSTNゲートウェイ、または基本的なIP電話は、唯一の12キーのキーパッドを有していてもよいです。これらのデバイスのためのユーザインタフェースは、キーパッドを介して提供されます
Markup Language (KPML). Considering once again the feature interaction case above, the prepaid calling card application and the call-recording application would both pass a KPML document to the device. When the user presses a button on the keypad, to which document does the input apply? The device does not allow the user to select. A device where the user cannot provide focus is called a "focusless device". This is quite a hard problem to solve. This framework does not make any explicit normative recommendation, but it concludes that the best option is to send the input to both user interfaces unless the markup in one interface has indicated that it should be suppressed from others. This is a sensible choice by analogy -- it's exactly what the existing circuit-switched telephone network will do. It is an explicit non-goal to provide a better mechanism for feature interaction resolution than the PSTN on devices that have the same user interface as they do on the PSTN. Devices with better displays, such as PCs or screen phones, can benefit from the capabilities of this framework, allowing the user to determine which application they are interacting with.
マークアップ言語（KPML）。もう一度、上記の機能の相互作用の場合、プリペイドカードのアプリケーションおよびコール・録画アプリケーションを考慮すると、両方のデバイスにKPMLドキュメントを渡します。ユーザーがキーパッドのボタンを押すと、その文書への入力が適用されていますか？デバイスは、ユーザが選択することはできません。フォーカスを提供できないユーザが「focuslessデバイス」と呼ばれる装置。これは、解決するために、非常に難しい問題です。このフレームワークは、明示的な規範的な勧告を行うわけではありませんが、最良の選択肢は一つのインタフェースでのマークアップは、それが他の人から抑制されるべきであることを示していない限り、両方のユーザーインターフェースに入力を送信することであると結論づけています。これは、類推によって賢明な選択である - それは、既存の回線交換電話網を行いますまさにです。彼らがPSTN上で行うのと同じユーザーインターフェースを持っているデバイス上のPSTNよりも機能の相互作用の解決のためのより良いメカニズムを提供するために、明示的な非目標です。例えばPCや画面電話など良好ディスプレイを有するデバイスは、ユーザがそれらが相互作用しているアプリケーションを判断することができ、このフレームワークの能力から利益を得ることができます。
Indeed, when a user provides input on a focusless device, the input must be passed to all client-local user interfaces AND all client-remote user interfaces, unless the markup tells the UI to suppress the media. In the case of KPML, key events are passed to remote user interfaces by encoding them as described in RFC 4733 [19]. Of course, since a client cannot determine whether or not a media stream terminates in a remote user interface, these key events are passed in all audio media streams unless the KPML request document is used to suppress them.
ユーザがfocuslessデバイスに入力を提供する場合、マークアップメディアを抑制するためにUIに指示しない限り、実際には、入力は、全てのクライアントのローカルユーザインタフェースと、すべてのクライアントのリモートユーザインタフェースに渡さなければなりません。 KPMLの場合には、キーイベントが[19] RFC 4733に記載されているように、それらを符号化することによって、遠隔ユーザインターフェースに渡されます。クライアントは、メディアストリームがリモート・ユーザー・インターフェースで終了するかどうかを判断することはできませんので、KPML要求文書は、それらを抑制するために使用されていない限り、当然のことながら、これらのキーイベントは、すべてのオーディオメディアストリームに渡されます。
When the user interfaces run remotely, the determination of focus can be much, much harder. There are many architectures that can be deployed to handle the interaction. None are ideal. However, all are beyond the scope of this specification.
ユーザインターフェースはリモートで実行するとき、焦点の決意は、はるかに、はるかに困難であることができます。対話を処理するために展開することができ、多くのアーキテクチャがあります。どれも理想的ではありません。しかし、すべてはこの仕様の範囲を超えています。
An application can instantiate a multiplicity of user interface components. For example, a single application can instantiate two separate HTML components and one WML component. Furthermore, an application can instantiate both client-local and client-remote user interfaces.
アプリケーションは、ユーザ・インターフェース・コンポーネントの複数のインスタンスを作成することができます。例えば、単一のアプリケーションは、2つの別個のHTMLコンポーネントと一つWMLコンポーネントをインスタンス化することができます。さらに、アプリケーションは、クライアントのローカルおよびクライアントのリモートユーザインタフェースの両方をインスタンス化することができます。
The feature interaction issues between these components within the same application are less severe. If an application has multiple client user interface components, their interaction is resolved identically to the inter-application case -- through focus determination. However, the problems in focusless user devices (such as a keypad on a telephone) generally won't exist, since the application can generate user interfaces that do not overlap in their usage of an input.
同じアプリケーション内でこれらのコンポーネント間の機能的相互作用の問題はそれほど深刻です。フォーカス決意を介して - アプリケーションは、複数のクライアント・ユーザ・インタフェース・コンポーネントを有する場合、それらの相互作用は、アプリケーション間の場合と同一に解決されます。アプリケーションは、入力のその使用に重複しないユーザインターフェースを生成することができるので、（例えば電話のキーパッドなど）focuslessユーザ装置における問題は、一般に、存在しないであろう。
The real issue is that the optimal user experience frequently requires some kind of coupling between the differing user interface components. This is a classic problem in multi-modal user interfaces, such as those described by Speech Application Language Tags (SALT). As an example, consider a user interface where a user can either press a labeled button to make a selection, or listen to a prompt, and speak the desired selection. Ideally, when the user presses the button, the prompt should cease immediately, since both of them were targeted at collecting the same information in parallel. Such interactions are best handled by markups that natively support such interactions, such as SALT, and thus require no explicit support from this framework.
本当の問題は、最適なユーザーエクスペリエンスが頻繁に異なるユーザインタフェースコンポーネント間の結合のいくつかの種類を必要とすることです。これは、音声アプリケーション言語タグ（SALT）によって記載されているものなどのマルチモーダルユーザインタフェース、クラシックな問題です。例として、ユーザーが選択を行うために書かれたボタンを押すか、プロンプトに耳を傾け、そして所望の選択を話すことができるいずれかのユーザインタフェースを考えます。ユーザーがボタンを押したときに、それらの両方を並行して同じ情報を収集で標的にされたので、理想的には、プロンプトは、ただちに中止すべきです。そのような相互作用は最高のネイティブ塩などのような相互作用をサポートし、したがって、このフレームワークからの明示的なサポートを必要としないマークアップによって処理されます。
This section shows the operation of a call-recording application. This application allows a user to record the media in their call by clicking on a button in a web form. The application uses a presentation-capable user interface component that is pushed to the caller. The conventions of [17] are used to describe representation of long message lines.
このセクションでは、通話録音アプリケーションの動作を示しています。このアプリケーションは、Webフォームのボタンをクリックすることで、自分のコールでメディアを記録するユーザーに許可します。アプリケーションは、発信者にプッシュされるプレゼンテーション可能なユーザ・インターフェース・コンポーネントを使用します。 [17]の規則は、長いメッセージ行の表現を記述するために使用されます。
A Recording App B
|(1) INVITE | |
|----------------------->| |
| |(2) INVITE |
| |----------------------->|
| |(3) 200 OK |
| |<-----------------------|
|(4) 200 OK | |
|<-----------------------| |
|(5) ACK | |
|----------------------->| |
| |(6) ACK |
| |----------------------->|
|(7) REFER | |
|<-----------------------| |
|(8) 200 OK | |
|----------------------->| |
|(9) NOTIFY | |
|----------------------->| |
|(10) 200 OK | |
|<-----------------------| |
|(11) HTTP GET | |
|----------------------->| |
|(12) 200 OK | |
|<-----------------------| |
|(13) NOTIFY | |
|----------------------->| |
|(14) 200 OK | |
|<-----------------------| |
|(15) HTTP POST | |
|----------------------->| |
|(16) 200 OK | |
|<-----------------------| |
Figure 6
図6
First, the caller, A, sends an INVITE to set up a call (message 1). Since the caller supports the framework and can handle presentation-capable user interface components, it includes the Supported header field indicating that the GRUU extension and the Target-Dialog header field are understood, the Allow header field indicating that REFER is understood, and the Contact header field that includes the "schemes" header field parameter.
まず、発信者は、Aは、コール（メッセージ1）を設定するINVITEを送信します。発信者がフレームワークをサポートし、提示できるユーザ・インターフェース・コンポーネントを扱うことができるので、それはGRUU拡張とターゲット対話ヘッダフィールドが理解されていることを示すサポートされているヘッダ・フィールドを含む、それが参照示す許可ヘッダフィールドが理解され、接触され「スキーム」ヘッダフィールドパラメータを含むヘッダフィールド。
INVITE sip:B@example.com SIP/2.0 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller <sip:A@example.com>;tag=kkaz-To: Callee <sip:B@example.org> Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Max-Forwards: 70 Supported: gruu, tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER Accept: application/sdp, text/html <allOneLine> Contact: <sip:A@example.com;gr=urn:uuid:f81d4fae -7dec-11d0-a765-00a0c91e6bf6>;schemes="http,sip" </allOneLine> Content-Length: ... Content-Type: application/sdp
SIPのINVITE：B@example.com SIP / 2.0経由：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9zz8から：発信者<SIP：A@example.com>;タグ= kkaz-TO：呼び出し先<SIP： B@example.org>コール-IDを：fa77as7dad8-sd98ajzz@host.example.comのCSeq：マックス・フォワードを1 INVITE：70はサポートされている：GRUU、許可tdialog：受け入れ、INVITE OPTIONS、BYE、CANCEL、ACK、REFER：アプリケーション/ SDP、text / htmlの<allOneLine>連絡先：<SIP：A@example.com;グラム= URN：UUID：f81d4fae -7dec-11D0-a765-00a0c91e6bf6>;スキーム= "HTTP、SIP" </ allOneLine>コンテンツ長：...のContent-Type：アプリケーション/ SDP
--SDP not shown--
shown--ない--SDP
The proxy acts as a recording server, and forwards the INVITE to the called party (message 2). It strips the Record-Route it would normally insert due to the presence of the GRUU in the INVITE:
プロキシは、録画サーバとして機能し、被呼者（メッセージ2）にINVITEを転送します。それは、通常、原因INVITEでGRUUの存在に挿入するレコード・ルートを取り除き：
INVITE sip:B@pc.example.com SIP/2.0 Via: SIP/2.0/TLS app.example.com;branch=z9hG4bK97sh Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller <sip:A@example.com>;tag=kkaz-To: Callee <sip:B@example.org> Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Max-Forwards: 70 Supported: gruu, tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER Accept: application/sdp, text/html <allOneLine> Contact: <sip:A@example.com;gr=urn:uuid:f81d4fae -7dec-11d0-a765-00a0c91e6bf6>;schemes="http,sip" </allOneLine> Content-Length: ... Content-Type: application/sdp
SIPのINVITE：B@pc.example.com SIP / 2.0経由：SIP / 2.0 / TLS app.example.com;ブランチ= z9hG4bK97sh経由：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9zz8から：発信者<一口：A@example.com>;タグ= kkaz-TO：呼び出し先<SIP：B@example.org>コールID：fa77as7dad8-sd98ajzz@host.example.comのCSeqを70サポート：最大転送しINVITE 1 GRUUをtdialog許可：アプリケーション/ SDP、text / htmlの<allOneLine>連絡先：<SIP：A@example.com;グラム= URN：受け入れ、INVITE OPTIONS、BYE、CANCEL、ACK、REFER UUID：f81d4fae -7dec-11D0-a765を-00a0c91e6bf6>;スキーム= "HTTP、SIP" </ allOneLine>のContent-Length：...のContent-Type：アプリケーション/ SDP
--SDP not shown--
shown--ない--SDP
B accepts the call with a 200 OK (message 3). It does not support the framework, so the various header fields are not present.
Bは200 OK（メッセージ3）とのコールを受け付けます。様々なヘッダフィールドが存在しないので、それは、フレームワークをサポートしていません。
SIP/2.0 200 OK Via: SIP/2.0/TLS app.example.com;branch=z9hG4bK97sh Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller <sip:A@example.com>;tag=kkaz-To: Callee <sip:B@example.com>;tag=7777 Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Contact: <sip:B@pc.example.com> Content-Length: ... Content-Type: application/sdp
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS app.example.com;ブランチ= z9hG4bK97sh経由：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9zz8から：発信者<SIP：A@example.com>。呼び出し先<SIP：B@example.com> = kkaz-にタグ;タグ= 7777のCall-ID：fa77as7dad8-sd98ajzz@host.example.comのCSeq：連絡先を1 INVITE：<SIP：B@pc.example.com>コンテンツの長さ：...のContent-Type：アプリケーション/ SDP
--SDP not shown--
shown--ない--SDP
This 200 OK is passed back to the caller (message 4):
この200 OKは、発信者（メッセージ4）に戻されます。
SIP/2.0 200 OK Record-Route: <sip:app.example.com;lr> Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller <sip:A@example.com>;tag=kkaz-To: Callee <sip:B@example.com>;tag=7777 Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Contact: <sip:B@pc.example.com> Content-Length: ... Content-Type: application/sdp
SIP / 2.0 200 OK録音-ルート：<SIP：app.example.com; LR>ビア：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9zz8から：発信者<SIP：A@example.com>;タグ= kkaz-TO：呼び出し先<SIP：B@example.com>;タグ= 7777のCall-ID：fa77as7dad8-sd98ajzz@host.example.comのCSeq：1連絡先をINVITE：<SIP：B@pc.example.com>コンテンツ-length：...のContent-Type：アプリケーション/ SDP
--SDP not shown--
shown--ない--SDP
The caller generates an ACK (message 5).
呼び出し側はACK（メッセージ5）を生成します。
ACK sip:B@pc.example.com Route: <sip:app.example.com;lr> Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz9 From: Caller <sip:A@example.com>;tag=kkaz-To: Callee <sip:B@example.com>;tag=7777 Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 ACK
ACK SIP：B@pc.example.comルート：<SIP：app.example.com; LR>ビア：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9zz9から：発信者<SIP：A@example.com >;タグ= kkaz-TO：呼び出し先<SIP：B@example.com>;タグ= 7777のCall-ID：fa77as7dad8-sd98ajzz@host.example.comのCSeq：1 ACK
The ACK is forwarded to the called party (message 6).
ACKを着信側（メッセージ6）に転送されます。
ACK sip:B@pc.example.com Via: SIP/2.0/TLS app.example.com;branch=z9hG4bKh7s Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz9 From: Caller <sip:A@example.com>;tag=kkaz-To: Callee <sip:B@example.com>;tag=7777 Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 ACK
ACKのSIP：B@pc.example.com経由：SIP / 2.0 / TLS app.example.com;ブランチ= z9hG4bKh7s経由：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9zz9から：発信者<SIP：@ example.com>; = kkaz-へタグ：呼び出し先<SIP：B@example.com>;タグ= 7777のCall-ID：fa77as7dad8-sd98ajzz@host.example.comのCSeq：1 ACK
Now, the application decides to push a user interface component to user A. So, it sends it a REFER request (message 7):
今、アプリケーションはそのためユーザAへのユーザ・インターフェース・コンポーネントをプッシュすることを決定し、それはREFER要求（メッセージ7）を送信します。
<allOneLine> REFER sip:A@example.com;gr=urn:uuid:f81d4fae -7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 </allOneLine> Refer-To: https://app.example.com/script.pl Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com ;remote-tag=7777;local-tag=kkaz-Require: tdialog Via: SIP/2.0/TLS app.example.com;branch=z9hG4bK9zh6 Max-Forwards: 70 From: Recorder Application <sip:app.example.com>;tag=jhgf <allOneLine> To: Caller <sip:A@example.com;gr=urn:uuid:f81d4fae -7dec-11d0-a765-00a0c91e6bf6> </allOneLine> Require: tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER Call-ID: 66676776767@app.example.com CSeq: 1 REFER Event: refer Contact: <sip:app.example.com>
<allOneLine> SIP REFER：A@example.comと、GR = URN：UUID：f81d4fae -7dec-11D0-a765-00a0c91e6bf6 SIP / 2.0 </ allOneLine>参照の-TO：https://app.example.com/script。 PLターゲット対話：fa77as7dad8-sd98ajzz@host.example.com;リモートタグ= 7777;ローカルタグ= kkaz-要求：tdialogのVia：SIP / 2.0 / TLS app.example.com;分岐= z9hG4bK9zh6最大転送します。 5,441：レコーダアプリケーション<SIP：app.example.com>;タグ= jhgf <allOneLine>：を発信<SIP：A@example.com; GR = URN：UUID：f81d4fae -7dec-11D0-a765-00a0c91e6bf6> < / allOneLine>が必要：許可tdialog：66676776767@app.example.comのCSeq：コールIDをREFER、ACK、BYE、CANCEL、INVITE OPTIONS 1イベントを参照してください。連絡先を参照してください。<SIP：app.example.com>
Since the recording application is the same as the authoritative proxy for the domain, it resolves the Request URI to the registered contact of A, and then sent there. The REFER is answered by a 200 OK (message 8).
記録アプリケーションは、ドメインに対する権限のプロキシと同じであるので、Aの登録連絡先に要求URIを解決し、そしてそこ送ら。 REFER 200 OK（メッセージ8）によって回答されます。
SIP/2.0 200 OK Via: SIP/2.0/TLS app.example.com;branch=z9hG4bK9zh6 From: Recorder Application <sip:app.example.com>;tag=jhgf To: Caller <sip:A@example.com>;tag=pqoew Call-ID: 66676776767@app.example.com Supported: gruu, tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER <allOneLine> Contact: <sip:A@example.com;gr=urn:uuid:f81d4fae -7dec-11d0-a765-00a0c91e6bf6>;schemes="http,sip" </allOneLine> CSeq: 1 REFER
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS app.example.com;ブランチ= z9hG4bK9zh6から：レコーダーアプリケーション<一口：app.example.com>;タグ= jhgfへ：発信者<SIP：A@example.com> ;タグ= pqoewのCall-ID：66676776767@app.example.comサポート：GRUU、許可tdialog：<SIP：<allOneLine>連絡先REFER、ACK、CANCEL、BYE、INVITE OPTIONS A@example.comを、GR =壷：UUID：f81d4fae -7dec-11D0-a765-00a0c91e6bf6>;スキーム= "HTTP、SIP" </ allOneLine>のCSeq：1参照
User A sends a NOTIFY (message 9):
ユーザAは、NOTIFY（メッセージ9）を送信します。
NOTIFY sip:app.example.com SIP/2.0 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9320394238995 To: Recorder Application <sip:app.example.com>;tag=jhgf From: Caller <sip:A@example.com>;tag=pqoew Call-ID: 66676776767@app.example.com CSeq: 1 NOTIFY Max-Forwards: 70 <allOneLine> Contact: <sip:A@example.com;gr=urn:uuid:f81d4fae -7dec-11d0-a765-00a0c91e6bf6>;schemes="http,sip" </allOneLine> Event: refer;id=93809824 Subscription-State: active;expires=3600 Content-Type: message/sipfrag;version=2.0 Content-Length: 20
app.example.com SIP / 2.0経由：SIP NOTIFYのSIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9320394238995へ：レコーダーアプリケーション<一口：app.example.com>;からタグ= jhgf：発信者<SIP： A@example.com>;タグ= pqoewのCall-ID：66676776767@app.example.comのCSeq：1マックス-前方にNOTIFY：70 <allOneLine>連絡先：<SIP：A@example.com;グラム= URN：UUID： f81d4fae -7dec-11D0-a765-00a0c91e6bf6>;スキーム= "HTTP、SIP" </ allOneLine>イベント：参照; ID = 93809824サブスクリプション状態に：活性; = 3600 Content-Typeの有効期限：メッセージ/ sipfrag、バージョン= 2.0コンテンツ-length：20
SIP/2.0 100 Trying
SIP / 2.0 100試行
And the recording server responds with a 200 OK (message 10).
そして、録画サーバーは、200 OK（メッセージ10）で応答します。
SIP/2.0 200 OK Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9320394238995 To: Recorder Application <sip:app.example.com>;tag=jhgf From: Caller <sip:A@example.com>;tag=pqoew Call-ID: 66676776767@app.example.com CSeq: 1 NOTIFY
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9320394238995へ：レコーダーアプリケーション<一口：app.example.com>;タグ= jhgfから：発信者<SIP：A@example.com> ;タグ= pqoewのCall-ID：66676776767@app.example.comのCSeq：1 NOTIFY
The REFER request contained a Target-Dialog header field parameter with a valid dialog identifier. Furthermore, all of the signaling was over TLS and the dialog identifiers contain sufficient randomness. As such, the caller, A, automatically authorizes the application. It then acts on the Refer-To URI, fetching the script from app.example.com (message 11). The response, message 12, contains a web application that the user can click on to enable recording. Because the client executed the URL in the Refer-To, it generates another NOTIFY to the application, informing it of the successful response (message 13). This is answered with a 200 OK (message 14). When the user clicks on the link (message 15), the results are posted to the server, and an updated display is provided (message 16).
REFER要求は、有効なダイアログ識別子を有するターゲット対話ヘッダフィールドパラメータを含んでいました。さらに、シグナリングの全ては、TLSを超えていたし、ダイアログ識別子は、十分なランダム性を含んでいます。このように、発信者は、Aは、自動的にアプリケーションを許可します。次に、参照の-TO URI、app.example.comからスクリプトを取得する（メッセージ11）に作用します。応答、メッセージ12は、ユーザが録画を可能にするためにクリックできるWebアプリケーションが含まれています。クライアントが参照してください-にURLを実行しているので、それは別の正常な応答（メッセージ13）のそれを知らせる、アプリケーションにNOTIFYが生成されます。これは、200 OK（メッセージ14）と答えています。ユーザがリンク（メッセージ15）をクリックすると、結果がサーバにポストされ、更新された表示は、（メッセージ16）が設けられています。
There are many security considerations associated with this framework. It allows applications in the network to instantiate user interface components on a client device. Such instantiations need to be from authenticated applications, and also need to be authorized to place a UI into the client. Indeed, the stronger requirement is authorization. It is not as important to know the name of the provider of the application, as it is to know that the provider is authorized to instantiate components.
このフレームワークに関連する多くのセキュリティ上の考慮事項があります。これは、ネットワーク内のアプリケーションがクライアントデバイス上で、ユーザー・インタフェース・コンポーネントをインスタンス化することができます。このようなインスタンスは、認証されたアプリケーションからする必要があり、また、クライアントにUIを配置することを許可する必要があります。確かに、強い要件が承認されます。プロバイダは、コンポーネントのインスタンスを作成する権限があることを知っているように、アプリケーションの提供者の名前を知っているとして重要ではありません。
This specification defines specific authorization techniques and requirements. Automatic authorization is granted if the application can prove that it is on the call path, or is trusted by an element on the call path. As documented above, this can be accomplished by the use of cryptographically random dialog identifiers and the usage of SIPS for message confidentiality. It is RECOMMENDED that SIPS be implemented by user agents compliant to this specification. This does not represent a change from the requirements in RFC 3261.
この仕様は、特定の認証技術や要件が定義されています。アプリケーションがコール・パス上にある、またはコール・パス上の要素によって信頼されていることを証明できる場合、自動認可が付与されます。上記記載されているように、これは暗号ランダムダイアログ識別子を使用すると、メッセージの機密性のためのSIPSの使用によって達成することができます。この仕様に準拠ユーザエージェントによって実装することがSIPSことをお勧めします。これは、RFC 3261の要求事項からの変化を表すものではありません。
This document was produced as a result of discussions amongst the application interaction design team. All members of this team contributed significantly to the ideas embodied in this document. The members of this team were:
このドキュメントは、アプリケーションのインタラクションデザインチームの中での議論の結果として生成されました。このチームのすべてのメンバーは、この文書で具体アイデアに大きく貢献しました。このチームのメンバーは以下の通りでした。
Eric Burger Cullen Jennings Robert Fairlie-Cuninghame
エリックバーガーカレン・ジェニングスロバート・フェアリー - Cuninghame
The authors would like to thank Martin Dolly and Rohan Mahy for their input and comments. Thanks to Allison Mankin for her support of this work.
作者は彼らの入力とコメントのためのマーティン・ドリーとローハンマーイに感謝したいと思います。この作品の彼女のサポートのためのアリソンマンキンに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] 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.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[3]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[5] McGlashan, S., Lucas, B., Porter, B., Rehor, K., Burnett, D., Carter, J., Ferrans, J., and A. Hunt, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C CR CR-voicexml20- 20030220, February 2003.
[5] McGlashan、S.、ルーカス、B.、ポーター、B.、Rehor、K.、バーネット、D.、カーター、J.、Ferrans、J.、およびA. Huntの、「音声拡張マークアップ言語（ボイスXML ）バージョン2.0" 、W3C CR CR-voicexml20- 20030220、2003年2月。
[6] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[6]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[7] R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月、火花。
[8] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[8]バーガー、E.およびM.ドリー、 "Aセッション開始プロトコル（SIP）キーを押して刺激のためのイベントパッケージ（KPML）"、RFC 4730、2006年11月。
[9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[9]ローゼンバーグ、J.、RFC 5627、2009年10月 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェントのURI（GRUUs）を取得および使用方法"。
[10] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
、RFC 4538、2006年6月[10]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）におけるダイアログ識別介して要求承認"。
[11] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[11]ピーターソン、J.とC.ジェニングス、 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、RFC 4474、2006年8月。
[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[12]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[13] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[13]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼されたネットワーク内でアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[14] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[14]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[15] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[15]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、 "セッション開始プロトコル（SIP）のための発呼者が設定"、RFC 3841、2004年8月。
[16] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[16]、RFC 4235 "セッション開始プロトコル（SIP）のためのINVITEが開始ダイアログイベントパッケージ" ローゼンバーグ、J.、Schulzrinneと、H.、およびR.マーイ、2005年11月。
[17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[17]スパークス、R.、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）調教テストメッセージ"、RFC 4475、2006年5月。
[18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[18] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[19] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[19] Schulzrinneと、H.、およびT.テイラー、 "DTMFケタ、電話トーン、およびテレフォニーシグナルのためのRTPペイロード"、RFC 4733、2006年12月。
[20] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[20]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[21] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[21]ローゼンバーグ、J.、 "Aセッション開始プロトコル（SIP）登録のためのイベントパッケージ"、RFC 3680、2004年3月。
Author's Address
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@cisco.com URI：http://www.jdrosen.net