[要約] RFC 5629は、SIPにおけるアプリケーション間の相互作用のためのフレームワークを提供するものであり、SIPセッションの制御とアプリケーションの連携を容易にすることを目的としています。
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)
セッション開始プロトコル（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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたは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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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".
ほとんどのアプリケーションが適切に機能するためには、操作をガイドするためにユーザーからの入力が必要です。例として、プリペイドのコーリングカードアプリケーションでは、ユーザーがコーリングカード番号、ピンコード、および到達したい宛先番号を入力する必要があります。ユーザーがアプリケーションへの入力を提供するプロセスは、「アプリケーションインタラクション」と呼ばれます。
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]
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
ユーザーインターフェイスコンポーネント：ユーザーインターフェイスの他のピースとは独立して動作するユーザーインターフェイスの一部。たとえば、ユーザーは、プリペイドコーリングカードアプリケーションに2つの個別のWebインターフェイスを持っている場合があります。1つはハングアップして別の電話をかけるため、もう1つはユーザー名とPINを入力するためです。
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.
ユーザーデバイス：ユーザーが直接対話してアプリケーションと通信するソフトウェアまたはハードウェアシステム。ユーザーデバイスの例は電話です。別の例は、Webブラウザーを備えた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.
ユーザーデバイスプロキシ：ユーザーが間接的に対話してアプリケーションと通信するソフトウェアまたはハードウェアシステム。この間接は、ネットワークを介して行うことができます。例は、IPから公開された電話ネットワーク（PSTN）へのゲートウェイです。これは、サーキットネットワーク上のユーザーに代わって機能するユーザーデバイスプロキシとして機能します。
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.
Interactive Voice Response（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.
Barge-in：その情報を要求するプロンプトが完了する前に、情報を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.
フォーカスレスデバイス：フォーカス決定を実行する能力がないユーザーデバイス。フォーカスレスデバイスの例は、キーパッド付きの電話です。
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とキーパッド入力は同義語でよく使用されますが、実際には1つ（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.
仲介アプリケーション：発信者でもCalleeでも、電話に関与する第三者でもない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.
ユーザーインターフェイスには、通常、ユーザーに対してリアルタイムの要件があります。つまり、ユーザーがユーザーインターフェイスと対話する場合、ユーザーインターフェイスは迅速に反応する必要があり、その変更をすぐにユーザーに伝播する必要があります。ただし、ユーザーインターフェイスとアプリケーションの間のインターフェイスは、それほど速くする必要はありません。より速い方が優れていますが、ユーザーインターフェイス自体は、ユーザーインターフェイスとアプリケーションの間の長いレイテンシを頻繁に補償できます。プリペイドコーリングカードアプリケーションの場合、ユーザーがピンの入力を求められた場合、ピンの最初の数字が入力されると、通常、プロンプトはすぐに停止するはずです。これは「バージイン」と呼ばれます。ユーザーインターフェイスがピンの残りの部分を収集した後、ユーザーに「処理中に待ってください」と指示できます。その後、ピンをアプリケーションに徐々に送信できます。この例では、ユーザーインターフェイスは、ユーザーに待機を求めることにより、遅い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.
この基本モデルを使用すると、構築できるシステムの種類を分類し始めることができます。
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.
システムを分類する最初の方法は、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.
別の方法は、刺激インターフェイスです。刺激インターフェイスでは、ユーザーインターフェイスは一般的です。つまり、アプリケーションの詳細については完全に無知です。実際、アプリケーションは、どのように動作するかを説明するユーザーインターフェイスに手順を渡すことができます。ユーザーインターフェイスは、ユーザーの入力を「刺激」に変換します。これは、アプリケーションのみが理解しているデータであり、ユーザーインターフェイスによっては理解されていません。それらは一般的であり、ユーザーへの情報を提供する方法を変更するためにアプリケーションとの通信を必要とするため、ユーザーインターフェイスは通常、機能的な対応物よりも遅く、ユーザーフレンドリーで、応答性が低くなります。ただし、ユーザーインターフェイスメカニズムの範囲内でユーザーと対話できる限り、新しいアプリケーションを構築するために標準化アクティビティが必要ではないため、アプリケーションの大幅なイノベーションを可能にします。Webは、アプリケーションへの刺激ユーザーインターフェイスの例です。
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ページを使用して、No-Answerアプリケーションでコールフォワードの転送番号を設定できます。リアルタイムインタラクションでは、ユーザーが呼び出し時にアプリケーションと対話する必要があります。
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.
分類法の別の軸は、ユーザーインターフェイスがユーザーデバイス（クライアントローカルユーザーインターフェイスと呼ばれる）と共同居住しているか、ユーザーインターフェイスがクライアントから分離されたホストで実行されるかどうかです（これはと呼ばれます。クライアントリモートユーザーインターフェイス）。クライアントリモートユーザーインターフェイスでは、クライアントデバイスと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]の操作の古典的なモードであり、ユーザーインターフェイス（Voice Browserとも呼ばれる）がネットワーク内のプラットフォームで実行されます。ユーザーは、電話ネットワークを介して音声ブラウザと通信します（またはSIPセッションを使用します）。Voice Browserは、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では、ユーザーインターフェイスはWebブラウザーであり、インターフェイスはHTMLドキュメントでレンダリングを定義しています。ユーザーは、ブラウザで実行されているユーザーインターフェイスと直接対話します。そのユーザーインターフェイスの結果は、HTTPを使用してアプリケーション（Webサーバーで実行）に送信されます。
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によってガイドされているユーザーインターフェイスは、クライアントからリモートで「ネットワークで」実行されるようになりました。同様に、Media Streamはまったくありません。実際、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は、入力ごとにユーザーにフィードバックを提供し、次の入力を収集するためのコンテキストを提供できます。その結果、プレゼンテーションで利用可能なユーザーインターフェイスには、各入力後にユーザーに提供される情報の更新が必要です。Webはこの典型的な例です。入力ごと（つまり、クリック）の後、ブラウザはアプリケーションに入力を提供し、次のページをフェッチしてレンダリングします。プレゼンテーションのないユーザーインターフェイスでは、そうではありません。ユーザーにはフィードバックが提供されていないため、これらのユーザーインターフェイスは、入力したときに情報を収集し、アプリケーションに渡す傾向があります。
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つの違いは、プレゼンテーションのないユーザーインターフェイスがフォーカスの概念を簡単にサポートできないことです。通常、フォーカスの選択には、利用可能なアプリケーションをユーザーに通知し、ユーザーが選択したものを選択できるようにするための手段が必要です。最初と3番目のステップ（プレゼンテーションのない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つの方法のいずれかで伝達できます。1つ目は、キーパッド入力をDTMFに変換し、適切なエンコードアルゴリズム（PCMUなど）を使用してそのDTMFを伝えることです。別の、そして一般的に好ましいアプローチは、RFC 4733 [19]を使用してキーパッド入力を送信することです。これは、RTP内でキーパッド入力を運ぶためのエンコーディングメカニズムを提供します。
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.
代替モデルは、ユーザーインターフェイス全体が電話に居住するためのものです。ユーザーインターフェイスは、VoiceXMLブラウザであり、マイク入力で音声認識を実行し、キーパッド入力をスクリプトに直接フィードすることができます。上記で説明したように、電話にテキスト表示がある場合、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.
中間のアプローチは、クライアントローカルとクライアントリモートのユーザーインターフェイスの間を行き来することです。多くの音声アプリケーションは、メディアストリームを聴き、より複雑なユーザーインタラクションを開始する特定のトリガーを待つタイプです。プリペイドのコーリングカードアプリケーションの長いポンドは1つの例です。別の例は、会議録音アプリケーションです。この場合、ユーザーは呼び出しのある時点でキーを押して録音を開始できます。キーが押されると、ユーザーはささやき声を聞き、録音が開始されたことを知らせます。
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イベントになる可能性があります。また、Webフォームの投稿やタイマーなどの非SIPイベントにすることもできます。アプリケーションインスタンスには終了時間もあります。一部のインスタンスには、SIPトランザクションまたはダイアログと組み合わされた寿命があります。たとえば、招待状が到着したときにプロキシアプリケーションが開始され、通話に応答したときに終了する場合があります。他のアプリケーションには、複数のダイアログまたはトランザクションにまたがる寿命があります。たとえば、接続されたダイアログがある限り、会議アプリケーションインスタンスが存在する場合があります。最後のダイアログが終了すると、アプリケーションインスタンスが終了します。他のアプリケーションには、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.
ここで説明されているフレームワークにとって、複数のアプリケーションインスタンスが1回のSIPトランザクションまたはダイアログ中にユーザーと対話できる可能性があることが基本的です。各インスタンスは、同じアプリケーションまたは異なるアプリケーション用である場合があります。それぞれが異なるプロバイダーによって所有されている可能性があり、お互いの存在を認識していない可能性があるという点で、各アプリケーションは完全に独立している可能性があります。同様に、同じトランザクションまたはダイアログ内の両方で、呼び出し元と相互作用するアプリケーションインスタンスがあり、Calleeと相互作用するインスタンスがあります。
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].
ユーザーインターフェイスコンポーネントは、ダイアログ（クライアントローカルユーザーインターフェイスの場合）またはネットワーク要素（クライアントリモートユーザーインターフェイスの場合）内のユーザーエージェントの1つにインスタンス化できます。クライアントローカルユーザーインターフェイスを使用する場合、アプリケーションは、ユーザーエージェントがクライアントローカルユーザーインターフェイスをサポートできるかどうか、およびどの形式でサポートできるかどうかを判断する必要があります。このフレームワークでは、すべてのクライアントローカルユーザーインターフェイスコンポーネントがマークアップ言語で説明されています。マークアップ言語は、ユーザーへの情報の表示の論理的なフロー、ユーザーからの情報のコレクション、およびその情報のアプリケーションへの送信を説明します。マークアップ言語の例には、HTML、ワイヤレスマークアップ言語（WML）、VoiceXML、およびキーパッドマークアップ言語（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が含まれており、参照にはユーザーインターフェイスコンポーネントに関連付けられたダイアログを識別するターゲットダイアログヘッダーフィールド[10]が含まれています。プレゼンテーションフリー（KPMLで定義されているものなど）のユーザーインターフェイスコンポーネントの場合、アプリケーションはユーザーエージェントにサブスクライブリクエストを送信します。購読要求の本文にはフィルターが含まれています。この場合、情報が通知でアプリケーションに送信される時期を定義するマークアップです。サブスクライブには、イベントヘッダーフィールドで同等の情報が伝えられるため、ターゲットダイアログヘッダーフィールドは含まれていません。
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フォームポスト操作が使用されます。プレゼンテーションのないユーザーインターフェイスの場合、SIP通知が使用されます。セクション4.4で説明されているように、これら2つのユーザーインターフェイスのニーズと機能が異なることは、相互作用のさまざまな選択を促進するものです。プレゼンテーション対応のユーザーインターフェイスには、ユーザーデータが入力されるたびにプレゼンテーションの更新が必要なため、HTTPに適しています。プレゼンテーションのないユーザーインターフェイスは、ユーザー入力をアプリケーションに送信するだけなので、通知がより適切です。
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.
実際、プレゼンテーションのないユーザーインターフェイスには、2つの異なる操作モダリティがあります。最初は「ワンショット」と呼ばれます。ワンショットの役割では、マークアップはユーザーがいくつかの情報を入力するのを待っており、そうすると、このイベントをアプリケーションに報告します。その後、アプリケーションは何かを行い、マークアップは使用されなくなりました。「モニター」と呼ばれる他のモダリティでは、マークアップは永続的に居住したままであり、関連するダイアログが終了するまでアプリケーションに情報を報告します。
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ダイアログの外側に存在します。その場合、アプリケーションは、ダイアログの識別子とともに、いくつかの帯域外の平均を通じて、ダイアログの開始と終了について学習します。そのような可能性の1つは、ダイアログイベントパッケージです[16]。ダイアログ情報は信頼できる当事者にのみ明らかにされるため、この情報を取得するには、ユーザーの1人が申請を信頼する必要があります。
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).
ダイアログの任意の時点で、アプリケーションは発信者またはCalleeのユーザーデバイスのユーザーインターフェイスコンポーネントをインスタンス化できます。これは、ユーザーインターフェイスのタイプ（プレゼンテーション可能またはプレゼンテーション無料）に応じて、購読または参照のいずれかを使用して行うことができます。
+--------+ 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人（上の写真の右側のもの）と共同住宅です。このアプリケーションは、ユーザーデバイスとして機能する他のユーザーエージェントにクライアントローカルユーザーインターフェイスコンポーネントをインストールできます。これらのコンポーネントは、プレゼンテーションのないユーザーインターフェイスの場合は、プレゼンテーション対応のインターフェイスについては、どちらのサブスクライブを使用してインストールできます。この状況は、通常、アプリケーションがプレゼンテーション対応のユーザーインターフェイスに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のようにサードパーティのアプリケーションがあります。ただし、エンドユーザーデバイスにユーザーインターフェイスコンポーネントをインストールする代わりに、コンポーネントはユーザーデバイスプロキシとして知られる中間デバイスにインストールされます。実際のユーザーデバイス（左側）の観点から見ると、ユーザーデバイスプロキシはクライアントリモートユーザーインターフェイスです。そのため、通常、RTP（ユーザー入力を運ぶためにRFC 4733を含む）を使用して輸送されるメディアは、ユーザーデバイスからユーザーデバイスプロキシのクライアントリモートユーザーインターフェイスに送信されます。アプリケーションに関する限り、ユーザーデバイスのクライアントローカルユーザーインターフェイスであると思われるものをインストールしていますが、アプリケーションのユーザーデバイスのように見えるユーザーデバイスプロキシにあります。
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]。ユーザーデバイスプロキシは、メディアストリームで受信したユーザー入力をユーザーインターフェイスに報告されたイベントに変換するために、各ダイアログに関連付けられたメディアストリームを監視する必要があります。これは、マルチメディアシステムで課題をもたらす可能性があります。マルチメディアシステムでは、ユーザーの入力が送信されているメディアストリーミングが不明になる可能性があります。RFC 3264 [20]で説明したように、ユーザーエージェントが単一のメディアソースを持ち、複数のストリームをサポートしている場合、そのソースをすべてのストリームに送信することになっています。複数のソースがある場合、マッピングはローカルポリシーの問題です。どのソースをどのストリームにマップするかを明示的に識別または要求する方法がない場合、ユーザーデバイスプロキシはできる限り最高の仕事をする必要があります。この仕様では、ユーザーデバイスプロキシが最初のストリームを監視することを推奨しています（セッションの説明内でメディアセッションの順序付けに関して定義されています）。そのため、ユーザーエージェントは、最初のストリームにユーザーの入力を送信する必要があります。
+----------+
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つまたは両方のユーザーデバイスにユーザーインターフェイスコンポーネントのインストールを参照してください。
This topology is common in routing applications, such as a web-assisted call-routing application.
このトポロジは、Webアシストされたコールルーティングアプリケーションなど、ルーティングアプリケーションで一般的です。
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.
このフレームワークの重要なコンポーネントの1つは、クライアントローカルユーザーインターフェイスのサポートです。
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の両方によって宣言されます。Allow HeaderフィールドがSIPサブスクライブメソッドのサポートを示し、Allow-Event HeaderフィールドがKPMLパッケージのサポート[8]を示し、サポートされているヘッダーフィールドは、グローバルにルーティング可能なUA URI（GRUU）[9]仕様のサポートを示している場合（これは、コンタクトヘッダーフィールドにGruuが含まれていることを意味します）、UAがプレゼンテーションのないユーザーインターフェイスコンポーネントをインスタンス化できることを意味します。この場合、アプリケーションは、セクション8.1.2のルールに従って、プレゼンテーションのないユーザーインターフェイスコンポーネントをプッシュできます。サポートできる特定のマークアップ言語は、受け入れヘッダーフィールドに示されています。
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]を示し、接触ヘッダーフィールドにはHTTP URIスキームのサポートを示すUA機能[6]が含まれている場合、それは、UAがプレゼンテーション対応ユーザーインターフェイスコンポーネントをサポートすることを意味します。この場合、アプリケーションは、セクション8.1.2のルールに従って、プレゼンテーションに対応するユーザーインターフェイスコンポーネントをクライアントにプッシュできます。サポートされている特定のマークアップは、受け入れヘッダーフィールドに示されています。
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].
コールパスに存在しないサードパーティのアプリケーションは、通過するダイアログ開始要求でこれらのヘッダーフィールドを認識しません。そのため、この機能情報を他の方法で取得する必要があります。1つの方法は、登録イベントパッケージ[21]を使用することです。これには、レジスタリクエスト[6]で提供されるユーザーエージェント機能情報を含めることができます。
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の場合、これは、アプリケーションがダイアログ作成応答の受信を確認するリクエストが表示されるまで、アプリケーションが招待されたダイアログのユーザーインターフェイスコンポーネントをプッシュしてはならないことを意味します。これは、200 OKのACK、または暫定的な反応のためのプラックである可能性があります[3]。購読しているダイアログの場合、アプリケーションがNotifyリクエストに200 OKが表示されるまで、アプリケーションはユーザーインターフェイスコンポーネントをプッシュしてはなりません。UASのユーザーインターフェイスコンポーネントの場合、アプリケーションは、UASからのダイアログ作成応答が表示されるまで、招待されたダイアログのユーザーインターフェイスコンポーネントをプッシュしてはなりません。購読しているダイアログの場合、通知者からの通知要求が表示されるまで、ユーザーインターフェイスコンポーネントをプッシュしてはなりません。
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が送信したダイアログ開示要求または応答の連絡先ヘッダーフィールドでそのuaによって宣伝されたgruu [9]に送信する必要があります。この参照要求は、アプリケーションとUAの間に個別のダイアログを作成することに注意してください。参照要求の参照ヘッダーフィールドには、フェッチするマークアップドキュメントを参照する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.
さらに、参照要求がユーザーインターフェイスコンポーネントが関連付けられるダイアログと相関することが不可欠です。これは、ダイアログが終了したときに認可され、ユーザーインターフェイスコンポーネントを終了するために必要です。このコンテキストを提供するには、参照要求には、ユーザーインターフェイスコンポーネントが関連付けられているダイアログを識別するターゲットダイアログヘッダーフィールドを含める必要があります。[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にサブスクライブリクエストを送信します。購読は、UAによって宣伝されたGruuに送信する必要があります。この購読要求は、個別のダイアログを作成します。購読要求は、KPML [8]イベントパッケージを使用する必要があります。購読要求の本文には、アプリケーションにユーザー入力の通知を希望する条件を定義するマークアップドキュメントが含まれています。
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:
From: "Prepaid Calling Card" <sip: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ポスト操作がアプリケーションにユーザー入力をプッシュします。ポスト操作の結果は、UIが使用することになっている新しいマークアップです。これにより、ユーザーアクションに応じてUIを更新できます。HTMLなどの一部のマークアップは、ユーザー入力なしでUIを更新できるように、一定期間後に更新を強制する機能を提供します。これらのメカニズムもここで使用できます。ただし、アプリケーションからユーザーエージェントへの更新されたUIコンポーネントの非同期プッシュに対するサポートはありません。同じGruuへの新しい紹介要求は、既に導入されているコンポーネントを更新するのではなく、新しいUIコンポーネントを作成します。
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の場合、ストーリーは異なります。アプリケーションは、新しいフィルターでサブスクライブリフレッシュを生成することにより、いつでもフィルターを更新できます。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.
ただし、アプリケーションが自然な終端ポイントの前にユーザーインターフェイスコンポーネントを終了する場合があります。プレゼンテーション対応のユーザーインターフェイスの場合、これは不可能です。プレゼンテーションのないユーザーインターフェイスの場合、アプリケーションは、有効期限がゼロになるようなサブスクライブを送信することにより、コンポーネントを終了する場合があります。これにより、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の場合、これはユーザーがWebフォームウィンドウを却下することに類似しています。この種のイベントをアプリケーションに報告するためのメカニズムは提供されていません。アプリケーションをタイムアウトするために準備し、ユーザーから入力を受け取らないでください。このタイムアウトの期間はアプリケーションに依存します。プレゼンテーションのないユーザーインターフェイスの場合、UAはサブスクリプションを明示的に終了できます。これにより、「終了」に等しいサブスクリプションヘッダーフィールドを使用した通知の生成が行われます。
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.
ユーザーエージェントがプレゼンテーション対応ユーザーインターフェイスをサポートする場合、参照方法をサポートする必要があります。すべてのダイアログ開始リクエストと応答に、参照方法を含む許容ヘッダーフィールドを含める必要があります。ユーザーエージェントは、ターゲットダイアログ仕様[10]をサポートする必要があり、ダイアログ形成リクエストと応答のサポートされているヘッダーフィールドに「TDialog」オプションタグを含める必要があります。さらに、UAはSIPユーザーエージェント機能の仕様[6]をサポートする必要があります。UAはHTTP URIを紹介できる必要があります。ダイアログ開始リクエストと応答の連絡先ヘッダーフィールドには、HTTP URIスキームを含む「スキーム」コンタクトヘッダーフィールドパラメーターを含める必要があります。UAには、すべてのダイアログ開始リクエストと応答に、UAがサポートするすべてのマークアップをリストするヘッダーフィールドを受け入れる必要があります。プレゼンテーション対応のユーザーインターフェイスをサポートするすべてのユーザーエージェントが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 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.
ユーザーエージェントがプレゼンテーションのないユーザーインターフェイスをサポートしている場合、サブスクライブ[4]メソッドをサポートする必要があります。KPML [8]イベントパッケージをサポートする必要があります。すべてのダイアログ開始リクエストと応答に、購読メソッドを含む許可ヘッダーフィールドを含める必要があります。すべてのダイアログ開始リクエストと応答に、KPMLイベントパッケージをリストするAllow-Iventsヘッダーフィールドを含める必要があります。UAには、すべてのダイアログ開始リクエストと応答に、サポートするイベントフィルターをリストするヘッダーフィールドを受け入れる必要があります。少なくとも、UAは「Application/KPML-Request 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]仕様をサポートする必要があります。すべてのダイアログ開始リクエストと応答の連絡先ヘッダーフィールドには、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に対する購読または参照リクエストを受信する準備をする必要があります。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.
ユーザーエージェントには、ユーザーインターフェイスコンポーネントをプッシュする特定のIDで自らを認証したアプリケーションを許可する事前定義された承認ポリシーがある場合があります。そのような一連のポリシーが存在する場合、最初にチェックされます。アプリケーションが承認されている場合、処理が進みます。
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.
アプリケーションが自体を認証しているが、明示的に承認またはブロックされていない場合、この仕様は、コールパス上にあるか、コールパス上の要素の1つによって信頼されていることを証明できる場合、アプリケーションが自動的に承認されることを推奨します。アプリケーションは、ダイアログ識別子を知っていることを実証することにより、これをユーザーエージェントに証明します。これは、参照リクエストのターゲットダイアログヘッダーフィールド、またはKPMLサブスクライブリクエストのイベントヘッダーフィールドパラメーターにそれらを含めることによって発生します。
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ビットのランダム性を持つ暗号化的にランダムなダイアログ識別子を使用する必要があります。このランダム性は、UACの場合は、Call-IDとヘッダーフィールドタグの間に分割することをお勧めします。
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つは、ユーザーにアプリケーションの身元とそれが関連付けられているダイアログを通知することです。許可ポリシーがユーザーの相互作用を必要とする場合、ユーザーエージェントは202でサブスクライブまたはリクエストに応答する必要があります。購読の場合、許可が許可されていない場合、ユーザーエージェントはサブスクリプションを終了するために通知を生成する必要があります。紹介の場合、ユーザーエージェントは、ユーザー許可が取得されるまで、紹介ヘッダーフィールドの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.
アプリケーションが紹介または購読要求に有効なダイアログ識別子を提示しない場合、ユーザーエージェントは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を実行し、ユーザーにレンダリングするコンテンツを取得します。これにより、プレゼンテーションに対応できるユーザーインターフェイスコンポーネントがインスタンス化されます。購読が承認された場合、プレゼンテーションのないユーザーインターフェイスコンポーネントがインスタンス化されます。
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.
プレゼンテーションのないユーザーインターフェイスの場合、アプリケーションは、新しいフィルターでサブスクライブの更新を送信することにより、コンポーネントに更新をプッシュできます。ユーザーエージェントは、イベントパッケージのルールに従ってこれらを処理します。
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は「終了」と「拒否された」理由に等しいサブスクリプションヘッダーフィールドを使用して通知要求を生成する必要があります。これにより、コンポーネントが削除され、再登録を試みてはならないことがアプリケーションに伝えられます。
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つ取得し、録音アプリケーションは「Start/ Stop」コマンドの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 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.
残念ながら、すべてのデバイスがこれらの高度なディスプレイを持っているわけではありません。PSTNゲートウェイ、または基本的なIP電話には、12キーキーパッドのみがあります。これらのデバイスのユーザーインターフェイスは、キーパッドマークアップ言語（KPML）を介して提供されます。上記の機能相互作用ケースをもう一度考慮して、プリペイドのコーリングカードアプリケーションとコール録音アプリケーションは両方ともKPMLドキュメントをデバイスに渡します。ユーザーがキーパッドのボタンを押すと、入力はどのドキュメントに適用されますか？デバイスでは、ユーザーが選択できません。ユーザーがフォーカスを提供できないデバイスは、「フォーカスレスデバイス」と呼ばれます。これは解決するのが非常に難しい問題です。このフレームワークは明示的な規範的推奨を行いませんが、1つのインターフェイスのマークアップが他のインターフェースから抑制されるべきであることを示していない限り、両方のユーザーインターフェイスに入力を送信することが最良のオプションであると結論付けています。これは類推による賢明な選択です - それはまさに既存のサーキット切り替えの電話ネットワークが行うことです。これは、PSTNで行うのと同じユーザーインターフェイスを持つデバイス上のPSTNよりも、機能相互作用解像度のより良いメカニズムを提供することは明示的な非ゴールです。PCSやScreen Phoneなどのより良いディスプレイを備えたデバイスは、このフレームワークの機能の恩恵を受けることができ、ユーザーが相互作用しているアプリケーションを決定できるようにします。
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.
実際、ユーザーがフォーカスレスデバイスに入力を提供する場合、マークアップがUIにメディアを抑制するように指示しない限り、すべてのクライアントローカルユーザーインターフェイスとすべてのクライアントリモートユーザーインターフェイスに入力を渡す必要があります。KPMLの場合、RFC 4733 [19]に記載されているように、それらをエンコードすることにより、主要なイベントがリモートユーザーインターフェイスに渡されます。もちろん、クライアントはメディアストリームがリモートユーザーインターフェイスで終了するかどうかを判断できないため、これらの主要なイベントは、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コンポーネントと1つの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.
同じアプリケーション内のこれらのコンポーネント間の特徴的な相互作用の問題は、それほど深刻ではありません。アプリケーションに複数のクライアントユーザーインターフェイスコンポーネントがある場合、それらの相互作用は、フォーカス決定により、アプリケーション間のケースと同じように解決されます。ただし、アプリケーションが入力の使用に重複しないユーザーインターフェイスを生成できるため、フォーカスレスユーザーデバイス（電話のキーパッドなど）の問題は一般に存在しません。
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）。発信者はフレームワークをサポートし、プレゼンテーションに対応するユーザーインターフェイスコンポーネントを処理できるため、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
--SDP not 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）。招待状に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
--SDP not 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
--SDP not 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
--SDP not 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
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 Now, the application decides to push a user interface component to user A. So, it sends it a REFER request (message 7):
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今、アプリケーションは、アプリケーションが決定することを決定します。ユーザーインターフェイスコンポーネントからユーザーA.したがって、参照要求（メッセージ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>
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).
録音アプリケーションはドメインの権威あるプロキシと同じであるため、Request URIを登録されたAの連絡先に解決し、そこに送信します。参照は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 User A sends a NOTIFY (message 9):
sip/2.0 200 ok via：sip/2.0/tls app.example.com; branch = z9hg4bk9zh6 from：レコーダーアプリケーション<sip：app.example.com>; tag = jhgf to：caller <sip：a@example.com>; tag = pqoew call-id：66676776767@app.example.comサポート：gruu、tdialog loction：招待、オプション、さようなら、キャンセル、ack、紹介<alloneline>連絡先：<sip：a@example.com; gr = urn：UUID：F81D4FAE -7DEC-11D0-A765-00A0C91E6BF6>; schemes = "http、sip" </alloneline> cseq：1ユーザーを参照する通知（メッセージ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
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
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).
参照要求には、有効なダイアログ識別子を備えたターゲットダイアログヘッダーフィールドパラメーターが含まれていました。さらに、すべてのシグナルはTLSを超えており、ダイアログ識別子には十分なランダム性が含まれています。そのため、発信者aはアプリケーションを自動的に承認します。次に、uriに参照して、app.example.com（メッセージ11）からスクリプトを取得します。応答、メッセージ12には、ユーザーがクリックして録音を有効にできるWebアプリケーションが含まれています。クライアントは紹介でURLを実行したため、アプリケーションに別の通知を生成し、成功した応答を通知します（メッセージ13）。これには、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.
この仕様は、特定の承認技術と要件を定義します。アプリケーションがコールパス上にあることを証明できる場合、またはコールパスの要素によって信頼されている場合、自動認証が許可されます。上記のように、これは、暗号的にランダムなダイアログ識別子の使用と、メッセージの機密性のためのSIPの使用によって実現できます。SIPは、この仕様に準拠したユーザーエージェントによって実装することをお勧めします。これは、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
エリック・バーガー・カレン・ジェニングス・ロバート・フェアリー・カニンガメ
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.
著者は、Martin DollyとRohan Mahyの意見とコメントに感謝したいと思います。この作品を支持してくれたアリソン・マンキンに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[3] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach、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.、Lucas、B.、Porter、B.、Rehor、K.、Burnett、D.、Carter、J.、Ferrans、J。、およびA. Hunt、 "Voice Extensible Markup Language（VoiceXML）バージョン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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[7] Sparks、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] Burger、E。and M. Dolly、「キープレス刺激用のセッション開始プロトコル（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] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（Gruus）を取得および使用」、RFC 5627、2009年10月。
[10] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[10] Rosenberg、J。、「セッション開始プロトコル（SIP）でのダイアログ識別による承認を要求する」、RFC 4538、2006年6月。
[11] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[11] Peterson、J。and C. Jennings、「セッション開始プロトコル（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] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[14] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[14] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[15] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[15] Rosenberg、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] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、「セッション開始プロトコル（SIP）の招待状のダイアログイベントパッケージ」、RFC 4235、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] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、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.、Frederick、R。、およびV. Jacobson、「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. Taylor、「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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[21] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[21] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、2004年3月。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net