[要約] RFC 5631は、SIPセッションの移動性をサポートするためのプロトコル拡張を提案しています。その目的は、セッションの移動中に通信を維持し、ユーザーのモビリティを向上させることです。
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
セッション開始プロトコル（SIP）セッションモビリティ
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow 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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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]で最初に説明されました。ここでは、2つの異なる方法が提案されています。サードパーティコールコントロール（3PCC）[2]および参照方法[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:
セッション転送ターゲットとして選択されたデバイスは、個人または公開のいずれかです。パーソナルデバイスは、自分の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種類のデバイスを区別します。強化されたデバイスは、セクション5で説明されているコールフローをサポートし、発見を実行できますが、基本的なデバイスはどちらも実行できず、基本的なSIP機能のみがあります。セッションモビリティを開始するデバイスは機能を強化している必要がありますが、他のすべては基本的または強化されたデバイスのいずれかです。これには、ローカルビデオカメラなどの転送先が、リモート参加者が使用するデバイスが含まれます。
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, when necessary, to translate between media streams, as described in Section 6.
セッションモビリティには、5種類のコンポーネントが含まれます。特派員ノード（CN）、モバイルノード（MN）、セッション転送のターゲットとして使用される1つ以上のローカルデバイス、SLP [17]ディレクトリエージェント（DA）、およびオプションでは、トランスコダー。特派員ノード（CN）は、リモート参加者が使用する基本的なマルチメディアエンドポイントであり、どこにでも配置できます。SIPユーザーエージェント（UA）、またはゲートウェイを介して到達可能な公開された電話ネットワーク（PSTN）電話などです。モバイルノード（MN）は、標準のSIPコールセットアップ用のSIP UA、セッションモビリティ用の専門的なSIP処理機能、およびローカルデバイスを発見するためのSLP [17]ユーザーエージェント（UA）を含むモバイルデバイスです。ローカルデバイスは、現在のセッションでの発見と使用のために、ユーザーのローカル環境にあります。それらはモビリティ強化または基本的なものである可能性があります。IP電話などの基本的なデバイスはSIP対応ですが、他の特別な機能はありません。Mobility-Enhanced Devicesには、サービスとセッションのモビリティ処理を宣伝するためのSLPサービスエージェント機能があります。また、SLP UAも含まれており、その目的はセクション5.4.3のマルチデバイスシステムの議論で説明されます。SLPディレクトリエージェント（DA）は、場所や機能を含むデバイスを追跡します。SLPの使用については、セクション4で詳細に説明します。SIPベースのトランスコーディングサービス[18]は、必要に応じて、セクション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の範囲外であり、別のサービスロケーションプロトコルが必要です。サービスロケーションプロトコルを定義するのは、このドキュメントの範囲外です。このセクションでは、さまざまなオプションについて説明し、そのうちの1つについてさらに詳しく説明します。
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.
任意の場所でデバイスやその他のサービスを発見するためのグローバルなインフラストラクチャを持つことが望ましいですが、この種のものは現在展開または標準化されていません。ただし、このドキュメントでは、このようなインフラストラクチャは、同じ部屋のように近接しているデバイスを発見するために不要であると想定しています。このようなデバイスは、Bluetoothセッション説明プロトコル（SDP）などの短距離ワイヤレスプロトコルを介した直接通信を通じて発見される可能性があります。物理的に互いに近いデバイスが同じネットワーク内および/または同じDNSドメインの一部内にあると仮定すると、サービス発見プロトコルの他の2つのカテゴリを使用できます。SLP [17]（サーバーレスモード）やBonjour（MDNS-SD [30]）などのマルチキャストベースのプロトコルは、モバイルノードがローカルデバイスと同じサブネット内にある限り、使用できます。デバイスが同じDNSドメインの一部である場合、サーバーモードSLPまたは非マルチカストDNSサービスディスカバリー（DNS-SD）[29]は可能なソリューションです。このようなプロトコルは、より大きな地理的領域内のデバイスを発見し、最初のカテゴリよりも優位性があります。これは、部屋や建物レベルなどのさまざまな場所の粒度や現在の場所以外の場所でデバイスを発見できるという点で利点があります。。特定の場所でデバイスを発見するには、部屋番号などの場所属性を検索で使用する必要があります。たとえば、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、およびname-valueペアとして定義される属性のセットでサービスを識別します。属性は、ベンダー、サポートされているメディアコーデック、表示解像度などの情報です。SLPは3つの役割を定義します。サービスの説明を送信するサービスエージェント（SAS）。
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-Device」とサービスURIとしてのSIP URIがあります。セクション5.2では、このURIの形式について説明します。属性は、ベンダー、サポートされているメディアコーデック、ディスプレイ解像度、および通りの住所や部屋番号などのロケーション座標などのデバイス特性を指定します。SASはセッションモビリティ拡張デバイスにSIP UASと共同で配置されていますが、SLP SASを統合していない基本デバイスに代わってSRVREGメッセージを送信するための別のSAを使用できます。
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ウリのリストを使用してモバイルデバイスに送信されます。次に、各URLに対して個別の属性要求（ATTRRQST）が送信され、サービスの属性が取得されます。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.デバイスがサービスとMNを登録するためのSLPメッセージフローと、その属性とともにそれを発見します。
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つのメディアタイプを転送したい場合があります。さらに、全二重セッションの2つの方向でさえ、デバイス間で分割される可能性があります。たとえば、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.
セッション転送、モバイルノードコントロール（MNC）モード、およびセッションハンドオフ（SH）モードには2つの異なるモードが可能です。以下に説明します。
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]。Transferで使用される各デバイスとのSIPセッションを確立し、SDPパラメーターを使用してCNと各デバイスの間のメディアセッションを確立し、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.
実験に基づいて、MNCモードは、CNの側で使用される既存のデバイスとより相互運用可能であることがわかりました。このセクションの残りの部分では、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本文で交渉されます。SIPエンドポイントに適したテキストメッセージ、および場合によっては他のMIMEタイプを運ぶための3つの異なる方法が存在します。RTPは、[9]に基づいて、テキストペイロードをリアルタイムで輸送するために使用できます。ペイロードのみが異なるため、オーディオとビデオに与えられた例は、テキストに対して同じように機能します。[RTPの少数の文字とは対照的に）メッセージ全体を転送する場合、SIPメッセージメソッド[21]またはメッセージセッションリレープロトコル（MSRP）[7]のいずれかを使用できます。メッセージは、個々のページモードメッセージを送信するために使用されます。メッセージはセッションに関連付けられておらず、セッションを確立するための交渉は行われません。通常、SIP UAは、ユーザーが確立されたダイアログ中にメッセージ要求を送信できるようにし、すべての信号メッセージがセッション中に送信されるのと同じ連絡先アドレスに送信されます。後でこれらのメッセージがセッションのモビリティによってどのように影響を受けるかについて説明します。一方、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.
前に述べたように、このドキュメントでは、個人と公共のデバイスの両方を想定しています。パブリックデバイスは、sip：device11@example.comなどの専用のレコード（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を登録します。各連絡先には関連するGruuがあり、SLPにサービスURIとして登録されており、プロキシを介して送信されたリクエストで別のデバイスによって直接対処される場合があります。プロキシがリクエストをデバイスに転送すると、[12]で説明されているように、Gruuを接触URIに置き換えます。したがって、関連するGruuではなく連絡先URIをデバイスで使用して、デバイス自体のリクエストか、マルチデバイスシステムのかどうかを判断します。公共のグルーが使用されていると仮定します。
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は、セッションを単一のローカルデバイスに転送するためのメッセージフローを示しています。第三者のコールコントロールフローI（[2]で指定）に続きます。これは、エンドポイントがすぐに回答する限り推奨されます。MNは、転送に使用されるローカルデバイスにSIP Inviteリクエストを送信し、新しいセッションを確立するように要求しますが、SDPボディは含まれていません。ローカルデバイスの応答には、メディアに使用するアドレスとポートを含むSDP本体、およびそれぞれをサポートするコーデックのリストが含まれています。MNは、次のように、ローカルデバイスのメディアパラメーターをSDPボディに含むInvite Request（RE-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
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の対応するメッセージを参照してください。空の招待状リクエスト（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
The messaging node responds with all of its media capabilities, including MSRP, as follows (2):
メッセージングノードは、MSRPを含むすべてのメディア機能（2）に応答します。
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
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).
同じ要求がMNによってCN（3）に送信されますが、上記の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（輸送層のセキュリティ）を使用して、信頼できる接続で実行されます。したがって、リアルタイムメディアの場合とは異なり、この接続を確立する必要があります。MSRP仕様によると、「提供者」として知られるメッセージセッションの開始者はアクティブエンドポイントでなければならず、それらの間のTCP接続を開く必要があります。この転送シナリオでは、両方のセッションの提供者はMNであり、目的のTCP接続のどちらの終わりでもありません。そのため、どちらのエンドポイントも接続を確立しません。ネゴシエーションメカニズムを使用して、セッションのセットアップ中にアクティブエンドポイントの役割を割り当てることができます。ただし、MSRPはこの可能性を開いたままにしていますが、複雑さのために現在このドキュメントに含まれていません。このようなセッション転送が可能になる唯一の方法は、CNとローカルデバイスの両方が通常MSRPリレーを使用している場合です[8]。各新しいエンドポイントがMNからの招待要求を受信すると、そのような接続がまだ存在しない場合、事前に構成されたリレーの1つとTLS接続が作成されます（MNとのセッションのためにCNは既にあります）。リレーのパス。MNへの応答には、パス属性内のリレーを含む、通過する必要があるパス全体が含まれます。たとえば、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
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は各ローカルデバイスとの新しいセッションを個別の招待リクエストで確立し、回答で受信する適切なメディアパラメーターを組み合わせたSDPボディで既存のセッションをCNで更新します。たとえば、オーディオとビデオコールを2つのデバイスに転送するために、MNはそれぞれのデバイスと個別のセッションを開始し、1つの応答からオーディオメディアラインを組み合わせて、ビデオメディアラインをもう1つのセッションから組み合わせて、リクエストとして一緒に送信します。次のように、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
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.
図3.複数のデバイスに転送するためのモバイルノード制御モードフロー。
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はローカルデバイスを2つの異なるセッションに招待しますが、SDPボディは含まれていません。彼らはそれぞれ利用可能なすべてのメディアで応答します。カメラまたはディスプレイのみのデバイスの場合のように、単方向のメディアのみをサポートする場合、「sendonly」または「recvonly」属性が含まれます。それ以外の場合、MNは、CNに合わせたSDP本体を送信する前に、各メディアラインに適切な属性を追加する必要があります。そのボディは次のように見えます：M =ビデオ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 = 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:
[4]のセクション8によると、SDPセッションの更新では、新しいSDPのIthメディアラインは、以前のSDPのIth Mediaラインに対応しています。上記の場合、転送中にメディアタイプが追加された場合、メディアラインは既存のラインに従う必要があります。既存のメディアが別のデバイスに転送される場合、メディアラインは、変更されていないすべてのメディアのラインと同様に、以前のSDPで行ったのと同じ場所に表示される必要があります。デュプレックスメディアストリームが入力および出力デバイスに分割されている場合、入力デバイスに対応するストリームがDuplex Media Streamの代わりに表示されるはずです。この新しいストリームは、古いものの代わりにCNを含むCNが受信するものであるため、CNが新しいストリームを古いストリームの置換として保証することを保証します。出力デバイスに対応するメディアラインは、すべての既存のメディアラインの後に表示する必要があります。最後の例では、SDPが最初にビデオラインが続くオーディオラインが続いていた場合、CNに送信された更新されたSDPは次のように見えます。
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
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にメッセージ要求を送信する場合があります。モバイルユーザーがMN以外のデバイスにそのようなメッセージを表示したい場合、リクエストは単にそのデバイスに転送されます。転送されたメッセージは、MNからローカルデバイスへの他のメッセージであるかのように構成され、受信したメッセージの本文を含める必要があります。ローカルデバイスは、MNにメッセージリクエストを送信し、MNはCNに転送します。
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に招待リクエストを送信してセッションを取得し、メディアストリームを返します。次に、各ローカルデバイスに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]を使用します。このメッセージは、「参照者」から「審判」に送信されたリクエストであり、「審判」を「参照」する「regureターゲット」に「参照」と呼びます。Webページなどの非SIP URI。このURIは、参照ヘッダーで指定されています。紹介された[5]ヘッダーは、リファラーの身元を示すために使用されます。このメッセージの必須ヘッダーは、暗号化され、メッセージ本文でセキュア/多目的インターネットメールエクステンション（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.
図4.単一のデバイスに転送するためのセッションハンドオフモードフロー。
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>
[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の「オーディオ」と「ビデオ」トークンは、Callee機能です[10]。ここでは、審判に、CNとのオーディオおよびビデオセッションを開始する必要があることを審判に通知するために使用されます。また、URIには交換ヘッダーフィールドが含まれており、その後の招待リクエストでは、交換ヘッダーフィールドを指定された値に含める必要があることを指定します。交換ヘッダーは、新しいセッションに置き換える必要がある既存のセッションを識別します。ここで、ローカルデバイスは、CNが現在のセッションをMNに置き換えることを要求します。[6]によれば、CNは、特定の承認されたカテゴリのユーザーからセッションを交換するリクエストのみを受け入れる必要があります。そのようなタイプのユーザーの1つは、セッションの現在の参加者です。したがって、MNは、現在のセッションをCNに置き換えるためにローカルデバイスを紹介する場合があります。ただし、紹介で送信するs/mime本体の元の参照要求からいくつかのヘッダーを暗号化することにより、認証を提供します。ローカルデバイスはこのボディをCNに送ります。これにより、悪意のあるユーザーが他のユーザーのセッションを無差別に置き換えることができなくなります。ローカルデバイスが参照要求を受信すると、CNに招待リクエストが送信され、通常のセッションのセットアップが続きます。その後、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には、（タグを含む）、（タグを含む）、および確立されたセッションのコールIDヘッダーフィールドが含まれており、セクション5.4.2で説明されているように、MNがその後セッションを取得できるようにします。
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とローカルデバイスの間に新しいセッションが確立されるため、その後のメッセージ要求はそのデバイスに送信されます。
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セッションを開始します。参照要求（1）は、オーディオやビデオのように、参照ヘッダーフィールドのCallee機能を使用してMSRPセッションを確立する必要があることを示しています。このようなメディア機能タグ「メッセージ」はすでに定義されています[11]。ローカルデバイスが参照要求を受信すると、CNとのMSRPセッションが開始されます。イニシエーターとして、セッションを実行するためにTCP接続を確立します（[7]で指定されている）、または設定されている場合はリレーを介してセッションを設定します。
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による検索のフローを示しています。メッセージフローをより良くするために、最終的な招待状（5）を説明し、後方に作業することから始めます。デバイスがセッションハンドオフモードでセッションを取得するには、CNの既存のセッションに置き換えるCNとのセッションを開始する必要があります。次のメッセージは、MNからCN（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>
[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とローカルデバイスのユーザーは異なるアイデンティティであるため、MNはローカルデバイスで紹介され、紹介されたヘッダーにURIを含める必要があります。セッションの交換を許可されるため。したがって、MNは、この招待状リクエストを送信するために、それを参照するローカルデバイスから参照要求を受信する必要があります。ユーザーは、ローカルデバイスのユーザーインターフェイスを使用して、この参照メッセージを送信できます。ただし、そのようなインターフェイスは利用できない場合があります。また、ユーザーは、モバイルデバイスを手にした状態でオフィスを使い果たしているときに転送を実行することを希望する場合があります。MNがローカルデバイスから紹介を促すために、「ネストされた紹介」[5]を送信します。この場合、2番目の参照はモバイルノードに送り返されます。その紹介は、交換ヘッダーを後続の招待リクエストに含めることを指定する必要があります。ローカルデバイスからMN（3）への参照要求は、次のように構成されています。
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):
Headerフィールドは、URIの紹介に含まれており、ターゲットInviteリクエストの交換ヘッダーの値を指定します。このメッセージを送信するには、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が参照ターゲットであり、紹介が紹介要求の形であることを指定します。ヘッダーフィールドは、参照要求にCNのURIを含む参照ヘッダーを含むことを指定します。そのURI自体には、MNにオーディオとビデオの呼び出しを開始するように指示する「オーディオ」および「ビデオ」Callee機能、および究極の招待リクエストに交換ヘッダーが含まれていることを指定するヘッダーフィールドが含まれています。MNが以前にセッションをローカルデバイスに転送した場合、セッションの確立後にローカルデバイスから送信された通知でこれらを受け取っていました。一方、MNが以前に保持していなかったセッションを取得している場合、上記のセクション5.1.1で上記のように、ローカルデバイスのダイアログイベントパッケージ[13]を購読することにより、これらのパラメーターを取得します。このようなサブスクリプションは、たとえば、セッションを運んだ元のデバイスの所有者にのみ付与されます。これらのパラメーターが交換ヘッダーで提供されている場合でも、ローカルデバイスは、セッションの元の参加者またはデバイスの所有者を除く誰からの紹介要求を受け入れません。MNはローカルデバイスから紹介要求を受信し、CNに招待リクエストを送信します。
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とローカルデバイスの間で複数のメディアセッションを確立する必要があります。これは、それぞれをCNに参照して、ローカルデバイスに複数の参照要求を送信することで実行できます。この方法の欠点は、SIPの1回の呼び出しの一部として複数のセッションを関連付ける標準的な方法が現在ないことです。したがって、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）と呼びます。少なくとも1つのモビリティ強化デバイスを含むシステムでは、そのうちの1つがMDSMとして機能する場合があります。完全に基本的なデバイスで構成されるシステムでは、専用ホストまたはシステムの外側からの別のローカルデバイスのいずれかがMDSMとして機能します。その後、MDSMが参照要求を受信すると、サードパーティのコールコントロールを使用して、CNとシステム内の各デバイス間のメディアセッションをセットアップします。具体的には、各ローカルデバイスを別のセッションに招待し、CNに送信する招待リクエストでメディアパラメーター（およびおそらく独自）を使用します。
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」を備えたデバイスは、独自の機能を表す連絡先「sip：device11@device11.example.com」を登録します。他のデバイスを発見してMDSを作成すると、新しい連絡先「sip：av1@device11.example.com」を登録します。Gruuをこれらのそれぞれの連絡先と関連付けます。デバイス自体と新しいシステムは、Gruuを使用してSLPに登録されています。プロキシがGruuに宛てられたリクエストを受信すると、リクエストをデバイスに転送する前に、Contact 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は、セッションのマルチデバイスシステムへの転送を示しています。オーディオデバイスは以前にビデオデバイスを発見し、マルチデバイスシステムを作成しました。「sip：device11@example.com; gr = urn：uuid：893eeeyuinm981」に送信されたリクエストは、オーディオデバイスにビデオデバイスをセッションに招待してSDPを確認し、その後、CNを使用してCNをセッションに招待するように促します。独自の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 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.
転送は、転送モードのいずれかで実行できます。ただし、セッションハンドオフモードで行われる別のデバイスへの完全なハンドオフは、プロキシやリダイレクトなどの既存の手段を通じて達成できます。MNCモードは、ユーザーが通話に追加のデバイスを自動的に含めることを希望する場合に役立ちます。たとえば、デスクIP電話とビデオカメラを備えたPCを備えたユーザーは、2つを単一の論理デバイスに結合できます。PC上のSIP UAは、着信コールの場合、招待状のリクエストをデスク電話に送信し、たとえばユーザーが識別できるように、From Headerフィールドのディスプレイ名を「Bob Jones（Audio Porate）」に設定します。電話で発信者。ユーザーは、電話に直接届くように、受け入れるか拒否することができます。彼が受け入れると、コントローラーとして機能する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.
デスクの電話がユーザーの連絡先として登録されている場合、コントローラーから送信された招待リクエストに加えて、ユーザーに招待されたリクエストに加えて、直接コールがそこにプロキシ化されることに応じて鳴ります。発信者は、発信者が音声およびビデオ機能を備えたデバイスにコールを優先的にプロキシ化する必要があることを示すため、発信者の好みを使用することがこの問題を解決できます。発信者は、いずれにせよ、いずれにせよ、発信者の好みを使用して、ビデオで利用可能なデバイスを使用できる場合に知らないうちにIP電話を拾うことを避けるために、発信者の好みを使用する可能性があります。ただし、発信者の好みは商用デバイスではまだ広くサポートされていないため、Calleeはコールの適切なルーティングを確保する必要があります。1つのソリューションは、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.
Interactive Connectivity Indecivity（ICE）[27]は、SIPで使用できるネットワークアドレス翻訳者（NAT）トラバーサルのプロトコルです。メディアセッションにSDPで直接使用される住所やポートを交渉するのではなく、可能なアドレス/ポート（候補者）のリストが交換され、NAT（Stun）[28]プロトコルのセッショントラバーサルユーティリティが使用され、候補者のペアが確認されます。利用される。このセクションで説明するコールフローで氷を使用できます。MNCモードでは、候補者は各ローカルデバイスによってMNに送信され、MNはCNと交換します。その後、各デバイスは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で使用されてデバイスのメディア機能を照会するか、SLPサービス属性として含めることができます。オプション方法は標準であるため、CNを照会するために使用されることが推奨されますが、SLPはすでに使用されているため、ローカルデバイスのメディア機能を取得するために使用されることが示唆されています。
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に転送します。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つのメディアセッションを確立します。これは、通常のトランスコーディングケースとは異なり、一方の当事者がそれ自体とトランスコダーの間のメディアセッションを確立し、トランスコーダーと他方のパーティの間のメディアセッションを確立します。MNは、ボディのないローカルデバイスに招待リクエストを送信することから始めます。応答で、デバイスが使用できるコーデックのリストを受信します。次に、CNについてこれを繰り返し、利用可能なコーデックを受け取ります。各デバイスのアドレスとポートとともに、両側から1つのコーデックを選択し、トランスコダーに送信された招待リクエストにそれらを組み合わせます。トランスコダーは、各ストリームを受け入れるポートで応答します。適切なポート情報は、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.
図7.トランスコダーを介したモバイルノード制御モードでのセッションの転送は、CNのネイティブコーデックと一般的なコーデックを共有しないオーディオノードANを翻訳します。
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とのセッションを確立します。参照要求を受信した後、Optionsメソッドを使用してCNの機能を見つけます。次に、セッションのセットアップで利用可能な場合は共通コーデックを使用するか、[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による特別な取り扱いは必要ありません。たとえば、H.263コーデックのこれらおよびその他のパラメーターを指定するために、SDP形式[19]が定義されています。適切な画像形式と対応するMPI（フレームレートに関連する最小画像間隔）は、指定されたコーデックでサポートされていることが、好みの順にメディアラインに従ってリストされています。たとえば、SDPの次の行は、デバイスが16CIF、4CIF、CIF、およびQCIFの画像サイズでH.263コーデック（値34）をサポートすることを示します（「=」に続く各形式のMPIを使用）
m=video 60300 RTP/AVP 34
a=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.
MNCモードでは、MNが送信した最初の招待リクエストに対するローカルデバイス（図2、メッセージ2）による応答には、SDPボディにこの行が含まれ、MNにはCNに送信された招待リクエストにITが含まれます（3）。セッションハンドオフモードでは、ローカルデバイスには、参照要求を受信した後、CN（図4、メッセージ3）に送信された招待要求にこのパラメーターを含めます。ローカルデバイスがセッションの確立中にサポートされている画像サイズを含めるように構成されていない場合、情報はSLPを介して利用可能にすることができます。次に、MNには、モバイルノード制御モードでCNに送信されたInviteリクエストにそれを含めます。ただし、ローカルデバイスが送信するように構成されていない限り、この情報はセッションハンドオフモードで送信されません。両方のモードで、MNはセッションを取得するために送信された招待要求の本文で独自の解像度とフレームレートの好みを送信します。
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は、他の参加者からの再入力または反対側のローカルデバイスからの招待リクエストのいずれかを受け取ります。このメッセージには、セッションの新しいメディアパラメーターが含まれています。したがって、MNは、これらのパラメーターを備えたローカルデバイスに再入力を送信する必要があります。次に、200 OK応答でこれらのデバイスから返されたパラメーターを含みます。最初の転送がSHモードで行われた場合、ローカルデバイスは相手からセッション転送メッセージを直接受信し、招待リクエストに応答するための通常の手順に従います。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モードでは、各ノードがローカルデバイスでセッションを開始し、他のノードに再インベティを送信します。[1]のセクション14.2は、別のre inviteがすでに送信されると、ダイアログのために再入手を受け取った場合、491の応答を義務付けています。両方の当事者がこの応答を受け取ると、それぞれがずらして間隔を置いてランダムタイマーを生成します。タイマーが発砲すると、各参加者は再び復元を試みます。他の参加者から最初にそれを受け取ったのは、ローカルデバイスのSDPパラメーターで応答します。両方の参加者は、再入手プロセス中に他のパラメーターから取得した新しいパラメーターを含むローカルデバイスに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.
SHモードでは、両方の参加者が同時に転送を試みた場合、1つのノードがローカルデバイスに参照要求を送信した後、反対側のローカルデバイスから招待要求を受信します。適切なプロトコル定義は、この場合にも491の応答が送信されることを義務付ける可能性があります。この応答は、紹介されたセッション確立のステータスを示す通知でリファラーに返されます。上記の驚異的なタイマーソリューションは機能する可能性があります。MNは、ローカルデバイスに送信された参照要求をキャンセルし、ランダムな時間を待ってから再度送信します。
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リクエストがコントローラーに送信されます。次に、コントローラーは、転送で使用される各デバイスにBYEリクエストを送信し、CNにBYEリクエストを送信する必要があります。SHモードに使用されるMDSMは、同じ手順に従う必要があります。SHモードでは、現在のデバイスは以前に参照要求に応じて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.
ローカルデバイスの使用は、認定当事者に制限される必要があります。前述のように、このドキュメントは個人と公共のデバイスの両方を想定しており、これらには異なる承認ポリシーがあります。パーソナルデバイスは、単一のID、デバイスの所有者からの転送要求のみを受け入れます。したがって、アクセス制御の最も適切な手段は、セッションをデバイスに転送することを許可されたデバイス所有者を表すアイデンティティのリストを維持することです。前述のように、デバイスは、ユーザーのAORに加えて、転送デバイスとしてのステータスを表すAORで構成されています。デバイスAORに行われたリクエストのみがアクセスリストに従いますが、ユーザーのAORへの着信要求は誰からも受け入れられます（白またはブラックリストまたはその他のポリシーが受け入れられないようにしない場合）。SIP-Identityヘッダー[25]を使用して、SIPリクエストのイニシエーターを安全に識別します。この仕様は、ローカルデバイスがそれぞれMNCまたはSHモードで招待または参照要求がデバイスの所有者からのものであることを保証する必要がある場合に、使用ケースで使用できます。
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通信の確立は、2つのドキュメントで定義されています。「crypto」属性[15]は、その値が目的の暗号スイートと、RTPパケットで対称暗号化を実行するために使用される重要なパラメーターを含むメディアレベルの属性です。主要な情報は、専用の暗号化または整合性保護なしでSDPボディに送信されるため、S/MIMEなどの個別のプロトコルを使用して、シグナリングメッセージを保護する必要があります。別のドキュメント[16]は、Mikeyなどのキー管理プロトコルのパラメーターを提供するために使用される「Key-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）からの応答には、サポートされているメディアタイプに加えて、各タイプの暗号情報が含まれます。この暗号化情報は、上記の2つの属性のいずれかを使用して、暗号スイートと重要なパラメーターを説明する属性行のリストになります。これらの行は、後続の要求（3）でMNによってCNに送信されます。CNは暗号化方法を選択し、応答に独自の重要な情報を返します（4）。SHモードで安全なメディアセッションを維持するには、ローカルデバイスが紹介要求の受領後に確立するセッションで暗号化関係を交渉する必要があります。
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]では、サードパーティのコールコントロールでメディアセキュリティを確立することは、コントローラーの協力に依存することに注意してください。このドキュメントでは、モバイルノード制御モード（MNC）のモバイルノード（MN）は3PCCでコントローラーの役割を持ち、セッションハンドオフ（SH）モードでは、MNは代わりに参照メソッドを使用します。以下は、そのドキュメントからの抜粋です。
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内のキーイング素材の交換に基づいています。サードパーティのコールコントロールを使用したこれらのメカニズムの適切な動作は、コントローラーが適切に動作することに依存します。これらのメカニズムを明示的に無効にしようとしていない限り、プロトコルは参加者間で適切に動作し、コントローラーでさえも盗用したり変更できない安全なメディアセッションになります。サードパーティのコールコントロールは、ユーザーとコントローラーの間の信頼モデルに基づいているため、行儀の良い方法で動作していると仮定することは合理的です。ただし、コントローラーがキーイング材料の最初の交換を妨害するのを防ぐことができる暗号化手段はありません。その結果、コントローラーがメディア交換の仲介者として自分自身を挿入することは、些細なことです。
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またはDatagramトランスポートレイヤーセキュリティ（DTLS）のいずれかを使用して、輸送層で代わりに確保できます[24]。セッションモビリティでこれらのプロトコルを使用するための1つの考慮事項は、クライアントとサーバーの役割を割り当てることです。SHモードでは、CNとの信号セッションを開始しているため、ローカルデバイスである審判がクライアントとして機能すると想定される場合があります。ただし、MNCモードでは、これらの役割は不明です。同じ問題は、MNCモードで転送されるMSRPセッションの安全な接続を確立する際に上記で言及しました。この問題は、接続指向のメディア（Comedia）[26]を使用して解決できます。これは、これらの役割を交渉するために「セットアップ」SDP属性を指定します。
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に送信されます。そのようなセッションに同意したと仮定すると、コメディアの仕様に従って、「セットアップ」属性で応答します。これは、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フローを3番目のデバイスに送信するよう指示し、洪水攻撃の可能性を提示します。これは、3PCCの使用に関連する一般的な問題です。このドキュメントでは、このセクションの冒頭で説明されているように、デバイスが公開されている場合に懸念があります。（例：機関）およびユーザー。明らかに、デバイスがプライベートであり、その所有者のみがそれに転送できる場合、前述のIDヘッダーの使用を考えると、懸念は存在しません。考えられる解決策は、氷の使用である可能性があります[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コミュニティ、特にJon Peterson、Joerg Ott、Cullen Jenningsによってこの文書について作成された有用なコメントを認めたいと思います。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、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] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）における第三者コールコントロール（3PCC）の最良の現在のプラクティス（SIP）」、BCP 85、RFC 3725、2004年4月。
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[3] Sparks、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[5] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[5] Sparks、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] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（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] Campbell、B.、ed。、Mahy、R.、ed。、およびC. Jennings、ed。、「The Message Session Relay Protocol（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] Jennings、C.、Mahy、R。、およびA. Roach、「メッセージセッションリレープロトコル（MSRP）のリレー拡張機能」、RFC 4976、2007年9月。
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[9] Hellstrom、G。およびP. Jones、「テキスト会話のための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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[11] Camarillo, G., "Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag", RFC 4569, July 2006.
[11] Camarillo、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] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（GRUU）を取得および使用」、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] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、ed。、「セッション開始プロトコル（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.、McGrew、D.、Naslund、M.、Carrara、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] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（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.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC 4567、7月2006年。
[17] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[17] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「サービスロケーションプロトコル、バージョン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] Camarillo、G.、Burger、E.、Schulzrinne、H。、およびA. Van Wijk、「サードパーティコールコントロール（3PCC）を使用したセッション開始プロトコル（SIP）のトランスコーディングサービスの呼び出し」、RFC 4117、2005年6月。
[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] Ott、J.、Bormann、C.、Sullivan、G.、Wenger、S.、およびR. ed。、 "RTP Payload Format for ITU-TRec。H.263ビデオ"、RFC 4629、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 Mobile Computing and Communications Review、Vol。4、No。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] Campbell、B.、Ed。、Rosenberg、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] Lennox、J.、Wu、X。、およびH. Schulzrinne、「Call Processing Language（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] Peterson、J.、Polk、J.、Sicker、D。、およびH. Tschofenig、「セッション開始プロトコル（SIP）の特性ベースの承認要件」、RFC 4484、2006年8月。
[24] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[24] Rescorla、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（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] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、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] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：Network Address Translator（NAT）Traversal for Offer/Answer Protocolsのプロトコル」、2007年10月の作業。
[28] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[28] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「Nat（Stun）のセッショントラバーサルユーティリティ」、RFC 5389、2008年10月。
[29] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.
[29] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリー」、2008年9月、進行中の作業。
[30] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, September 2008.
[30] Cheshire、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. Rescorla、「DTLSを使用してSRTPセキュリティコンテキストを確立するためのフレームワーク」、2009年3月、Work in Progress。
Authors' Addresses
著者のアドレス
Ron Shacham Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
Ron Shacham Columbia University 1214 Amsterdam Avenue、MC 0401 New York、NY 10027 USA
EMail: shacham@cs.columbia.edu
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
ヘニングシュルツリンコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
EMail: hgs@cs.columbia.edu
Srisakul Thakolsri DoCoMo Communications Laboratories Europe Landsberger Str. 312 Munich 80687 Germany
Srisakul Thakolsri Docomo Communications Laboratories Europe Landsberger St。312ミュンヘン80687ドイツ
EMail: thakolsri@docomolab-euro.com
Wolfgang Kellerer DoCoMo Communications Laboratories Europe Landsberger Str. 312 Munich 80687 Germany
Wolfgang Kellerer Docomo Communications Laboratories Europe Landsberger St。312ミュンヘン80687ドイツ
EMail: kellerer@docomolab-euro.com