idnits 2.17.1 draft-shacham-sipping-session-mobility-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1658. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in 'Intended Status: Informational ', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 6004 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '17' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1530, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1533, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1540, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 1543, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2793 (ref. '9') (Obsoleted by RFC 4103) ** Downref: Normative reference to an Informational RFC: RFC 4569 (ref. '11') -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. '29') (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '30') (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '33') (Obsoleted by RFC 5389) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING R. Shacham 3 Internet-Draft H. Schulzrinne 4 Intended Status: Informational Columbia University 5 Expires: May 21, 2008 S. Thakolsri 6 W. Kellerer 7 DoCoMo Euro-Labs 8 November 18, 2007 10 Session Initiation Protocol (SIP) Session Mobility 11 draft-shacham-sipping-session-mobility-05 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 Session mobility is the transfer of media of an ongoing communication 45 session from one device to another. This document describes the 46 basic approaches and shows the signaling and media flow examples for 47 providing this service using the Session Initiation Protocol (SIP). 48 Service discovery is essential to locate targets for session transfer 49 and is discussed using the Service Location Protocol (SLP) as an 50 example. This document is intended as an informational document. 52 Table of Contents 54 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Roles of Entities . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Device Discovery . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Session Mobility . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.1. Options for Session Mobility . . . . . . . . . . . . . . . 8 60 5.1.1. Transfer and Retrieval . . . . . . . . . . . . . . . . 8 61 5.1.2. Whole and Split Transfer . . . . . . . . . . . . . . . 8 62 5.1.3. Transfer Modes . . . . . . . . . . . . . . . . . . . . 8 63 5.1.3.1. Mobile Node Control (MNC) Mode . . . . . . . . . . 8 64 5.1.3.2. Session Handoff (SH) Mode . . . . . . . . . . . . 9 65 5.1.4. Types of Transferred Media . . . . . . . . . . . . . . 9 66 5.2. Addressing of Local Devices . . . . . . . . . . . . . . . 10 67 5.3. Mobile Node Control Mode . . . . . . . . . . . . . . . . . 10 68 5.3.1. Transfering a Session to a Single Local Device . . . . 10 69 5.3.1.1. RTP Media . . . . . . . . . . . . . . . . . . . . 11 70 5.3.1.2. MSRP Sessions . . . . . . . . . . . . . . . . . . 12 71 5.3.2. Transfer to Multiple Devices . . . . . . . . . . . . . 14 72 5.3.3. Retrieval of a Session . . . . . . . . . . . . . . . . 17 73 5.4. Session Handoff (SH) mode . . . . . . . . . . . . . . . . 17 74 5.4.1. Transfer to a Single Device . . . . . . . . . . . . . 17 75 5.4.2. Retrieval of a Session . . . . . . . . . . . . . . . . 20 76 5.4.3. Transfer to Multiple Devices . . . . . . . . . . . . . 22 77 5.5. Distributing Sessions for Incoming Call . . . . . . . . . 24 78 5.6. Use of ICE in Session Mobility . . . . . . . . . . . . . . 25 79 6. Reconciling Device Capability Differences . . . . . . . . . . 25 80 6.1. Codec Differences . . . . . . . . . . . . . . . . . . . . 26 81 6.2. Display Resolution and Bandwidth Differences . . . . . . . 28 82 7. Simultaneous Session Transfer . . . . . . . . . . . . . . . . 28 83 8. Session Termination . . . . . . . . . . . . . . . . . . . . . 29 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 85 9.1. Authorization for Using Local Devices . . . . . . . . . . 30 86 9.2. Maintaining Media Security During Session Mobility . . . . 30 87 9.2.1. Establishing Secure RTP using SDP . . . . . . . . . . 30 88 9.2.2. Securing Media Using the Transport Layer . . . . . . . 32 89 9.3. Flooding Attacks in MNC Mode . . . . . . . . . . . . . . . 32 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 92 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 33 93 12.1. Changes from draft-shacham-sipping-session-mobility-00 . . 33 94 12.2. Changes from draft-shacham-sipping-session-mobility-01 . . 33 95 12.3. Changes from draft-shacham-sipping-session-mobility-02 . . 33 96 12.4. Changes from draft-shacham-sipping-session-mobility-03 . . 34 97 12.5. Changes from draft-shacham-sipping-session-mobility-04 . . 34 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 99 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 100 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 102 Intellectual Property and Copyright Statements . . . . . . . . . . 39 104 1. Overview 106 As mobile devices improve and include more enhanced capabilities for 107 IP-based multimedia communications, they will remain limited in terms 108 of bandwidth, display size and computational power. Stationary IP 109 multimedia endpoints, including hardware IP phones, videoconferencing 110 units, embedded devices and software phones allow more convenience of 111 use, but are not mobile. Moving active multimedia sessions between 112 these devices allows mobile and stationary devices to be used 113 concurrently or interchangeably in mid-session, combining their 114 advantages into a single "virtual device." An approach to session 115 mobility based on the Session Initiation Protocol (SIP) [1] was 116 described first in [23], where two different methods are proposed, 117 third-party call control (3PCC) [2] and the REFER method [3]. 119 This document expands on this concept, defining a framework for 120 session mobility that allows a mobile node to discover available 121 devices and to include them in an active session. In particular the 122 framework for session mobility presented in this document, describes 123 basic approaches for using existing protocols and shows the signaling 124 and media flow examples for providing session mobilty using SIP. It 125 is intended as an informational document. 127 The devices selected as session transfer targets may be either 128 personal or public. Personal devices are any ones used by a single 129 individual, such as one's PC or phone. Public devices are available 130 for use by a large group of people and include large conference-room 131 displays. Two capabilities are required to transfer sessions: 133 Device Discovery - At all times, a user is aware of the devices 134 which are available in his local area, along with their 135 capabilities. 136 Session Mobility - While in a session with a remote participant, 137 the user may transfer any subset of the active media sessions to 138 one or more devices. 140 This document describes session mobility examples for SIP. It does 141 not mandate any particular protocol for device discovery. Many 142 different protocols exist and we discuss the tradeoffs involved in 143 choosing between them. For our examples, we use the Service Location 144 Protocol (SLP) [18] primarily because it is the only such protocol 145 standardized by the IETF. 147 2. Requirements 149 This session mobility framework seeks to fulfill the following 150 requirements: 152 o REQ 1: Backward Compatibility - We distinguish two kinds of 153 devices. Enhanced devices support the call flows described in 154 Section 5 and can perform discovery, while basic devices can do 155 neither, and only have basic SIP capabilities. Devices initiating 156 session mobility must have enhanced functionality, while all 157 others can be either basic or enhanced devices. This includes the 158 transfer destinations, such as the local video camera, as well as 159 the device being used by the remote participant. 160 o REQ 2: Flexibility - Differences in device capabilities should be 161 reconciled. Transfer should be possible to devices that do not 162 support the codec being used in the session, and even to devices 163 that do not have a codec in common with the remote participant. A 164 transfer should also take into account device differences in 165 display resolution and bandwidth. 166 o REQ 3: Minimal Disruption - Session transfer should involve 167 minimal disruption of the media flow and should not appear to the 168 remote participant as a new call. 170 3. Roles of Entities 172 Session Mobility involves five types of components: A correspondent 173 Node (CN), a Mobile Node (MN), one or more local devices used as 174 targets for session transfer, an SLP [18] Directory Agent (DA), and, 175 optionally, a transcoder. The Correspondent Node (CN) is a basic 176 multimedia endpoint being used by a remote participant and may be 177 located anywhere. It may be a SIP User Agent (UA), or a Public 178 System Telephone Network (PSTN) phone reachable through a gateway. 179 The Mobile Node (MN) is a mobile device, containing a SIP UA for 180 standard SIP call setup, as well as specialized SIP-handling 181 capabilities for session mobility and an SLP [18] User Agent (UA) for 182 discovering local devices. The local devices are located in the 183 user's local environment, for discovery and use in his current 184 session. They may be mobility-enhanced or basic. Basic devices, 185 such as IP phones, are SIP-enabled, but have no other special 186 capabilities. Mobility-enhanced devices have SLP Service Agent 187 capabilities for advertising their services and session mobility 188 handling. They also contain an SLP UA, whose purpose will be 189 explained in the discussion of multi-device systems in Section 5.4.3. 190 The SLP Directory Agent (DA) keeps track of devices including their 191 locations and capabilities. The use of SLP will be described in more 192 detail in Section 4. SIP-based transcoding services [19] are used, 193 when necessary, to translate between media streams, as described in 194 Section 6. 196 4. Device Discovery 198 A mobile node must be able to discover suitable devices in its 199 vicinity. This is outside the scope of SIP and a separate service 200 location protocol is needed. It is outside the scope of this 201 document to define any service location protocol. This section 202 discusses various options, and describes one of them in more detail. 204 While having a global infrastructure for discovering devices or other 205 services in any location would be desirable, nothing of this sort is 206 currently deployed or standardized. However, this document assumes 207 that such an infrastructure is unnecessary for discovering devices 208 that are in close proximity, such as in the same room. It is 209 possible for such devices to be discovered through direct 210 communication over a short-range wireless protocol such as Bluetooth 211 SDP. Two other categories of service discovery protocols may be 212 used, assuming that devices that are physically close to each other 213 are also within the same network and/or part of the same DNS domain. 214 Multicast-based protocols, such as SLP [18] (in its serverless mode) 215 or Bonjour (mDNS-SD [35]) may be used as long as the mobile node is 216 within the same subnet as the local devices. When devices are part 217 of the same DNS domain, server-mode SLP or non-multicast DNS Service 218 Discovery (DNS-SD) [34] are possible solutions. Such protocols can 219 discover devices within a larger geographical area, and have the 220 advantage over the first category in that they allow for the 221 discovery of devices at different location granularities, such as at 222 the room or building level, and in locations other than the current 223 one. In order to discover devices in a specific location, location 224 attributes, such as room number, must be used in the search, e.g., as 225 service attributes in SLP or a domain name in DNS-SD). The mobile 226 device must ascertain its location in order to perform this search. 227 We note that many of these techniques could be difficult to implement 228 in practice. For example, different wireless networks may be 229 deployed by different organizations, which could make it unrealistic 230 to have a common DNS setup. 232 We describe here how SLP is used in server mode in general, then how 233 it may be used to discover devices based on their location. As 234 mentioned before, this is only one of many ways to perform service 235 discovery. SLP identifies services by a "service type," a "service 236 URL," which can be any URL, and a set of attributes, defined as name- 237 value pairs. The attributes may be information such as vendor, 238 supported media codecs and display resolution. SLP defines three 239 roles: Service Agents (SAs) which send descriptions of services, User 240 Agents (UAs) which query for services and Directory Agents (DAs) 241 which receive the registrations and queries. An SA registers a 242 service description to the DA with a service registration (SrvReg) 243 message that includes its service type, service URL and attribute- 244 value set. A UA queries for services by sending the service request 245 (SrvRqst) message, narrowing the query based on service type and 246 attribute values. It receives a reply (SrvRply) that contains a list 247 of URLs of services that match the query. It may then ascertain the 248 specific attributes of each service using an attribute request 249 (AttrRqst) message. 251 This document assumes the following use of SLP for discovering local 252 devices. Devices have a service type of "sip-device" and a SIP URI 253 as the service URI. Section 5.2 describes the form of this URI. 254 Attributes specify device characteristics such as vendor, supported 255 media codec, display resolution, as well as location coordinates, 256 such as street address and room number. SAs are co-located with SIP 257 UAs on session mobility enhanced devices, while a separate SA is 258 available to send SrvReg messages on behalf of basic devices, which 259 do not have integrated SLP SAs. 261 The Mobile Node includes an SLP UA that discovers available local 262 devices and displays them to the user, showing, for example, a map of 263 all devices in a building or a list of devices in a current room. 264 Once the MN receives its current location in some manner, its SLP UA 265 issues a SrvRqst message to the DA requesting all SIP devices, using 266 the location attributes to filter out those which are not in the 267 current room. A SrvRply message is sent to the mobile device with a 268 list of SIP URIs for all devices in the room. A separate Attribute 269 Request (AttrRqst) is then sent for each URL to get the attributes of 270 the service. The MN displays for the user the available devices in 271 the room, and their attributes. Figure 1 shows this protocol flow. 273 Device DA MN 274 |(1) SrvReg | | 275 |------------------------->| | 276 |(2) SrvRply | | 277 |<-------------------------| | 278 | | | 279 | | | 280 | |(3) SrvRqst | 281 | |<----------------------| 282 | |(4) SrvRply URL list | 283 | |---------------------->| 284 | |(5) AttrRqst URL1 | 285 | |<----------------------| 286 | |(6) AttrRply | 287 | |---------------------->| 288 | | ... | 289 | | | 291 Figure 1 SLP message flow for the device to register its service and 292 the MN to discover it, along with its attributes. 294 5. Session Mobility 296 5.1. Options for Session Mobility 298 5.1.1. Transfer and Retrieval 300 Session mobility involves both transfer and retrieval of an active 301 session. Transfer means to move the session on the current device to 302 one or more other devices. Retrieval means to cause a session 303 currently on another device to be transferred to the local device. 304 This may mean to return a session to the device on which it had 305 originally been before it was transferred to another device. For 306 example, after discovering a large video monitor, a user transfers 307 the video output stream to that device. When he walks away, he 308 returns the stream to his mobile device for continued communication. 309 One may also move a session to a device that had not previously 310 carried it. For example, a participant in an audio call on his 311 stationary phone may leave his office in the middle of the call and 312 transfer the call to the mobile device as he is running out the door. 314 5.1.2. Whole and Split Transfer 316 The set of session media may either be transferred completely to a 317 single device or split across multiple devices. For instance, a user 318 may only wish to transfer the video component of his session while 319 maintaining the audio component on his PDA. Alternatively, he may 320 find separate video and audio devices and wish to transfer one media 321 type to each. Furthermore, even the two directions of a full-duplex 322 session may be split across devices. For example, a PDA's display 323 may be too small for a good view of the other call participant, so 324 the user may transfer video output to a projector and continue to use 325 the PDA camera. 327 5.1.3. Transfer Modes 329 Two different modes are possible for session transfer, Mobile Node 330 Control (MNC) mode and Session Handoff (SH) mode. We describe them 331 below in turn. 333 5.1.3.1. Mobile Node Control (MNC) Mode 335 In Mobile Node Control mode, the Mobile Node uses third-party call 336 control [2]. It establishes a SIP session with each device used in 337 the transfer and updates its session with the CN, using the SDP 338 parameters to establish media sessions between the CN and each 339 device, which take the place of the current media session with the 340 CN. The shortcoming of this approach is that it requires the MN to 341 remain active to maintain the sessions. 343 5.1.3.2. Session Handoff (SH) Mode 345 A user may need to transfer a session completely because, for 346 example, the battery on his mobile device is running out or he is 347 losing radio connectivity. Alternatively, the user of a stationary 348 device who leaves the area and wishes to transfer the session to his 349 mobile device will not want the session to remain on the stationary 350 device when he is away, since it will allow others to easily tamper 351 with his call. In such case, session handoff mode, which completely 352 transfers the session signaling and media to another device, is 353 useful. 355 Based on our experiments, we have found MNC mode to be more 356 interoperable with existing devices used on the CN's side. The 357 remainder of this section describes the transfer, retrieval and 358 splitting of sessions in each of the two session transfer modes. 360 5.1.4. Types of Transferred Media 362 A communication session may consist of a number of media types, and a 363 user should be able to transfer any of them to his device of choice. 364 This document considers audio, video and messaging. Audio and video 365 are carried by RTP and negotiated in the SDP body of the SIP requests 366 and responses. Three different methods exist for carrying messaging 367 of text, and possibly other MIME types, that are suitable for SIP 368 endpoints. RTP may be used to transport text payloads in real time 369 based on [9]. Any examples given for audio and video will work 370 identically for text, as only the payloads differ. For the transfer 371 of entire messages (as opposed to a small number of characters in 372 RTP), either the SIP MESSAGE method [26] or the Message Session Relay 373 Protocol (MSRP) [7] may be used. MESSAGE is used to send individual 374 page-mode messages. The messages are not associated with a session, 375 and no negotiation is done to establish a session. Typically, a SIP 376 UA will allow the user to send MESSAGE requests during an established 377 dialog, and they are sent to the same contact address as all 378 signaling messages are sent in mid-session. We discuss later how 379 these messages are affected by session mobility. MSRP, on the other 380 hand, is based on sessions that are established like the real-time 381 media sessions previously described. As such, transferring them is 382 similar to transferring other media sessions. However, this document 383 will point out where special handling is necessary for these types of 384 sessions. 386 5.2. Addressing of Local Devices 388 As stated before, this document assumes both personal and public 389 devices. We assume that public devices use a dedicated Address of 390 Record (AOR), such as sip:device11@example.com. A personal device 391 already uses the owner's AOR so that he should be reachable there, 392 and that AOR could also be used for transferring sessions. However, 393 it is preferable to distinguish the role of a device as a transfer 394 target from its existing role. Therefore, all devices are assumed to 395 have dedicated AORs. 397 Since every transfer device has its own AOR, there is a one-to-one 398 mapping between AOR and device. Therefore, a transfer request could 399 be addressed to the AOR, which would resolve to the device. However, 400 in Section 5.4.3, we present a model where devices create multi- 401 device systems to pool their capabilities. Therefore, a single 402 device must be reachable with multiple URIs representing different 403 combinations of devices. The appropriate solution is to define each 404 with a Globally Routable UA URI (GRUU) [12]. 406 We therefore assume the following addressing for the remainder of the 407 document. As mentioned earlier, a device has a unique AOR. It 408 registers a separate contact URI for itself, and for each system of 409 devices that it controls. Each contact has an associated GRUU, which 410 is registered with SLP as the Service URI, and may be directly 411 addressed by another device in a request sent through the proxy. 412 When the proxy forwards the request to the device, it will replace 413 the GRUU with the contact URI, as described in [12]. Therefore, the 414 contact URI, not the associated GRUU, will be used by devices to 415 determine whether the request is for the device itself or for a 416 multi-device system. We assume that the public GRUU is used. 418 5.3. Mobile Node Control Mode 420 5.3.1. Transfering a Session to a Single Local Device 421 5.3.1.1. RTP Media 423 local device MN CN 424 |(1) INVITE no sdp | | 425 |<------------------------| | 426 |(2) 200 OK local params | | 427 |------------------------>| | 428 | |(3) INVITE local params | 429 | |------------------------>| 430 | RTP | | 431 |<..................................................| 432 | |(4) 200 OK CN params | 433 | |<------------------------| 434 | |(5) ACK | 435 | |------------------------>| 436 |(6) ACK CN params | | 437 |<------------------------| RTP | 438 |..................................................>| 439 | | | 440 | | | 442 Figure 2 Mobile Node Control mode flow for transfer to a single 443 device. 445 Figure 2 shows the message flow for transferring a session to a 446 single local device. It follows Third Party Call Control Flow I 447 specified in [2] which is recommended as long as the endpoints will 448 immediately answer. The MN sends a SIP INVITE request to the local 449 device used for the transfer, requesting that a new session be 450 established, but does not include an SDP body. The local device's 451 response contains an SDP body that includes the address and port it 452 will use for any media, as well as a list of codecs it supports for 453 each. The MN updates the session with the CN by sending an INVITE 454 request (re-INVITE) containing the local device's media parameters in 455 the SDP body, as follows: 457 v=0 458 c=IN IP4 av_device.example.com 459 m=audio 4400 RTP/AVP 0 8 460 a=rtpmap:0 PCMU/8000 461 a=rtpmap:8 PCMA/8000 462 m=video 5400 RTP/AVP 31 34 463 a=rtpmap:31 H261/90000 464 a=rtpmap:34 H263/90000 466 Sending both audio and video media lines will transfer both media 467 sessions of an existing audio/video call to the local device. 469 Alternatively, the MN may select a subset of the media available on 470 the local device, and use the local device's parameters for those 471 media in the request sent to the CN, while continuing to use its own 472 parameters for the rest of the media. For example, if it only wishes 473 to transfer an audio session to a local device that supports audio 474 and video, it will isolate the appropriate media line for audio from 475 the response received from the local device, putting it in the 476 request sent to the CN, along with its own video parameters. The CN 477 sends a response and includes, in its body, the media parameters that 478 it will use, which may or may not be the same as the ones used in the 479 existing session. The MN sends an ACK message to the local device, 480 which includes these parameters in the body. The MN has established 481 a session with the local device and maintained its session with the 482 CN, while the media flow has been established directly between the CN 483 and the local device. Only the MN, who is in an ongoing session with 484 the CN, will later be allowed to retrieve the media session. Parsing 485 of unknown SDP attributes by the controller is discussed in [2]. 487 5.3.1.2. MSRP Sessions 489 The message sequence for transferring an MSRP message session using 490 MNC mode is identical to that used for audio or video, in Figure 2, 491 although the contents of the messages differ. To simplify the 492 example, we assume that an MSRP session, with no other media, is 493 being transferred to a local messaging device, MSGN. In the 494 following flow, we refer to the corresponding messages in Figure 2. 495 An empty INVITE request (1) is sent to the local messaging node, 496 MSGN, as follows: 498 INVITE sip:msgn@example.com;gr=urn:uuid:jtr5623n SIP/2.0 499 To: 500 From: ;tag=786 501 Call-ID: 893rty@mn.example.com 502 Content-Type: application/sdp 504 The messaging node responds with all of its media capabilities, 505 including MSRP, as follows (2): 507 SIP/2.0 200 OK 508 To: ;tag=087js 509 From: ;tag=786 510 Call-ID: 893rty@mn.example.com 511 Content-Type: application/sdp 513 v=0 514 c=IN IP4 msgn.example.com 515 m=message 52000 msrp/tcp * 516 a=accept-types:text/plain 517 a=path:msrp://msgn.example.com:12000/kjhd37s2s2;tcp 518 m=audio 4400 RTP/AVP 0 8 519 a=rtpmap:0 PCMU/8000 520 a=rtpmap:8 PCMA/8000 521 m=video 5400 RTP/AVP 31 34 522 a=rtpmap:31 H261/90000 523 a=rtpmap:34 H263/90000 525 The same request is then sent by the MN to the CN (3), but containing 526 the MSRP media and attribute lines with the path given in the MSGN 527 response above. The CN responds (4) with its own path. The MN 528 includes this in the ACK that it sends to the MSGN (6). 530 MSRP sessions are carried over a reliable connection, using TCP or 531 TLS. Therefore, unlike in the case of real-time media, this 532 connection must be established. According to the MSRP 533 specifications, the initiator of a message session, known as the 534 "offerer", must be the active endpoint, and open the TCP connection 535 between them. In this transfer scenario, the offerer of both 536 sessions is the MN, who is on neither end of the desired TCP 537 connection. As such, neither end point will establish the 538 connection. A negotiation mechanism could be used to assign the role 539 of active endpoint during session setup. However, while MSRP leaves 540 open this possibility, it is not currently included due to 541 complexity. The only other way that such session transfer would be 542 possible is if both the CN and the local device ordinarily use an 543 MSRP relay [8], since no direct connection must be established 544 between them. When each new endpoint receives the INVITE request 545 from the MN, it will create a TLS connection with one of its 546 preconfigured relays if such a connection does not yet exist (the CN 547 will already have one because of its session with the MN) and receive 548 the path of the relay. In its response to the MN, it will include 549 the entire path that must be traversed to it, including its relay, in 550 the path attribute. For instance, the response from the MSGN will 551 look as follows: 553 SIP/2.0 200 OK 554 To: ;tag=087js 555 From: ;tag=786 556 Call-ID: 893rty@mn.example.com 557 Content-Type: application/sdp 559 v=0 560 c=IN IP4 msgn.example.com 561 m=message 52000 msrp/tcp * 562 a=accept-types:text/plain 563 a=path:msrp://relayA.example.com:12000/kjhd37s2s2;tcp \ 564 path:msrp://msgn.example.com:12000/kjhd37s2s2;tcp 566 Since the CN and the local device each establish a TLS connection 567 with their relay, as they would for any session, and the relays will 568 establish a connection between them when a subsequent MSRP message is 569 sent, neither party needs to establish any special connection. The 570 existing protocol may therefore be used for session transfer. 572 5.3.2. Transfer to Multiple Devices 574 In order to split the session across multiple devices, the MN 575 establishes a new session with each local device through a separate 576 INVITE request and updates the existing session with the CN with an 577 SDP body that combines appropriate media parameters it receives in 578 their responses. For instance, in order to transfer an audio and 579 video call to two devices, it initiates separate sessions with each 580 of them, combines the audio media line from one response and the 581 video line from the other, and sends them together as the request to 582 the CN, as follows: 584 v=0 585 m=audio 48400 RTP/AVP 0 586 c= IN IP4 audio_dev.example.com 587 a=rtpmap:0 PCMU/8000 588 m=video 58400 RTP/AVP 34 589 c= IN IP4 video_dev.example.com 590 a=rtpmap:34 H263/90000 592 The CN responds with its own parameters for audio and video. The MN 593 splits them and sends one to each local device in the ACK that 594 completes each session setup. 596 video_dev audio_dev MN CN 597 | |(1) INVITE no sdp | | 598 | |<-------------------| RTP Audio | 599 | |(2) 200 params | | 600 | |------------------->| | 601 | |(3) INVITE no sdp | | 602 |<---------------------------------------| | 603 | |(4) 200 params | | 604 |--------------------------------------->| | 605 | | |(5) INVITE a/v params| 606 | | |---------------------->| 607 | | RTP Audio | | 608 | RTP Video |<...........................................| 609 |<...............................................................| 610 | | |(6) 200 OK | 611 | | |<----------------------| 612 | | |(7) ACK | 613 | | |---------------------->| 614 | |(8) ACK CN audio | | 615 | |<-------------------| RTP Audio | 616 | |...........................................>| 617 | |(9) ACK CN video | | 618 |<---------------------------------------| RTP Video | 619 |...............................................................>| 620 | | | | 621 | | | | 623 Figure 3 Mobile Node Control mode flow for transfer to multiple 624 devices. 626 Splitting a full-duplex media service such as video across an input 627 and an output device, such as a camera and a video display, is a 628 simple extension of this approach. The signaling is identical to 629 that of Figure 3, with the audio and video devices replaced by a 630 video output and a video input device. The SDP, however, is slightly 631 different. The MN invites the local devices into two different 632 sessions, but does not include any SDP body. They each respond with 633 all of their available media. If they only support unidirectional 634 media, as is the case for a camera or devoted display device, they 635 will include the "sendonly" or "recvonly" attributes. Otherwise, the 636 MN will have to append the appropriate attribute to each one's media 637 line before sending the combined SDP body to the CN. That body will 638 look as follows: 640 m=video 50900 RTP/AVP 34 641 a=rtpmap:34 H263/90000 642 a=sendonly 643 c=IN IP4 camera.example.com 644 m=video 50800 RTP/AVP 34 645 a=rtpmap:34 H263/90000 646 a=recvonly 647 c=IN IP4 display.example.com 649 In updating an SDP session, according to Section 8 of [4], the i-th 650 media line in the new SDP corresponds to the i-th media line in the 651 previous SDP. In the above cases, if a media type is added during 652 the transfer, the media line(s) should follow the existing ones. 653 When an existing media is transferred to a different device, the 654 media line should appear in the same place that it did in the 655 previous SDP, as should the lines for all media that have not been 656 altered. When a duplex media stream is being split across an input 657 and output device, the stream corresponding to the input device 658 should appear in place of the duplex media stream. Since this new 659 stream is the one that will be received by the CN, including it in 660 place of the old one ensures that the CN views the new stream as a 661 replacement of the old one. The media line corresponding to the 662 output device must appear after all existing media lines. In the 663 last example, if the SDP had initially contained a video line 664 followed by an audio line, the updated SDP sent to the CN would look 665 as follows: 667 m=video 50900 RTP/AVP 34 668 a=rtpmap:34 H263/90000 669 a=sendonly 670 c=IN IP4 camera.example.com 671 m=audio 45000 RTP/AVP 0 672 a=rtpmap:0 PCMU/8000 673 m=video 50800 RTP/AVP 34 674 a=rtpmap:34 H263/90000 675 a=recvonly 676 c=IN IP4 display.example.com 678 During the course of the session, the CN may send a MESSAGE request 679 to the MN containing text conversation from the remote user. If the 680 mobile user wishes to have such messages displayed on a device other 681 than the MN, the request is simply forwarded to that device. The 682 forwarded message should be composed as though it were any other 683 message from the MN to the local device, and include the body of the 684 received message. The local device will send any MESSAGE request to 685 the MN, who will forward it to the CN. 687 5.3.3. Retrieval of a Session 689 The MN may later retrieve the session by sending an INVITE request to 690 the CN with its own media parameters, causing the media streams to 691 return. It then sends a BYE message to each local device to 692 terminate the session. 694 5.4. Session Handoff (SH) mode 696 5.4.1. Transfer to a Single Device 698 Session Handoff mode uses the SIP REFER method [3]. This message is 699 a request sent by a "referer" to a "referee," which "refers" it to 700 another URI, the "refer target," which may be a SIP URI to be 701 contacted with an INVITE or other request, or a non-SIP URI, such as 702 a web page. This URI is specified in the "Refer-To" header. The 703 "Referred-By" [5] header is used to give the referer's identity which 704 is sent to the refer target for authorization. Essential headers 705 from this message may also be encrypted and sent in the message body 706 as S/MIME to authenticate the REFER request. Figure 4 shows the flow 707 for transferring a session. 709 device15 MN CN 710 |(1) REFER | | 711 |<----------------------------| | 712 |(2) 202 Accepted | | 713 |---------------------------->| | 714 |(3) INVITE, Replaces | | 715 |-------------------------------------------------->| 716 | RTP | 717 |<..................................................| 718 |(4) 200 OK | | 719 |<--------------------------------------------------| 720 | RTP | 721 |..................................................>| 722 |(5) ACK | | 723 |-------------------------------------------------->| 724 |(6) NOTIFY | | 725 |---------------------------->| | 726 |(7) 200 OK | | 727 |<----------------------------| | 728 | |(6) BYE | 729 | |-------------------->| 730 | |(7) 200 OK | 731 | |<--------------------| 732 | | | 733 | | | 735 Figure 4 Session Handoff mode flow for transfer to a single device. 737 The MN sends the following REFER request (1) to a local device: 739 REFER sip:device15@example.com;gr=urn:uuid:qfnb443ccui SIP/2.0 740 To: 741 From: 742 Refer-To: 745 Referred-By: 747 [S/MIME authentication body] 749 This message refers the local device to invite the refer target, the 750 CN, into a session. The "audio" and "video" tokens in the Refer-To 751 URI are callee capabilities [10]. Here they are used to inform the 752 referee that it should initiate an audio and video session with the 753 CN. Also included in the URI is the "Replaces" header field, 754 specifying that a "Replaces" header field should be included with the 755 specified value in the subsequent INVITE request. The "Replaces" 756 header identifies an existing session that should be replaced by the 757 new session. Here, the local device will request that the CN 758 replaces its current session with the MN with the new session. 759 According to [6], the CN should only accept a request to replace a 760 session by certain authorized categories of users. One such type of 761 user is the current participant in the session. The MN may, 762 therefore, refer the local device to replace its current session with 763 the CN. However, it provides authentication by encrypting several 764 headers from the original REFER request in an S/MIME body that it 765 sends in the REFER. The local device sends this body to the CN. 766 This keeps a malicious user from indiscriminately replacing another 767 user's session. Once the local device receives the REFER request, it 768 sends an INVITE request to the CN, and a normal session setup ensues. 769 The CN then tears down its session with the MN. 771 Once the local device has established a session with the CN, it sends 772 a NOTIFY request to the MN, as specified in [3]. This NOTIFY 773 contains the "To" (including tag), "From" (including tag) and 774 "Call-ID" header fields from the established session to allow the MN 775 to subsequently retrieve the session, as described in Section 5.4.2. 777 Once a session is transferred, the destination for MESSAGE requests 778 moves automatically. Since a new session is established between the 779 CN and the local device, any subsequent MESSAGE requests will be sent 780 to that device. 782 The transfer flow described above for media sessions may also be used 783 to transfer an MSRP session. The local device will initiate an MSRP 784 session in message (4), along with the other sessions. The REFER 785 request (1) indicates that an MSRP session should be established 786 using callee capabilities in the "Refer-To" header field, as it does 787 for audio and video. Such a media field tag, "message" has already 788 been defined [11]. Once the local device receives the REFER request, 789 it initiates an MSRP session with the CN. As the initiator, it will 790 establish a TCP connection in order to carry the session, as 791 specified in [7] or will set up the session through its relay if 792 configured to do so. 794 5.4.2. Retrieval of a Session 796 device15 MN CN 797 |(1) REFER | | 798 |<----------------------------| | 799 |(2) 202 Accepted | | 800 |---------------------------->| | 801 |(3) REFER | | 802 |---------------------------->| | 803 |(4) 202 Accepted | | 804 |<----------------------------| | 805 | |(4) INVITE, Replaces | 806 | |-------------------->| 807 | | RTP | 808 | |<....................| 809 | |(5) 200 OK | 810 | |<--------------------| 811 | | RTP | 812 | |....................>| 813 | |(6) ACK | 814 | |-------------------->| 815 | (7) BYE | | 816 |<--------------------------------------------------| 817 | (8) 200 OK | | 818 |-------------------------------------------------->| 819 | | | 820 | | | 822 Figure 5 Session Handoff mode flow for session retrieval. 824 Figure 5 shows the flow for retrieval by the MN of a session 825 currently on a local device. In order to better motivate the message 826 flow, we start by describing the final INVITE (4) and work backwards. 827 In order for a device to retrieve a session in Session Handoff mode, 828 it must initiate a session with the CN that replaces the CN's 829 existing session. The following message is sent by the MN to the CN 830 (4): 832 INVITE sip:corresp@example.com;gr=urn:uuid:bbb6981 SIP/2.0 833 To: 834 From: 835 Replaces: 1@device15.example.com;to-tag=aaa;from-tag=bbb 836 Referred-By: 838 [S/MIME authentication body] 840 Since the user on the MN and the local device are different 841 identities, the MN needs to be referred by the local device and 842 include its URI in the "Referred-By" header, in addition to including 843 an S/MIME authentication body from the local device, in order to be 844 permitted to replace the session. Therefore, the MN must receive a 845 REFER request from the local device referring it to send this INVITE 846 request. The user could use the user interface of the local device 847 to send this REFER message. However, such an interface may not be 848 available. Also, the user may wish to execute the transfer while 849 running out of the office with mobile device in hand. In order for 850 the MN to prompt the REFER from the local device, it sends a "nested 851 REFER," [5] a REFER request for another REFER. In this case, the 852 second REFER is sent back to the Mobile Node. That REFER must 853 specify that the "Replaces" header be included in the subsequent 854 INVITE request. The REFER request from the local device to the MN 855 (3) is composed as follows: 857 REFER sip:bob@example.com;gr=urn:uuid:ytav223h67gb3 SIP/2.0 858 To: 859 From: 860 Refer-To: 863 Referred-By: 865 [S/MIME authentication body] 867 A header field is included in the "Refer-To" URI to specify the value 868 of the "Replaces" header in the target INVITE request. In order to 869 have this message sent to it, the MN must send the following REFER 870 request (1): 872 REFER sip:device15@example.com;gr=urn:uuid:qfnb443ccui SIP/2.0 873 To: 874 From: 875 Refer-To: 880 The "Refer-To" header specifies the MN as the refer target and that 881 the referral be in the form of a REFER request. The header field 882 specifies that the REFER request contains a "Refer-To" header 883 containing the URI of the CN. That URI, itself, contains the "audio" 884 and "video" callee capabilities that will tell the MN to initiate an 885 audio and video call, and a header field specifying that the ultimate 886 INVITE request contains a "Replaces" header. If the MN had 887 previously transferred the session to the local device, it would have 888 received these in the NOTIFY sent by the local device following the 889 establishment of the session. If, on the other hand, the MN is 890 retrieving a session it had not previously held, as mentioned above 891 in Section 5.1.1, it gets these parameters by subscribing to the 892 Dialog Event Package [13] of the local device. Such a subscription 893 would only be granted, for instance, to the owner of the original 894 device that carried the session. Even when these parameters are 895 provided in the "Replaces" header, the local device does not accept 896 the REFER request from anybody except for the original participant in 897 the session or the owner of the device. The MN receives the REFER 898 request from the local device, sends the INVITE request to the CN, 899 which accepts it and, once the session is established, terminates its 900 session with the local device. 902 5.4.3. Transfer to Multiple Devices 904 Splitting a session in SH mode requires multiple media sessions to be 905 established between the CN and local devices, without the MN 906 controlling the signaling. This could be done by sending multiple 907 REFER requests to the local devices, referring each to the CN. The 908 disadvantage of this method is that there is currently no standard 909 way to associate multiple sessions as part of a single call in SIP. 910 Therefore, each session between the CN and a local device will be 911 treated as a separate call. They may occupy different parts of the 912 user interface, their media may not be available simultaneously, and 913 they may have to be terminated separately. This certainly does not 914 fulfill the requirement of seamlessness. 916 This document describes the use of multi-device systems to overcome 917 this problem. A local device's SLP UA queries for other devices and 918 joins with them to create a "virtual device", or a Multi-Device 919 System (MDS). We refer to the controlling device as the Multi-Device 920 System Manager (MDSM). In a system that includes at least one 921 mobility-enhanced device, one of them may act as the MDSM. In a 922 system consisting entirely of basic devices, either a dedicated host 923 or another local device from outside of the system acts as MDSM. 924 When the MDSM subsequently receives a REFER request, it uses third- 925 party call control to set up media sessions between the CN and each 926 device in the system. Specifically, it invites each local device 927 into a separate session, and uses their media parameters (and 928 possibly its own) in the INVITE it sends to the CN. 930 A single device may act as an MDSM for several different groups of 931 devices, and also acts as an ordinary device with only its native 932 capabilities. There must be a way to address a request to a device 933 and specify whether it is to the device itself or one of the multi- 934 device systems it controls. As mentioned above in Section 5.2, a 935 device registers a separate contact for itself and for each of its 936 multi-device systems. For example, the device with AOR 937 "sip:device11@example.com" and hostname "device11.example.com" will 938 register a contact "sip:device11@device11.example.com" that 939 represents its own capabilities. Once it discovers other devices and 940 creates an MDS, it will register a new contact, 941 "sip:av1@device11.example.com". It associates a GRUU with each of 942 these contacts. The device itself and any new system is registered 943 in SLP using the GRUU. When the proxy receives a request addresses 944 to a GRUU, it will rewrite it as the contact URI before forwarding 945 the request to the device. The device will use this unique contact 946 to determine whether to handle the request natively or with one of 947 its systems. 949 Figure 6 shows the transfer of a session to a multi-device system. 950 The audio device has previously discovered the video device, and 951 created a multi-device system. The REFER request sent to 952 "sip:device11@example.com;gr=urn:uuid:893eeeyuinm981" prompts the 953 audio device to invite the video device into a session to ascertain 954 its SDP, and then to invite the CN into a session using its own SDP 955 and that of the video device. 957 video audio MN CN 958 | |(1) REFER | | 959 | |<--------------------| | 960 | |(2) 202 Trying | | 961 | (3) INVITE no sdp |-------------------->| | 962 |<---------------------| | | 963 | (4) 200 OK SDP | | | 964 |--------------------->| | | 965 | |(5) INVITE a/v SDP, Replaces | 966 | |--------------------------------->| 967 | | RTP Audio | 968 | |<.................................| 969 | | RTP Video | 970 |<........................................................| 971 | |(6) 200 OK CN SDP | 972 | |<---------------------------------| 973 | | RTP Audio | 974 | (7) ACK CN Video SDP |.................................>| 975 |<---------------------| | | 976 | RTP Video | | | 977 |........................................................>| 978 | |(8) ACK | | 979 | |--------------------------------->| 980 | | |(9) BYE | 981 | | |<-----------| 982 | | |(10) 200 OK | 983 | | |----------->| 984 | | | | 985 | | | | 987 Figure 6 Session handoff to a multi-device system. 989 5.5. Distributing Sessions for Incoming Call 991 The examples presented above have involved an established session 992 which a user transfers to one or more devices. Another scenario 993 would be for an incoming call to be immediately distributed between 994 multiple devices when the user accepts the call. In such a case, the 995 initial session would not yet be established when the transfer takes 996 place. 998 The transfer could be carried out in either of the transfer modes. 999 However, complete handoff to a separate device, which is done in 1000 Session Handoff mode, could be achieved through existing means, such 1001 as proxying or redirection. MNC mode would be useful in a case where 1002 the user wishes to automatically include an additional device in a 1003 call. For instance, a user with a desk IP phone and a PC with a 1004 video camera could join the two into a single logical device. The 1005 SIP UA on the PC would, for any incoming call, send an INVITE request 1006 to the desk phone, setting the display name in the From header field 1007 to "Bob Jones (audio portion)", for instance, so that the user can 1008 identify the caller on the phone. The user could then either accept 1009 or reject, as he would with a call coming directly to the phone. If 1010 he accepts, the PC UA, acting as the controller, would respond to the 1011 caller with its video parameters and the phone's audio parameters in 1012 the SDP body. The final ACK from the correspondent node would then 1013 complete the session establishment. 1015 If the desk phone is registered as a contact for the user, it would 1016 also ring in response to the direct call being proxied there, in 1017 addition to the INVITE request sent by the controller, causing 1018 confusion to the user. The use of caller preferences can solve this 1019 problem, as the caller would indicate that the call should 1020 preferentially be proxied to devices with audio and video 1021 capabilities. It is likely that the caller would use caller 1022 preferences in any case, if they were available to him, to avoid the 1023 callee unknowingly picking up the IP phone when he has a video- 1024 capable device available. However, since caller preferences are not 1025 yet widely supported on commercial devices, the callee must ensure 1026 the proper routing of the call. One solution would be for the PC to 1027 register its contact with a higher priority than the one given to the 1028 phone. The Call Processing Language (CPL) [27] (the "proxy" node) 1029 could then be used to specify that forking should be done to the set 1030 of user devices in sequence, rather than in parallel. Since all 1031 calls would first be sent to the PC as long as it were online, it 1032 would redirect any request that included only audio in its SDP. 1034 5.6. Use of ICE in Session Mobility 1036 Interactive Connectivity Establishment (ICE) [32] is a protocol for 1037 Network Address Translator (NAT) traversal that may be used with SIP. 1038 Rather than negotiating addresses and ports used for media sessions 1039 directly in SDP, a list of possible address/ports (candidates) is 1040 exchanged, and the Session Traversal Utilities for NAT (STUN) [33] 1041 protocol is used to check which pairs of candidates may be used. ICE 1042 could be used in the call flows described in this section. In MNC 1043 mode, the candidates would be sent by each local device to the MN, 1044 who would exchange them with the CN. Afterward, each device would 1045 perform checks with the CN to determine an appropriate candidate. In 1046 SH mode, where the local device establishes a session with the CN, 1047 ICE would work no differently than in the standard case. 1049 6. Reconciling Device Capability Differences 1051 Session mobility sometimes involves the transfer of a session between 1052 devices with different capabilities. For example, the codec being 1053 used in the current session may not be available on the new device. 1054 Furthermore, that device may not support any codec that is supported 1055 by the CN. In addition to codecs, devices may have different 1056 resolutions or bandwidth limitations which must be taken into account 1057 when carrying out session transfer. 1059 6.1. Codec Differences 1061 Before executing a session transfer, the device checks the 1062 capabilities of the CN and the new device. These may be found 1063 through either the SIP OPTIONS method, used in SIP to query a 1064 device's media capabilities, or may be included as SLP service 1065 attributes. Since the OPTIONS method is standard, it is suggested to 1066 be used to query the CN, while SLP is suggested to be used to get the 1067 media capabilities of local devices, since it is already being used 1068 for them. 1070 If the CN and the local device are found to have a common codec, the 1071 transfer flow will negotiate that this should become the codec used 1072 in the media session. In MNC Mode, the MN forwards the response from 1073 the local device to the CN who will choose from the available codecs 1074 one which it supports. In Session Handoff Mode, the MN sends a REFER 1075 request to the local device and allows it to negotiate a common codec 1076 with the CN during their session establishment. No special behavior 1077 of the MN is required. 1079 If the MN sees that a common codec does not exist, it executes the 1080 transfer through an intermediate transcoding service. Rather than 1081 establishing a direct media session between the CN and the local 1082 device, separate sessions are established between the transcoder and 1083 each of them, with the transcoder translating between the streams. 1084 The Mobile Node discovers available transcoders through some means, 1085 including SLP. 1087 Using transcoding services in SIP is defined in [19] using third- 1088 party call control. In MNC mode, the Mobile Node establishes one 1089 media session between the transcoder and the CN, and one between the 1090 transcoder and the local device. This differs from the normal 1091 transcoding case where one party establishes a media session between 1092 itself and the transcoder and one between the transcoder and the 1093 other party. The MN starts by sending an INVITE request to the local 1094 device with no body, and it receives in the response the list of 1095 codecs that the device can use. It then repeats this for the CN, and 1096 receives its available codecs. It chooses one codec from each side, 1097 along with the address and port of each device, and combines them in 1098 an INVITE request sent to the transcoder. The transcoder responds 1099 with the ports on which it will accept each stream. The appropriate 1100 port information is individually sent to the CN and local device. 1101 Once the three sessions have been established, two media sessions 1102 exist, and the transcoder translates between them. This flow is 1103 shown in Figure 7. 1105 AN Transcoder MN CN 1106 (codec A) (codec B) 1107 | |(1) INVITE no sdp | | 1108 |<---------------------------------------| | 1109 | |(2) 200 AN params | | 1110 |--------------------------------------->| | 1111 | | |(3) INVITE no sdp | 1112 | | |---------------------->| 1113 | | |(4) 200 OK CN params | 1114 | | |<----------------------| 1115 | |(5) INVITE AN, CN params | | 1116 | |<---------------------------| | 1117 | |(6) 200 OK TA, TB params | | 1118 | |<---------------------------| | 1119 | |(7) ACK | | 1120 | |<---------------------------| | 1121 | |(8) ACK TA params | | 1122 |<---------------------------------------| | 1123 | RTP | | | 1124 |..........>| | | 1125 | |...................................................>| 1126 | | | (9) ACK TB params | 1127 | | |---------------------->| 1128 | | | RTP | 1129 | RTP |<...................................................| 1130 |<..........| | | 1131 | | | | 1133 Figure 7 Transfer of a session in Mobile Node Control mode through a 1134 transcoder to translate between native codecs of CN and an audio 1135 device AN, where they share no common codec. 1137 In Session Handoff mode, the local device itself establishes a 1138 session with the CN through the transcoder. After receiving the 1139 REFER request, it uses the OPTIONS method to find the capabilities of 1140 the CN. It will then use a common codec, if available, in the 1141 session setup, or set up the transcoded session using third-party 1142 call control as in [19]. 1144 6.2. Display Resolution and Bandwidth Differences 1146 Other differences in device capabilities, such as display resolution 1147 and bandwidth limitations, are also suggested to be reconciled during 1148 transfer. For example, a mobile device, limited both in its display 1149 size and bandwidth, will likely be receiving the video stream from 1150 the other call participant at a low resolution and framerate. When 1151 the user transfers his video output to a large-screen display, he may 1152 start viewing much higher quality video at the higher native 1153 resolution of the display and at a higher framerate. 1155 Changing the image resolution and framerate requires no special 1156 handling by the MN. An SDP format is defined [20] for specifying 1157 these and other parameters for the H.263+ codec, for example. The 1158 suitable image formats and corresponding MPIs (Minimum Picture 1159 Interval, related to the framerate) supported for the given codec are 1160 listed following the media line, in order of preference. For 1161 example, the following lines in SDP would indicate that a device 1162 supports the H.263 codec (value 34) with the image sizes of 16CIF, 1163 4CIF, CIF and QCIF (with the MPI for each format following the "="): 1165 m=video 60300 RTP/AVP 34 1166 a=fmtp:34 16CIF=8;4CIF=6;CIF=4;QCIF=3 1168 In MNC mode, the response by the local device (Figure 2, message 1) 1169 to the initial INVITE request sent by the MN includes this line in 1170 the SDP body, and the MN then includes it in the INVITE request sent 1171 to the CN (3). In Session Handoff mode, the local device includes 1172 this parameter in the INVITE request sent to the CN (Figure 4, 1173 message 3) after receiving the REFER request. If the local device is 1174 not configured to include the supported image sizes during session 1175 establishment, the information could be made available through SLP. 1176 The MN then includes it in the INVITE request sent to the CN in 1177 mobile node control mode. However, this information is not sent in 1178 Session Handoff mode unless the local device was configured to send 1179 it. In both modes, the MN sends its own resolution and framerate 1180 preferences in the body of the INVITE request sent to retrieve the 1181 session. 1183 7. Simultaneous Session Transfer 1185 A session transfer may be carried out by one call participant after 1186 the other participant has transferred the session on his side. If 1187 the first transfer was done in MNC mode, a subset of the original 1188 session media is now on local devices. The MN receives either a re- 1189 INVITE from the other participant or an INVITE request from a local 1190 device on the other side. This message carries the new media 1191 parameters of the session. The MN, therefore, must send a re-INVITE 1192 to any local devices with these parameters. It then includes the 1193 parameters returned from these devices in the 200 OK response. If 1194 the first transfer was done in SH mode, the local device will 1195 directly receive the session transfer message from the other party 1196 and will follow the normal procedure for responding to an INVITE 1197 request. If it is controlling other local devices for this session 1198 as part of an MDS, it follows the procedure above where the first 1199 transfer was done in MNC mode. 1201 It may occur that both participants attempt a transfer at the same 1202 time. In MNC mode, each node initiates a session with a local 1203 device, then sends a re-INVITE to the other node. Section 14.2 in 1204 [1] mandates a 491 response when a re-INVITE is received for a dialog 1205 once another re-INVITE has already been sent. Once both parties 1206 receive this response, they each generate a random timer, with 1207 staggered intervals. Once its timer fires, each participant attempts 1208 the re-INVITE again. The first to receive it from the other 1209 participant responds to it with the SDP parameters of its local 1210 device. Both participants then send an ACK request to their local 1211 device containing the new parameters obtained from the other one 1212 during the re-INVITE process. 1214 In SH mode, if both participants attempt a transfer at the same time, 1215 after one node sends a REFER request to the local device, it receives 1216 the INVITE request from the local device on the other end. The 1217 appropriate protocol definition could mandate that a 491 response be 1218 sent in this case, as well. This response would be returned to the 1219 referrer in a NOTIFY indicating the status of the referred session 1220 establishment. The staggered timer solution described above could 1221 work. The MN would cancel the REFER request sent to the local 1222 device, then wait a random amount of time before sending it again. 1224 8. Session Termination 1226 Once a session has been transferred, the user may terminate it by 1227 hanging up the current device, as he would do in a call originating 1228 on that device. This should be true even when the session is using 1229 several local devices. In MNC mode, when the user hangs up the 1230 current device, a BYE request is sent to the controller. The 1231 controller must then send a BYE request to each device used in the 1232 transfer and a BYE request to the CN. A MDSM used for SH mode must 1233 follow the same procedure. In SH mode, the current device has 1234 previously initiated an ordinary session with the CN in response the 1235 the REFER request, and the BYE it sends to the CN on hang-up requires 1236 no special handling. 1238 9. Security Considerations 1240 As this work is based heavily on the work in [2], [3] and [5], the 1241 security considerations described in those documents apply. We 1242 discuss here the particular issues of authorizing use of local 1243 devices, providing media-level security following transfer and the 1244 issue of flooding attacks in MNC mode. 1246 9.1. Authorization for Using Local Devices 1248 It is neccessary that the use of a local device is limited to 1249 authorized parties. As stated earlier, this document assumes both 1250 personal and public devices, and these have different authorization 1251 policies. A personal device only accepts transfer requests from a 1252 single identity, the device owner. Therefore, the most appropriate 1253 means of access control is to maintain a list of identities 1254 representing the device owner who is authorized to transfer sessions 1255 to the device. As mentioned before, the device is configured with an 1256 AOR representing its status as a transfer device, in addition to the 1257 user's AOR. Only requests made to the device AOR follows the access 1258 list, while incoming requests to the user's AOR is accepted from 1259 anyone (provided that a white or blacklist or other policy does not 1260 preclude their request from being accepted). The SIP Identity header 1261 [30] is used to securely identify the initiator of a SIP request. 1262 That specification can be used in our use-cases when the local device 1263 must ensure that the INVITE or REFER request in MNC or SH mode, 1264 respectively, is indeed from the owner of the device. 1266 Public devices accept transfer requests from a large number of 1267 identities. Access lists may be used for this purpose. 1268 Alternatively, since devices are often available to categories of 1269 users, such as "manager" or "faculty member", an appropriate solution 1270 may be to use trait-based authorization [28]. Using this mechanism, 1271 a user may acquire from a trusted authorization service an 1272 "assertion" of his user status and permissions. The assertion, or a 1273 reference to it, is included in the request to use the device. 1275 9.2. Maintaining Media Security During Session Mobility 1277 9.2.1. Establishing Secure RTP using SDP 1279 Confidentiality, message authentication and replay protection are 1280 necessary in internet protocols, including those used for real-time 1281 multimedia communications. The Secure Real-time Transfer Protocol 1282 (SRTP) [14] provides these for RTP streams. Since SRTP may be used 1283 to carry the media sessions of SIP devices, such as the MN and CN, we 1284 discuss how to ensure that the session continues to use SRTP 1285 following the transfer to another device. This is also discussed in 1286 less detail in [2]. 1288 The establishment of secure RTP communications through SDP is defined 1289 by two documents. The "crypto" attribute [15], is a media-level 1290 attribute whose value includes the desired cryptographic suite and 1291 key parameters used to perform symmetric encryption on the RTP 1292 packets. Since the key information is sent in the SDP body with no 1293 dedicated encryption or integrity protection, a separate protocol 1294 such as S/MIME must be used to protect the signaling messages. 1295 Another document [16] specifies the "key-mgmt" attribute used to 1296 provide parameters for a key management protocol, such as MIKEY. 1297 Using this attribute, the two participants exchange keys encrypted by 1298 a public or shared key, or negotiate a key using the Diffie-Hellman 1299 method. 1301 The use of cryptographic parameters in SDP does not change the 1302 message flows described earlier in this document. For instance, in 1303 MNC mode shown in Figure 2, the response from the local device (2) 1304 will include, in addition to any supported media type, cryptographic 1305 information for each type. This cryptographic information will be a 1306 list of attribute lines describing crypto suite and key parameters 1307 using either of the two attributes mentioned. These lines will be 1308 sent by the MN to the CN in the subsequent request (3). The CN will 1309 choose a cryptographic method and return its own key information in 1310 the response (4). Maintaining a secure media session in SH mode 1311 requires the local device to negotiate a cryptographic relationship 1312 in the session that it establishes following its receipt of the REFER 1313 request. 1315 It is noted in [2] that establishing media security in Third Party 1316 Call Control depends on the cooperation of the controller. In this 1317 document, the Mobile Node (MN) in Mobile Node Control mode (MNC) has 1318 the role of controller in 3pcc, while in the Session Handoff mode 1319 (SH) mode, MN uses REFER method instead. The following is an excerpt 1320 from that document: 1322 End-to-end media security is based on the exchange of keying 1323 material within SDP. The proper operation of these mechanisms 1324 with third party call control depends on the controller behaving 1325 properly. So long as it is not attempting to explicitly disable 1326 these mechanisms, the protocols will properly operate between the 1327 participants, resulting in a secure media session that even the 1328 controller cannot eavesdrop or modify. Since third party call 1329 control is based on a model of trust between the users and the 1330 controller, it is reasonable to assume it is operating in a well- 1331 behaved manner. However, there is no cryptographic means that can 1332 prevent the controller from interfering with the initial exchanges 1333 of keying materials. As a result, it is trivially possibly for 1334 the controller to insert itself as an intermediary on the media 1335 exchange, if it should so desire. 1337 We note here that given the model presented in this document, where 1338 the controller is operated by the same person that uses the local 1339 device, i.e. the MN user, there is even more reason to believe that 1340 the controller will be well-behaved and will not interfere with the 1341 initial transfer of key exchanges. 1343 9.2.2. Securing Media Using the Transport Layer 1345 The exchange of media could alternatively be secured at the transport 1346 layer, using either TLS or Datagram Transport Layer Security (DTLS) 1347 [29]. The one consideration for use of these protocols in session 1348 mobility would be assigning the client and server roles. In SH mode, 1349 it may be assumed that the local device, the referee, would act as 1350 the client, since it is initiating the signaling session with the CN. 1351 However, in MNC mode, these roles would be unclear. The same problem 1352 was mentioned above in establishing a secure connection for an MSRP 1353 session transferred in MNC mode. This problem could be solved 1354 through the use of comedia [31], which specifies the "setup" SDP 1355 attribute to negotiate these roles. 1357 We describe here briefly how this is done. In the MNC exchange shown 1358 in Figure 2, the local device chooses to specify a media session over 1359 a secured transport in its response to the MN. If so, it includes 1360 under the media line a "setup" attribute set to either "active", 1361 "passive" or "actpass". This is sent on to the CN. Assuming it 1362 agreed to such a session, it responds with a "setup" attribute, as 1363 per the comedia specifications. This is then sent by the MN to the 1364 local device. If the local device and CN agreed on their roles, the 1365 appropriate session could be established through which the media 1366 would be transmitted. Before they transmit media between them, the 1367 CN and local device exchange messages to establish the TLS or DTLS 1368 session. This same approach could be used to establish an SRTP 1369 security context over DTLS, as per [36]. 1371 9.3. Flooding Attacks in MNC Mode 1373 The MNC call flows in this document, where one device instructs 1374 another device to send an RTP flow to a third one, present the 1375 possibility of a flooding attack. This is a general problem that 1376 relates to any use of 3PCC. In this document, it is only a concern 1377 where the device is public, as described at the beginning of this 1378 section, and a large group of people can transfer media to it, since 1379 there may not be a very strong trust relationship between the device 1380 owner (e.g. an institution) and the users. Obviously, where a device 1381 is private and only its owner can transfer to it, the concern does 1382 not exist, given the use of the Identity header mentioned earlier. A 1383 possible solution may be the use of ICE [32], since both sides 1384 confirm that they want to receive each other's media. 1386 10. IANA Considerations 1388 This document has no actions for IANA. 1390 11. Acknowledgments 1392 We would like to acknowledge the helpful comments made about this 1393 document by the SIP community, in particular Jon Peterson, Joerg Ott, 1394 and Cullen Jennings. 1396 12. Change History 1398 [[RFC Editor: Please remove this entire section upon publication as 1399 an RFC.]] 1401 12.1. Changes from draft-shacham-sipping-session-mobility-00 1402 o Discussed in 5.3.1 how MN receives To, From tags and Call-ID of 1403 transferred session, and in 5.3.2 how it receives these if it had 1404 not previously held the session. 1405 o Defined in subsection 5.1.4 the different media that may be 1406 transferred, introducing the three types of messaging 1407 o Specified in 5.2.2 and 5.3.2 how transfer flows apply to messaging 1408 using SIP MESSAGE and MSRP 1409 o Added subsection 5.4 on incoming call 1410 o Added section 7 on hangup behavior 1411 o Divided up subsection 8.1 to discuss disruption for transfer of 1412 continuous media (8.1.1) and MSRP sessions (8.1.2) 1413 o Added Section 9.3 about privacy concerns for output devices 1415 12.2. Changes from draft-shacham-sipping-session-mobility-01 1416 o Clarified in Section 5.2 how media lines must be arranged in a re- 1417 INVITE to the CN in MNC mode. 1418 o Discussed in the Security Considerations section how security 1419 settings are maintained after session transfer. 1420 o Added Section 7 on Simultaneous Session Transfer. 1422 12.3. Changes from draft-shacham-sipping-session-mobility-02 1423 o Discussed the use of the "key-mgmt" attribute in the Security 1424 Considerations section and made reference to the concern raised in 1425 3pcc RFC about media security establishment. 1427 o Removed sections on input and output devices in Security 1428 Considerations. 1429 o Removed section on performance. 1431 12.4. Changes from draft-shacham-sipping-session-mobility-03 1432 o Added section on addressing of local devices using GRUUs 1433 o Added section on ICE interoperation 1434 o Added security section on use of comedia 1436 12.5. Changes from draft-shacham-sipping-session-mobility-04 1437 o Revised abstract and introduction to reflect informational scope 1438 of this document 1439 o Revised document to limit the usage of must and should 1440 o Removed reference to 3GPP 1441 o Referenced DTLS SRTP 1442 o Referenced unknown SDP attributes in 3PCC 1443 o Added a note on limitations on usage of service discovery 1444 technologies 1445 o Added paragraph on flooding attack 1446 o Mentioned the use of Identity header in 9.1 1447 o Revised section 9.2.1 1449 13. References 1451 13.1. Normative References 1453 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1454 Sparks, R., Handley, A., and E. Schooler, "SIP: Session 1455 Initiation Protocol", RFC 3261, June 2002. 1457 [2] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1458 "Best Current Practices for Third Party Call Control (3pcc) in 1459 the Session Initiation Protocol (SIP)", RFC 3725, April 2004. 1461 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1462 Method", RFC 3515, April 2003. 1464 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1465 the Session Description Protocol (SDP)", RFC 3264, June 2002. 1467 [5] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By 1468 Mechanism", RFC 3892, September 2004. 1470 [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1471 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1473 [7] Campbell, B., Mahy, R., and C. Jennings, "The Message Session 1474 Relay Protocol," IETF Internet Draft (Work in Progress), 1475 February 2007. 1477 [8] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the 1478 Message Session Relay Protocol," IETF Internet Draft (Work in 1479 Progress), December 2006. 1481 [9] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793, 1482 May 2000. 1484 [10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1485 User Agent Capabilities in the Session Initiation Protocol 1486 (SIP)", RFC 3840, August 2004. 1488 [11] Camarillo, G., "Internet Assigned Number Authority (IANA) 1489 Registration of the Message Media Feature Tag Session 1490 Initiation Protocol (SIP)", RFC 4569, July 2006. 1492 [12] Rosenberg, J., "Obtaining and Using Globally Routable User 1493 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1494 (SIP)," IETF Internet Draft (Work in Progress), June 2007. 1496 13.2. Informative References 1498 [13] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1499 Initiated Dialog Event Package for the Session Initiation 1500 Protocol (SIP)", RFC 4235, November 2005. 1502 [14] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1503 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1504 RFC 3711, March 2004. 1506 [15] Andreasen, F., Baugher, M., and D. Wing, "Session Description 1507 Protocol (SDP) Security Descriptions for Media Streams", 1508 RFC 4568, July 2006. 1510 [16] Arkko, J., Lindhold, F., Naslund, M., Norrman, K., and E. 1511 Carrara, "Key Management Extensions for Session Description 1512 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 1513 RFC 4567, July 2006. 1515 [17] "3GPP: TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2), 1516 Release 5", September 2002. 1518 [18] Gutman, E., Perkins, C., Veizades, J., and M. Day, "Service 1519 Location Protocol, Version 2", RFC 2608, June 1999. 1521 [19] Camarillo, G., Burger, E., Schulzrinne, H., and A. Van Wijk, 1522 "Transcoding Services Invocation in the Session Initiation 1523 Protocol (SIP) Using Third Party Call Control (3pcc)", 1524 RFC 4117, June 2005. 1526 [20] Ott, J., Sullivan, G., Wenger, S., and R. Even, "RTP Payload 1527 Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)," 1528 IETF Internet Draft (Work in Progress), September 2005. 1530 [21] Peterson, J., "A Presence-based GEOPRIV Location Object 1531 Format", RFC 4119, December 2005. 1533 [22] "Global Positioning System Standard Positioning Service 1534 Specification, 2nd Edition", June 1995. 1536 [23] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility 1537 Using SIP, ACM Mobile Computing and Communications Review, 1538 Vol.4, No.3", July 2000. 1540 [24] Rosenberg, J., "A Presence Event Package for the Session 1541 Initiation Protocol (SIP)", RFC 3856, August 2004. 1543 [25] Peterson, J., "A Presence Architecture for the Distribution of 1544 GEOPRIV Location Objects", RFC 4079, July 2005. 1546 [26] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1547 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1548 Instant Messaging", RFC 3428, December 2002. 1550 [27] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1551 Language (CPL): A Language for User Control of Internet 1552 Telephony Services", RFC 3880, October 2004. 1554 [28] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, "Trait- 1555 Based Authorization Requirements for the Session Initiation 1556 Protocol (SIP)", RFC 4484, August 2006. 1558 [29] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1559 Security", RFC 4347, April 2006. 1561 [30] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1562 Identity Management in the Session Initiation Protocol (SIP)", 1563 RFC 4474, August 2006. 1565 [31] Yon, D. and G. Camarillo, "Trait-Based Authorization 1566 Requirements for the Session Initiation Protocol (SIP)", 1567 RFC 4145, September 2005. 1569 [32] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1570 Methodology for Network Address Translator (NAT) Traversal for 1571 Offer/Answer Protocols", March 2007. 1573 [33] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 1574 - Simple Traversal of User Datagram Protocol (UDP) Through 1575 Network Address Translators (NATs)", RFC 3489, March 2003. 1577 [34] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", 1578 IETF Internet Draft (Work in Progress), August 2006. 1580 [35] Cheshire, S. and M. Krochmal, "Multicast DNS", IETF Internet 1581 Draft (Work in Progress), August 2006. 1583 [36] Fischl, J. and H. Tschofenig, "Framework for Establishing an 1584 SRTP Security Context using DTLS", IETF Internet Draft (Work 1585 in Progress), November 2007. 1587 Authors' Addresses 1589 Ron Shacham 1590 Columbia University 1591 1214 Amsterdam Avenue, MC 0401 1592 New York, NY 10027 1593 USA 1595 Email: shacham@cs.columbia.edu 1597 Henning Schulzrinne 1598 Columbia University 1599 1214 Amsterdam Avenue, MC 0401 1600 New York, NY 10027 1601 USA 1603 Email: hgs@cs.columbia.edu 1605 Srisakul Thakolsri 1606 DoCoMo Communications Laboratories Europe 1607 Landsberger Str. 312 1608 Munich 80687 1609 Germany 1611 Email: thakolsri@docomolab-euro.com 1612 Wolfgang Kellerer 1613 DoCoMo Communications Laboratories Europe 1614 Landsberger Str. 312 1615 Munich 80687 1616 Germany 1618 Email: kellerer@docomolab-euro.com 1620 Full Copyright Statement 1622 Copyright (C) The IETF Trust (2007). 1624 This document is subject to the rights, licenses and restrictions 1625 contained in BCP 78, and except as set forth therein, the authors 1626 retain all their rights. 1628 This document and the information contained herein are provided on an 1629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1631 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1632 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1633 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1636 Intellectual Property 1638 The IETF takes no position regarding the validity or scope of any 1639 Intellectual Property Rights or other rights that might be claimed to 1640 pertain to the implementation or use of the technology described in 1641 this document or the extent to which any license under such rights 1642 might or might not be available; nor does it represent that it has 1643 made any independent effort to identify any such rights. Information 1644 on the procedures with respect to rights in RFC documents can be 1645 found in BCP 78 and BCP 79. 1647 Copies of IPR disclosures made to the IETF Secretariat and any 1648 assurances of licenses to be made available, or the result of an 1649 attempt made to obtain a general license or permission for the use of 1650 such proprietary rights by implementers or users of this 1651 specification can be obtained from the IETF on-line IPR repository at 1652 http://www.ietf.org/ipr. 1654 The IETF invites any interested party to bring to its attention any 1655 copyrights, patents or patent applications, or other proprietary 1656 rights that may cover technology that may be required to implement 1657 this standard. Please address the information to the IETF at 1658 ietf-ipr@ietf.org. 1660 Acknowledgment 1662 Funding for the RFC Editor function is provided by the IETF 1663 Administrative Support Activity (IASA).