Network Working Group R. Shacham
Request for Comments: 5631 H. Schulzrinne
Category: Informational Columbia University
S. Thakolsri
W. Kellerer
DoCoMo Euro-Labs
October 2009
Session Initiation Protocol (SIP) Session Mobility
Abstract
抽象
Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is an informational document.
セッションモビリティは、別のデバイスからの進行中の通信セッションのメディアの転送です。この文書では、基本的な方法を説明し、セッション開始プロトコル（SIP）を使用してこのサービスを提供するためのシグナリングとメディアフローの例を示します。サービス発見は、セッション転送のための目標を見つけることが不可欠であり、例として、サービスロケーションプロトコル（SLP）を使用して議論されています。この文書は情報提供文書です。
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンスに関するお知らせ
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow 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トラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Overview ........................................................3
2. Requirements ....................................................4
3. Roles of Entities ...............................................4
4. Device Discovery ................................................5
5. Session Mobility ................................................7
5.1. Options for Session Mobility ...............................7
5.1.1. Transfer and Retrieval ..............................7
5.1.2. Whole and Split Transfer ............................7
5.1.3. Transfer Modes ......................................8
5.1.3.1. Mobile Node Control (MNC) Mode .............8
5.1.3.2. Session Handoff (SH) Mode ..................8
5.1.4. Types of Transferred Media ..........................8
5.2. Addressing of Local Devices ................................9
5.3. Mobile Node Control Mode ..................................10
5.3.1. Transferring a Session to a Single Local Device ....10
5.3.1.1. RTP Media .................................10
5.3.1.2. MSRP Sessions .............................11
5.3.2. Transfer to Multiple Devices .......................13
5.3.3. Retrieval of a Session .............................16
5.4. Session Handoff (SH) mode .................................16
5.4.1. Transferring a Session to a Single Local Device ....16
5.4.2. Retrieval of a Session .............................19
5.4.3. Transfer to Multiple Devices .......................21
5.5. Distributing Sessions for Incoming Call ...................23
5.6. Use of ICE in Session Mobility ............................24
6. Reconciling Device Capability Differences ......................25
6.1. Codec Differences .........................................25
6.2. Display Resolution and Bandwidth Differences ..............27
7. Simultaneous Session Transfer ..................................27
8. Session Termination ............................................28
9. Security Considerations ........................................29
9.1. Authorization for Using Local Devices .....................29
9.2. Maintaining Media Security During Session Mobility ........29
9.2.1. Establishing Secure RTP Using SDP ..................29
9.2.2. Securing Media Using the Transport Layer ...........31
9.3. Flooding Attacks in MNC Mode ..............................31
10. Acknowledgments ...............................................32
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................33
As mobile devices improve and include more enhanced capabilities for IP-based multimedia communications, they will remain limited in terms of bandwidth, display size, and computational power. Stationary IP multimedia endpoints (including hardware IP phones, videoconferencing units, embedded devices and software phones) allow more convenience of use, but are not mobile. Moving active multimedia sessions between these devices allows mobile and stationary devices to be used concurrently or interchangeably in mid-session, combining their advantages into a single "virtual device". An approach to session mobility based on the Session Initiation Protocol (SIP) [1] was described first in [20], where two different methods are proposed: third-party call control (3pcc) [2] and the REFER method [3].
モバイルデバイスが改善し、IPベースのマルチメディア通信のためのより高度な機能を含むとして、彼らは、帯域幅、表示サイズ、および計算能力の面で制限されたままになります。 （ハードウェアIP電話、ビデオ会議ユニット、組み込み機器やソフトフォンを含む）、静止IPマルチメディア・エンドポイントは、使用のより多くの利便性を許すが、モバイルではありません。これらのデバイス間の活性のマルチメディアセッションを移動すると、単一の「仮想デバイス」にそれらの利点を組み合わせた、モバイル及び固定装置は中間セッションで同時にまたは相互交換可能に使用されることを可能にします。セッション開始プロトコル（SIP）[1]に最初に記載されたに基づいてセッションモビリティへのアプローチ[20]、二つの異なる方法が提案されている場合：第三者呼制御（3PCC）[2]とREFERメソッド[3] 。
This document expands on this concept, defining a framework for session mobility that allows a Mobile Node to discover available devices and to include them in an active session. In particular, the framework for session mobility presented in this document describes basic approaches for using existing protocols and shows the signaling and media flow examples for providing session mobility using SIP. It is intended as an informational document.
この文書では、モバイルノード利用可能なデバイスを発見すると、アクティブなセッションでそれらを含めることを可能にするセッションのモビリティのためのフレームワークを定義し、この概念を拡張したものです。具体的には、この文書のセッションモビリティのためのフレームワークは、既存のプロトコルを使用するための基本的なアプローチを説明し、SIPを用いたセッションモビリティを提供するためのシグナリングとメディアフローの例を示します。これは、情報提供文書として意図されています。
The devices selected as session transfer targets may be either personal or public. Personal devices are ones used by a single individual, such as one's PC or phone. Public devices are ones available for use by a large group of people and include large conference-room displays. Two capabilities are required to transfer sessions:
セッションの転送先として選択されたデバイスは、個人または公共のいずれであってもよいです。個人的なデバイスは、1つのPCや携帯電話などの単一の個人によって使用されるもの、です。公共のデバイスは、人々の大規模なグループによって使用可能なものであり、大会議室のディスプレイを含みます。 2つの機能は、セッションを転送するために必要とされています。
Device Discovery - At all times, a user is aware of the devices that are available in his local area, along with their capabilities.
デバイス検出 - すべての回では、ユーザーは自分の能力と一緒に、彼のローカルエリアで利用可能なデバイスを認識しています。
Session Mobility - While in a session with a remote participant, the user may transfer any subset of the active media sessions to one or more devices.
セッションモビリティ - リモートの参加者とのセッションでは、ユーザーは、1つまたは複数のデバイスにアクティブなメディアセッションの任意のサブセットを転送するかもしれないが。
This document describes session mobility examples for SIP. It does not mandate any particular protocol for device discovery. Many different protocols exist and we discuss the tradeoffs involved in choosing between them. For our examples, we use the Service Location Protocol (SLP) [17], primarily because it is the only such protocol standardized by the IETF.
この文書では、SIPのセッションモビリティ例を説明しています。これは、デバイス検出のための任意の特定のプロトコルを規定していません。多くの異なるプロトコルが存在し、我々はそれらの間の選択に関与トレードオフを議論します。私たちの例については、我々はそれがIETFによって標準化されただけで、このようなプロトコルである主な理由は、サービスロケーションプロトコル（SLP）[17]を使用します。
This session mobility framework seeks to fulfill the following requirements:
このセッションモビリティフレームワークは、次の要件を満たすために目指して：
o REQ 1: Backward Compatibility - We distinguish two kinds of devices. Enhanced devices support the call flows described in Section 5 and can perform discovery, while basic devices can do neither and only have basic SIP capabilities. Devices initiating session mobility must have enhanced functionality, while all others can be either basic or enhanced devices. This includes the transfer destinations, such as the local video camera, as well as the device being used by the remote participant.
OのREQ 1：下位互換性 - 私たちは、デバイスの2種類を区別する。強化されたデバイスは、基本的なデバイスが何もないと、基本的なSIP機能を有することができる呼び出しは、第5章で説明したフローと発見を行うことができますサポートしています。他のすべては、基本または拡張のいずれかの装置とすることができる一方、セッションモビリティを開始するデバイスは、機能が強化されている必要があります。これは、ローカルビデオカメラなどの転送先、ならびに遠隔参加者によって使用されている装置を含みます。
o REQ 2: Flexibility - Differences in device capabilities should be reconciled. Transfer should be possible to devices that do not support the codec being used in the session, and even to devices that do not have a codec in common with the remote participant. A transfer should also take into account device differences in display resolution and bandwidth.
O REQ 2：柔軟性 - デバイスの機能の違いは和解しなければなりません。転送は、セッションで使用されているコーデックをサポートしていないデバイスへ、さらには遠隔参加者との共通のコーデックを持っていないデバイスに可能でなければなりません。転送は、ディスプレイの解像度と帯域幅での口座デバイスの違いを考慮する必要があります。
o REQ 3: Minimal Disruption - Session transfer should involve minimal disruption of the media flow and should not appear to the remote participant as a new call.
O REQ 3：最小限の中断 - セッションの転送は、メディアフローの最小限の中断を伴わなければならないし、新しいコールなどのリモートの参加者に表示されません。
Session mobility involves five types of components: A Correspondent Node (CN), a Mobile Node (MN), one or more local devices used as targets for session transfer, an SLP [17] Directory Agent (DA), and, optionally, a transcoder. The Correspondent Node (CN) is a basic multimedia endpoint being used by a remote participant and may be located anywhere. It may be a SIP User Agent (UA), or a Public Switched Telephone Network (PSTN) phone reachable through a gateway. The Mobile Node (MN) is a mobile device, containing a SIP UA for standard SIP call setup, as well as specialized SIP-handling capabilities for session mobility, and an SLP [17] User Agent (UA) for discovering local devices. The local devices are located in the user's local environment for discovery and use in his current session. They may be mobility-enhanced or basic. Basic devices, such as IP phones, are SIP-enabled, but have no other special capabilities. Mobility-enhanced devices have SLP Service Agent capabilities for advertising their services and session mobility handling. They also contain an SLP UA, whose purpose will be explained in the discussion of multi-device systems in Section 5.4.3. The SLP Directory Agent (DA) keeps track of devices, including their locations and capabilities. The use of SLP will be described in more detail in Section 4. SIP-based transcoding services [18] are used,
対応ノード（CN）、モバイルノード（MN）、セッションの転送のための標的として使用される1つ以上のローカルデバイス、SLP [17]ディレクトリエージェント（DA）、及び、必要に応じて、A：セッション移動度は5つのコンポーネントの種類を含みますトランスコーダ。対応ノード（CN）は、リモート参加者によって使用されている基本的なマルチメディアエンドポイントであり、どこにでも配置することができます。これは、SIPユーザエージェント（UA）であってもよいし、公衆交換電話網ゲートウェイ経由で到達可能（PSTN）電話を交換しました。モバイルノード（MN）は、ローカルデバイスを発見するための標準的なSIPコールセットアップと同様に、セッションのモビリティのための専門SIP処理機能、およびSLP [17]ユーザーエージェント（UA）のためのSIP UAを含む、モバイルデバイスです。ローカルデバイスは、彼の現在のセッションで発見され、使用者のローカル環境に位置しています。彼らは、移動性強化や基本的なことがあります。 IP電話などの基本的なデバイスは、SIPに対応していますが、それ以外の特別な能力を持っていません。モビリティ強化デバイスは、そのサービスとのセッションモビリティ処理を宣伝するためのSLPサービス・エージェント機能を持っています。彼らはまた、その目的は、セクション5.4.3でマルチデバイス・システムの議論に説明するSLP UAを、含まれています。 SLPディレクトリエージェント（DA）は、それらの場所及び機能を含むデバイスを追跡し、保持します。 SLPの使用は、前記SIPベースのトランスコーディングサービスは、[18]が使用されているセクションでより詳細に説明します
when necessary, to translate between media streams, as described in Section 6.
必要な場合、セクション6で説明したように、メディア・ストリームの間で変換します。
A Mobile Node must be able to discover suitable devices in its vicinity. This is outside the scope of SIP, and a separate service location protocol is needed. It is outside the scope of this document to define any service location protocol. This section discusses various options, and describes one of them in more detail.
モバイルノードは、その近傍に適したデバイスを検出することができなければなりません。これは、SIPの範囲外であり、別のサービス・ロケーション・プロトコルが必要です。これは、任意のサービス・ロケーション・プロトコルを定義するには、この文書の範囲外です。このセクションでは、さまざまなオプションについて説明し、より詳細にそれらのいずれかを記述しています。
While having a global infrastructure for discovering devices or other services in any location would be desirable, nothing of this sort is currently deployed or standardized. However, this document assumes that such an infrastructure is unnecessary for discovering devices that are in close proximity, such as in the same room. It is possible for such devices to be discovered through direct communication over a short-range wireless protocol such as the Bluetooth Session Description Protocol (SDP). Two other categories of service discovery protocols may be used, assuming that devices that are physically close to each other are also within the same network and/or part of the same DNS domain. Multicast-based protocols, such as SLP [17] (in its serverless mode) or Bonjour (mDNS-SD [30]), may be used as long as the Mobile Node is within the same subnet as the local devices. When devices are part of the same DNS domain, server-mode SLP or non-multicast DNS Service Discovery (DNS-SD) [29] are possible solutions. Such protocols can discover devices within a larger geographical area, and have the advantage over the first category in that they allow for the discovery of devices at different location granularities, such as at the room or building level, and in locations other than the current one. In order to discover devices in a specific location, location attributes, such as room number, must be used in the search, e.g., as service attributes in SLP or as a domain name in DNS-SD. The mobile device must ascertain its location in order to perform this search. We note that many of these techniques could be difficult to implement in practice. For example, different wireless networks may be deployed by different organizations, which could make it unrealistic to have a common DNS setup.
任意の場所にデバイスまたは他のサービスを発見するためのグローバルなインフラを有することが望ましいであろうが、この種のものは、現在展開されていないか、標準化されています。しかし、この文書では、このようなインフラストラクチャは、同じ部屋のように近接しているデバイスを、発見するための不必要であることを前提としています。そのようなデバイスは、ブルートゥースセッション記述プロトコル（SDP）のような短距離無線プロトコルを介して直接通信を介して発見されることが可能です。サービス発見プロトコルの二つの他のカテゴリは、互いに物理的に近接しているデバイスが同じネットワークおよび/または同一のDNSドメインの一部内であると仮定し、使用することができます。このような（そのサーバレスモード）SLP [17]またはボンジュール（のmDNS-SD [30]）のようなマルチキャストベースのプロトコルは、限り、モバイルノードがローカルデバイスと同じサブネット内にあるとして使用されてもよいです。デバイスが同じDNSドメインの一部である場合、サーバモードSLPまたは非マルチキャストDNSサービスディスカバリ（DNS-SD）[29]は可能な解決策です。そのようなプロトコルは、大きな地理的領域内の装置を発見し、それらは例えば部屋又は建物レベルのような異なる位置粒度、にデバイスの検出を可能にする点で、第1のカテゴリに勝る利点を有し、現在以外の場所にすることができ。サービスは、SLPまたはDNS-SDのドメイン名などの属性として、特定の場所にあるデバイスを検出するために、そのような部屋番号などの位置属性は、例えば、検索に使用されなければなりません。モバイルデバイスは、この検索を実行するためにその位置を確認しなければなりません。私たちは、これらの技術の多くは、実際に実装するのは難しいかもしれないことに注意してください。例えば、異なる無線ネットワークは、それが非現実的な共通のDNS設定を持つように作ることができるさまざまな組織によって展開されることができます。
We describe here how SLP is used in server mode in general, then how it may be used to discover devices based on their location. As mentioned before, this is only one of many ways to perform service discovery. SLP identifies services by a "service type", a "service URL", which can be any URL, and a set of attributes, defined as name-value pairs. The attributes may be information such as vendor, supported media codecs, and display resolution. SLP defines three roles: Service Agents (SAs), which send descriptions of services;
私たちは、SLPは、一般的にサーバモードで使用する方法をここで説明し、彼らの位置に基づいてデバイスを検出する方法を使用することができます。前に述べたように、これは、サービス・ディスカバリを実行するための多くの方法のうちの1つにすぎません。 SLPは、任意のURLすることができ、「サービス種別」、「サービスURL」と、名前と値のペアとして定義された属性のセットによってサービスを識別します。属性は、ベンダー、サポートされているメディアコーデックと、表示解像度などの情報であってもよいです。 SLPは、3つの役割を定義：サービスエージェント（SA）を、サービスの記述を送ります。
User Agents (UAs), which query for services; and Directory Agents (DAs), which receive the registrations and queries. An SA registers a service description to a DA with a service registration (SrvReg) message that includes its service type, service URL, and attribute-value set. A UA queries for services by sending a service request (SrvRqst) message, narrowing the query based on service type and attribute values. It receives a reply (SrvRply) that contains a list of URLs of services that match the query. It may then ascertain the specific attributes of each service using an attribute request (AttrRqst) message.
ユーザーエージェントサービスのクエリ（UAS）;登録およびクエリを受け取り、ディレクトリエージェント（DAS）、。 SAは、そのサービスタイプ、サービスURL、及び属性値のセットを含むサービス登録（のSrvReg）メッセージでDAにサービス記述を登録します。サービスタイプと属性値に基づいてクエリを狭めるサービス要求（SrvRqst）メッセージを、送信することにより、サービスのためのUAクエリ。これは、クエリに一致するサービスのURLのリストが含まれています回答（SrvRply）を受け取ります。次に、属性要求（AttrRqst）メッセージを使用して、各サービスの特定の属性を確認することができます。
This document assumes the following use of SLP for discovering local devices. Devices have a service type of "sip-device" and a SIP URI as the service URI. Section 5.2 describes the form of this URI. Attributes specify device characteristics such as vendor, supported media codec, display resolution, as well as location coordinates, such as street address and room number. SAs are co-located with SIP UAs on session-mobility enhanced devices, while a separate SA is available to send SrvReg messages on behalf of basic devices, which do not have integrated SLP SAs.
この文書では、ローカルデバイスを検出するためのSLPの次使用を前提としています。デバイスは、「SIP-デバイス」とサービスURIとしてSIP URIのサービスタイプを持っています。 5.2節では、このURIの形式について説明します。属性は、住所と部屋番号として位置座標、ならびに、そのようなベンダなどのデバイス特性、サポートされているメディアコーデック、表示解像度を指定します。別のSAはSLP SAを統合していません基本的なデバイスに代わってのSrvRegメッセージを送信するために利用可能である一方、SAは、セッション・モビリティ強化デバイス上でSIPのUAと同じ場所に配置されています。
The Mobile Node includes an SLP UA that discovers available local devices and displays them to the user, showing, for example, a map of all devices in a building or a list of devices in a current room. Once the MN receives its current location in some manner, its SLP UA issues a SrvRqst message to the DA requesting all SIP devices, using the location attributes to filter out those that are not in the current room. A SrvRply message is sent to the mobile device with a list of SIP URIs for all devices in the room. A separate attribute request (AttrRqst) is then sent for each URL to get the attributes of the service. The MN displays for the user the available devices in the room and their attributes. Figure 1 shows this protocol flow.
モバイルノードは、利用可能なローカルデバイスを検出し、例えば、建物又は現在の部屋内のデバイスのリスト内のすべてのデバイスのマップを示し、それらをユーザに表示SLP UAを含みます。 MNは、いくつかの方法で、現在の場所を受信すると、そのSLP UAは場所が現在の部屋にないものを除外するために属性を使用して、すべてのSIPデバイスを要求してDAにSrvRqstメッセージを発行します。 SrvRplyメッセージは、部屋内のすべてのデバイスのためのSIP URIのリストをモバイルデバイスに送信されます。別の属性要求（AttrRqst）は、サービスの属性を取得するには、各URLのために送られます。 MNは、ユーザーのために利用できる部屋内のデバイスとその属性を表示します。図1は、このプロトコルの流れを示します。
Device DA MN
|(1) SrvReg | |
|------------------------->| |
|(2) SrvRply | |
|<-------------------------| |
| | |
| | |
| |(3) SrvRqst |
| |<----------------------|
| |(4) SrvRply URL list |
| |---------------------->|
| |(5) AttrRqst URL1 |
| |<----------------------|
| |(6) AttrRply |
| |---------------------->|
| | ... |
| | |
Figure 1. SLP message flow for the device to register its service and the MN to discover it, along with its attributes.
デバイスの図1. SLPのメッセージ・フローは、そのサービスとその属性とともに、それを発見するMNを登録します。
Session mobility involves both transfer and retrieval of an active session. A transfer means to move the session on the current device to one or more other devices. A retrieval causes a session currently on another device to be transferred to the local device. This may mean returning a session to the device on which it had originally been before it was transferred to another device. For example, after discovering a large video monitor, a user transfers the video output stream to that device; when he walks away, he returns the stream to his mobile device for continued communication. One may also move a session to a device that had not previously carried it. For example, a participant in an audio call on his stationary phone may leave his office in the middle of the call and transfer the call to the mobile device as he is running out the door.
セッションモビリティは、アクティブなセッションの転送および検索の両方を含みます。転送は、1つのまたは複数の他のデバイスに現在のデバイス上でセッションを移動することを意味します。検索は、別のデバイス上の現在のセッションが、ローカル装置に転送させます。これは、それが別のデバイスに転送される前に、それはもともとされていた上のデバイスにセッションを返すことを意味してもよいです。例えば、大規模なビデオモニタを発見した後、ユーザは、そのデバイスにビデオ出力ストリームを転送します。彼は離れて歩くとき、彼は続けた通信のための彼のモバイルデバイスにストリームを返します。一つは、以前にそれを実行していなかったデバイスへのセッションを移動させることができます。たとえば、彼の静止電話での音声通話での参加者は、通話の途中で彼のオフィスを残すことができると、彼はドアの外に実行されているモバイルデバイスにコールを転送します。
The set of session media may either be transferred completely to a single device or split across multiple devices. For instance, a user may only wish to transfer the video component of his session while maintaining the audio component on his PDA. Alternatively, he may find separate video and audio devices and wish to transfer one media type to each. Furthermore, even the two directions of a full-duplex session may be split across devices. For example, a PDA's display may be too small for a good view of the other call participant, so the user may transfer video output to a projector and continue to use the PDA camera.
セッションのメディアのセットは、単一のデバイスに完全に転送したり、複数のデバイスにまたがって分割されてもよいです。たとえば、ユーザーは自分のPDA上のオーディオコンポーネントを維持しながら、彼のセッションのビデオコンポーネントを転送したいことがあります。また、彼は別のビデオとオーディオデバイスを検索し、それぞれに1つのメディアタイプを転送したいことがあります。また、全二重セッションのも二つの方向はデバイス間で分割することができます。例えば、PDAのディスプレイは、他のコールの参加者がよく見えるために小さすぎる可能性があり、ユーザは、プロジェクターに映像出力を転送し、PDAのカメラを使用し続けることができます。
Two different modes are possible for session transfer, Mobile Node Control (MNC) mode and Session Handoff (SH) mode. We describe them below in turn.
2つの異なるモードは、セッション転送、モバイルノードコントロール（MNC）モードとセッションハンドオフ（SH）モードで可能です。私たちは順番に以下にそれらを記述します。
In Mobile Node Control mode, the Mobile Node uses third-party call control [2]. It establishes a SIP session with each device used in the transfer and updates its session with the CN, using the SDP parameters to establish media sessions between the CN and each device, which take the place of the current media sessions with the CN. The shortcoming of this approach is that it requires the MN to remain active to maintain the sessions.
移動ノード制御モードでは、モバイルノードは、第三者呼制御を使用する[2]。これは、転送に使用される各デバイスとのSIPセッションを確立し、CNとの現在のメディアセッションの場所を取るCN、各デバイス間のメディアセッションを確立するために、SDPパラメータを使用して、CNとのセッションを更新します。このアプローチの欠点は、それがセッションを維持するためにアクティブなままにMNを必要とすることです。
A user may need to transfer a session completely because, for example, the battery on his mobile device is running out or he is losing radio connectivity. Alternatively, the user of a stationary device who leaves the area and wishes to transfer the session to his mobile device will not want the session to remain on the stationary device when he is away, since it will allow others to easily tamper with his call. In such a case, Session Handoff mode, which completely transfers the session signaling and media to another device, is useful.
ユーザは、例えば、自分のモバイルデバイスのバッテリが切れているか、彼はラジオの接続性を失っている、ので、完全にセッションを転送する必要があるかもしれません。それは他の人が簡単に彼の呼び出しを改ざんすることができますので、また、地域を離れ、自分のモバイルデバイスにセッションを転送したい静止デバイスのユーザは、彼が離れているときに、セッションが静止デバイス上に残りたくはありません。このような場合には、完全に別のデバイスへのセッションシグナリングとメディアを転送セッションハンドオフモードは、有用です。
Based on our experiments, we have found MNC mode to be more interoperable with existing devices used on the CN's side. The remainder of this section describes the transfer, retrieval, and splitting of sessions in each of the two session transfer modes.
我々の実験に基づいて、我々は、CNの側で使用される既存のデバイスとより相互運用できるようにMNCモードを発見しました。このセクションの残りの部分は、転写、検索、および2つのセッションの転送モードの各々におけるセッションの分割を記述する。
A communication session may consist of a number of media types, and a user should be able to transfer any of them to his device of choice. This document considers audio, video, and messaging. Audio and video are carried by RTP and negotiated in the SDP body of the SIP requests and responses. Three different methods exist for carrying text messages, and possibly other MIME types, that are suitable for SIP endpoints. RTP may be used to transport text payloads in real time, based on [9]. Any examples given for audio and video will work identically for text, as only the payloads differ. For the transfer of entire messages (as opposed to a small number of characters in RTP), either the SIP MESSAGE method [21] or the Message Session Relay Protocol (MSRP) [7] may be used. MESSAGE is used to send individual page-mode messages. The messages are not associated with a session, and no negotiation is done to establish a session. Typically, a SIP UA will allow the user to send MESSAGE requests during an established dialog, and they are sent to the same contact address as all signaling messages are sent in mid-session. We discuss later how these messages are affected by session mobility. MSRP, on the other hand, is based on sessions that are established like the real-time media sessions previously described. As such, transferring them is similar to transferring other media sessions. However, this document will point out where special handling is necessary for these types of sessions.
通信セッションは、メディアタイプの数から構成されてもよいし、ユーザが選択した彼のデバイスにそれらのいずれかを転送することができるはずです。この文書では、オーディオ、ビデオ、およびメッセージングを考慮しています。オーディオとビデオは、RTPによって運ばれ、SIPの要求と応答のSDPボディで交渉されています。 3つの異なる方法は、SIPエンドポイントに適しているテキストメッセージ、およびおそらく他のMIMEタイプを、運ぶために存在しています。 RTPは、[9]に基づいて、リアルタイムでテキストペイロードを輸送するために使用されてもよいです。唯一のペイロードが異なるとして、オーディオとビデオのために与えられた任意の例は、テキストのために同じように動作します。全体のメッセージの転送（RTPにおける文字の数が少ないとは対照的に）のために、いずれかのSIPメッセージ方法[21]またはメッセージセッションリレープロトコル（MSRP）は、[7]を使用することができます。 MESSAGEは、個々のページモードメッセージを送信するために使用されます。メッセージは、セッションに関連付けられていない、と何の交渉は、セッションを確立するために行われません。一般的に、SIP UAは、ユーザが確立し、ダイアログ中にMESSAGEリクエストを送信できるようになり、すべてのシグナリングメッセージは半ばセッションに送信されますと、それらは同じ連絡先アドレスに送信されます。私たちは、これらのメッセージは、セッションの移動性の影響を受けているか、後で議論します。 MSRPは、他の一方で、前述のリアルタイムメディアセッションのように確立されたセッションに基づいています。そのため、彼らは他のメディアセッションを転送するに似て転送します。特別な処理は、セッションのこれらのタイプのために必要な場合しかし、この文書は指摘します。
As stated before, this document assumes both personal and public devices. We assume that public devices use a dedicated Address of Record (AOR), such as sip:device11@example.com. A personal device already uses the owner's AOR, so that he should be reachable there; that AOR could also be used for transferring sessions. However, it is preferable to distinguish the role of a device as a transfer target from its existing role. Therefore, all devices are assumed to have dedicated AORs.
前に述べたように、この文書は、個人と公共の両方のデバイスを想定しています。 device11@example.com：私たちは、公共デバイスは、SIPなどのレコード（AOR）の専用アドレスを、使用することを前提としています。彼はそこに到達可能でなければなりませんように、個人的なデバイスは、すでに、所有者のAORを使用しています。そのAORもセッションを転送するために使用することができます。しかし、既存のロールから転送対象となるデバイスの役割を区別することが好ましいです。そのため、すべてのデバイスは、専用のAORを持っていると想定されています。
Since every transfer device has its own AOR, there is a one-to-one mapping between AOR and device. Therefore, a transfer request could be addressed to the AOR, which would resolve to the device. However, in Section 5.4.3, we present a model where devices create multi-device systems to pool their capabilities. Therefore, a single device must be reachable by multiple URIs representing different combinations of devices. The appropriate solution is to define each combination of devices with a Globally Routable UA URI (GRUU) [12].
すべての移送装置は、それ自身のAORを有するので、AORとデバイスとの間の1対1のマッピングがあります。そのため、転送要求がデバイスに解決するでしょうAORに対処することができます。しかし、5.4.3項では、我々は、デバイスがその能力をプールするマルチデバイス・システムを作成したモデルを提示します。したがって、単一のデバイスは、デバイスの異なる組み合わせを表す複数のURIによって到達可能でなければなりません。適切な溶液は、グローバルにルーティング可能なUA URI（GRUU）[12]を用いてデバイスのそれぞれの組み合わせを定義することです。
Therefore, we assume the following addressing for the remainder of the document. As mentioned earlier, a device has a unique AOR. It registers a separate contact URI for itself and for each system of devices that it controls. Each contact has an associated GRUU, which is registered with SLP as the Service URI, and may be directly addressed by another device in a request sent through the proxy. When the proxy forwards the request to the device, it will replace the GRUU with the contact URI, as described in [12]. Therefore, the contact URI, not the associated GRUU, will be used by devices to determine whether the request is for the device itself or for a multi-device system. We assume that the public GRUU is used.
したがって、我々は、文書の残りのためのアドレッシング、以下を想定しています。前述したように、デバイスは、ユニークなAORを持っています。それ自体およびそれが制御装置のシステムごとに別々の接触URIを登録します。各コンタクトは、サービスURIとしてSLPに登録されている関連するGRUUを有し、直接プロキシを介して送信された要求に別の装置によって対処することができます。プロキシはデバイスに要求を転送するとき、[12]に記載されているように、それは、接触URIにGRUUを交換します。したがって、接触URIは、関連するGRUUは、要求は、デバイス自体またはマルチデバイスシステムのためのものであるかどうかを決定するためにデバイスによって使用されるわけではありません。私たちは、公共GRUUが使用されていることを前提としています。
local device MN CN
|(1) INVITE no sdp | |
|<------------------------| |
|(2) 200 OK local params | |
|------------------------>| |
| |(3) INVITE local params |
| |------------------------>|
| RTP | |
|<..................................................|
| |(4) 200 OK CN params |
| |<------------------------|
| |(5) ACK |
| |------------------------>|
|(6) ACK CN params | |
|<------------------------| RTP |
|..................................................>|
| | |
| | |
Figure 2. Mobile Node Control mode flow for transfer to a single device.
単一のデバイスに転送する2.移動ノード制御モードのフロー図。
Figure 2 shows the message flow for transferring a session to a single local device. It follows Third Party Call Control Flow I (specified in [2]), which is recommended as long as the endpoints will immediately answer. The MN sends a SIP INVITE request to the local device used for the transfer, requesting that a new session be established, but does not include an SDP body. The local device's response contains an SDP body that includes the address and port it will use for any media, as well as a list of codecs it supports for each. The MN updates the session with the CN by sending an INVITE request (re-INVITE) containing the local device's media parameters in the SDP body, as follows:
図2は、単一のローカルデバイスにセッションを転送するためのメッセージフローを示します。私がいる限り、エンドポイントはすぐに答えるとして推奨されている、（[2]で指定）第三者呼制御フローに従っています。 MNは、新しいセッションが確立されることを要求し、SIPを転送するために使用するローカルデバイスにINVITEリクエストを送信しますが、SDP体が含まれていません。ローカルデバイスの応答は、それがどのメディアに使用するアドレスとポートを含みSDP本体だけでなく、それはそれぞれのためにサポートしているコーデックのリストが含まれています。次のようにMNは、SDPボディにおいてローカルデバイスのメディアパラメータを含むINVITE要求（再INVITE）を送信することによって、CNとのセッションを更新します。
v=0 c=IN IP4 av_device.example.com m=audio 4400 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 5400 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000
V = 0 C = IN IP4 av_device.example.com M =オーディオ4400 RTP / AVP 0 8 A = rtpmap：0 PCMU / 8000 = rtpmap：8 PCMA / 8000 M =映像5400 RTP / AVP 31 34 = rtpmap： 31 H261 / 90000 = rtpmap：34 H263 / 90000
Sending both audio and video media lines will transfer both media sessions of an existing audio/video call to the local device. Alternatively, the MN may select a subset of the media available on the local device, and use the local device's parameters for those media in the request sent to the CN, while continuing to use its own parameters for the rest of the media. For example, if it only wishes to transfer an audio session to a local device that supports audio and video, it will isolate the appropriate media line for audio from the response received from the local device and put it in the request sent to the CN, along with its own video parameters. The CN will send a response and includes, in its body, the media parameters that it will use, which may or may not be the same as the ones used in the existing session. The MN will send an ACK message to the local device, which includes these parameters in the body. The MN will establish a session with the local device and maintain its session with the CN, while the media flow will be established directly between the CN and the local device. Only the MN, who will be in an ongoing session with the CN, will later be allowed to retrieve the media session. Parsing of unknown SDP attributes by the controller is discussed in [2].
送信オーディオとビデオの両方のメディアラインがローカルデバイスに既存のオーディオ/ビデオ通話の両方のメディアセッションを転送します。また、MNは、ローカルデバイス上で使用可能なメディアのサブセットを選択することができ、メディアの残りのための独自のパラメータを使用することを続けながら、CNに送信された要求にこれらのメディアのためのローカルデバイスのパラメータを使用します。それだけでオーディオとビデオをサポートするローカルデバイスにオーディオセッションを転送したい場合、例えば、それは、ローカルデバイスから受信した応答からのオーディオのための適切なメディアラインを隔離し、CNに送信されたリクエストに入れて、独自のビデオパラメータと一緒に。 CNは、応答を送信し、その本体内に含まれるか、または既存のセッションに使用されるものと同じであってもなくてもよいが使用するメディアパラメータ、。 MNは、体内のこれらのパラメータを含むローカルデバイスにACKメッセージを送信します。 MNは、ローカルデバイスとのセッションを確立し、メディアフローは、CNとローカルデバイスとの間で直接確立されるが、CNとのセッションを維持します。 CNと進行中のセッションになりますMN、唯一のは、後にメディアセッションを取得するために許可されます。コントローラによって未知のSDP属性の解析は[2]に記載されています。
In figure 2, the message sequence for transferring an MSRP message session using MNC mode is identical to that used for audio or video, although the contents of the messages differ. To simplify the example, we assume that an MSRP session, with no other media, is being transferred to a local messaging node, MSGN. In the following flow, we refer to the corresponding messages in Figure 2. An empty INVITE request (1) is sent to the local messaging node, MSGN, as follows:
メッセージの内容が異なるものの、図2において、MNCモードを使用してMSRPメッセージセッションを転送するためのメッセージシーケンスは、オーディオまたはビデオのために使用されるものと同一です。例を単純化するために、我々は、MSRPセッションは、他のメディアで、ローカル・メッセージング・ノード、MSGNに転送されていることを前提としています。以下のフローでは、図2に対応するメッセージを参照して、空のINVITE要求（1）以下のように、ローカル・メッセージング・ノード、MSGNに送られます。
INVITE sip:msgn@example.com;gr=urn:uuid:jtr5623n SIP/2.0 To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n> From: <sip:bob@example.com>;tag=786 Call-ID: 893rty@mn.example.com Content-Type: application/sdp
SIP INVITE：msgn@example.comと、GR = URN：UUID：jtr5623nのSIP / 2.0 <SIP：msgn@example.com; GR = URN：UUID：jtr5623n>から<SIP：bob@example.com>。タグ= 786コールID：893rty@mn.example.comのContent-Type：アプリケーション/ SDP
The messaging node responds with all of its media capabilities, including MSRP, as follows (2):
（2）次のようにメッセージング・ノードは、MSRPを含むそのメディア機能の全てで応答します。
SIP/2.0 200 OK To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n;tag=087js>;tag=087js From: <sip:bob@example.com>;tag=786 Call-ID: 893rty@mn.example.com Content-Type: application/sdp v=0 c=IN IP4 msgn.example.com m=message 52000 msrp/tcp * a=accept-types:text/plain a=path:msrp://msgn.example.com:12000/kjhd37s2s2;tcp m=audio 4400 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 m=video 5400 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000
SIP / 2.0 200 OK <SIP：msgn@example.com; GR = URN：UUID：jtr5623n;タグ= 087js>;タグ= 087jsから<SIP：bob@example.com>;タグ= 786のCall-ID ：893rty@mn.example.comコンテンツタイプ：アプリケーション/ SDP V = 0 C = IN IP4 msgn.example.com M =メッセージ52000 MSRP / TCP * A =受け入れる - タイプ：text / plainの=パス：MSRPを： //msgn.example.com:12000/kjhd37s2s2;tcpのM =オーディオ4400 RTP / AVP 0 8 A = rtpmap：0 PCMU / 8000 = rtpmap：8 PCMA / 8000 M =映像5400 RTP / AVP 31 34 = rtpmap ：31 H261 / 90000 = rtpmap：34 H263 / 90000
The same request is then sent by the MN to the CN (3), but containing the MSRP media and attribute lines with the path given in the MSGN response above. The CN responds (4) with its own path. The MN includes this in the ACK that it sends to the MSGN (6).
同じ要求はCN（3）にMNによって送信されたが、上記MSGN応答で指定されたパスとMSRPメディア属性行を含むされます。 CNは、独自のパスで（4）応答します。 MNは、MSGN（6）に送信するACKでこれを含みます。
MSRP sessions are carried over a reliable connection, using TCP or TLS (Transport Layer Security). Therefore, unlike in the case of real-time media, this connection must be established. According to the MSRP specifications, the initiator of a message session, known as the "offerer", must be the active endpoint, and open the TCP connection between them. In this transfer scenario, the offerer of both sessions is the MN, who is on neither end of the desired TCP connection. As such, neither endpoint will establish the connection. A negotiation mechanism could be used to assign the role of active endpoint during session setup. However, while MSRP leaves open this possibility, it is not currently included in this document due to complexity. The only other way that such session transfer would be possible is if both the CN and the local device ordinarily use an MSRP relay [8], since no direct connection must be established between them. When each new endpoint receives the INVITE request from the MN, it will create a TLS connection with one of its preconfigured relays if such a connection does not yet exist (the CN will already have one because of its session with the MN) and receive the path of the relay. In its response to the MN, it will include the entire path that must be traversed, including its relay, in the path attribute. For instance, the response from the MSGN will look as follows:
MSRPセッションは、TCPまたはTLS（Transport Layer Security）を使用して、信頼性の高い接続を介して運ばれます。そのため、リアルタイムメディアの場合とは異なり、この接続が確立されなければなりません。 MSRPの仕様によると、「オファー側」として知られているメッセージセッションのイニシエータは、アクティブなエンドポイントであること、およびそれらの間のTCP接続を開く必要があります。この転送シナリオでは、両方のセッションのオファー側は希望TCP接続のどちらの端にあるMN、です。そのため、どちらのエンドポイントは、接続を確立します。交渉メカニズムは、セッションセットアップ中にアクティブエンドポイントの役割を割り当てるために使用することができます。 MSRPはこの可能性を開いたままにしながら、しかし、それは現在、原因の複雑さに、この文書に含まれていません。直接的な接続がそれらの間に確立されてはならないので、CNおよびローカルデバイスの両方は、通常、[8] MSRPリレーを使用する場合、セッション転送が可能であろうと他の唯一の方法です。それぞれの新しいエンドポイントがMNからのINVITEリクエストを受信すると、このような接続がまだ存在し（CNが既にあるためMNとのセッションの一つを持っています）と、受信しない場合、それはその事前設定されたリレーの一つとのTLS接続を作成します。リレーのパス。 MNへの応答では、path属性で、そのリレーを含め、横断しなければならない全体のパスが含まれます。例えば、のようになります。MSGNからの応答は次のとおりです。
SIP/2.0 200 OK To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n;tag=087js>;tag=087js From: <sip:bob@example.com>;tag=786 Call-ID: 893rty@mn.example.com Content-Type: application/sdp v=0 c=IN IP4 msgn.example.com m=message 52000 msrp/tcp * a=accept-types:text/plain a=path:msrp://relayA.example.com:12000/kjhd37s2s2;tcp \ path:msrp://msgn.example.com:12000/kjhd37s2s2;tcp
SIP / 2.0 200 OK <SIP：msgn@example.com; GR = URN：UUID：jtr5623n;タグ= 087js>;タグ= 087jsから<SIP：bob@example.com>;タグ= 786のCall-ID ：893rty@mn.example.comコンテンツタイプ：アプリケーション/ SDP V = 0 C = IN IP4 msgn.example.com M =メッセージ52000 MSRP / TCP * A =受け入れる - タイプ：text / plainの=パス：MSRPを： //relayA.example.com:12000/kjhd37s2s2;tcp \パス：メーカー希望小売価格：//msgn.example.com：12000 / kjhd37s2s2、TCP
Since the CN and the local device each establish a TLS connection with their relay, as they would for any session, and the relays will establish a connection between them when a subsequent MSRP message is sent, neither party needs to establish any special connection. The existing protocol may therefore be used for session transfer.
彼らは任意のセッションの場合と同じようにCNとローカルデバイスそれぞれが、自分のリレーとのTLS接続を確立し、その後のMSRPメッセージが送信されたときにリレーがそれらの間の接続を確立しますので、いずれの当事者も、特別な接続を確立する必要があります。既存のプロトコルは、したがって、セッション転送のために使用することができます。
In order to split the session across multiple devices, the MN establishes a new session with each local device through a separate INVITE request, and updates the existing session with the CN with an SDP body that combines appropriate media parameters it receives in their responses. For instance, in order to transfer an audio and video call to two devices, the MN initiates separate sessions with each of them, combines the audio media line from one response and the video media line from the other, and sends them together as the request to the CN, as follows:
複数のデバイス間でセッションを分割するために、MNは、別個のINVITE要求を介してローカル装置との新しいセッションを確立し、それは彼らの応答で受信し、適切なメディアパラメータを組み合わせたSDP本体とCNとの既存のセッションを更新します。例えば、二つの装置にオーディオとビデオ通話を転送するために、MNは、それらのそれぞれと個別のセッションを開始つの応答及び他のビデオメディアラインからの音声メディアラインを組み合わせ、そして要求として一緒にそれらを送信しますCNに、としては、次のとおりです。
v=0 m=audio 48400 RTP/AVP 0 c= IN IP4 audio_dev.example.com a=rtpmap:0 PCMU/8000 m=video 58400 RTP/AVP 34 c= IN IP4 video_dev.example.com a=rtpmap:34 H263/90000
V = 0、M =オーディオ48400 RTP / AVP 0 C = IN IP4 audio_dev.example.com A = rtpmap：0 PCMU / 8000メートル=ビデオ58400 RTP / AVP 34 C = IN IP4 video_dev.example.com A = rtpmap：34 H263 / 90000
The CN responds with its own parameters for audio and video. The MN splits them and sends one to each local device in the ACK that completes each session setup.
CNは、オーディオとビデオのために、独自のパラメータを使用して応答します。 MNは、それらを分割し、各セッションのセットアップを完了ACKの各ローカルデバイスに1を送信します。
video_dev audio_dev MN CN
| |(1) INVITE no sdp | |
| |<-------------------| RTP Audio |
| |(2) 200 params | |
| |------------------->| |
| |(3) INVITE no sdp | |
|<---------------------------------------| |
| |(4) 200 params | |
|--------------------------------------->| |
| | |(5) INVITE a/v params|
| | |---------------------->|
| | RTP Audio | |
| RTP Video |<...........................................|
|<...............................................................|
| | |(6) 200 OK |
| | |<----------------------|
| | |(7) ACK |
| | |---------------------->|
| |(8) ACK CN audio | |
| |<-------------------| RTP Audio |
| |...........................................>|
| |(9) ACK CN video | |
|<---------------------------------------| RTP Video |
|...............................................................>|
| | | |
| | | |
Figure 3. Mobile Node Control mode flow for transfer to multiple
devices.
Splitting a full-duplex media service, such as video, across an input and an output device, such as a camera and a video display, is a simple extension of this approach. The signaling is identical to that of Figure 3, with the audio and video devices replaced by a video output and a video input device. The SDP, however, is slightly different. The MN invites the local devices into two different sessions, but does not include any SDP body. They each respond with all of their available media. If they only support unidirectional media, as is the case for a camera or display-only device, they will include the "sendonly" or "recvonly" attributes. Otherwise, the MN will have to append the appropriate attribute to each one's media line before sending the combined SDP body to the CN. That body will look as follows: m=video 50900 RTP/AVP 34 a=rtpmap:34 H263/90000 a=sendonly c=IN IP4 camera.example.com m=video 50800 RTP/AVP 34 a=rtpmap:34 H263/90000 a=recvonly c=IN IP4 display.example.com
そのようなカメラおよびビデオディスプレイとして、入力及び出力装置を横切って、例えばビデオとして、全二重メディアサービスを分割し、このアプローチの単純な拡張です。シグナリングは、ビデオ出力と映像入力装置で置き換えたオーディオおよびビデオデバイスと、図3のものと同一です。 SDPは、しかし、わずかに異なっています。 MNは、二つの異なるセッションにローカルデバイスを誘うが、任意のSDP本体は含まれません。彼らには、それぞれの利用可能なメディアのすべてに対応しています。カメラやディスプレイ専用デバイスの場合のように、彼らは唯一の、一方向のメディアをサポートしている場合、彼らは「sendonlyで」または「がrecvonly」が含まれる属性。それ以外の場合は、MNはCNに組み合わせたSDP本体を送信する前に、各1のメディアラインに適切な属性を追加する必要があります。ようになります。その体は、以下：M =ビデオ50900 RTP / AVP 34 = rtpmap：34 H263 / 90000 = sendonlyのC = IN IP4 camera.example.com M =ビデオ50800 RTP / AVP 34 = rtpmap：34 H263 / 90000 A =がrecvonly C IN = IP4 display.example.com
In updating an SDP session, according to Section 8 of [4], the i-th media line in the new SDP corresponds to the i-th media line in the previous SDP. In the above cases, if a media type is added during the transfer, the media line(s) should follow the existing ones. When an existing media is transferred to a different device, the media line should appear in the same place that it did in the previous SDP, as should the lines for all media that have not been altered. When a duplex media stream is being split across an input and output device, the stream corresponding to the input device should appear in place of the duplex media stream. Since this new stream is the one that will be received by the CN, including it in place of the old one ensures that the CN views the new stream as a replacement of the old one. The media line corresponding to the output device must appear after all existing media lines. In the last example, if the SDP had initially contained a video line followed by an audio line, the updated SDP sent to the CN would look as follows:
SDPセッションを更新する際に、セクション8に記載の方法、[4]、新しいSDPにおけるi番目のメディア・ラインは、前のSDPのi番目のメディア・ラインに対応します。メディアタイプは、転送中に添加される場合、上記の場合には、メディア行（複数可）は、既存のに従うべきです。既存のメディアが別のデバイスに転送されると、メディアラインが変更されていないすべてのメディアのための行が必要として、それは、前のSDPでやったのと同じ場所に表示されます。両面メディアストリームが入出力デバイスにまたがって分割されているとき、入力装置に対応するストリームは、二重メディアストリームの代わりに表示されます。この新しいストリームは古いものの代わりに、それを含めて、CNによって受信される1があるので、CNは、古いものの代わりとして新しいストリームを閲覧することを保証します。出力デバイスに対応するメディア・ラインは、すべての既存のメディア行の後に現れなければなりません。 SDPは、最初にオーディオラインに続いてビデオラインが含まれていた場合、最後の例では、更新されたSDPは、次のようになりますCNに送信されました：
m=video 50900 RTP/AVP 34 a=rtpmap:34 H263/90000 a=sendonly c=IN IP4 camera.example.com m=audio 45000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 50800 RTP/AVP 34 a=rtpmap:34 H263/90000 a=recvonly c=IN IP4 display.example.com
M =ビデオ50900 RTP / AVP 34 = rtpmap：34 H263 / 90000 A = sendonlyのC = IN IP4 camera.example.com M =オーディオ45000 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル=ビデオ50800 RTP / AVP 34 = rtpmap：34 H263 / 90000 = recvonlyでC = IN IP4 display.example.com
During the course of the session, the CN may send a MESSAGE request to the MN containing text conversation from the remote user. If the mobile user wishes to have such messages displayed on a device other than the MN, the request is simply forwarded to that device. The forwarded message should be composed as though it were any other message from the MN to the local device, and include the body of the received message. The local device will send any MESSAGE request to the MN, who will forward it to the CN.
セッションの過程で、CNは、リモートユーザからのテキストの会話を含むMNにMESSAGEリクエストを送信することができます。モバイルユーザーがMN以外のデバイスに表示されるようなメッセージを持っているしたい場合は、要求は単にそのデバイスに転送されます。転送されたメッセージは、MNからローカルデバイスへの任意の他のメッセージであったかのように構成され、受信されたメッセージの本文を含むべきです。ローカルデバイスは、CNに転送しますMNに任意のMESSAGEリクエストを送信します。
The MN may later retrieve the session by sending an INVITE request to the CN with its own media parameters, causing the media streams to return. It then sends a BYE message to each local device to terminate the session.
MNは、後にメディアストリームを返すために引き起こして、独自のメディアパラメータをCNにINVITEリクエストを送信することにより、セッションを検索することができます。これは、セッションを終了するには、各ローカルデバイスにBYEメッセージを送信します。
Session Handoff mode uses the SIP REFER method [3]. This message is a request sent by a "referrer" to a "referee", which "refers" it to another URI, the "refer target", which may be a SIP URI to be contacted with an INVITE or other request, or a non-SIP URI, such as a web page. This URI is specified in the Refer-To header. The Referred-By [5] header is used to give the referrer's identity, which is sent to the refer target for authorization. Essential headers from this message may also be encrypted and sent in the message body as Secure/Multipurpose Internet Mail Extensions (S/MIME) to authenticate the REFER request. Figure 4 shows the flow for transferring a session.
セッションハンドオフモードは、SIPメソッド参照使用する[3]。このメッセージは、INVITEまたは他の要求と接触するSIP URIとすることができる、「参照標的」、又は、別のURIにそれを「意味」「審判」、に「リファラー」によって送信された要求でありますWebページなど非SIP URI、。このURIは、参照のために、ヘッダで指定されています。いうバイ[5]ヘッダーを許可するための参照ターゲットに送信されるリファラーのアイデンティティを与えるために使用されます。このメッセージの必須ヘッダはまた、REFER要求を認証する多目的インターネットメール拡張（S / MIME）/などの安全なメッセージボディに暗号化して送信することができます。図4は、セッションを転送するためのフローを示します。
device15 MN CN
|(1) REFER | |
|<----------------------------| |
|(2) 202 Accepted | |
|---------------------------->| |
|(3) INVITE, Replaces | |
|-------------------------------------------------->|
| RTP |
|<..................................................|
|(4) 200 OK | |
|<--------------------------------------------------|
| RTP |
|..................................................>|
|(5) ACK | |
|-------------------------------------------------->|
| |(6) BYE |
| |<--------------------|
| |(7) 200 OK |
| |-------------------->|
|(8) NOTIFY | |
|---------------------------->| |
|(9) 200 OK | |
|<----------------------------| |
| | |
| | |
Figure 4. Session Handoff mode flow for transfer to a single device.
単一のデバイスに転送するために前記セッションハンドオフモードフロー図。
The MN sends the following REFER request (1) to a local device:
MNは、ローカルデバイスに次の要求（1）を参照してください送信します。
REFER sip:device15@example.com;gr=urn:uuid:qfnb443ccui SIP/2.0 To: <sip:device15@example.com;gr=urn:uuid:qfnb443ccui> From: <sip:bob@example.com> Refer-To:<sip:corresp@example.com;gr=urn:uuid:bbb6981;audio;video? Replaces="1@mn.example.com; to-tag=bbb;from-tag=aaa"> Referred-By: <sip:bob@example.com>
SIP REFER：device15@example.comと、GR = URN：UUID：qfnb443ccui SIP / 2.0 <SIP：device15@example.com; GR = URN：UUID：qfnb443ccui>から<SIP：bob@example.com>参照してください-to：<SIP：corresp@example.com;グラム= URN：UUID：bbb6981、オーディオ、ビデオ？置き換え= "1@mn.example.com;のタグ= BBB;からタグ= AAA">呼ばバイ<SIP：bob@example.com>
[S/MIME authentication body]
[S / MIME認証体]
This message refers the local device to invite the refer target, the CN, into a session. The "audio" and "video" tokens in the Refer-To URI are callee capabilities [10]. Here they are used to inform the referee that it should initiate an audio and video session with the CN. Also included in the URI is the Replaces header field, specifying that a Replaces header field should be included with the specified value in the subsequent INVITE request. The Replaces header identifies an existing session that should be replaced by the new session. Here, the local device will request that the CN replaces its current session with the MN with the new session. According to [6], the CN should only accept a request to replace a session from certain authorized categories of users. One such type of user is the current participant in the session. The MN may, therefore, refer the local device to replace its current session with the CN. However, it provides authentication by encrypting several headers from the original REFER request in an S/MIME body that it sends in the REFER. The local device sends this body to the CN. This keeps a malicious user from indiscriminately replacing another user's session. Once the local device receives the REFER request, it sends an INVITE request to the CN, and a normal session setup ensues. The CN then tears down its session with the MN.
このメッセージは、セッション中に、参照対象を招待するためのローカルデバイス、CNを指します。参照してください-にURIある呼び出し先能力の「オーディオ」と「映像」トークン[10]。ここで彼らは、それがCNとオーディオとビデオセッションを開始すべき審判を通知するために使用されています。また、URIに含まれるReplacesヘッダーフィールドは、後続のINVITE要求で指定された値に含まれるべきであることを指定代わるヘッダフィールドです。 Replacesヘッダーは新しいセッションで置き換えなければならない既存のセッションを識別する。ここでは、ローカルデバイスは、CNは新しいセッションとMNとの現在のセッションを置き換えることを要求します。 [6]によれば、CNは、ユーザの特定の認可カテゴリからセッションを交換するための要求を受け入れなければなりません。ユーザーのそのようなタイプは、セッション中に現在の参加者です。 MNは、それ故、CNとの現在のセッションを置き換えるために、ローカルデバイスを指してもよいです。しかし、それはREFERに送信S / MIMEボディの元REFERリクエストからいくつかのヘッダーを暗号化することで、認証を提供します。ローカルデバイスは、CNにこの体を送信します。これは無差別に別のユーザーのセッションを交換するから、悪意のあるユーザーを保持します。ローカルデバイスがREFERリクエストを受信すると、それはCNにINVITEリクエストを送信し、通常のセッションのセットアップが行われます。 CNは、MNとのセッションを切断します。
Once the local device has established a session with the CN, it sends a NOTIFY request to the MN, as specified in [3]. This NOTIFY contains the To (including tag), From (including tag), and Call-ID header fields from the established session to allow the MN to subsequently retrieve the session, as described in Section 5.4.2.
ローカルデバイスはCNとのセッションを確立した後、それは、[3]で指定されるように、MNに対してNOTIFYリクエストを送信します。これは、NOTIFY（タグを含む）から、（タグを含む）には含まれており、5.4.2項で説明したようにMNはその後、セッションを取得できるようにするために確立されたセッションからのヘッダフィールド-IDを呼び出します。
Once a session is transferred, the destination for MESSAGE requests moves automatically. Since a new session is established between the CN and the local device, any subsequent MESSAGE requests will be sent to that device.
セッションが転送されると、メッセージの宛先は、自動的に移動を要求します。新しいセッションがCNとローカルデバイスとの間で確立されているので、それ以降のMESSAGE要求は、そのデバイスに送信されます。
The transfer flow described above for media sessions may also be used to transfer an MSRP session. The local device will initiate an MSRP session in message (4), along with the other sessions. The REFER request (1) indicates that an MSRP session should be established using callee capabilities in the Refer-To header field, as it does for audio and video. Such a media feature tag, "message" has already been defined [11]. Once the local device receives the REFER request, it initiates an MSRP session with the CN. As the initiator, it will establish a TCP connection in order to carry the session (as specified in [7]), or will set up the session through its relay if configured to do so.
メディアセッションのために上記搬送フローはまた、MSRPセッションを転送するために使用されてもよいです。ローカルデバイスは、他のセッションと一緒に、メッセージ（4）でMSRPセッションを開始します。 REFER要求（1）MSRPセッションが参照-には、オーディオとビデオの場合と同様に、フィールドをヘッダに着信機能を使用して確立されるべきであることを示しています。そのようなメディア特徴タグは、「メッセージ」は、既に定義されている[11]。ローカルデバイスは、REFER要求を受信すると、それはCNとのMSRPセッションを開始します。開始剤としては、それがそうするように構成されている場合、またはそのリレーを介してセッションを設定します（[7]で指定されるように）セッションを実行するためにTCPコネクションを確立します。
device15 MN CN
|(1) REFER | |
|<----------------------------| |
|(2) 202 Accepted | |
|---------------------------->| |
|(3) REFER | |
|---------------------------->| |
|(4) 202 Accepted | |
|<----------------------------| |
| |(5) INVITE, Replaces |
| |-------------------->|
| | RTP |
| |<....................|
| |(6) 200 OK |
| |<--------------------|
| | RTP |
| |....................>|
| |(7) ACK |
| |-------------------->|
| (8) BYE | |
|<--------------------------------------------------|
| (9) 200 OK | |
|-------------------------------------------------->|
| | |
| | |
Figure 5. Session Handoff mode flow for session retrieval.
セッション検索5.セッションハンドオフモードフロー図。
Figure 5 shows the flow for retrieval by the MN of a session currently on a local device. In order to better motivate the message flow, we start by describing the final INVITE (5) and work backwards. In order for a device to retrieve a session in Session Handoff mode, it must initiate a session with the CN that replaces the CN's existing session. The following message is sent by the MN to the CN (5):
図5は、ローカルデバイス上の現在のセッションのMNによる検索のためのフローを示します。より良いメッセージ・フローをやる気にさせるために、我々は、INVITE（5）と逆方向に動作し、最終的に記述することから始めます。セッションハンドオフモードでセッションを取得するデバイスのためには、CNの既存のセッションを置き換えるCNとのセッションを開始する必要があります。次のメッセージがCNにMN（5）によって送信されます。
INVITE sip:corresp@example.com;gr=urn:uuid:bbb6981 SIP/2.0 To: <sip:corresp@example.com;gr=urn:uuid:bbb6981> From: <sip:bob@example.com> Replaces: 1@device15.example.com;to-tag=aaa;from-tag=bbb Referred-By: <sip:device15@example.com>
SIP INVITE：corresp@example.comと、GR = URN：UUID：bbb6981のSIP / 2.0 <SIP：corresp@example.com; GR = URN：UUID：bbb6981>から<SIP：bob@example.com>に置き換え：1@device15.example.com;のタグ= AAA;からタグ= BBB呼ばバイ<SIP：device15@example.com>
[S/MIME authentication body]
[S / MIME認証体]
Since the users on the MN and the local device are different identities, the MN needs to be referred by the local device and include its URI in the Referred-By header, in addition to including an S/MIME authentication body from the local device, in order to be permitted to replace the session. Therefore, the MN must receive a REFER request from the local device referring it to send this INVITE request. The user could use the user interface of the local device to send this REFER message. However, such an interface may not be available. Also, the user may wish to execute the transfer while running out of the office with mobile device in hand. In order for the MN to prompt the REFER from the local device, it sends a "nested REFER" [5], a REFER request for another REFER. In this case, the second REFER is sent back to the Mobile Node. That REFER must specify that the Replaces header be included in the subsequent INVITE request. The REFER request from the local device to the MN (3) is composed as follows:
MNおよびローカルデバイス上のユーザーが別のIDであるので、MNは、ローカルデバイスからS / MIME認証体を含むことに加えて、呼ばれるバイヘッダに自装置が参照される必要があり、そのURIを含みます順番にセッションを交換することを許可します。そのため、MNは、このINVITEリクエストを送信するために、それを参照するローカルデバイスからREFER要求を受けなければなりません。ユーザは、このREFERメッセージを送信するローカルデバイスのユーザインタフェースを使用することができます。しかしながら、そのようなインタフェースが利用可能ではないかもしれません。また、ユーザーが手にモバイルデバイスで、オフィスの外に実行している間転送を実行することもできます。 MNは、ローカルデバイスからREFER要求するために、それは、「ネストされたREFER」を送信する[5]、別の要求をREFER REFER。この場合には、REFER第二のモバイルノードに送り返されます。すなわち、REFERはReplacesヘッダが、後続のINVITE要求に含まれることを指定しなければなりません。次のように（3）が構成されているMNにローカルデバイスからの要求を参照してください。
REFER sip:bob@example.com;gr=urn:uuid:ytav223h67gb3 SIP/2.0
To: <sip:bob@example.com;gr=urn:uuid:ytav223h67gb3>
From: <sip:device15@example.com>
Refer-To: <sip:correspondent@example.com;gr=urn:uuid:bbb6981;audio;
video?Replaces="1@device15.example.com;to-tag=aaa;
from-tag=bbb">
Referred-By: <sip:device15@example.com>
[S/MIME authentication body]
[S / MIME認証体]
A header field is included in the Refer-To URI to specify the value of the Replaces header in the target INVITE request. In order to have this message sent to it, the MN must send the following REFER request (1):
ヘッダフィールドはINVITE参照の対URI対象におけるReplacesヘッダーの値を指定する要求に含まれています。それに送られ、このメッセージを持っているために、MNは、以下を送信する必要があります（1）要求を参照してください。
REFER sip:device15@example.com;gr=urn:uuid:qfnb443ccui SIP/2.0
To: <sip:device15@example.com;gr=urn:uuid:qfnb443ccui>
From: <sip:bob@example.com>
Refer-To:<sip:bob@example.com;gr=urn:uuid:ytav223h67gb3;method=REFER
?Refer-To="<sip:correspondent@example.com;gr=urn:uuid:bbb6981;
audio;video?Replaces=%221@device15.example.com;
to-tag=aaa;from-tag=bbb%221>">
The Refer-To header specifies that the MN is the refer target and that the referral be in the form of a REFER request. The header field specifies that the REFER request contains a Refer-To header containing the URI of the CN. That URI, itself, contains the "audio" and "video" callee capabilities that will tell the MN to initiate an audio and video call, and a header field specifying that the ultimate INVITE request contains a Replaces header. If the MN had previously transferred the session to the local device, it would have received these in the NOTIFY sent by the local device following the establishment of the session. If, on the other hand, the MN is retrieving a session it had not previously held, as mentioned above in Section 5.1.1, it gets these parameters by subscribing to the Dialog Event Package [13] of the local device. Such a subscription would only be granted, for instance, to the owner of the original device that carried the session. Even when these parameters are provided in the Replaces header, the local device does not accept the REFER request from anybody except the original participant in the session or the owner of the device. The MN receives the REFER request from the local device, sends the INVITE request to the CN, which accepts it, and, once the session is established, terminates its session with the local device.
参照のために、ヘッダMNは、参照対象であることを指定し、照会が参照要求の形であること。ヘッダフィールドは、REFER要求が含まれていることを指定する参照の-するCNのURIを含むヘッダ。 URI、それ自体は、「オーディオ」、音声およびビデオ通話、および究極のINVITEリクエストがReplacesヘッダーが含まれていることを指定するヘッダフィールドを開始するために、MNを教えてくれます「ビデオ」呼び出し先機能が含まれていること。 MNは、以前にローカルデバイスへセッションを転送していた場合、それはセッションの確立次のローカルデバイスによって送信されたNOTIFYでこれらを受けているだろう。 5.1.1項で前述したように、一方で、MNは、それが以前に開催されていなかったセッションを取得している場合は、ローカルデバイスのダイアログイベントパッケージ[13]に加入することにより、これらのパラメータを取得します。そのようなサブスクリプションは、セッションを行う元のデバイスの所有者に、例えば、付与されることになります。これらのパラメータは、Replacesヘッダー内に設けられている場合でも、ローカル装置は、セッション中に、元の参加者またはデバイスの所有者以外は誰からのREFERリクエストを受け付けません。 MNは、セッションが確立されると、それを受け入れ、CN、へINVITEリクエストを送信し、そして、ローカルデバイスからREFER要求を受信すると、ローカルデバイスとのセッションを終了します。
Splitting a session in SH mode requires multiple media sessions to be established between the CN and local devices, without the MN controlling the signaling. This could be done by sending multiple REFER requests to the local devices, referring each to the CN. The disadvantage of this method is that there is currently no standard way to associate multiple sessions as part of a single call in SIP. Therefore, each session between the CN and a local device will be treated as a separate call. They may occupy different parts of the user interface, their media may not be available simultaneously, and they may have to be terminated separately. This certainly does not fulfill the requirement of seamlessness.
SHモードでセッションを分割する複数のメディアセッションは、シグナリングを制御することなくMN、CNとローカルデバイスとの間で確立することが必要です。これは、ローカルデバイスに複数のREFERリクエストを送信するCNにそれぞれを参照することによって行うことができます。この方法の欠点は、SIP内の単一コールの一部として、複数のセッションを関連付けるための標準的な方法は現在存在しないことです。したがって、CNとローカルデバイスとの間の各セッションは、別のコールとして扱われます。彼らは、ユーザーインターフェイスのさまざまな部分を占めることができる、自分のメディアを同時に使用できない可能性があり、そしてそれらを個別に終了する必要があります。これは確かにシームレスの要件を満たしていません。
This document describes the use of multi-device systems to overcome this problem. A local device's SLP UA queries for other devices and joins with them to create a "virtual device", or a Multi-Device System (MDS). We refer to the controlling device as the Multi-Device System Manager (MDSM). In a system that includes at least one mobility-enhanced device, one of them may act as the MDSM. In a system consisting entirely of basic devices, either a dedicated host or another local device from outside of the system acts as MDSM. When the MDSM subsequently receives a REFER request, it uses third-party call control to set up media sessions between the CN and each device in the system. Specifically, it invites each local device into a separate session, and uses their media parameters (and possibly its own) in the INVITE request it sends to the CN.
この文書では、この問題を克服するためのマルチデバイス・システムの使用を記載しています。ローカルデバイスのSLP UAは、他のデバイスに照会し、「仮想デバイス」、またはマルチデバイスシステム（MDS）を作成するためにそれらを結合します。私たちは、マルチデバイスシステムマネージャ（MDSM）として制御装置を参照してください。少なくとも一つの可動性増強装置を含むシステムでは、そのうちの一つは、MDSMとして作用することができます。基本的なデバイスの完全なるシステム、専用ホストまたはMDSMなどのシステム動作の外部から別のローカルデバイスのいずれかで。 MDSMがその後REFER要求を受信すると、CNと、システム内の各デバイス間のメディアセッションを設定するために、サードパーティの呼制御を使用します。具体的には、別々のセッションに各ローカルデバイスを招き、それがCNに送信するINVITE要求におけるそれらのメディアパラメータ（およびおそらく独自）を使用します。
A single device may act as an MDSM for several different groups of devices, and also act as an ordinary device with only its native capabilities. There must be a way to address a request to a device and specify whether it is to the device itself or one of the multi-device systems it controls. As mentioned above in Section 5.2, a device registers a separate contact for itself and for each of its multi-device systems. For example, the device with AOR "sip:device11@example.com" and hostname "device11.example.com" will register a contact "sip:device11@device11.example.com" that represents its own capabilities. Once it discovers other devices and creates an MDS, it will register a new contact, "sip:av1@device11.example.com". It associates a GRUU with each of these contacts. The device itself and any new system is registered in SLP using the GRUU. When the proxy receives a request addressed to a GRUU, it will rewrite it as the contact URI before forwarding the request to the device. The device will use this unique contact to determine whether to handle the request natively or with one of its systems.
単一のデバイスは、デバイスのいくつかの異なるグループのためにMDSMとして作用し、また唯一のネイティブ機能を備えた通常のデバイスとして働くことができます。デバイスへの要求に対処し、それがデバイス自体またはそれが制御するマルチデバイス・システムのいずれかにあるかどうかを指定する方法があるに違いありません。セクション5.2で上述したように、デバイスは、それ自体のために、そのマルチデバイスシステムの各々のための別個の接触を登録します。例えば、AOR「SIP：device11@example.com」とデバイス：独自の能力を表し、ホスト名「device11.example.comは」接触「device11@device11.example.com一口」を登録します。それは他のデバイスを検出し、MDSを作成したら、それは新しい連絡先、「：av1@device11.example.com一口」を登録します。これは、これらの接点のそれぞれとのGRUUを関連付けます。デバイス自体とその新しいシステムがGRUUを使用してSLPに登録されています。プロキシはリクエストがGRUU宛受信すると、そのデバイスに要求を転送する前に、コンタクトURIとしてそれを書き換えます。デバイスは、ネイティブまたはそのシステムの一つで要求を処理するかどうかを決定するために、このユニークな連絡先を使用します。
Figure 6 shows the transfer of a session to a multi-device system. The audio device has previously discovered the video device and created a multi-device system. The REFER request sent to "sip:device11@example.com;gr=urn:uuid:893eeeyuinm981" prompts the audio device to invite the video device into a session to ascertain its SDP, and then to invite the CN into a session using its own SDP and that of the video device.
図6は、マルチデバイスシステムへのセッションの転送を示します。オーディオデバイスは、以前にビデオデバイスを発見し、マルチデバイスシステムを作成しました。そのSDPを確認するためにセッションにビデオデバイスを招待し、そのを使用してセッションにCNを招待するオーディオデバイスを促す;：「：UUID 893eeeyuinm981がGR = URN device11@example.com SIP」に送信されたREFER要求自分のSDPおよびビデオ装置と。
video audio MN CN
| |(1) REFER | |
| |<--------------------| |
| |(2) 202 Trying | |
| (3) INVITE no sdp |-------------------->| |
|<---------------------| | |
| (4) 200 OK SDP | | |
|--------------------->| | |
| |(5) INVITE a/v SDP, Replaces |
| |--------------------------------->|
| | RTP Audio |
| |<.................................|
| | RTP Video |
|<........................................................|
| |(6) 200 OK CN SDP |
| |<---------------------------------|
| | RTP Audio |
| (7) ACK CN Video SDP |.................................>|
|<---------------------| | |
| RTP Video | | |
|........................................................>|
| |(8) ACK | |
| |--------------------------------->|
| | |(9) BYE |
| | |<-----------|
| | |(10) 200 OK |
| | |----------->|
| | | |
| | | |
Figure 6. Session Handoff to a multi-device system.
マルチデバイスシステムに6セッションのハンドオフを図。
The examples presented above have involved an established session that a user transfers to one or more devices. Another scenario would be for an incoming call to be immediately distributed between multiple devices when the user accepts the call. In such a case, the initial session would not yet be established when the transfer takes place.
上記の例は、1つのまたは複数のデバイスへのユーザの転送確立されたセッションに関与しています。別のシナリオは、ユーザがコールを受け入れると直ちに、複数のデバイス間に分散される着信呼のためであろう。転送が行われるとき、そのような場合には、最初のセッションはまだ確立されません。
The transfer could be carried out in either of the transfer modes. However, complete handoff to a separate device, which is done in Session Handoff mode, could be achieved through existing means, such as proxying or redirection. MNC mode would be useful in a case where the user wishes to automatically include an additional device in a call. For instance, a user with a desk IP phone and a PC with a video camera could join the two into a single logical device. The
転送は、転送モードのいずれかで行うことができました。しかし、セッションハンドオフモードで行われる別のデバイスへの完全なハンドオフは、そのようなプロキシまたはリダイレクトなどの既存の手段によって達成することができます。 MNCモードは、ユーザが自動的にコールに追加のデバイスを含むことを望む場合に有用であろう。例えば、ビデオカメラ付きデスクIP電話とPCを持つユーザーは、単一の論理デバイスに2を結合することができます。ザ・
SIP UA on the PC would, for any incoming call, send an INVITE request to the desk phone, setting the display name in the From header field to "Bob Jones (audio portion)", for instance, so that the user can identify the caller on the phone. The user could then either accept or reject, as he would with a call coming directly to the phone. If he accepts, the PC UA, acting as the controller, would respond to the caller with its video parameters and the phone's audio parameters in the SDP body. The final ACK from the Correspondent Node would then complete the session establishment.
PC上のSIP UAは、任意の着信コールのために、Fromヘッダーフィールドに表示名を設定し、デスクの電話にINVITEリクエストを送信します例えば、「ボブ・ジョーンズ（音声部分）」、利用者が識別できるように電話での発信者。彼は電話に直接来てコールと同じように、ユーザは、その後、受け入れるか拒否することができどちらか。彼が受け入れた場合、PC UAは、コントローラとして動作し、そのビデオパラメータとSDPボディで携帯電話の音声パラメータで呼び出し元に応答します。相手ノードからの最終ACKは、セッション確立を完了します。
If the desk phone is registered as a contact for the user, it would also ring in response to the direct call being proxied there, in addition to the INVITE request sent by the controller, causing confusion to the user. The use of caller preferences can solve this problem, as the caller would indicate that the call should preferentially be proxied to devices with audio and video capabilities. It is likely that the caller would use caller preferences in any case, if they were available to him, to avoid the callee unknowingly picking up the IP phone when he has a video-capable device available. However, since caller preferences are not yet widely supported on commercial devices, the callee must ensure the proper routing of the call. One solution would be for the PC to register its contact with a higher priority than the one given to the phone. The Call Processing Language (CPL) [22] (the "proxy" node) could then be used to specify that forking should be done to the set of user devices in sequence, rather than in parallel. Since all calls would first be sent to the PC as long as it were online, it would redirect any request that included only audio in its SDP.
デスクの電話がユーザーの連絡先として登録されている場合、それはまた、ユーザーに混乱を引き起こし、コントローラによって送られたINVITEリクエストに加えて、そこにプロキシされている直接呼び出しに応じて鳴ります。呼び出し側は、コールが優先オーディオおよびビデオ機能を備えたデバイスにプロキシする必要があることを示すだろうと、発信者の好みの使用は、この問題を解決することができます。彼らが彼に利用できた場合、発信者は、彼が使用可能なビデオ対応デバイスを持っているとき、無意識のうちにIP電話を拾っ呼び出し先を避けるために、どのような場合には、発信者の好みを使用する可能性が高いです。発信者の好みがまだ広く商用デバイスではサポートされていないので、呼び出し先は、コールの適切なルーティングを確認する必要があります。一つの解決策は、携帯電話に与えられたものよりも高い優先順位との接触を登録するPCのためになります。呼処理言語（CPL）[22]（「プロキシ」ノード）は、そのフォークではなく平行に比べ、シーケンス内のユーザ装置のセットに行われるべき指定するために使用することができます。すべてのコールが最初であれば、オンラインであったようにPCに送信されるので、それはそのSDPで音声のみ含まれるすべての要求をリダイレクトします。
Interactive Connectivity Establishment (ICE) [27] is a protocol for Network Address Translator (NAT) traversal that may be used with SIP. Rather than negotiating addresses and ports used for media sessions directly in SDP, a list of possible address/ports (candidates) is exchanged, and the Session Traversal Utilities for NAT (STUN) [28] protocol is used to check which pairs of candidates may be used. ICE could be used in the call flows described in this section. In MNC mode, the candidates would be sent by each local device to the MN, who would exchange them with the CN. Afterward, each device would perform checks with the CN to determine an appropriate candidate. In SH mode, where the local device establishes a session with the CN, ICE would work no differently than in the standard case.
インタラクティブ接続確立（ICE）[27]はSIPで使用することができるネットワークアドレス変換（NAT）トラバーサルのためのプロトコルです。むしろ直接SDP内のメディアセッションに使用されるアドレスとポートを交渉よりも、可能なアドレス/ポート（候補）のリストが交換され、およびセッショントラバーサルユーティリティは、NAT（STUN）のための[28]プロトコルは、候補のどのペアをチェックするために使用されてもよいです利用される。 ICEは、このセクションで説明するコールフローで使用することができます。 MNCモードでは、候補者は、CNでそれらを交換しますMNに各ローカルデバイスによって送信されます。その後、各デバイスは、適切な候補者を決定するために、CNとのチェックを行うことになります。ローカルデバイスがCNとのセッションを確立SHモードでは、ICEは全く異なり、標準の場合よりも動作しないでしょう。
Session mobility sometimes involves the transfer of a session between devices with different capabilities. For example, the codec being used in the current session may not be available on the new device. Furthermore, that device may not support any codec that is supported by the CN. In addition to codecs, devices may have different resolutions or bandwidth limitations that must be taken into account when carrying out a session transfer.
セッションモビリティは時々異なる機能を持つデバイス間でのセッションの移動を伴います。例えば、現在のセッションで使用されるコーデックは、新しいデバイス上で利用可能ではないかもしれません。さらに、その装置は、CNによってサポートされている任意のコーデックをサポートしていなくてもよいです。コーデックに加えて、デバイスは、異なる解像度やセッション転送を行う際に考慮しなければならない帯域幅の制限を有することができます。
Before executing a session transfer, the device checks the capabilities of the CN and the new device. These may be found through either the SIP OPTIONS method, used in SIP to query a device's media capabilities, or may be included as SLP service attributes. Since the OPTIONS method is standard, it is suggested to be used to query the CN, while SLP is suggested to be used to get the media capabilities of local devices, since it is already being used for them.
セッション転送を実行する前に、デバイスはCNと新しいデバイスの機能を確認します。これらは、デバイスのメディア機能を照会するためにSIPで使用されるSIP OPTIONS方法、のいずれかを通して見ることができる、またはSLPサービスの属性として含めることができます。 OPTIONSメソッドが標準ですので、SLPは、ローカルデバイスのメディア機能を取得するために使用することが示唆されている間、それはすでに彼らのために使用されているので、CNを照会するために使用することが示唆されます。
If the CN and the local device are found to have a common codec, the transfer flow will negotiate that this should become the codec used in the media session. In MNC mode, the MN forwards the response from the local device to the CN, who will choose a codec it supports from those available. In Session Handoff mode, the MN sends a REFER request to the local device and allows it to negotiate a common codec with the CN during their session establishment. No special behavior of the MN is required.
CNおよびローカルデバイスが共通のコーデックを有することが判明している場合は、転送フローは、これはメディアセッションで使用されるコーデックになっていることを交渉します。 MNCモードでは、MNは、それが利用可能なものからサポートコーデックを選択しますCNへのローカルデバイスからの応答を転送します。セッションハンドオフモードでは、MNは、ローカルデバイスを参照する要求を送信し、それが彼らのセッション確立中にCNと共通のコーデックを交渉することができます。 MNの特別な動作は必要ありません。
If the MN sees that a common codec does not exist, it executes the transfer through an intermediate transcoding service. Rather than establishing a direct media session between the CN and the local device, separate sessions are established between the transcoder and each of them, with the transcoder translating between the streams. The Mobile Node discovers available transcoders through some means, including SLP.
MNは、共通のコーデックが存在しないことを認識した場合、それは中間のトランスコーディングサービスを介して転送を実行します。むしろCNとローカルデバイスとの間の直接的なメディアセッションを確立するよりも、別のセッションはストリーム間のトランスコーダの並進と、トランスコーダ及びそれらのそれぞれの間に確立されています。モバイルノードは、SLPを含むいくつかの手段を介して利用可能なトランスコーダを、発見します。
Using transcoding services in SIP is defined in [18] using third-party call control. In MNC mode, the Mobile Node establishes one media session between the transcoder and the CN, and one between the transcoder and the local device. This differs from the normal transcoding case, where one party establishes a media session between itself and the transcoder and one between the transcoder and the other party. The MN starts by sending an INVITE request to the local device with no body; it receives in the response the list of codecs that the device can use. It then repeats this for the CN, and receives its available codecs. It chooses one codec from each side, along with the address and port of each device, and combines them in an INVITE request sent to the transcoder. The transcoder responds with the ports on which it will accept each stream. The appropriate port information is sent individually to the CN and the local device. Once the three sessions have been established, two media sessions exist, and the transcoder translates between them. This flow is shown in Figure 7.
SIPにトランスコーディングサービスを使用して、サードパーティの呼制御を使用して[18]で定義されています。 MNCモードでは、モバイルノードはトランスコーダとCNとの間の1つのメディアセッションを確立し、トランスコーダとローカルデバイスとの間の1つ。これは、一方の当事者が自分自身とトランスコーダとトランスコーダと相手方との間に1間のメディアセッションを確立し、通常のトランスコーディングの場合とは異なります。 MNは無いボディとローカルデバイスにINVITEリクエストを送信することにより開始します。それは応答して、デバイスが使用できるコーデックのリストを受け取ります。その後、CNのためにこれを繰り返し、その利用可能なコーデックを受けます。これは、各デバイスのアドレスおよびポートと共に、各側から1つのコーデックを選択し、そしてトランスコーダに送信されたINVITE要求にそれらを結合します。トランスコーダは、各ストリームを受け入れるのポートで応答します。適切なポート情報がCNとローカルデバイスへ個別に送信されます。 3つのセッションが確立されたら、2つのメディアセッションが存在し、トランスコーダは、それらの間の変換を行います。このフローは、図7に示されています。
AN Transcoder MN CN
(codec A) (codec B)
| |(1) INVITE no sdp | |
|<---------------------------------------| |
| |(2) 200 AN params | |
|--------------------------------------->| |
| | |(3) INVITE no sdp |
| | |---------------------->|
| | |(4) 200 OK CN params |
| | |<----------------------|
| |(5) INVITE AN, CN params | |
| |<---------------------------| |
| |(6) 200 OK TA, TB params | |
| |--------------------------->| |
| |(7) ACK | |
| |<---------------------------| |
| |(8) ACK TA params | |
|<---------------------------------------| |
| RTP | | |
|..........>| RTP | |
| |...................................................>|
| | | (9) ACK TB params |
| | |---------------------->|
| | | RTP |
| RTP |<...................................................|
|<..........| | |
| | | |
Figure 7. Transfer of a session in Mobile Node Control mode
through a transcoder to translate between native codecs
of CN and an audio node AN, where they share no common
codec.
In Session Handoff mode, the local device itself establishes a session with the CN through the transcoder. After receiving the REFER request, it uses the OPTIONS method to find the capabilities of the CN. It will then use a common codec, if available, in the session setup, or set up the transcoded session using third-party call control as in [18].
セッションハンドオフモードでは、ローカルデバイス自体は、トランスコーダを介してCNとのセッションを確立します。 REFER要求を受信した後、それはCNの機能を見つけるために、OPTIONSメソッドを使用しています。これは、利用可能な場合には、セッション設定で、共通のコーデックを使用するか、または[18]のようなサードパーティコール制御を使用してトランスコードセッションを設定します。
Other differences in device capabilities, such as display resolution and bandwidth limitations, are also suggested to be reconciled during transfer. For example, a mobile device, limited both in its display size and bandwidth, will likely be receiving the video stream from the other call participant at a low resolution and frame rate. When the user transfers his video output to a large-screen display, he may start viewing much higher-quality video at the higher native resolution of the display and at a higher frame rate.
このようなディスプレイの解像度や帯域幅の制限などのデバイスの機能の他の違いは、また、転送中に和解していることが示唆されています。例えば、両方の表示サイズ及び帯域幅に制限モバイルデバイスは、おそらく低解像度とフレームレートで他の通話参加者からのビデオストリームを受信します。ユーザーが大画面ディスプレイへの彼のビデオ出力を転送するとき、彼は、ディスプレイの高いネイティブ解像度で、高フレームレートではるかに高い品質のビデオを見始めることができます。
Changing the image resolution and frame rate requires no special handling by the MN. An SDP format is defined [19] for specifying these and other parameters for the H.263+ codec, for example. The suitable image formats and corresponding MPIs (Minimum Picture Interval, related to the frame rate) supported for the given codec are listed following the media line, in order of preference. For example, the following lines in SDP would indicate that a device supports the H.263 codec (value 34) with the image sizes of 16CIF, 4CIF, CIF, and QCIF (with the MPI for each format following the "="):
画像解像度とフレームレートを変更すると、MNによって特別な処理は必要ありません。 SDPフォーマットが定義されている[19]例えば、H.263 +コーデックのこれらおよびその他のパラメータを指定します。所定のコーデックのサポート（フレームレートに関連する最小ピクチャ間隔）適切な画像フォーマットと対応のMPIは、優先順に、メディア・ライン以下に列挙する。例えば、SDPの次の行は、デバイスが（「=」次の各フォーマットにMPIを伴う）16CIF、4CIF、CIF、およびQCIFの画像サイズでH.263コーデック（値34）をサポートしていることを示すであろう。
m=video 60300 RTP/AVP 34 a=fmtp:34 16CIF=8;4CIF=6;CIF=4;QCIF=3
M =ビデオ60300 RTP / AVP 34 =のfmtp：34 16CIF = 8; 4CIF = 6; CIF = 4; QCIF = 3
In MNC mode, the response by the local device (Figure 2, message 2) to the initial INVITE request sent by the MN includes this line in the SDP body, and the MN then includes it in the INVITE request sent to the CN (3). In Session Handoff mode, the local device includes this parameter in the INVITE request sent to the CN (Figure 4, message 3) after receiving the REFER request. If the local device is not configured to include the supported image sizes during session establishment, the information could be made available through SLP. The MN then includes it in the INVITE request sent to the CN in Mobile Node Control mode. However, this information is not sent in Session Handoff mode unless the local device was configured to send it. In both modes, the MN sends its own resolution and frame rate preferences in the body of the INVITE request sent to retrieve the session.
3（MNCモードでは、MNによって送信された初期INVITE要求にローカルデバイス（図2、メッセージ2）による応答はSDPボディにおいて、このラインを含み、MNは次いで、CNに送信されたINVITEリクエストに含め）。セッションハンドオフモードでは、ローカルデバイスは、REFER要求を受信した後にCN（図4、メッセージ3）に送信されたINVITEリクエストでこのパラメータを含みます。ローカル装置は、セッション確立時にサポートされている画像サイズを含むように構成されていない場合、情報は、SLPを介して利用可能にすることができます。 MNは次いで、移動ノード制御モードでCNに送信INVITE要求に含め。ローカルデバイスは、それを送信するように設定された場合を除きしかし、この情報は、セッションハンドオフモードでは送信されません。どちらのモードでも、MNは、セッションを取得するために送られたINVITEリクエストのボディに、独自の解像度とフレームレート設定を送信します。
A session transfer may be carried out by one call participant after the other participant has transferred the session on his side. If the first transfer was done in MNC mode, a subset of the original session media is now on local devices. The MN receives either a re-INVITE from the other participant or an INVITE request from a local device on the other side. This message carries the new media parameters of the session. The MN, therefore, must send a re-INVITE to any local devices with these parameters. It then includes the parameters returned from these devices in the 200 OK response. If the first transfer was done in SH mode, the local device will directly receive the session transfer message from the other party and will follow the normal procedure for responding to an INVITE request. If it is controlling other local devices for this session as part of an MDS, it follows the procedure above, where the first transfer was done in MNC mode.
他の参加者が自分の側でセッションを転送した後にセッション転送は、1人のコールの参加者によって行うことができます。最初の転送はMNCモードで行われた場合は、元のセッションのメディアのサブセットは、ローカルデバイス上で今です。 MNはいずれかの他の参加者からの再INVITEまたは他の側のローカルデバイスからINVITE要求を受信します。このメッセージは、セッションの新しいメディアパラメータを運びます。 MNは、それゆえ、これらのパラメータを持つ任意のローカルデバイスに再INVITEを送信する必要があります。その後、200 OK応答では、これらのデバイスから返されたパラメータを含んでいます。最初の転送がSHモードで行われた場合、ローカルデバイスは、直接、他のパーティからのセッションの転送メッセージを受信すると、INVITE要求に応答するための通常の手順に従います。それはMDSの一部として、このセッションのために他のローカルデバイスを制御している場合、それは一次転写がMNCモードで行った上記の手順に従います。
It may occur that both participants attempt a transfer at the same time. In MNC mode, each node initiates a session with a local device, then sends a re-INVITE to the other node. Section 14.2 in [1] mandates a 491 response when a re-INVITE is received for a dialog once another re-INVITE has already been sent. Once both parties receive this response, they each generate a random timer with staggered intervals. Once its timer fires, each participant attempts the re-INVITE again. The first to receive it from the other participant responds to it with the SDP parameters of its local device. Both participants then send an ACK request to their local device containing the new parameters obtained from the other one during the re-INVITE process.
両方の参加者が同時に転送を試みることを発生することがあります。 MNCモードでは、各ノードはローカルデバイスとのセッションを開始し、その後、他のノードに再INVITEを送信します。別の-INVITE再すでに送信された後、ダイアログのために受信されたときに再INVITE [1]で14.2は491応答を義務付け。両当事者は、この応答を受信したら、彼らはそれぞれ、千鳥間隔でランダムタイマーを生成します。そのタイマーが起動したら、各参加者は、再び再INVITEをしようとします。他の参加者からそれを受信する最初は、ローカルデバイスのSDPパラメータを使用してそれに応答します。両方の参加者は、その後、再INVITEプロセス中に他の一方から得られた新たなパラメータを含むそのローカルデバイスにACK要求を送ります。
In SH mode, if both participants attempt a transfer at the same time, after one node sends a REFER request to the local device, it receives the INVITE request from the local device on the other end. The appropriate protocol definition could mandate that a 491 response be sent in this case, as well. This response would be returned to the referrer in a NOTIFY indicating the status of the referred session establishment. The staggered timer solution described above could work. The MN would cancel the REFER request sent to the local device, then wait a random amount of time before sending it again.
両方の参加者が同時に転送を試みる場合は、1つのノードがローカルデバイスを参照要求を送信した後、SHモードでは、それは、もう一方の端のローカルデバイスからINVITE要求を受信します。適切なプロトコル定義は、491応答は同様に、この場合に送信されることを強制できました。この応答は呼ばセッション確立の状況を示すNOTIFYにリファラーに戻されることになります。上記の千鳥タイマーソリューションは、仕事ができます。 MNは再びそれを送信する前にランダムな時間を待って、ローカルデバイスに送信されたREFERリクエストをキャンセルします。
Once a session has been transferred, the user may terminate it by hanging up the current device, as he would do in a call originating on that device. This should be true even when the session is using several local devices. In MNC mode, when the user hangs up the current device, a BYE request is sent to the controller. The controller must then send a BYE request to each device used in the transfer and a BYE request to the CN. An MDSM used for SH mode must follow the same procedure. In SH mode, the current device has previously initiated an ordinary session with the CN in response to the REFER request, and the BYE it sends to the CN on hang-up requires no special handling.
セッションが転送されると、彼はそのデバイス上で発信して行うように、ユーザーは、現在のデバイスをハングアップすることによってそれを終了することができます。これは、セッションが複数のローカルデバイスを使用する場合であっても真でなければなりません。ユーザが現在のデバイスをハングアップするときMNCモードでは、BYE要求が制御装置に送られます。次に、コントローラは、CNへの転送とBYE要求に使用される各デバイスにBYE要求を送信しなければなりません。 SHモードで使用MDSMは、同じ手順に従わなければなりません。 SHモードでは、現在のデバイスは、以前にREFERリクエストに応じて、CNと通常のセッションを開始しており、それがハングアップにCNに送信するBYEは、特別な処理は必要ありません。
As this work is based heavily on the work in [2], [3], and [5], the security considerations described in those documents apply. We discuss here the particular issues of authorizing use of local devices, providing media-level security following transfer, and the issue of flooding attacks in MNC mode.
この作業は、[2]、[3]、[5]、これらの文献に記載されたセキュリティ上の考慮事項が適用で仕事に大きく基づいています。ここでは、ローカルデバイスの使用を許可するメディアレベルの転送を次のセキュリティ、およびMNCモードでのフラッディング攻撃の問題を提供する特定の問題を議論します。
It is necessary that the use of a local device be limited to authorized parties. As stated earlier, this document assumes both personal and public devices, and these have different authorization policies. A personal device only accepts transfer requests from a single identity, the device owner. Therefore, the most appropriate means of access control is to maintain a list of identities representing the device owner authorized to transfer sessions to the device. As mentioned before, the device is configured with an AOR representing its status as a transfer device, in addition to the user's AOR. Only requests made to the device AOR follow the access list, while incoming requests to the user's AOR are accepted from anyone (provided that a white or blacklist or other policy does not preclude their request from being accepted). The SIP-Identity header [25] is used to securely identify the initiator of a SIP request. That specification can be used in our use-cases when the local device must ensure that the INVITE or REFER request in MNC or SH mode, respectively, is indeed from the owner of the device.
ローカルデバイスの使用が許可された者に限定することが必要です。先に述べたように、この文書は、個人と公共の両方のデバイスを想定し、これらは異なる認可ポリシーを持っています。個人的なデバイスは、単一のアイデンティティ、デバイス所有者からの転送要求を受け入れます。したがって、アクセス制御の最も適切な手段は、デバイスにセッションを転送する権限デバイスの所有者を示す識別情報のリストを維持することです。前に述べたように、デバイスは、ユーザのAORに加えて、転写装置としての地位を示すAORで構成されています。ユーザーのAORへの着信要求は（白またはブラックリストまたは他のポリシーが受け入れられてから自分の要求を妨げないものとする）誰からも認められている間、デバイスのAORに作られた唯一の要求は、アクセスリストに従ってください。 SIP-Identityヘッダ[25]安全SIPリクエストのイニシエータを識別するために使用されます。ローカルデバイスは、それぞれ、MNC又はSHモードでINVITE要求またはREFERは、デバイスの所有者から実際にあることを保証しなければならない場合、その仕様は、我々のユースケースで使用することができます。
Public devices accept transfer requests from a large number of identities. Access lists may be used for this purpose. Alternatively, since devices are often available to categories of users, such as "manager" or "faculty member", an appropriate solution may be to use trait-based authorization [23]. Using this mechanism, a user may acquire, from a trusted authorization service, an "assertion" of his user status and permissions. The assertion, or a reference to it, is included in the request to use the device.
公共のデバイスは、アイデンティティの多数からの転送要求を受け入れます。アクセスリストは、この目的のために使用することができます。デバイスは、しばしば、「管理者」または「教職員」としてユーザのカテゴリに利用可能であるので、あるいは、適切な解決策は、形質ベースの許可[23]を使用することができます。このメカニズムを使用して、ユーザは、信頼できる認証サービス、彼のユーザステータスとアクセス権の「主張」から、取得することができます。アサーション、またはそれへの参照は、デバイスを使用するための要求に含まれています。
Confidentiality, message authentication, and replay protection are necessary in internet protocols, including those used for real-time multimedia communications. The Secure Real-time Transfer Protocol (SRTP) [14] provides these for RTP streams. Since SRTP may be used to carry the media sessions of SIP devices, such as the MN and CN, we discuss how to ensure that the session continues to use SRTP following the transfer to another device. This is also discussed in less detail in [2].
機密性、メッセージ認証、および再生保護は、リアルタイムマルチメディア通信のために使用されるものを含むインターネット・プロトコルに必要です。セキュアリアルタイム転送プロトコル（SRTP）[14] RTPストリームのためにこれらを提供します。 SRTPは、MNとCNのようなSIPデバイスのメディアセッションを搬送するために使用することができるので、我々は、セッションが別のデバイスへの転送次のSRTPを使用し続けることを保証する方法について説明します。これはまた、[2]で以下詳細に説明します。
The establishment of secure RTP communications through SDP is defined by two documents. The "crypto" attribute [15] is a media-level attribute whose value includes the desired cryptographic suite and key parameters used to perform symmetric encryption on the RTP packets. Since the key information is sent in the SDP body with no dedicated encryption or integrity protection, a separate protocol such as S/MIME must be used to protect the signaling messages. Another document [16] specifies the "key-mgmt" attribute used to provide parameters for a key management protocol, such as MIKEY. Using this attribute, the two participants exchange keys encrypted by a public or shared key, or negotiate a key using the Diffie-Hellman method.
SDPによるセキュアなRTP通信の確立は、二つの文書で定義されています。 「暗号化」属性[15]は、値の所望の暗号スイートおよびRTPパケットに対して対称暗号化を実行するために使用されるキーパラメータを含むメディアレベル属性です。鍵情報は専用の暗号化または完全性保護とSDP本体に送信されるので、このようなS / MIMEのような別のプロトコルは、シグナリングメッセージを保護するために使用されなければなりません。別の文書[16]例えばMIKEYなどの鍵管理プロトコルのためのパラメータを提供するために使用される「キーMGMT」属性を指定します。この属性を使用して、2人の参加者は、公共または共有鍵で暗号化鍵を交換、またはのDiffie-Hellman方式を使用してキーを交渉します。
The use of cryptographic parameters in SDP does not change the message flows described earlier in this document. For instance, in MNC mode shown in Figure 2, the response from the local device (2) will include, in addition to any supported media type, cryptographic information for each type. This cryptographic information will be a list of attribute lines describing the crypto suite and key parameters using either of the two attributes mentioned. These lines will be sent by the MN to the CN in the subsequent request (3). The CN will choose a cryptographic method and return its own key information in the response (4). Maintaining a secure media session in SH mode requires the local device to negotiate a cryptographic relationship in the session that it establishes following its receipt of the REFER request.
SDP内の暗号化パラメータを使用するメッセージを変更しないが、以前、この文書で説明流れます。例えば、図2に示されているMNCモードでは、ローカルデバイスからの応答は、（2）各タイプのための任意のサポートされるメディアタイプ、暗号情報に加えて、含まれます。この暗号情報は、暗号スイートと述べた二つの属性のいずれかを使用して主要なパラメータを記述した属性行のリストになります。これらのラインは、後続の要求（3）CNにMNによって送信されます。 CNは、暗号化方式を選択し、応答（4）に、自身のキー情報を返します。 SHモードでのセキュアなメディアセッションを維持することは、それがREFER要求のその領収書を以下の確立というセッションでの暗号化の関係を交渉するローカルデバイスが必要です。
It is noted in [2] that establishing media security in third party call control depends on the cooperation of the controller. In this document, the Mobile Node (MN) in Mobile Node Control mode (MNC) has the role of controller in 3pcc, while in the Session Handoff (SH) mode, MN uses the REFER method instead. The following is an excerpt from that document:
サードパーティの呼制御にメディアセキュリティを確立することは、コントローラの協力に依存していること、[2]に記載されています。セッションハンドオフ（SH）モードにおいて、MNはなくREFERメソッドを使用しながら、本書では、モバイルノード制御モードにおけるモバイルノード（MN）（MNC）は、3PCCのコントローラの役割を有しています。以下は、その文書からの抜粋です。
End-to-end media security is based on the exchange of keying material within SDP. The proper operation of these mechanisms with third party call control depends on the controller behaving properly. So long as it is not attempting to explicitly disable these mechanisms, the protocols will properly operate between the participants, resulting in a secure media session that even the controller cannot eavesdrop or modify. Since third party call control is based on a model of trust between the users and the controller, it is reasonable to assume it is operating in a well-behaved manner. However, there is no cryptographic means that can prevent the controller from interfering with the initial exchanges of keying materials. As a result, it is trivially possibl[e] for the controller to insert itself as an intermediary on the media exchange, if it should so desire.
エンドツーエンドメディアのセキュリティはSDP内の材料を鍵の交換に基づいています。サードパーティ呼制御とこれらの機構の適切な動作は、適切に動作し、コントローラに依存します。長いので、明示的にこれらのメカニズムを無効にしようとされていないとして、プロトコルが適切であっても、コントローラは、盗聴または変更することはできません安全なメディアセッションで、その結果、参加者の間で動作します。サードパーティ呼制御をユーザーとコントローラとの間の信頼のモデルに基づいているので、行儀の方法で動作していると仮定することは合理的です。しかし、キーイング材料の初期の交換に干渉コントローラを防ぐことができない暗号化手段が存在しません。結果として、それがそう望むかどうか、メディア交換に仲介者として自分自身を挿入するコントローラの[E]自明possiblあります。
We note here that given the model presented in this document, where the controller is operated by the same person that uses the local device, i.e., the MN user, there is even more reason to believe that the controller will be well-behaved and will not interfere with the initial transfer of key exchanges.
私たちは、コントローラがローカルデバイスを使用して同じ人、すなわちによって運営され、この文書で提示したモデル、与えられた、MNのユーザーは、さらに多くのコントローラは行儀されると考えられる理由と意志があることをここで注目します鍵交換の初期転送を妨げません。
The exchange of media could alternatively be secured at the transport layer, using either TLS or Datagram Transport Layer Security (DTLS) [24]. The one consideration for use of these protocols in session mobility would be assigning the client and server roles. In SH mode, it may be assumed that the local device, the referee, would act as the client, since it is initiating the signaling session with the CN. However, in MNC mode, these roles would be unclear. The same problem was mentioned above in establishing a secure connection for an MSRP session transferred in MNC mode. This problem could be solved through the use of Connection-Oriented Media (COMEDIA) [26], which specifies the "setup" SDP attribute to negotiate these roles.
培地の交換は、代替的にTLSまたはデータグラムトランスポート層セキュリティ（DTLS）[24]のいずれかを使用して、トランスポート層で固定することができます。セッションモビリティにおけるこれらのプロトコルの使用のための1つの考慮事項は、クライアントとサーバーの役割を割り当てることになります。 SHモードでは、CNとのシグナリングセッションを開始しているので、ローカルデバイス、審判は、クライアントとして作用すると仮定することができます。しかし、MNCモードでは、これらの役割が不明確になります。同じ問題は、MNCモードで転送MSRPセッションの安全な接続を確立する際に上述しました。この問題は、これらの役割を交渉する「セットアップ」SDP属性を指定するコネクション型メディア（COMEDIA）[26]の使用により解決することができます。
We describe here briefly how this is done. In the MNC exchange shown in Figure 2, the local device chooses whether to specify a media session over a secured transport in its response to the MN. If so, it includes under the media line a "setup" attribute set to either "active", "passive", or "actpass". This is sent on to the CN. Assuming it agreed to such a session, it responds with a "setup" attribute, as per the COMEDIA specifications. This is then sent by the MN to the local device. If the local device and CN agreed on their roles, the appropriate session could be established, through which the media would be transmitted. Before they transmit media between them, the CN and local device exchange messages to establish the TLS or DTLS session. This same approach could be used to establish an SRTP security context over DTLS, as per [31].
ここでは簡単にこれがどのように行われるかを説明します。図2に示されているMNC交換において、ローカルデバイスは、MNへの応答で保護されたトランスポートを介してメディアセッションを指定するかどうかを選択します。そうだとすれば、それはメディア行の下に「アクティブ」、「受動的」、または「actpass」のいずれかに設定「設定」属性を含んでいます。これは、CNへ送られます。それは、このようなセッションに同意したと仮定すると、それはCOMEDIA仕様に従って、「設定」属性で応答します。これは、ローカルデバイスにMNによって送られます。ローカルデバイスとCNがそれぞれの役割に合意した場合は、適切なセッションは、メディアが送信されるだろう、それを通して、確立することができます。彼らはそれらの間でメディアを送信する前に、CNおよびローカルデバイスの交換メッセージがTLSまたはDTLSセッションを確立します。この同じアプローチは、[31]に従って、DTLS上SRTPセキュリティコンテキストを確立するために使用することができます。
The MNC call flows in this document, where one device instructs another device to send an RTP flow to a third one, present the possibility of a flooding attack. This is a general problem that relates to any use of 3pcc. In this document, it is only a concern where the device is public, as described at the beginning of this section, and a large group of people can transfer media to it, since there may not be a very strong trust relationship between the device owner (e.g., an institution) and the users. Obviously, where a device is private and only its owner can transfer to it, the concern does not exist, given the use of the Identity header mentioned earlier. A possible solution may be the use of ICE [27], since both sides confirm that they want to receive each other's media.
MNCコールは、1つのデバイスがフラッド攻撃の可能性を提示し、第三のいずれかにRTPフローを送信する他の装置に指示し、この文書に流れます。これは3PCCのいずれかの使用に関する一般的な問題です。この文書では、このセクションの冒頭で説明したように、デバイスは、公開されている唯一の関心事である、およびデバイスの所有者との間に非常に強い信頼関係がないかもしれないので、人々の大規模なグループは、それにメディアを転送することができます（例えば、機関）とユーザー。デバイスがプライベートであり、唯一のその所有者がそれに転送することができ、懸念は前述のIdentityヘッダの使用を考えると、存在しません。もちろん、どこ双方がお互いのメディアを受信することを確認するので可能な解決策は、ICE [27]を使用するかもしれません。
We would like to acknowledge the helpful comments made about this document by the SIP community, in particular Jon Peterson, Joerg Ott, and Cullen Jennings.
私たちは、特定のジョン・ピーターソン、イェルク・オット、およびカレンジェニングスに、SIPコミュニティによって、この文書について行わ有益なコメントを承認したいと思います。
[1] 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.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[2]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[3] R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月、火花。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[5] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[5]、R.、 "セッション開始プロトコル（SIP）と呼ば-メカニズム"、RFC 3892、2004年9月スパークス。
[6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[6]マーイ、R.、ビッグス、B.、およびR.ディーンを、 "セッション開始プロトコル（SIP） "は、" ヘッダ" を置き換えRFC 3891、2004年9月。
[7] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[7]キャンベル、B.、エド。、マーイ、R.、エド。、およびC.ジェニングス、エド。、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[8] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
[8]ジェニングス、C.、マーイ、R.、およびA.ローチ、RFC 4976の "メッセージセッションリレープロトコル（MSRP）のためのリレー拡張機能"、2007年9月。
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[9]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のためのRTPペイロード"、RFC 4103、2005年6月。
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[10]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[11] Camarillo, G., "Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag", RFC 4569, July 2006.
[11]カマリロ、G.、 "インターネット割り当て番号機関（IANA）メッセージメディア特徴タグの登録"、RFC 4569、2006年7月。
[12] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[12]ローゼンバーグ、J.、 "取得及び使用グローバルにルーティング可能なユーザエージェントのURI（GRUU）セッション開始プロトコル（SIP）における"、RFC 5627、2009年10月。
[13] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[13]ローゼンバーグ、J.、Schulzrinneと、H.、およびR.マーイ、エド。、 "INVITEが開始ダイアログイベントパッケージセッション開始プロトコル（SIP）のための"、RFC 4235、2005年11月。
[14] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[14] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[15] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[15]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（SDP）のセキュリティの説明"、RFC 4568、2006年7月。
[16] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[16] Arkko、J.、リンドホルム、F.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[17] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[17]ガットマン、E.、パーキンス、C.、Veizades、J.、およびM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[18] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", RFC 4117, June 2005.
[18]カマリロ、G.、バーガー、E.、Schulzrinneと、H.、および "セッション開始プロトコルにおけるトランスコーディングサービス呼び出し（SIP）を使用して、第三者呼制御（3PCC）" A.バンWijk、RFC 4117、6月2005。
[19] Ott, J., Bormann, C., Sullivan, G., Wenger, S., and R. Even, Ed., "RTP Payload Format for ITU-T Rec. H.263 Video", RFC 4629, January 2007.
[19]オット、J.、ボルマン、C.、サリバン、G.、ウェンガー、S.、およびR.ても、編、RFC 4629 "ITU-T勧告H.263ビデオ用のRTPペイロードフォーマット"、 2007年1月。
[20] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility Using SIP", ACM SIGMOBILE Mobile Computing and Communications Review, Vol. 4, No. 3, July 2000.
[20] Schulzrinneと、H.及びE. Wedlund、 "SIPを使用したアプリケーションレイヤモビリティ"、ACM SIGMOBILEモバイルコンピューティングと通信のレビュー、巻。図4に示すように、第3号、2000年7月。
[21] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[21]キャンベル、B.、編。、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[22] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
[22]レノックス、J.、呉、X.、およびH. Schulzrinneと、 "コール処理言語（CPL）：インターネット電話サービスのユーザコントロールのための言語"、RFC 3880、2004年10月。
[23] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, "Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)", RFC 4484, August 2006.
[23]ピーターソン、J.、ポーク、J.、病状、D.、およびH. Tschofenig、 "セッション開始プロトコル（SIP）のための形質ベースの承認要件"、RFC 4484、2006年8月。
[24] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[24]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[25] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[25]ピーターソン、J.とC.ジェニングス、 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、RFC 4474、2006年8月。
[26] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[26]ヨン、D.とG.キャマリロ、 "セッション記述プロトコルでTCPベースのメディアトランスポート（SDP）"、RFC 4145、2005年9月。
[27] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[27]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書」、進歩、2007年10月の作業。
[28] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[28]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[29] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.
[29]チェシャー、S.とM. Krochmal、 "DNSベースのサービス発見"、進歩、2008年9月の作業。
[30] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, September 2008.
[30]チェシャー、S.とM. Krochmal、 "マルチキャストDNS"、進歩、2008年9月の作業。
[31] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing an SRTP Security Context using DTLS", Work in Progress, March 2009.
[31] Fischl、J.、Tschofenig、H.、およびE.レスコラ、 "DTLSを使用して、SRTPセキュリティコンテキストを確立するためのフレームワーク"、進歩、2009年3月に作業。
Authors' Addresses
著者のアドレス
Ron Shacham Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
ロンShachamコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027 USA
EMail: shacham@cs.columbia.edu
メールアドレス：shacham@cs.columbia.edu
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
ヘニングSchulzrinneとコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027 USA
EMail: hgs@cs.columbia.edu
メールアドレス：hgs@cs.columbia.edu
Srisakul Thakolsri DoCoMo Communications Laboratories Europe Landsberger Str. 312 Munich 80687 Germany
Srisakul Thakolsriドコモコミュニケーション研究所ヨーロッパランデスのStr。 312ミュンヘン80687ドイツ
EMail: thakolsri@docomolab-euro.com
メールアドレス：thakolsri@docomolab-euro.com
Wolfgang Kellerer DoCoMo Communications Laboratories Europe Landsberger Str. 312 Munich 80687 Germany
ヴォルフガングKellererドコモコミュニケーション研究所ヨーロッパランデスのStr。 312ミュンヘン80687ドイツ
EMail: kellerer@docomolab-euro.com
メールアドレス：kellerer@docomolab-euro.com