RFC 5631
Session Initiation Protocol (SIP) Session Mobility
Session Initiation Protocol (SIP) Session Mobility 🎀
Okay bestie, this one is about moving a live call from one device to another, and it's giving main character energy ✨
- Network Working Group
- Request for Comments: 5631
- Category: Informational
- Authors: R. Shacham and H. Schulzrinne (Columbia University), S. Thakolsri and W. Kellerer (DoCoMo Euro-Labs)
- Date: October 2009
- Obsoletes: none. Updates: none. (The title block doesn't list either one, so this doc doesn't replace or change any older RFC 🫶)
Abstract ✨
Okay so session mobility is when you move the media from an ongoing call onto a different device, like sliding your video call from your phone onto the big screen 📺 This doc walks through the basic ways to pull that off and shows the signaling and media flow examples for doing it with the Session Initiation Protocol (SIP). Finding the right devices to transfer to is super important, so it also covers that, using the Service Location Protocol (SLP) as the example 🔍 It's an informational document.
Status of This Memo 💅
This memo gives info to the Internet community. It is not a standard of any kind, so don't treat it as one 🙈 You can distribute it freely, no restrictions.
Copyright and License Notice 📜
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, bestie, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the BSD License.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, 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. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🌍
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 ...................................331. Overview ✨
Okay so mobile devices keep getting better, with more advanced IP-based multimedia features, but they're still limited when it comes to bandwidth, display size, and computing power 📱 Stationary IP multimedia endpoints (think hardware IP phones, videoconferencing units, embedded devices, and software phones) are way more convenient to use, but they aren't mobile 🖥️ If you move an active multimedia session between these devices, mobile and stationary devices can be used together or swapped back and forth in the middle of a call. Their strengths combine into one "virtual device" 🦋
An approach to session mobility based on the Session Initiation Protocol (SIP) [1] was first described in [20]. That earlier work proposed two methods: third-party call control (3pcc) [2] and the REFER method [3].
This document builds on that idea and defines a framework for session mobility. It lets a Mobile Node discover the devices that are available and include them in an active session. The framework described here lays out basic approaches for using existing protocols, and it shows the signaling and media flow examples for providing session mobility using SIP. It is intended as an informational document 💜
The devices chosen as session transfer targets can be either personal or public. Personal devices are used by a single individual, like someone's PC or phone. Public devices are available for a large group of people to use, and they include big 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 their 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 require any particular protocol for device discovery. Lots of different protocols exist, and we talk through the tradeoffs of choosing between them 🤓 For our examples, we use the Service Location Protocol (SLP) [17], mainly because it is the only such protocol standardized by the IETF 👑
2. Requirements 🎯
This session mobility framework is set up to meet the following requirements:
- 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 that initiate 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 📷
- REQ 2: Flexibility - Differences in device capabilities should be reconciled. A transfer should be possible to devices that don't support the codec being used in the session, and even to devices that don't have a codec in common with the remote participant. A transfer should also take into account device differences in display resolution and bandwidth 🌈
- 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 🫧
3. Roles of Entities 🧚
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 it can be located anywhere. It may be a SIP User Agent (UA), or a Public Switched Telephone Network (PSTN) phone that you reach through a gateway ☎️
The Mobile Node (MN) is a mobile device. It has a SIP UA for standard SIP call setup, plus specialized SIP-handling capabilities for session mobility. It also has 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 their 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 handling session mobility. 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. Section 4 goes into more detail about how SLP is used 🗂️ When necessary, SIP-based transcoding services [18] are used to translate between media streams, as described in Section 6 🔄
Part 1 of 8 done, bestie! Section 4 and everything after it is still coming up next 💖
4. Device Discovery ✨
okay so the Mobile Node (MN) has to be able to find suitable devices around it 📱💖 that part is literally outside SIP's job, so a separate service location protocol is needed. defining that protocol isn't this document's problem 🙅♀️ this section just goes over a few options and digs into one of them 🦋
ngl a global discovery system that works in any location would be iconic, but nothing like that is deployed or standardized yet 😭 so this doc assumes you don't need one for devices that are close by, like in the same room 🌸 those can be found by talking directly over a short-range wireless protocol, such as the Bluetooth Session Description Protocol (SDP) 📡
there are two other categories, and they assume the nearby devices are on the same network and/or in the same DNS domain 🧚 first up, multicast-based protocols like SLP [17] (in serverless mode) or Bonjour (mDNS-SD [30]). these work as long as the MN is on the same subnet as the local devices 💜 second, when devices share a DNS domain, you can use server-mode SLP or non-multicast DNS Service Discovery (DNS-SD) [29] 🎀 these can find devices across a bigger area, and they beat the first category because they can search at different location granularities, like the room or the whole building, and even somewhere that isn't where you currently are 🏢✨
to search a specific location, you have to use location attributes, like a room number 🚪 that means service attributes in SLP, or a domain name in DNS-SD. the mobile device has to figure out where it is first so it can run that search 📍
real talk though, a lot of these techniques could be hard to pull off in practice 💀 different wireless networks can belong to different organizations, so having one common DNS setup might be totally unrealistic 🙈
here's how SLP works in server mode in general, and then how it can find devices by location 🫶 again, this is just one of many ways to do service discovery 💅 SLP identifies services with a "service type", a "service URL" (which can be any URL), and a set of attributes that are name-value pairs 🌈 attributes can be stuff like vendor, supported media codecs, and display resolution ✨
SLP has three roles 👑:
- Service Agents (SAs) send descriptions of services.
- User Agents (UAs) query for services.
- Directory Agents (DAs) receive the registrations and the queries.
an SA registers a service description with a DA using a service registration (SrvReg) message that includes its service type, service URL, and attribute-value set 📝 a UA asks for services by sending a service request (SrvRqst) message, and it narrows the search using service type and attribute values 🔍 then it gets back a reply (SrvRply) with a list of URLs for services that match 🧁 after that, it can check each service's specific attributes with an attribute request (AttrRqst) message 💖
this document assumes this SLP setup for finding 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 🦋 the attributes describe device stuff like vendor, supported media codec, display resolution, and also location coordinates, such as street address and room number 📍 SAs live right alongside SIP UAs on session-mobility enhanced devices 🌟 but basic devices don't have an SLP SA built in, so a separate SA is there to send SrvReg messages for them 🫧
the MN has an SLP UA that finds the local devices and shows them to the user 🗺️ it could show a map of every device in a building or just a list of devices in the current room 🍓 once the MN gets its location somehow, its SLP UA sends a SrvRqst to the DA asking for all SIP devices, and it uses the location attributes to filter out anything that isn't in the current room 🚪 the DA sends back a SrvRply with a list of SIP URIs for all the devices in the room ⭐ then a separate attribute request (AttrRqst) goes out for each URL to get that service's attributes 🎀 the MN shows the user the available devices in the room along with their attributes 💅 here's the protocol flow in Figure 1 👇
Device DA MN
|(1) SrvReg | |
|------------------------->| |
|(2) SrvRply | |
|<-------------------------| |
| | |
| | |
| |(3) SrvRqst |
| |<----------------------|
| |(4) SrvRply URL list |
| |---------------------->|
| |(5) AttrRqst URL1 |
| |<----------------------|
| |(6) AttrRply |
| |---------------------->|
| | ... |
| | |
Figure 1. SLP message flow for the device to register its service
and the MN to discover it, along with its attributes.5. Session Mobility 🦋
5.1. Options for Session Mobility 💖
5.1.1. Transfer and Retrieval 🌸
okay so session mobility is about both transfer and retrieval of an active session 🔄 a transfer means moving the session off the current device onto one or more other devices 📲 a retrieval means pulling a session that's on another device over to the local device 🫶 that can mean sending it back to the device it originally came from before it was transferred away 🔙 for example, a user finds a big video monitor and transfers the video output stream to it 📺 when he walks away, he retrieves the stream back to his mobile device so he can keep communicating 🏃♂️✨ you can also move a session to a device that never carried it before 🌈 like, a person on an audio call on his desk phone can leave his office mid-call and transfer it to his mobile device while he's running out the door 🚪💨
5.1.2. Whole and Split Transfer 🍓
the session's media can move completely to one device, or it can be split across several 👑 like, a user might only want to transfer the video part and keep the audio on his PDA 🎧 or he might find separate video and audio devices and send one media type to each 📺🔊 even the two directions of a full-duplex session can be split across devices 💅 for example, a PDA's screen might be too tiny to see the other call participant well, so the user sends the video output to a projector and keeps using the PDA camera 📽️💜
5.1.3. Transfer Modes 🧚
there are two different modes for session transfer: Mobile Node Control (MNC) mode and Session Handoff (SH) mode 🎀 we'll go through both of them in a sec 💖
5.1.3.1. Mobile Node Control (MNC) Mode 🦋
in Mobile Node Control mode, the MN uses third-party call control [2] 📞 it sets up a SIP session with each device used in the transfer, and it updates its session with the CN, using the SDP parameters to set up media sessions between the CN and each device ✨ those media sessions take the place of the current media sessions with the CN 🔁 the downside is that the MN has to stay active to keep the sessions going 😬
5.1.3.2. Session Handoff (SH) Mode 🌷
sometimes a user needs to transfer a session completely, like when the battery on his mobile device is about to die or he's losing radio connectivity 🔋💀 another situation: the user of a stationary device leaves the area and wants to move the session to his mobile device 🏃♂️ he won't want the session to stay on the stationary device while he's away, since that lets other people easily mess with his call 🙈 Session Handoff mode fully transfers the session signaling and media to another device, so it's perfect for these cases 🫶
based on experiments, MNC mode turned out to be more interoperable with existing devices on the CN's side 🎉 the rest of this section covers how sessions get transferred, retrieved, and split in each of the two session transfer modes 💅
5.1.4. Types of Transferred Media 🌈
a communication session can have a bunch of different media types, and a user should be able to send any of them to the device they want 💖 this document looks at audio, video, and messaging ✨ audio and video are carried by RTP and negotiated in the SDP body of the SIP requests and responses 🎵 there are three different ways to carry text messages (and maybe other MIME types) that work well for SIP endpoints 📝 RTP can carry text payloads in real time, based on [9] ⏱️ the examples given for audio and video work the same for text, since only the payloads are different 🔁 for transferring whole messages (instead of just a few characters over RTP), you can use either the SIP MESSAGE method [21] or the Message Session Relay Protocol (MSRP) [7] 💌 MESSAGE is for sending individual page-mode messages 📩 those messages aren't tied to a session, and there's no negotiation to set one up 🙅♀️ usually, a SIP UA lets the user send MESSAGE requests during an established dialog, and they go to the same contact address that all signaling messages go to during the mid-session 📮 we'll talk later about how these messages get affected by session mobility 🦋 MSRP, on the other hand, is based on sessions that get set up just like the real-time media sessions we already covered 🫧 so transferring them is pretty similar to transferring other media sessions 💜 this document will still point out where these types of sessions need special handling 👑 ✨
5.2. Addressing of Local Devices
okay so, quick vibe check 💅 this doc assumes both personal devices and public ones 🌸. public devices get a dedicated Address of Record (AOR), like sip:device11@example.com 🎀. a personal device already uses its owner's AOR, so the owner should be reachable there 🫶. that AOR could also be used for transferring sessions, but it's preferable to keep a device's role as a transfer target separate from its existing role ✨. so every device is assumed to have its own dedicated AOR 🦋.
since every transfer device has its own AOR, it's a one-to-one mapping between AOR and device 💖. a transfer request could be addressed to the AOR, and that would resolve to the device. BUT (plot twist 🙈) in Section 5.4.3 we get a model where devices team up into multi-device systems to pool their capabilities 👑. so one device has to be reachable by multiple URIs, each representing a different combination of devices. the appropriate solution is to give each combination its own Globally Routable UA URI (GRUU) [12] 💅.
okay, so here's the addressing we're rolling with for the rest of the doc 🧚. like I said, 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 it can be directly addressed by another device in a request sent through the proxy ✨. when the proxy forwards the request to the device, it replaces the GRUU with the contact URI, as described in [12] 🔥. so the contact URI, not the associated GRUU, is what devices use to figure out whether a request is for the device itself or for a multi-device system 🧠. we assume the public GRUU is used 🌈.
5.3. Mobile Node Control Mode
5.3.1. Transferring a Session to a Single Local Device
5.3.1.1. RTP Media
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. 🎬
okay, 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, asking for a new session to be established, but it does not include an SDP body 🙈. the local device's response contains an SDP body with the address and port it will use for any media, plus a list of codecs it supports for each. then the MN updates the session with the CN by sending an INVITE request (re-INVITE) with the local device's media parameters in the SDP body, like this:
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/90000sending both audio and video media lines transfers both media sessions of an existing audio/video call to the local device 🎀. but wait, there's more ✨: the MN may pick a subset of the media available on the local device, use the local device's parameters for those media in the request to the CN, and keep using its own parameters for the rest. for example, if it only wants to transfer an audio session to a local device that supports audio and video, it isolates the audio media line from the local device's response and puts it in the request to the CN, along with its own video parameters 🧁. the CN sends a response that includes, in its body, the media parameters it will use, which may or may not match the ones from the existing session. the MN then sends an ACK to the local device with these parameters in the body 🫶. the MN establishes a session with the local device and keeps its session with the CN, while the media flow is set up directly between the CN and the local device 🔥. only the MN, who is in an ongoing session with the CN, will later be allowed to retrieve the media session 👑. and parsing of unknown SDP attributes by the controller is discussed in [2] 📚.
5.3.1.2. MSRP Sessions
okay, so in figure 2, the message sequence for transferring an MSRP message session using MNC mode is identical to the one for audio or video 🌈, even though the message contents are different 💅. to keep things simple, we assume an MSRP session with no other media is being transferred to a local messaging node, MSGN 🧚. we'll refer to the matching messages in Figure 2 as we go. first, an empty INVITE request (1) goes to the local messaging node, 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/sdpthe messaging node replies with all of its media capabilities, including MSRP (2) 🍓:
SIP/2.0 200 OK
To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n;tag=087js>;tag=087js
From: <sip:bob@example.com>;tag=786
Call-ID: 893rty@mn.example.com
Content-Type: application/sdp
v=0
c=IN IP4 msgn.example.com
m=message 52000 msrp/tcp *
a=accept-types:text/plain
a=path:msrp://msgn.example.com:12000/kjhd37s2s2;tcp
m=audio 4400 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
m=video 5400 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000then the MN sends the same request to the CN (3) 🦋, but this time with the MSRP media and attribute lines containing the path from the MSGN response above. the CN responds (4) with its own path 💜, and the MN puts that in the ACK it sends to the MSGN (6) ✨.
ngl, this is where it gets spicy 🌶️. MSRP sessions run over a reliable connection, using TCP or TLS (Transport Layer Security) 🔒. so, unlike 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 😭. so neither endpoint will establish the connection. a negotiation mechanism could assign the role of active endpoint during session setup 🧠. however, while MSRP leaves that possibility open, it's not currently included in this document due to complexity. the only other way this session transfer would work 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 creates a TLS connection with one of its preconfigured relays if one doesn't already exist (the CN already has one because of its session with the MN), and receives the path of the relay 🧚. in its response to the MN, it includes the entire path that must be traversed, including its relay, in the path attribute. for instance, the response from the MSGN looks like this:
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;tcpand here's the best part 👑: since the CN and the local device each set up a TLS connection with their relay, the same way they would for any session, and the relays connect to each other when a later MSRP message is sent, neither party needs to set up any special connection 🎉. the existing protocol can be used for session transfer as-is 🫶🌸
5.3.2. Transfer to Multiple Devices ✨
okay so if the session needs to be split across multiple devices, the MN sets up a brand-new session with each local device using its own separate INVITE request. Then it updates the existing session with the CN, using an SDP body that mixes the right media parameters it got back in those responses. 🎀 For example, say you want to move an audio and video call onto two devices. The MN starts separate sessions with each one, grabs the audio media line from one response and the video media line from the other, and bundles them together into the request to the CN, like this:
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/90000The CN replies with its own audio and video parameters 💅. Then the MN splits those up and sends one piece to each local device, inside the ACK that wraps up each session setup. 🦋
video_dev audio_dev MN CN
| |(1) INVITE no sdp | |
| |<-------------------| RTP Audio |
| |(2) 200 params | |
| |------------------->| |
| |(3) INVITE no sdp | |
|<---------------------------------------| |
| |(4) 200 params | |
|--------------------------------------->| |
| | |(5) INVITE a/v params|
| | |---------------------->|
| | RTP Audio | |
| RTP Video |<...........................................|
|<...............................................................|
| | |(6) 200 OK |
| | |<----------------------|
| | |(7) ACK |
| | |---------------------->|
| |(8) ACK CN audio | |
| |<-------------------| RTP Audio |
| |...........................................>|
| |(9) ACK CN video | |
|<---------------------------------------| RTP Video |
|...............................................................>|
| | | |
| | | |Figure 3. Mobile Node Control mode flow for transfer to multiple devices.
Splitting a full-duplex media service, like video, across an input device and an output device (think a camera and a video display) is basically the same trick, just extended 🌈. The signaling looks exactly like Figure 3, except the audio and video devices get swapped out for a video output device and a video input device. The SDP is where things change a little. The MN invites the local devices into two different sessions, but it doesn't put any SDP body in those INVITEs. Each device then answers with all of its available media. If a device only does one direction, like a camera or a display-only device, it'll include the "sendonly" or "recvonly" attributes. Otherwise, the MN has to tack the right attribute onto each device's media line before it sends the combined SDP body to the CN. That body ends up looking like this:
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.comOkay, ordering matters here, bestie 🙈. When an SDP session gets updated (this is covered in Section 8 of [4]), the i-th media line in the new SDP lines up with the i-th media line in the previous one. So if a new media type gets added during the transfer, its media line(s) should go after the existing ones. If an existing media stream gets moved to a different device, its media line should stay in the exact same spot it had in the previous SDP, and so should every line for media that didn't change. When a duplex stream gets split across an input and an output device, the stream for the input device should take the place of the original duplex stream. The CN is going to receive that new stream, so putting it in the old stream's spot makes sure the CN sees it as a replacement for the old one 🫶. The media line for the output device has to come after all the existing media lines. In the example above, if the original SDP had a video line followed by an audio line, the updated SDP that goes to the CN would look like this:
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.comHere's another fun one 🧚. While the session is going, the CN might send a MESSAGE request to the MN with a text conversation from the remote user. If the mobile user wants those messages shown on some device other than the MN, the request just gets forwarded to that device. The forwarded message should be built as though it were any other message from the MN to the local device, and it should include the body of the message that was received. Whatever MESSAGE requests the local device sends go to the MN first, and then the MN forwards them to the CN.
5.3.3. Retrieval of a Session 🌸
The MN can take the session back later on. It does that by sending an INVITE request to the CN that carries its own media parameters, and that makes the media streams come back. After that, it sends a BYE message to each local device to end the session on their end. 💜
5.4. Session Handoff (SH) mode 🦋
5.4.1. Transferring a Session to a Single Local Device 💖
Session Handoff mode uses the SIP REFER method [3]. Basically, a REFER is a request sent by a "referrer" to a "referee", and it tells the referee to "refer" to another URI, called the "refer target". That target can be a SIP URI that gets contacted with an INVITE or some other request, or it can be a non-SIP URI, like a web page 👑. The URI shows up in the Refer-To header. The Referred-By [5] header carries the referrer's identity, and that identity gets sent to the refer target so it can decide whether to authorize the request. Essential headers from this message can also get encrypted and put in the message body as Secure/Multipurpose Internet Mail Extensions (S/MIME), which authenticates the REFER request. Figure 4 shows what the flow looks like when a session gets transferred.
device15 MN CN
|(1) REFER | |
|<----------------------------| |
|(2) 202 Accepted | |
|---------------------------->| |
|(3) INVITE, Replaces | |
|-------------------------------------------------->|
| RTP |
|<..................................................|
|(4) 200 OK | |
|<--------------------------------------------------|
| RTP |
|..................................................>|
|(5) ACK | |
|-------------------------------------------------->|
| |(6) BYE |
| |<--------------------|
| |(7) 200 OK |
| |-------------------->|
|(8) NOTIFY | |
|---------------------------->| |
|(9) 200 OK | |
|<----------------------------| |
| | |
| | |Figure 4. Session Handoff mode flow for transfer to a single device.
The MN sends this REFER request (1) to a local device:
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]This message basically tells the local device to invite the refer target, which is the CN, into a session. The "audio" and "video" tokens in the Refer-To URI are callee capabilities [10]. In this case they tell the referee to start an audio and video session with the CN ✨. The Refer-To URI also includes a Replaces header field, which says that a Replaces header field with the specified value should be included in the later INVITE request. The Replaces header identifies an existing session that the new session should take over. So here, the local device will ask the CN to replace its current session with the MN with the new one 🔥.
Now, according to [6], the CN should only accept a request to replace a session from certain authorized categories of users. One of those categories is the current participant in the session. That means the MN can refer the local device to replace its current session with the CN. But there's a catch, and it's a good one 😭: the MN backs this up with authentication by encrypting several headers from the original REFER request into an S/MIME body that it sends along in the REFER. The local device passes that body on to the CN. This keeps a malicious user from replacing someone else's session willy-nilly 🛡️. Once the local device gets the REFER request, it sends an INVITE request to the CN, and then a normal session setup happens. After that, the CN tears down its session with the MN.
Once the local device has a session established with the CN, it sends a NOTIFY request to the MN, as specified in [3]. This NOTIFY carries the To (including tag), From (including tag), and Call-ID header fields from the established session. That way, the MN has what it needs to retrieve the session later, as described in Section 5.4.2 💜.
Also, once a session is transferred, the destination for MESSAGE requests moves over automatically 🌈. Because a new session now exists between the CN and the local device, any MESSAGE requests from then on go straight to that device.
The transfer flow above for media sessions can also be used to transfer an MSRP session. The local device starts an MSRP session in message (4), right alongside the other sessions. The REFER request (1) says that an MSRP session should be set up, using callee capabilities in the Refer-To header field, the same way it does for audio and video. That media feature tag, "message", has already been defined [11]. Once the local device gets the REFER request, it starts an MSRP session with the CN. As the initiator, it'll establish a TCP connection to carry the session (as specified in [7]), or it'll set up the session through its relay if it's configured to do that 🦋.
5.4.2. Retrieval of a Session ✨
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.
okay so this one is giving retrieval 🎀. Figure 5 shows the flow for when the MN grabs a session that's currently sitting on a local device 💅. To make the message flow make sense, we start at the final INVITE (5) and work our way backwards 🔙. So here's the deal: for a device to retrieve a session in Session Handoff mode, it has to start a session with the CN that replaces the CN's existing session 🦋. The MN sends this INVITE to the CN (5):
INVITE sip:corresp@example.com;gr=urn:uuid:bbb6981 SIP/2.0
To: <sip:corresp@example.com;gr=urn:uuid:bbb6981>
From: <sip:bob@example.com>
Replaces: 1@device15.example.com;to-tag=aaa;from-tag=bbb
Referred-By: <sip:device15@example.com>
[S/MIME authentication body]Why the drama? The users on the MN and the local device are different identities 🙈, so the MN needs to be referred by the local device. That means it has to include its URI in the Referred-By header AND carry an S/MIME authentication body from the local device. Only then is it allowed to replace the session 🔐. So the MN must get a REFER request from the local device telling it to send this INVITE. The user could just tap around on the local device's interface to send that REFER, but honestly, that interface might not even be available 😭. Plus, the user might wanna do the whole transfer while running out of the office with their phone in hand 🏃♀️. So to get the local device to send that REFER, the MN sends a "nested REFER" [5], which is a REFER for another REFER 🪆. In this case, the second REFER gets sent back to the Mobile Node. That REFER has to specify that the Replaces header be included in the INVITE request that comes after it. The REFER request from the local device to the MN (3) is put together like this:
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]A header field gets included in the Refer-To URI to set the value of the Replaces header in the target INVITE request 🧩. For this message to actually get sent to the MN, the MN has to send the following REFER request (1):
REFER sip:device15@example.com;gr=urn:uuid:qfnb443ccui SIP/2.0
To: <sip:device15@example.com;gr=urn:uuid:qfnb443ccui>
From: <sip:bob@example.com>
Refer-To:<sip:bob@example.com;gr=urn:uuid:ytav223h67gb3;method=REFER
?Refer-To="<sip:correspondent@example.com;gr=urn:uuid:bbb6981;
audio;video?Replaces=%221@device15.example.com;
to-tag=aaa;from-tag=bbb%221>">The Refer-To header says the MN is the refer target and that the referral has to take the form of a REFER request 🎯. That header field says the REFER request carries a Refer-To header holding the CN's URI. And that URI has the "audio" and "video" callee capabilities, which tell the MN to start an audio and video call 📞📹. It also has a header field saying the final INVITE request carries a Replaces header 💅. If the MN had already handed the session off to the local device, it would have gotten all of this from the NOTIFY the local device sent after the session was set up 🔔. But if the MN is retrieving a session it never held before, like we mentioned back in Section 5.1.1, then it gets these parameters by subscribing to the Dialog Event Package [13] on the local device 🧾. And honestly? That subscription only gets granted to the owner of the original device that carried the session 👑. Even when these parameters show up in the Replaces header, the local device won't accept a REFER request from just anybody. Only the original participant in the session or the owner of the device gets through 🚫. So the MN gets the REFER from the local device, sends the INVITE to the CN, the CN accepts it, and once the session is up, the MN wraps up its session with the local device ✨. Slay, the handoff is complete 🥹.
5.4.3. Transfer to Multiple Devices 🌈
Splitting a session in SH mode needs multiple media sessions set up between the CN and the local devices, and the MN doesn't control the signaling for any of it 🫠. One way to do this is to send several REFER requests to the local devices, each one referring to the CN. The downside? There's currently no standard way in SIP to link multiple sessions together as one call 💀. So each session between the CN and a local device gets treated as its own separate call. They might show up in different parts of the user interface, their media might not be available at the same time, and they might have to be ended one by one. Honestly, that does not fulfill the requirement of seamlessness 😤.
This document describes how multi-device systems fix that problem 🙌. A local device's SLP UA goes looking for other devices and teams up with them to make a "virtual device", which is a Multi-Device System (MDS) 🧚. We call the device in charge the Multi-Device System Manager (MDSM) 👑. In a system with at least one mobility-enhanced device, one of them can act as the MDSM. In a system made up entirely of basic devices, either a dedicated host or another local device from outside the system acts as the MDSM 🖥️. When the MDSM gets 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 its own separate session, and then uses their media parameters (and maybe its own too) in the INVITE request it sends to the CN 🎀.
A single device can act as an MDSM for several different groups of devices, and it can also act as an ordinary device with only its native capabilities 🦋. So there has to be a way to address a request either to the device itself or to one of the multi-device systems it controls 🔍. As mentioned above in Section 5.2, a device registers a separate contact for itself and for each of its multi-device systems 📇. For example, the device with AOR "sip:device11@example.com" and hostname "device11.example.com" registers a contact "sip:device11@device11.example.com" that represents its own capabilities 💜. Once it finds other devices and creates an MDS, it registers a new contact, "sip:av1@device11.example.com" 🆕. It associates a GRUU with each of these contacts 🏷️. The device itself and any new system get registered in SLP using the GRUU. When the proxy gets a request addressed to a GRUU, it rewrites it as the contact URI before forwarding the request to the device 🔁. The device uses that unique contact to decide whether to handle the request natively or pass it to one of its systems 🧠.
Figure 6 shows a session being transferred to a multi-device system 🎬. The audio device has already discovered the video device and made a multi-device system with it. 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 figure out its SDP, and then to invite the CN into a session using its own SDP and the video device's SDP 🎥🎧.
video audio MN CN
| |(1) REFER | |
| |<--------------------| |
| |(2) 202 Trying | |
| (3) INVITE no sdp |-------------------->| |
|<---------------------| | |
| (4) 200 OK SDP | | |
|--------------------->| | |
| |(5) INVITE a/v SDP, Replaces |
| |--------------------------------->|
| | RTP Audio |
| |<.................................|
| | RTP Video |
|<........................................................|
| |(6) 200 OK CN SDP |
| |<---------------------------------|
| | RTP Audio |
| (7) ACK CN Video SDP |.................................>|
|<---------------------| | |
| RTP Video | | |
|........................................................>|
| |(8) ACK | |
| |--------------------------------->|
| | |(9) BYE |
| | |<-----------|
| | |(10) 200 OK |
| | |----------->|
| | | |
| | | |Figure 6. Session Handoff to a multi-device system.
5.5. Distributing Sessions for Incoming Call ✨
okay so the examples above were all about an established session that a user moves over to one or more devices 💖 but another scenario is an incoming call getting split between multiple devices the moment the user accepts it 📞 in that case, the initial session isn't established yet when the transfer happens 🙈
the transfer could go either way, in either transfer mode 🦋 but a complete handoff to a separate device (that's Session Handoff mode) could already be done with existing stuff like proxying or redirection 💅 MNC mode is the one that shines when the user wants to automatically bring an extra device into a call 🔥 picture a desk IP phone and a PC with a video camera, and you smush them into one single logical device 🎀
so the SIP UA on the PC would, for any incoming call, send an INVITE request to the desk phone, and it sets the display name in the From header field to "Bob Jones (audio portion)", for example 💜 that way the user can tell who's calling right on the phone ✨ then they can accept or reject, same as if the call came straight to the phone 📱 if they accept, the PC UA (acting as the controller) responds to the caller with its video parameters plus the phone's audio parameters in the SDP body 🌸 and then the final ACK from the Correspondent Node finishes off the session establishment 👑
ngl this is where it can get messy 💀 if the desk phone is registered as a contact for the user, it would also ring when the direct call gets proxied there, on top of the INVITE the controller sent 😭 that's the confusion the user would be stuck with 🙈
the fix is caller preferences 🧚 the caller can indicate that the call should preferentially get proxied to devices with audio and video capabilities ✨ honestly the caller would probably use caller preferences anyway, if they had them, so the callee doesn't accidentally pick up the IP phone when a video-capable device is right there 💖 but caller preferences aren't widely supported on commercial devices yet, so the callee has to make sure the call gets routed properly 💅 one option is for the PC to register its contact with a higher priority than the phone's 🎀 then the Call Processing Language (CPL) [22] (the "proxy" node) could be used to say that forking should happen to the set of user devices in sequence instead of in parallel 🦋 since all calls would hit the PC first as long as it's online, it would redirect any request that included only audio in its SDP 🫶
5.6. Use of ICE in Session Mobility ✨
Interactive Connectivity Establishment (ICE) [27] is a protocol for Network Address Translator (NAT) traversal that may be used with SIP 🌈 instead of negotiating the addresses and ports for media sessions directly in SDP, a list of possible address/ports (candidates) gets 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, each local device sends its candidates to the MN, who exchanges them with the CN 🦋 after that, each device performs checks with the CN to figure out an appropriate candidate 🌸 in SH mode, where the local device establishes a session with the CN, ICE works no differently than in the standard case 💅
6. Reconciling Device Capability Differences ✨
session mobility sometimes means transferring a session between devices with different capabilities 🧚 for example, the codec being used in the current session might not be available on the new device 🙈 and that device might not support any codec the CN supports 😭 on top of codecs, devices can have different resolutions or bandwidth limitations that must be taken into account when doing a session transfer 👑
6.1. Codec Differences 🎀
before running a session transfer, the device checks the capabilities of the CN and the new device 💖 those can be found either through the SIP OPTIONS method (which is what SIP uses to query a device's media capabilities) or through SLP service attributes 💅 since the OPTIONS method is standard, it is suggested to be used to query the CN, while SLP is suggested for getting the media capabilities of local devices, since SLP is already being used for them 🦋
if the CN and the local device turn out to have a common codec, the transfer flow negotiates that this becomes the codec for the media session ✨ in MNC mode, the MN forwards the response from the local device to the CN, who picks a codec it supports from the ones available 🌈 in Session Handoff mode, the MN sends a REFER request to the local device and lets it negotiate a common codec with the CN during their session establishment 💜 no special behavior of the MN is required there 🫶
if the MN sees that there's no common codec, it runs the transfer through an intermediate transcoding service 🔥 instead of a direct media session between the CN and the local device, separate sessions get set up between the transcoder and each of them, and the transcoder translates between the streams 🎀 the Mobile Node discovers available transcoders through some means, including SLP 🌸
transcoding services in SIP are defined in [18] using third-party call control 🦋 in MNC mode, the Mobile Node sets up one media session between the transcoder and the CN, and another between the transcoder and the local device 💅 this is different from the normal transcoding case, where one party sets up a media session between itself and the transcoder, and another between the transcoder and the other party ✨ the MN starts by sending an INVITE request with no body to the local device, and it gets back the list of codecs that device can use 🧚 then it repeats that for the CN and gets the CN's available codecs 💖 it picks one codec from each side, along with the address and port of each device, and combines them in an INVITE request sent to the transcoder 👑 the transcoder responds with the ports where it will accept each stream 🌈 the right port info gets sent individually to the CN and the local device 🙈 once all three sessions are set up, two media sessions exist and the transcoder translates between them 😭 here's the flow, shown in Figure 7 🎀
AN Transcoder MN CN
(codec A) (codec B)
| |(1) INVITE no sdp | |
|<---------------------------------------| |
| |(2) 200 AN params | |
|--------------------------------------->| |
| | |(3) INVITE no sdp |
| | |---------------------->|
| | |(4) 200 OK CN params |
| | |<----------------------|
| |(5) INVITE AN, CN params | |
| |<---------------------------| |
| |(6) 200 OK TA, TB params | |
| |--------------------------->| |
| |(7) ACK | |
| |<---------------------------| |
| |(8) ACK TA params | |
|<---------------------------------------| |
| RTP | | |
|..........>| RTP | |
| |...................................................>|
| | | (9) ACK TB params |
| | |---------------------->|
| | | RTP |
| RTP |<...................................................|
|<..........| | |
| | | |
Figure 7. Transfer of a session in Mobile Node Control mode
through a transcoder to translate between native codecs
of CN and an audio node AN, where they share no common
codec.in Session Handoff mode, the local device itself sets up a session with the CN through the transcoder 🦋 after getting the REFER request, it uses the OPTIONS method to find the CN's capabilities 💜 then it uses a common codec if one is available in the session setup, or sets up the transcoded session with third-party call control as in [18] 🫶
6.2. Display Resolution and Bandwidth Differences 🌸
other differences in device capabilities, like display resolution and bandwidth limitations, are also suggested to be reconciled during transfer 💅 for example, a mobile device that's limited in both display size and bandwidth will probably be getting the video stream from the other call participant at a low resolution and frame rate 📱 when the user moves their video output to a large-screen display, they can start watching much higher-quality video at the display's higher native resolution and at a higher frame rate 🔥
changing the image resolution and frame rate doesn't need any 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 the corresponding MPIs (Minimum Picture Interval, which is related to the frame rate) supported for the given codec are listed after the media line, in order of preference 🎀 for instance, these lines in SDP would show that a device supports the H.263 codec (value 34) with image sizes of 16CIF, 4CIF, CIF, and QCIF (with the MPI for each format after the "=") 🧚
m=video 60300 RTP/AVP 34
a=fmtp:34 16CIF=8;4CIF=6;CIF=4;QCIF=3in MNC mode, the local device's response (Figure 2, message 2) to the initial INVITE request sent by the MN includes this line in the SDP body 💖 then the MN includes it in the INVITE request it sends 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 it gets the REFER request 💜 if the local device isn't configured to include the supported image sizes during session establishment, the info 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 isn't 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 it sends to retrieve the session 👑
7. Simultaneous Session Transfer ✨
okay so a session transfer can happen when one call participant goes after the other participant has already transferred the session on their side 🦋. If the first transfer was done in MNC mode, a subset of the original session media is now on local devices. The MN gets either a re-INVITE from the other participant or an INVITE request from a local device on the other side 📞. That message carries the new media parameters of the session. So the MN, therefore, has to send a re-INVITE to any local devices with these parameters 💅. It then includes the parameters returned from these devices in the 200 OK response. If the first transfer was done in SH mode, the local device will directly receive the session transfer message from the other party and will follow the normal procedure for responding to an INVITE request. If it is controlling other local devices for this session as part of an MDS, it follows the procedure above, where the first transfer was done in MNC mode 🫶.
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. When 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 ✨.
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 🌸.
8. Session Termination
Once a session has been transferred, the user may terminate it by hanging up the current device, just like they would on 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 💜.
9. Security Considerations 🔐
okay bestie, this part is SERIOUS 😤 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 💀.
9.1. Authorization for Using Local Devices
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 🔑.
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 🎓.
9.2. Maintaining Media Security During Session Mobility
9.2.1. Establishing Secure RTP Using SDP
Confidentiality, message authentication, and replay protection are necessary in internet protocols, including those used for real-time multimedia communications 🔒. The Secure Real-time Transfer Protocol (SRTP) [14] provides these for RTP streams. Since SRTP may be used to carry the media sessions of SIP devices, such as the MN and CN, we discuss how to ensure that the session continues to use SRTP following the transfer to another device. This is also discussed in less detail in [2] 🎀.
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 🗝️.
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 🦋.
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:
End-to-end media security is based on the exchange of keying material
within SDP. The proper operation of these mechanisms with third
party call control depends on the controller behaving properly. So
long as it is not attempting to explicitly disable these mechanisms,
the protocols will properly operate between the participants,
resulting in a secure media session that even the controller cannot
eavesdrop or modify. Since third party call control is based on a
model of trust between the users and the controller, it is reasonable
to assume it is operating in a well-behaved manner. However, there
is no cryptographic means that can prevent the controller from
interfering with the initial exchanges of keying materials. As a
result, it is trivially possibl[e] for the controller to insert itself
as an intermediary on the media exchange, if it should so desire.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 🥰.
9.2.2. Securing Media Using the Transport Layer
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 🧩.
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] 💖.
9.3. Flooding Attacks in MNC Mode
The MNC call flows in this document, where one device instructs another device to send an RTP flow to a third one, present the possibility of a flooding attack. This is a general problem that relates to any use of 3pcc. In this document, it is only a concern where the device is public, as described at the beginning of this section, and a large group of people can transfer media to it, since there may not be a very strong trust relationship between the device owner (e.g., an institution) and the users. Obviously, where a device is private and only its owner can transfer to it, the concern does not exist, given the use of the Identity header mentioned earlier. A possible solution may be the use of ICE [27], since both sides confirm that they want to receive each other's media. 🚨
10. Acknowledgments 🫶
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. Huge thanks to them, they're literally the best 👑🌸
11. References 📚✨
Okay bestie, this is the reading list 🤓📚. Section 11.1 has the normative references, the ones you actually need to read to implement this stuff. Section 11.2 has the informative references, which are great background but not required. Every entry is listed exactly as the original has it.
11.1. Normative References 💅
[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.
[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.
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[7] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[8] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[11] Camarillo, G., "Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag", RFC 4569, July 2006.
[12] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
11.2. Informative References 🧠🌸
[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.
[14] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[15] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[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.
[17] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[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.
[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.
[20] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility Using SIP", ACM SIGMOBILE Mobile Computing and Communications Review, Vol. 4, No. 3, July 2000.
[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.
[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.
[23] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, "Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)", RFC 4484, August 2006.
[24] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[25] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[26] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[27] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[28] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[29] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.
[30] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, September 2008.
[31] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing an SRTP Security Context using DTLS", Work in Progress, March 2009.
Authors' Addresses 💌🎀
The authors are listed below, with their addresses exactly as the original gives them 🫶.
Ron Shacham
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
EMail: shacham@cs.columbia.edu
Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
EMail: hgs@cs.columbia.edu
Srisakul Thakolsri
DoCoMo Communications Laboratories Europe
Landsberger Str. 312
Munich 80687
Germany
EMail: thakolsri@docomolab-euro.com
Wolfgang Kellerer
DoCoMo Communications Laboratories Europe
Landsberger Str. 312
Munich 80687
Germany
EMail: kellerer@docomolab-euro.comThat's the whole RFC, babe! 🌈💖 You made it through every section, and the whole thing is now in your own voice, slay 👑🔥
📦 where this page comes from
- ietf: rfc5631 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms