Network Working Group R. Shacham
Request for Comments: 5631 H. Schulzrinne
Category: Informational Columbia University
S. Thakolsri
W. Kellerer
DoCoMo Euro-Labs
October 2009
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.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。未从控制人处获得足够的许可证
the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
此类材料、本文件的版权不得在IETF标准流程之外进行修改，其衍生作品不得在IETF标准流程之外创建，除非将其格式化为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
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电话、视频会议单元、嵌入式设备和软件电话）使用更方便，但不是移动的。在这些设备之间移动活动多媒体会话允许移动设备和固定设备在会话中期同时或互换使用，将它们的优势结合到一个“虚拟设备”中。[20]首先描述了一种基于会话发起协议（SIP）[1]的会话移动性方法，其中提出了两种不同的方法：第三方呼叫控制（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:
被选为会话传输目标的设备可以是个人的，也可以是公共的。个人设备是指个人使用的设备，如个人电脑或手机。公共设备是供一大群人使用的设备，包括大型会议室显示器。传输会话需要两种功能：
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.
会话移动性-在与远程参与者的会话中，用户可以将活动媒体会话的任何子集传输到一个或多个设备。
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的会话移动示例。它不要求任何特定的设备发现协议。存在许多不同的协议，我们讨论了在它们之间进行选择所涉及的权衡。对于我们的示例，我们使用服务位置协议（SLP）[17]，主要是因为它是IETF标准化的唯一此类协议。
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 要求1：向后兼容性-我们区分两种设备。增强型设备支持第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 要求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 请求3：最小中断-会话传输应涉及媒体流的最小中断，并且不应在远程参与者看来是新呼叫。
Session mobility involves five types of components: A Correspondent Node (CN), a Mobile Node (MN), one or more local devices used as targets for session transfer, an SLP [17] Directory Agent (DA), and, optionally, a transcoder. The Correspondent Node (CN) is a basic multimedia endpoint being used by a remote participant and may be located anywhere. It may be a SIP User Agent (UA), or a Public Switched Telephone Network (PSTN) phone reachable through a gateway. The Mobile Node (MN) is a mobile device, containing a SIP UA for standard SIP call setup, as well as specialized SIP-handling capabilities for session mobility, and an SLP [17] User Agent (UA) for discovering local devices. The local devices are located in the user's local environment for discovery and use in his current session. They may be mobility-enhanced or basic. Basic devices, such as IP phones, are SIP-enabled, but have no other special capabilities. Mobility-enhanced devices have SLP Service Agent capabilities for advertising their services and session mobility handling. They also contain an SLP UA, whose purpose will be explained in the discussion of multi-device systems in Section 5.4.3. The SLP Directory Agent (DA) keeps track of devices, including their locations and capabilities. The use of SLP will be described in more detail in Section 4. SIP-based transcoding services [18] are used,
会话移动性涉及五种类型的组件：对应节点（CN）、移动节点（MN）、用作会话传输目标的一个或多个本地设备、SLP[17]目录代理（DA）以及可选的转码器。通信节点（CN）是远程参与者正在使用的基本多媒体端点，可以位于任何位置。它可以是SIP用户代理（UA）或可通过网关访问的公共交换电话网（PSTN）电话。移动节点（MN）是移动设备，包含用于标准SIP呼叫设置的SIP UA，以及用于会话移动的专用SIP处理能力，以及用于发现本地设备的SLP[17]用户代理（UA）。本地设备位于用户的本地环境中，以便在其当前会话中发现和使用。它们可以是机动性增强型或基本型。IP电话等基本设备支持SIP，但没有其他特殊功能。移动性增强型设备具有SLP服务代理功能，用于宣传其服务和会话移动性处理。它们还包含一个SLP UA，其用途将在第5.4.3节的多设备系统讨论中解释。SLP目录代理（DA）跟踪设备，包括其位置和功能。第4节将更详细地描述SLP的使用。使用基于SIP的转码服务[18]，
when necessary, to translate between media streams, as described in Section 6.
必要时，在媒体流之间进行转换，如第6节所述。
A Mobile Node must be able to discover suitable devices in its vicinity. This is outside the scope of SIP, and a separate service location protocol is needed. It is outside the scope of this document to define any service location protocol. This section discusses various options, and describes one of them in more detail.
移动节点必须能够在其附近发现合适的设备。这超出了SIP的范围，需要一个单独的服务位置协议。定义任何服务位置协议超出了本文档的范围。本节讨论各种选项，并更详细地描述其中的一种。
While having a global infrastructure for discovering devices or other services in any location would be desirable, nothing of this sort is currently deployed or standardized. However, this document assumes that such an infrastructure is unnecessary for discovering devices that are in close proximity, such as in the same room. It is possible for such devices to be discovered through direct communication over a short-range wireless protocol such as the Bluetooth Session Description Protocol (SDP). Two other categories of service discovery protocols may be used, assuming that devices that are physically close to each other are also within the same network and/or part of the same DNS domain. Multicast-based protocols, such as SLP [17] (in its serverless mode) or Bonjour (mDNS-SD [30]), may be used as long as the Mobile Node is within the same subnet as the local devices. When devices are part of the same DNS domain, server-mode SLP or non-multicast DNS Service Discovery (DNS-SD) [29] are possible solutions. Such protocols can discover devices within a larger geographical area, and have the advantage over the first category in that they allow for the discovery of devices at different location granularities, such as at the room or building level, and in locations other than the current one. In order to discover devices in a specific location, location attributes, such as room number, must be used in the search, e.g., as service attributes in SLP or as a domain name in DNS-SD. The mobile device must ascertain its location in order to perform this search. We note that many of these techniques could be difficult to implement in practice. For example, different wireless networks may be deployed by different organizations, which could make it unrealistic to have a common DNS setup.
尽管在任何位置都有一个用于发现设备或其他服务的全球基础设施是可取的，但目前还没有部署或标准化这类基础设施。但是，本文档假定，对于发现靠近的设备（例如在同一房间中），不需要这样的基础设施。可以通过短距离无线协议（例如蓝牙会话描述协议（SDP））上的直接通信来发现此类设备。假设物理上彼此接近的设备也在同一网络和/或同一DNS域的一部分中，则可以使用另外两类服务发现协议。只要移动节点与本地设备位于同一子网内，就可以使用基于多播的协议，例如SLP[17]（在其无服务器模式下）或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通常是如何在服务器模式下使用的，然后介绍了如何使用SLP根据设备的位置发现设备。如前所述，这只是执行服务发现的众多方法之一。SLP通过“服务类型”、“服务URL”（可以是任何URL）和一组属性（定义为名称-值对）来标识服务。属性可以是诸如供应商、支持的媒体编解码器和显示分辨率等信息。SLP定义了三个角色：服务代理（SA），用于发送服务描述；
User Agents (UAs), which query for services; and Directory Agents (DAs), which receive the registrations and queries. An SA registers a service description to a DA with a service registration (SrvReg) message that includes its service type, service URL, and attribute-value set. A UA queries for services by sending a service request (SrvRqst) message, narrowing the query based on service type and attribute values. It receives a reply (SrvRply) that contains a list of URLs of services that match the query. It may then ascertain the specific attributes of each service using an attribute request (AttrRqst) message.
用户代理（UAs），用于查询服务；以及接收注册和查询的目录代理（DAs）。SA使用服务注册（SrvReg）消息向DA注册服务描述，该消息包括其服务类型、服务URL和属性值集。UA通过发送服务请求（SrvRqst）消息来查询服务，根据服务类型和属性值缩小查询范围。它接收一个回复（SrvRply），其中包含与查询匹配的服务的URL列表。然后，它可以使用属性请求（AttrRqst）消息确定每个服务的特定属性。
This document assumes the following use of SLP for discovering local devices. Devices have a service type of "sip-device" and a SIP URI as the service URI. Section 5.2 describes the form of this URI. Attributes specify device characteristics such as vendor, supported media codec, display resolution, as well as location coordinates, such as street address and room number. SAs are co-located with SIP UAs on session-mobility enhanced devices, while a separate SA is available to send SrvReg messages on behalf of basic devices, which do not have integrated SLP SAs.
本文档假设以下使用SLP查找本地设备。设备具有“sip设备”的服务类型和作为服务URI的SIPURI。第5.2节描述了此URI的形式。属性指定设备特征，如供应商、支持的媒体编解码器、显示分辨率以及位置坐标，如街道地址和房间号。SA与SIP UAs在会话移动增强设备上位于同一位置，而单独的SA可代表基本设备发送SrvReg消息，这些设备没有集成SLP 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向DA发出SrvRqst消息，请求所有SIP设备，使用位置属性过滤掉不在当前房间中的设备。向移动设备发送SrvRply消息，其中包含房间中所有设备的SIP URI列表。然后为每个URL发送一个单独的属性请求（AttrRqst），以获取服务的属性。MN为用户显示房间中的可用设备及其属性。图1显示了这个协议流。
Device DA MN
|(1) SrvReg | |
|------------------------->| |
|(2) SrvRply | |
|<-------------------------| |
| | |
| | |
| |(3) SrvRqst |
| |<----------------------|
| |(4) SrvRply URL list |
| |---------------------->|
| |(5) AttrRqst URL1 |
| |<----------------------|
| |(6) AttrRply |
| |---------------------->|
| | ... |
| | |
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.
会话移动性涉及活动会话的传输和检索。传输意味着将当前设备上的会话移动到一个或多个其他设备。检索导致当前在另一个设备上的会话传输到本地设备。这可能意味着在将会话传输到另一个设备之前，将会话返回到它原来所在的设备。例如，在发现大型视频监视器之后，用户将视频输出流传输到该设备；当他离开时，他将流返回到他的移动设备以继续通信。还可以将会话移动到以前未携带会话的设备上。例如，在他的固定电话上的音频呼叫的参与者可以在呼叫的中间离开他的办公室，并且在他跑出门时将呼叫转移到移动设备。
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
会话媒体集可以完全传输到单个设备，也可以在多个设备之间分割。例如，用户可能只希望在其PDA上维护音频组件的同时传输其会话的视频组件。或者，他可能会找到单独的视频和音频设备，并希望传输一种媒体
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的显示器可能太小，无法很好地看到另一呼叫参与者，因此用户可以将视频输出传送到投影仪并继续使用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）模式。我们在下面依次描述它们。
In Mobile Node Control mode, the Mobile Node uses third-party call control [2]. It establishes a SIP session with each device used in the transfer and updates its session with the CN, using the SDP parameters to establish media sessions between the CN and each device, which take the place of the current media sessions with the CN. The shortcoming of this approach is that it requires the MN to remain active to maintain the sessions.
在移动节点控制模式下，移动节点使用第三方呼叫控制[2]。它与传输中使用的每个设备建立SIP会话，并更新其与CN的会话，使用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端使用的现有设备更具互操作性。本节的其余部分介绍了两种会话传输模式中会话的传输、检索和拆分。
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,
通信会话可能由多种媒体类型组成，用户应能够将其中任何一种传输到所选设备。本文档考虑音频、视频和消息。音频和视频由RTP传输，并在SIP请求和响应的SDP主体中协商。有三种不同的方法用于承载文本消息，可能还有其他适合SIP端点的MIME类型。RTP可用于实时传输文本有效载荷，
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.
基于[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.
如前所述，本文件假设使用个人和公共设备。我们假设公共设备使用专用记录地址（AOR），例如sip：device11@example.com. 个人设备已经使用了所有者的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和设备之间存在一对一的映射。因此，传输请求可以发送到AOR，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，该GRUU在SLP中注册为服务URI，并且可以由另一个设备在通过代理发送的请求中直接寻址。当代理将请求转发给设备时，它将用联系人URI替换GRUU，如[12]所述。因此，设备将使用联系人URI而不是关联的GRUU来确定请求是针对设备本身还是针对多设备系统。我们假设使用了公共GRUU。
local device MN CN
|(1) INVITE no sdp | |
|<------------------------| |
|(2) 200 OK local params | |
|------------------------>| |
| |(3) INVITE local params |
| |------------------------>|
| RTP | |
|<..................................................|
| |(4) 200 OK CN params |
| |<------------------------|
| |(5) ACK |
| |------------------------>|
|(6) ACK CN params | |
|<------------------------| RTP |
|..................................................>|
| | |
| | |
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]中指定），只要端点立即应答，建议使用第三方呼叫控制流I。MN向用于传输的本地设备发送SIP INVITE请求，请求建立新会话，但不包括SDP主体。本地设备的响应包含一个SDP正文，其中包括它将用于任何媒体的地址和端口，以及它支持的每个媒体的编解码器列表。MN通过在SDP主体中发送包含本地设备的媒体参数的INVITE请求（重新INVITE）来更新与CN的会话，如下所示：
v=0
c=IN IP4 av_device.example.com
m=audio 4400 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
m=video 5400 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
v=0
c=IN IP4 av_device.example.com
m=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稍后才被允许检索媒体会话。[2]中讨论了控制器对未知SDP属性的解析。
In figure 2, the message sequence for transferring an MSRP message session using MNC mode is identical to that used for audio or video, although the contents of the messages differ. To simplify the example, we assume that an MSRP session, with no other media, is being transferred to a local messaging node, MSGN. In the following flow, we refer to the corresponding messages in Figure 2. An empty INVITE request (1) is sent to the local messaging node, MSGN, as follows:
在图2中，使用MNC模式传输MSRP消息会话的消息序列与用于音频或视频的消息序列相同，尽管消息的内容不同。为了简化示例，我们假设一个没有其他媒体的MSRP会话正在传输到本地消息传递节点MSGN。在下面的流程中，我们参考图2中相应的消息。将空的INVITE请求（1）发送到本地消息传递节点MSGN，如下所示：
INVITE sip:msgn@example.com;gr=urn:uuid:jtr5623n SIP/2.0
To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n>
From: <sip:bob@example.com>;tag=786
Call-ID: 893rty@mn.example.com
Content-Type: application/sdp
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
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
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）发送相同的请求，但包含MSRP媒体和属性行，路径在上面的MSGN响应中给出。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，MN位于所需TCP连接的两端。因此，两个端点都不会建立连接。协商机制可用于在会话设置期间分配活动端点的角色。然而，尽管管理系统更新项目保留了这种可能性，但由于其复杂性，目前并未包含在本文件中。如果CN和本地设备通常都使用MSRP中继[8]，那么这种会话传输将成为可能的唯一其他方式，因为它们之间不必建立直接连接。当每个新端点接收到来自MN的INVITE请求时，如果还不存在这样的连接（由于CN与MN的会话，CN将已经有一个连接），它将创建一个与它的一个预配置中继的TLS连接，并接收中继的路径。在对MN的响应中，它将在path属性中包含必须遍历的整个路径，包括其中继。例如，来自MSGN的响应如下所示：
SIP/2.0 200 OK
To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n;tag=087js>;tag=087js
From: <sip:bob@example.com>;tag=786
Call-ID: 893rty@mn.example.com
Content-Type: application/sdp
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
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通过单独的INVITE请求与每个本地设备建立新会话，并使用SDP主体更新与CN的现有会话，该SDP主体将其在其响应中接收的适当媒体参数组合在一起。例如，为了将音频和视频呼叫传送到两个设备，MN与它们中的每一个发起单独的会话，组合来自一个响应的音频媒体线和来自另一个响应的视频媒体线，并将它们作为请求一起发送到CN，如下所示：
v=0
m=audio 48400 RTP/AVP 0
c= IN IP4 audio_dev.example.com
a=rtpmap:0 PCMU/8000
m=video 58400 RTP/AVP 34
c= IN IP4 video_dev.example.com
a=rtpmap:34 H263/90000
v=0
m=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中向每个本地设备发送一个。
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 |
|...............................................................>|
| | | |
| | | |
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:
在输入和输出设备（如照相机和视频显示器）之间拆分全双工媒体服务（如视频），是该方法的简单扩展。信令与图3相同，音频和视频设备由视频输出和视频输入设备代替。然而，SDP略有不同。MN邀请本地设备进入两个不同的会话，但不包括任何SDP主体。他们每个人都用所有可用的媒体进行回应。如果它们仅支持单向介质，如照相机或仅显示设备，则它们将包括“sendonly”或“RecvoOnly”属性。否则，MN必须在将组合的SDP正文发送到CN之前将适当的属性附加到每个媒体行。该机构将如下：
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
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
In updating an SDP session, according to Section 8 of [4], the i-th media line in the new SDP corresponds to the i-th media line in the previous SDP. In the above cases, if a media type is added during the transfer, the media line(s) should follow the existing ones. When an existing media is transferred to a different device, the media line should appear in the same place that it did in the previous SDP, as should the lines for all media that have not been altered. When a duplex media stream is being split across an input and output device, the stream corresponding to the input device should appear in place of the duplex media stream. Since this new stream is the one that will be received by the CN, including it in place of the old one ensures that the CN views the new stream as a replacement of the old one. The media line corresponding to the output device must appear after all existing media lines. In the last example, if the SDP had initially contained a video line followed by an audio line, the updated SDP sent to the CN would look as follows:
在更新SDP会话时，根据[4]的第8节，新SDP中的第i个媒体行对应于先前SDP中的第i个媒体行。在上述情况下，如果在传输过程中添加了介质类型，则介质线应遵循现有的介质线。将现有介质传输到其他设备时，介质线应显示在与上一个SDP相同的位置，所有未更改的介质线也应显示在相同的位置。当双工媒体流在输入和输出设备之间被拆分时，与输入设备相对应的流应该出现在双工媒体流的位置。由于此新流是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
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发送具有其自己的媒体参数的INVITE请求来检索会话，从而导致媒体流返回。然后，它向每个本地设备发送BYE消息以终止会话。
Session Handoff mode uses the SIP REFER method [3]. This message is a request sent by a "referrer" to a "referee", which "refers" it to another URI, the "refer target", which may be a SIP URI to be contacted with an INVITE or other request, or a non-SIP URI, such as a web page. This URI is specified in the Refer-To header. The Referred-By [5] header is used to give the referrer's identity, which is sent to the refer target for authorization. Essential headers from this message may also be encrypted and sent in the message body as Secure/Multipurpose Internet Mail Extensions (S/MIME) to authenticate the REFER request. Figure 4 shows the flow for transferring a session.
会话切换模式使用SIP REFER方法[3]。该消息是由“推荐人”发送给“推荐人”的请求，该“推荐人”将其“推荐”到另一个URI，“推荐目标”，其可以是要与邀请或其他请求联系的SIP URI，或者非SIP URI，例如网页。此URI在引用标头中指定。Referred By[5]标头用于提供推荐人的身份，该身份将发送给推荐目标进行授权。此邮件中的基本邮件头也可以加密并作为安全/多用途Internet邮件扩展（S/MIME）在邮件正文中发送，以验证REFER请求。图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 | |
|<----------------------------| |
| | |
| | |
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向本地设备发送以下REFER请求（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>
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
此消息指示本地设备邀请引用目标CN加入会话。Refer-Refer URI中的“音频”和“视频”标记是被调用方功能[10]。在这里，它们用于通知裁判员，裁判员应启动与CN的音频和视频会话。URI中还包括Replaces标头字段，指定Replaces标头字段应包含在后续INVITE请求中的指定值中。替换
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用新会话替换MN的当前会话。根据[6]，CN应只接受某些授权类别用户的会话替换请求。这种类型的用户之一是会话中的当前参与者。因此，MN可以参考本地设备以用CN替换其当前会话。但是，它通过加密它在REFER中发送的S/MIME正文中原始REFER请求的多个头来提供身份验证。本地设备将此正文发送到CN。这可以防止恶意用户不加区别地替换其他用户的会话。一旦本地设备接收到REFER请求，它将向CN发送INVITE请求，然后进行正常会话设置。然后CN中断了与MN的会话。
Once the local device has established a session with the CN, it sends a NOTIFY request to the MN, as specified in [3]. This NOTIFY contains the To (including tag), From (including tag), and Call-ID header fields from the established session to allow the MN to subsequently retrieve the session, as described in Section 5.4.2.
一旦本地设备与CN建立了会话，它将向MN发送通知请求，如[3]中所述。此通知包含已建立会话的To（包括标记）、From（包括标记）和Call ID报头字段，以允许MN随后检索会话，如第5.4.2节所述。
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会话以及其他会话。REFER请求（1）表示应使用REFER REFER header字段中的被叫方功能建立MSRP会话，就像音频和视频一样。此类媒体功能标签“消息”已经定义[11]。一旦本地设备接收到REFER请求，它将启动与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 | |
|-------------------------------------------------->|
| | |
| | |
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>
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和本地设备上的用户是不同的身份，因此除了包括来自本地设备的S/MIME认证主体之外，本地设备还需要引用MN并在referenced by报头中包括其URI，以便允许替换会话。因此，MN必须接收来自本地设备的REFER请求，以发送该INVITE请求。用户可以使用本地设备的用户界面发送此REFER消息。但是，这样的接口可能不可用。此外，用户可能希望在手持移动设备离开办公室时执行传输。为了让MN提示来自本地设备的REFER，它发送一个“嵌套REFER”[5]，一个针对另一个REFER的REFER请求。在这种情况下，第二个参考被发送回移动节点。该引用必须指定在后续的INVITE请求中包含Replaces标头。从本地设备到MN（3）的refere请求由以下组成：
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>
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):
refereferuri中包含一个header字段，用于指定目标INVITE请求中Replaces头的值。为了向其发送此消息，MN必须发送以下REFER请求（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>">
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
refere-To报头指定MN是refere目标，并且reference采用refere请求的形式。header字段指定REFER请求包含包含CN URI的REFER-REFER标头。该URI本身包含“音频”和“视频”被叫方功能，这些功能将告诉MN启动音频和视频呼叫，以及一个头字段，该头字段指定最终邀请请求包含替换头。如果MN先前已将会话转移到本地设备，则它将收到
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.
在会话建立后，本地设备发送的通知中包含这些消息。另一方面，如上文第5.1.1节所述，如果MN正在检索其之前未持有的会话，则它通过订阅本地设备的对话事件包[13]来获取这些参数。例如，这样的订阅只能授予承载会话的原始设备的所有者。即使在Replaces报头中提供了这些参数，本地设备也不会接受来自会话的原始参与者或设备所有者以外的任何人的refere请求。MN从本地设备接收REFER请求，将INVITE请求发送给CN，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模式下分割会话需要在CN和本地设备之间建立多个媒体会话，而MN不控制信令。这可以通过向本地设备发送多个REFER请求来实现，每个请求都指向CN。这种方法的缺点是，目前没有标准方法将多个会话关联为SIP中单个调用的一部分。因此，CN和本地设备之间的每个会话将被视为单独的呼叫。它们可能占用用户界面的不同部分，它们的媒体可能无法同时使用，并且可能必须单独终止。这当然不符合无缝的要求。
This document describes the use of multi-device systems to overcome this problem. A local device's SLP UA queries for other devices and joins with them to create a "virtual device", or a Multi-Device System (MDS). We refer to the controlling device as the Multi-Device System Manager (MDSM). In a system that includes at least one mobility-enhanced device, one of them may act as the MDSM. In a system consisting entirely of basic devices, either a dedicated host or another local device from outside of the system acts as MDSM. When the MDSM subsequently receives a REFER request, it uses third-party call control to set up media sessions between the CN and each device in the system. Specifically, it invites each local device into a separate session, and uses their media parameters (and possibly its own) in the INVITE request it sends to the CN.
本文档介绍了如何使用多设备系统来克服此问题。本地设备的SLP UA查询其他设备，并与它们联合创建“虚拟设备”或多设备系统（MDS）。我们将控制设备称为多设备系统管理器（MDSM）。在包括至少一个移动性增强设备的系统中，其中一个可以充当MDSM。在完全由基本设备组成的系统中，系统外部的专用主机或另一个本地设备充当MDSM。当MDSM随后收到REFER请求时，它使用第三方呼叫控制在CN和系统中的每个设备之间建立媒体会话。具体地说，它邀请每个本地设备进入一个单独的会话，并在发送给CN的INVITE请求中使用它们的媒体参数（可能还有它自己的）。
A single device may act as an MDSM for several different groups of devices, and also act as an ordinary device with only its native capabilities. There must be a way to address a request to a device and specify whether it is to the device itself or one of the multi-device systems it controls. As mentioned above in Section 5.2, a device registers a separate contact for itself and for each of its
单个设备可以充当多个不同设备组的MDSM，也可以充当仅具有本机功能的普通设备。必须有一种方法来处理对设备的请求，并指定是对设备本身还是对其控制的多设备系统之一的请求。如上文第5.2节所述，设备为其自身和每个设备注册一个单独的触点
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.
多设备系统。例如，具有AOR“sip:device11@example.com主机名“device11.example.com”将注册联系人“sip:device11@device11.example.com“这代表了它自己的能力。一旦发现其他设备并创建MDS，它将注册一个新联系人，“sip:av1@device11.example.com". 它将GRUU与每个联系人关联。设备本身和任何新系统都使用GRUU在SLP中注册。当代理收到发往GRUU的请求时，它将在将请求转发到设备之前将其重写为联系人URI。设备将使用此唯一联系人来确定是以本机方式还是使用其系统之一来处理请求。
Figure 6 shows the transfer of a session to a multi-device system. The audio device has previously discovered the video device and created a multi-device system. The REFER request sent to "sip:device11@example.com;gr=urn:uuid:893eeeyuinm981" prompts the audio device to invite the video device into a session to ascertain its SDP, and then to invite the CN into a session using its own SDP and that of the video device.
图6显示了会话到多设备系统的传输。音频设备先前已发现视频设备并创建了多设备系统。将REFER请求发送到“sip:device11@example.com；gr=urn:uuid:893eeeyuinm981“提示音频设备邀请视频设备加入会话以确定其SDP，然后使用其自己的SDP和视频设备的SDP邀请CN加入会话。
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 |
| | |----------->|
| | | |
| | | |
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.
上述示例涉及用户向一个或多个设备传输的已建立会话。另一种情况是，当用户接受呼叫时，传入呼叫将立即分布在多个设备之间。在这种情况下，在转让发生时，初始届会尚未成立。
The transfer could be carried out in either of the transfer modes. However, complete handoff to a separate device, which is done in Session Handoff mode, could be achieved through existing means, such as proxying or redirection. MNC mode would be useful in a case where the user wishes to automatically include an additional device in a call. For instance, a user with a desk IP phone and a PC with a video camera could join the two into a single logical device. The
可以在任一传输模式下执行传输。但是，可以通过代理或重定向等现有方式实现到单独设备的完全切换（在会话切换模式下完成）。在用户希望在呼叫中自动包括附加设备的情况下，MNC模式将非常有用。例如，一个拥有台式IP电话和一台带有摄像机的PC的用户可以将两者合并到一个逻辑设备中。这个
SIP UA on the PC would, for any incoming call, send an INVITE request to the desk phone, setting the display name in the From header field to "Bob Jones (audio portion)", for instance, so that the user can identify the caller on the phone. The user could then either accept or reject, as he would with a call coming directly to the phone. If he accepts, the PC UA, acting as the controller, would respond to the caller with its video parameters and the phone's audio parameters in the SDP body. The final ACK from the Correspondent Node would then complete the session establishment.
对于任何来电，PC上的SIP UA都会向桌面电话发送INVITE请求，例如，将From头字段中的显示名称设置为“Bob Jones（音频部分）”，以便用户能够识别电话上的来电者。然后，用户可以接受或拒绝，就像直接打电话给手机一样。如果他接受，作为控制器的PC UA将使用SDP主体中的视频参数和手机音频参数响应来电者。来自对应节点的最终ACK随后将完成会话建立。
If the desk phone is registered as a contact for the user, it would also ring in response to the direct call being proxied there, in addition to the INVITE request sent by the controller, causing confusion to the user. The use of caller preferences can solve this problem, as the caller would indicate that the call should preferentially be proxied to devices with audio and video capabilities. It is likely that the caller would use caller preferences in any case, if they were available to him, to avoid the callee unknowingly picking up the IP phone when he has a video-capable device available. However, since caller preferences are not yet widely supported on commercial devices, the callee must ensure the proper routing of the call. One solution would be for the PC to register its contact with a higher priority than the one given to the phone. The Call Processing Language (CPL) [22] (the "proxy" node) could then be used to specify that forking should be done to the set of user devices in sequence, rather than in parallel. Since all calls would first be sent to the PC as long as it were online, it would redirect any request that included only audio in its SDP.
如果桌面电话注册为用户的联系人，除了控制器发送的INVITE请求外，它还将响起来响应在那里代理的直接呼叫，从而给用户造成混乱。使用呼叫者偏好可以解决这个问题，因为呼叫者会指示呼叫应该优先代理给具有音频和视频功能的设备。呼叫方可能会在任何情况下使用呼叫方首选项（如果他可用），以避免被呼叫方在有视频设备可用时无意中拿起IP电话。然而，由于商业设备尚未广泛支持呼叫者偏好，因此被呼叫者必须确保呼叫的正确路由。一种解决方案是，PC以比手机更高的优先级注册其联系人。然后，可以使用呼叫处理语言（CPL）[22]（代理）节点）来指定应该按顺序而不是并行地对用户设备集进行分叉。由于只要PC在线，所有呼叫都会首先发送到PC，因此它会重定向SDP中仅包含音频的任何请求。
Interactive Connectivity Establishment (ICE) [27] is a protocol for Network Address Translator (NAT) traversal that may be used with SIP. Rather than negotiating addresses and ports used for media sessions directly in SDP, a list of possible address/ports (candidates) is exchanged, and the Session Traversal Utilities for NAT (STUN) [28] protocol is used to check which pairs of candidates may be used. ICE could be used in the call flows described in this section. In MNC mode, the candidates would be sent by each local device to the MN, who would exchange them with the CN. Afterward, each device would perform checks with the CN to determine an appropriate candidate. In SH mode, where the local device establishes a session with the CN, ICE would work no differently than in the standard case.
交互式连接建立（ICE）[27]是一种用于网络地址转换器（NAT）遍历的协议，可与SIP一起使用。不是直接在SDP中协商用于媒体会话的地址和端口，而是交换可能的地址/端口（候选）列表，并使用NAT（STUN）[28]协议的会话遍历实用程序检查可能使用的候选对。ICE可用于本节所述的调用流中。在MNC模式下，每个本地设备将候选设备发送给MN，MN将与CN交换候选设备。之后，每个设备将与CN进行检查，以确定合适的候选设备。在SH模式下，本地设备与CN建立会话，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服务属性包含。由于OPTIONS方法是标准的，因此建议使用它来查询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向本地设备发送REFER请求，并允许其在会话建立期间与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,
在SIP中使用转码服务在[18]中定义为使用第三方呼叫控制。在MNC模式下，移动节点在转码器和CN之间以及转码器和本地设备之间建立一个媒体会话。这不同于正常转码情况，其中一方在自身和转码器之间以及转码器和另一方之间建立媒体会话。MN首先向没有主体的本地设备发送INVITE请求；它在响应中接收设备可以使用的编解码器列表。然后对CN重复此操作，并接收其可用的编解码器。它从每一侧选择一个编解码器，
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.
以及每个设备的地址和端口，并将它们组合在发送到转码器的INVITE请求中。代码转换器用它将接受每个流的端口进行响应。适当的端口信息分别发送到CN和本地设备。一旦建立了三个会话，就存在两个媒体会话，转码器在它们之间进行转换。该流程如图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 |<...................................................|
|<..........| | |
| | | |
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建立会话。收到REFER请求后，它使用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进行特殊处理。例如，定义了SDP格式[19]，用于为H.263+编解码器指定这些参数和其他参数。给定编解码器支持的合适图像格式和相应的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
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模式下，本地设备（图2，消息2）对MN发送的初始INVITE请求的响应在SDP正文中包括该行，然后MN将其包括在发送给CN的INVITE请求中（3）。在会话切换模式下，本地设备在接收到REFER请求后，在发送给CN的INVITE请求（图4，消息3）中包含此参数。如果本地设备未配置为在会话建立期间包括支持的图像大小，则可以通过SLP提供信息。然后，MN将其包括在以移动节点控制模式发送到CN的INVITE请求中。但是，除非本地设备配置为发送此信息，否则不会以会话切换模式发送此信息。在这两种模式中，MN在INVITE请求主体中发送自己的分辨率和帧速率首选项，以检索会话。
A session transfer may be carried out by one call participant after the other participant has transferred the session on his side. If the first transfer was done in MNC mode, a subset of the original session media is now on local devices. The MN receives either a re-INVITE from the other participant or an INVITE request from a local device on the other side. This message carries the new media parameters of the session. The MN, therefore, must send a re-INVITE
会话转移可以由一个呼叫参与方在另一个参与方转移其一侧的会话后执行。如果第一次传输是在MNC模式下完成的，则原始会话媒体的子集现在位于本地设备上。MN接收来自另一方参与者的重新邀请或来自另一方本地设备的邀请请求。此消息包含会话的新媒体参数。因此，MN必须发送重新邀请
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.
到具有这些参数的任何本地设备。然后在200 OK响应中包含从这些设备返回的参数。如果第一次传输是在SH模式下完成的，本地设备将直接接收来自另一方的会话传输消息，并将按照正常程序响应INVITE请求。如果作为MDS的一部分，它正在控制该会话的其他本地设备，那么它将遵循上面的过程，其中第一次传输是在MNC模式下完成的。
It may occur that both participants attempt a transfer at the same time. In MNC mode, each node initiates a session with a local device, then sends a re-INVITE to the other node. Section 14.2 in [1] mandates a 491 response when a re-INVITE is received for a dialog once another re-INVITE has already been sent. Once both parties receive this response, they each generate a random timer with staggered intervals. Once its timer fires, each participant attempts the re-INVITE again. The first to receive it from the other participant responds to it with the SDP parameters of its local device. Both participants then send an ACK request to their local device containing the new parameters obtained from the other one during the re-INVITE process.
两个参与者可能同时尝试转移。在MNC模式下，每个节点启动与本地设备的会话，然后向另一个节点发送重新邀请。[1]中的第14.2节规定，一旦收到一个对话框的重新邀请，并且已经发送了另一个重新邀请，则需要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模式下，如果两个参与者同时尝试传输，则在一个节点向本地设备发送REFER请求后，它会从另一端的本地设备接收INVITE请求。在这种情况下，适当的协议定义也可以要求发送491响应。该响应将以通知的形式返回给推荐人，说明推荐会话建立的状态。上述交错定时器解决方案可以工作。MN将取消发送到本地设备的REFER请求，然后在再次发送之前随机等待一段时间。
Once a session has been transferred, the user may terminate it by hanging up the current device, as he would do in a call originating on that device. This should be true even when the session is using several local devices. In MNC mode, when the user hangs up the current device, a BYE request is sent to the controller. The controller must then send a BYE request to each device used in the transfer and a BYE request to the CN. An MDSM used for SH mode must follow the same procedure. In SH mode, the current device has previously initiated an ordinary session with the CN in response to the REFER request, and the BYE it sends to the CN on hang-up requires no special handling.
一旦会话被转移，用户可以通过挂断当前设备来终止会话，就像他在该设备上发起的呼叫中所做的那样。即使会话使用多个本地设备，也应如此。在MNC模式下，当用户挂断当前设备时，将向控制器发送BYE请求。然后，控制器必须向传输中使用的每个设备发送BYE请求，并向CN发送BYE请求。用于SH模式的MDSM必须遵循相同的程序。在SH模式下，当前设备先前已响应REFER请求启动与CN的普通会话，并且在挂断时发送给CN的BYE不需要特殊处理。
As this work is based heavily on the work in [2], [3], and [5], the security considerations described in those documents apply. We discuss here the particular issues of authorizing use of local devices, providing media-level security following transfer, and the issue of flooding attacks in MNC mode.
由于这项工作主要基于[2]、[3]和[5]中的工作，因此这些文件中描述的安全注意事项适用。我们在此讨论授权使用本地设备、在传输后提供媒体级安全以及MNC模式下的泛洪攻击等特定问题。
It is necessary that the use of a local device be limited to authorized parties. As stated earlier, this document assumes both personal and public devices, and these have different authorization policies. A personal device only accepts transfer requests from a single identity, the device owner. Therefore, the most appropriate means of access control is to maintain a list of identities representing the device owner authorized to transfer sessions to the device. As mentioned before, the device is configured with an AOR representing its status as a transfer device, in addition to the user's AOR. Only requests made to the device AOR follow the access list, while incoming requests to the user's AOR are accepted from anyone (provided that a white or blacklist or other policy does not preclude their request from being accepted). The SIP-Identity header [25] is used to securely identify the initiator of a SIP request. That specification can be used in our use-cases when the local device must ensure that the INVITE or REFER request in MNC or SH mode, respectively, is indeed from the owner of the device.
必须将本地设备的使用限制在授权方。如前所述，本文档假设个人设备和公共设备，并且它们具有不同的授权策略。个人设备仅接受来自单一身份（设备所有者）的传输请求。因此，最合适的访问控制方法是维护一个标识列表，该列表表示被授权将会话传输到设备的设备所有者。如前所述，除了用户的AOR之外，设备还配置了表示其作为传输设备的状态的AOR。只有向设备AOR发出的请求才会遵循访问列表，而向用户AOR发出的传入请求会被任何人接受（前提是白名单或黑名单或其他策略不会阻止其请求被接受）。SIP标识头[25]用于安全地标识SIP请求的发起方。当本地设备必须分别确保MNC或SH模式下的INVITE或REFER请求确实来自设备所有者时，可以在我们的用例中使用该规范。
Public devices accept transfer requests from a large number of identities. Access lists may be used for this purpose. Alternatively, since devices are often available to categories of users, such as "manager" or "faculty member", an appropriate solution may be to use trait-based authorization [23]. Using this mechanism, a user may acquire, from a trusted authorization service, an "assertion" of his user status and permissions. The assertion, or a reference to it, is included in the request to use the device.
公共设备接受来自大量身份的传输请求。访问列表可用于此目的。或者，由于设备通常可供不同类别的用户使用，例如“经理”或“教员”，因此一个合适的解决方案可能是使用基于特征的授权[23]。使用此机制，用户可以从可信授权服务获取其用户状态和权限的“断言”。断言或对它的引用包含在使用设备的请求中。
Confidentiality, message authentication, and replay protection are necessary in internet protocols, including those used for real-time multimedia communications. The Secure Real-time Transfer Protocol (SRTP) [14] provides these for RTP streams. Since SRTP may be used to carry the media sessions of SIP devices, such as the MN and CN, we
保密性、消息认证和重播保护在互联网协议中是必要的，包括用于实时多媒体通信的协议。安全实时传输协议（SRTP）[14]为RTP流提供了这些功能。由于SRTP可用于承载SIP设备（例如MN和CN）的媒体会话，因此我们
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。[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通信由两个文件定义。“crypto”属性[15]是一个媒体级属性，其值包括用于对RTP数据包执行对称加密的所需加密套件和密钥参数。由于密钥信息在SDP正文中发送，没有专用的加密或完整性保护，因此必须使用单独的协议（如S/MIME）来保护信令消息。另一个文档[16]指定了用于为密钥管理协议（如MIKEY）提供参数的“密钥管理”属性。使用此属性，两个参与者交换由公钥或共享密钥加密的密钥，或者使用Diffie-Hellman方法协商密钥。
The use of cryptographic parameters in SDP does not change the message flows described earlier in this document. For instance, in MNC mode shown in Figure 2, the response from the local device (2) will include, in addition to any supported media type, cryptographic information for each type. This cryptographic information will be a list of attribute lines describing the crypto suite and key parameters using either of the two attributes mentioned. These lines will be sent by the MN to the CN in the subsequent request (3). The CN will choose a cryptographic method and return its own key information in the response (4). Maintaining a secure media session in SH mode requires the local device to negotiate a cryptographic relationship in the session that it establishes following its receipt of the REFER request.
在SDP中使用加密参数不会改变本文档前面描述的消息流。例如，在图2所示的MNC模式下，来自本地设备（2）的响应除了包括任何支持的媒体类型外，还包括每种类型的加密信息。该加密信息将是一个属性行列表，使用上述两个属性之一描述加密套件和密钥参数。这些线路将在后续请求（3）中由MN发送到CN。CN将选择加密方法并在响应（4）中返回其自己的密钥信息。在SH模式下维护安全的媒体会话需要本地设备在会话中协商加密关系，该会话在收到REFER请求后建立。
It is noted in [2] that establishing media security in third party call control depends on the cooperation of the controller. In this document, the Mobile Node (MN) in Mobile Node Control mode (MNC) has the role of controller in 3pcc, while in the Session Handoff (SH) mode, MN uses the REFER method instead. The following is an excerpt from that document:
[2]中指出，在第三方呼叫控制中建立媒体安全取决于控制器的合作。在本文中，移动节点控制模式（MNC）下的移动节点（MN）在3pcc中扮演控制器的角色，而在会话切换（SH）模式下，MN使用REFER方法。以下是该文件的摘录：
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
端到端媒体安全性基于SDP内密钥材料的交换。这些具有第三方调用控制的机制的正确运行取决于控制器的正常运行。只要不试图显式禁用这些机制，协议将在参与者之间正常运行，从而产生一个即使控制器也无法窃听或修改的安全媒体会话。由于第三方呼叫控制基于用户和控制器之间的信任模型，因此可以合理地假设它以良好的方式运行。但是，没有任何加密方法可以
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.
防止控制器干扰键控材料的初始交换。因此，如果控制器愿意的话，它很可能在媒体交换上插入自己作为中介。
We note here that given the model presented in this document, where the controller is operated by the same person that uses the local device, i.e., the MN user, there is even more reason to believe that the controller will be well-behaved and will not interfere with the initial transfer of key exchanges.
我们在此注意到，鉴于本文件中提出的模型，其中控制器由使用本地设备的同一人（即MN用户）操作，更有理由相信控制器将表现良好，不会干扰密钥交换的初始传输。
The exchange of media could alternatively be secured at the transport layer, using either TLS or Datagram Transport Layer Security (DTLS) [24]. The one consideration for use of these protocols in session mobility would be assigning the client and server roles. In SH mode, it may be assumed that the local device, the referee, would act as the client, since it is initiating the signaling session with the CN. However, in MNC mode, these roles would be unclear. The same problem was mentioned above in establishing a secure connection for an MSRP session transferred in MNC mode. This problem could be solved through the use of Connection-Oriented Media (COMEDIA) [26], which specifies the "setup" SDP attribute to negotiate these roles.
媒体交换也可以使用TLS或数据报传输层安全性（DTLS）在传输层进行保护[24]。在会话移动中使用这些协议的一个考虑因素是分配客户机和服务器角色。在SH模式中，可以假设本地设备（仲裁人）将充当客户端，因为它正在发起与CN的信令会话。然而，在跨国公司模式下，这些角色并不明确。在为以MNC模式传输的MSRP会话建立安全连接时，上文也提到了同样的问题。这个问题可以通过使用面向连接的媒体（COMEDIA）[26]来解决，它指定了“setup”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]，同样的方法可用于在DTL上建立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
本文档中的MNC调用流（其中一个设备指示另一个设备向第三个设备发送RTP流）可能会引发泛洪攻击。这是与3pcc的任何使用相关的一般问题。在本文档中，仅当设备为公共设备时（如本节开头所述），并且由于设备之间可能没有很强的信任关系，大量人员可以向其传输媒体，这是一个值得关注的问题
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.
所有者（如机构）和用户。显然，如果设备是私有的，并且只有其所有者可以向其传输，那么考虑到前面提到的标识头的使用，问题就不存在了。一个可能的解决方案可能是使用ICE[27]，因为双方都确认希望接收对方的媒体。
We would like to acknowledge the helpful comments made about this document by the SIP community, in particular Jon Peterson, Joerg Ott, and Cullen Jennings.
我们要感谢SIP社区，特别是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：会话启动协议”，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）的最佳当前实践”，BCP 85，RFC 37252004年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 38922004年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 38912004年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.，“消息会话中继协议（MSRP）”，RFC 49752007年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 49762007年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）信息媒体功能标签的注册”，RFC4569，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）中获取和使用全局可路由用户代理URI（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 42352005年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 37112004年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，2006年7月。
[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 26081999年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 41172005年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.Even，编辑，“ITU-T Rec.H.263视频的RTP有效载荷格式”，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移动计算和通信评论，第4卷，第3期，2000年7月。
[21] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[21] Campbell，B.，Ed.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年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，“呼叫处理语言（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.和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 41452005年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.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，正在进行的工作，2007年10月。
[28] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[28] 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，“使用DTL建立SRTP安全上下文的框架”，正在进行的工作，2009年3月。
Authors' Addresses
作者地址
Ron Shacham Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号罗恩·沙查姆哥伦比亚大学，邮编：10027
EMail: shacham@cs.columbia.edu
EMail: shacham@cs.columbia.edu
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号亨宁·舒尔兹林内哥伦比亚大学，邮编：10027
EMail: hgs@cs.columbia.edu
EMail: hgs@cs.columbia.edu
Srisakul Thakolsri DoCoMo Communications Laboratories Europe Landsberger Str. 312 Munich 80687 Germany
Srisakul Thakolsri DoCoMo通信实验室欧洲兰德斯伯格大街312号慕尼黑80687德国
EMail: thakolsri@docomolab-euro.com
EMail: thakolsri@docomolab-euro.com
Wolfgang Kellerer DoCoMo Communications Laboratories Europe Landsberger Str. 312 Munich 80687 Germany
德国慕尼黑兰德斯伯格大街312号Wolfgang Kellerer DoCoMo通信实验室欧洲实验室80687
EMail: kellerer@docomolab-euro.com
EMail: kellerer@docomolab-euro.com