SPLICES Working Group G. Camarillo
Internet-Draft S. Loreto
Intended status: Informational Ericsson
Expires: December 27, 2011 R. Shekh-Yusef
Avaya
June 25, 2011
Disaggregated Media in the Session Initiation Protocol (SIP)
draft-loreto-splices-disaggregated-media-02.txt
Abstract
Disaggregated media refers to the ability for a user to create a
multimedia session combining different media streams, coming from
different devices under his or her control, so that they are treated
by the far end of the session as a single media session. This
document lists several use cases that involve disaggregated media in
SIP. Additionally, this document analyzes what types of
disaggregated media can be implemented using existing protocol
mechanisms, and the pros and cons of using each of those mechanisms.
Finally, this document describes scenarios that are not covered by
current mechanisms and proposes new IETF work to cover them.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2011.
Copyright Notice
Copyright (c) 2011 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
Camarillo, et al. Expires December 27, 2011 [Page 1]
Internet-Draft Disaggregated Media in SIP June 25, 2011
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Using Two Separate devices to Start a Conversation . . . . 3
2.2. Showing a Pre-recorded Video During a Conversation . . . . 4
2.3. Sending a File from a PC During a Conversation . . . . . . 4
2.4. Including Live Video in a Conversation . . . . . . . . . . 4
2.5. Including Remote Live Video in a Conversation . . . . . . 5
2.6. Answering a call using Two Separate Devices . . . . . . . 5
2.7. Other possible use cases . . . . . . . . . . . . . . . . . 6
3. Existing Mechanisms to Implement Disaggregated Media . . . . . 6
3.1. Message Bus (Mbus) . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Mbus issues . . . . . . . . . . . . . . . . . . . . . 8
3.2. Megaco (H.248) . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Megaco issues . . . . . . . . . . . . . . . . . . . . 9
3.3. Third Part Call Control (3pcc) . . . . . . . . . . . . . . 9
3.3.1. 3pcc issues . . . . . . . . . . . . . . . . . . . . . 10
4. Distributed Call Control with Actions . . . . . . . . . . . . 11
4.1. Answering an A/V call using Two Separate Devices
example . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Discovery of Capabilities . . . . . . . . . . . . . . 12
4.1.2. Answering Using PC . . . . . . . . . . . . . . . . . . 13
4.1.3. Answering Using Desk Phone . . . . . . . . . . . . . . 14
4.1.4. Departure of One Device . . . . . . . . . . . . . . . 15
5. Scenarios Not Covered by Existing Mechanisms . . . . . . . . . 17
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Informational References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Camarillo, et al. Expires December 27, 2011 [Page 2]
Internet-Draft Disaggregated Media in SIP June 25, 2011
1. Introduction
Disaggregated media refers to the ability for a user to create a
multimedia session combining different media streams, coming from
different devices under his or her control, so that they are treated
by the far end of the session as a single media session.
The SIP specification [RFC3261] defines a multimedia session as "an
exchange of data between an association of participants". SDP
(Session Description Protocol) is the default session description
format in SIP. The SDP (Session Description Protocol) specification
[RFC4566] defines a multimedia session as "a set of multimedia
senders and receivers and the data streams flowing from senders to
receivers".
Generally, a given participant uses a single device to establish (or
participate in) a given multimedia session. Consequently, the SIP
signaling to manage the multimedia session and the actual media
streams are typically co-located in the same device. In scenarios
involving disaggregated media, a user wants to establish a single
multimedia session combining different media streams coming from
different devices under his or her control. This creates a need to
coordinate the exchange of the those media streams within the media
session.
The remainder of this document is organized as follows. Section 2
contains use cases where different media streams, coming from
different devices, are combined to establish a multimedia session.
Section 3 describes what types of disaggregated media can be
implemented using existing protocol mechanisms, and the pros and cons
of using each of those mechanisms. Section 4 describes scenarios
that are not covered by current mechanisms and proposes new IETF work
to cover them.
2. Use Cases
This section lists several use cases where users participate in a
multimedia session using multiple devices. That is, either the user
initiating the session uses several devices in parallel during the
session, or the user receiving the session invitation uses several
devices in parallel during the session, or both.
2.1. Using Two Separate devices to Start a Conversation
Laura is at her office. On her desk, she has a PC with a soft client
and a desk phone. The PC has a low-quality built-in microphone and
is connected to high-quality speakers.
Camarillo, et al. Expires December 27, 2011 [Page 3]
Internet-Draft Disaggregated Media in SIP June 25, 2011
Laura wants to establish a voice session with Bob using the desk
phone as the microphone and the soft client as the speaker.
Laura wants Bob to treat the send-only audio stream from her
deskphone and the receive-only audio stream from her softclient as
part of the same communication space. That is, Laura wants Bob to
treat both streams as belonging to the same multimedia session.
2.2. Showing a Pre-recorded Video During a Conversation
Bob has a voice-only phone and an IP-TV device. Laura has an
integrated advanced multimedia phone with camera.
Bob is talking on his voice-only phone with Laura, who is on her
multimedia phone.
Bob wants to show Laura part of the TV show he recorded last night.
Bob interacts, using his voice-only phone, with his IP-TV device and
sends a video stream to Laura's device.
Bob talks about the show with Laura on his voice-only phone while
Laura watches the show.
Bob wants Laura to treat the video stream from his IP-TV device and
the voice stream from his voice-only phone as part of the same
communication space. That is, Bob wants Laura to treat both streams
as belonging to the same multimedia session.
2.3. Sending a File from a PC During a Conversation
Bob has a voice-only phone and a PC with a soft client. Laura has an
integrated advanced multimedia phone with support for file transfers.
Bob wants to send a file to Laura from his PC during his conversation
with Laura on his voice-only phone.
Bob interacts, using his voice-only phone, with his PC and starts a
file transfer session to Laura's multimedia phone.
Bob wants Laura to treat the file transfer from his PC and the voice
stream from his voice-only phone as part of the same communication
space. That is, Bob wants Laura to treat both streams as belonging
to the same multimedia session.
2.4. Including Live Video in a Conversation
Bob has a voice-only phone and a PC which has a soft client, a
Webcam, and a low-quality built-in microphone. Laura has an
Camarillo, et al. Expires December 27, 2011 [Page 4]
Internet-Draft Disaggregated Media in SIP June 25, 2011
integrated advanced multimedia phone with camera.
Bob wants to send a live video to Laura from his PC during his
conversation with Laura.
Bob interacts, using his voice-only phone, with his PC and starts
live video stream to Laura's multimedia phone.
Bob wants Laura to treat the live video stream from his PC and the
voice stream from his voice-only phone as part of the same
communication space. That is, Bob wants Laura to treat both streams
as belonging to the same multimedia session.
2.5. Including Remote Live Video in a Conversation
Bob, who is at his office, has a multimedia phone. At his summer
cottage, Bob has a webcam-phone (e.g. a video-surveillance system).
Laura has an integrated advanced multimedia phone with a camera.
During his conversation with Laura, Bob wants to show her the new
summer cottage he just bought. Bob interacts, using his multimedia
phone, with his webcam phone at this summer cottage and start live
video stream to Laura's multimedia phone.
Bob wants Laura to treat the live video stream from his webcam-phone
and the voice stream from his voice-only phone as part of the same
communication space. That is, Bob wants Laura to treat both streams
as belonging to the same multimedia session.
2.6. Answering a call using Two Separate Devices
Laura has a PC with a softclient and a desk phone. Bob has an
integrated advanced multimedia phone with camera.
Laura receives on her desk phone an incoming voice-video call from
Bob.
Laura decides to answer Bob's session invitation by establishing a
voice session with Bob using the desk phone and the video session
using her multimedia phone. Two SIP dialogs need to be established:
one between Bob's device and Laura's desk phone and one between Bob's
device and Laura's multimedia phone.
Laura wants Bob to treat the audio stream from her deskphone and the
video stream from her softclient as part of the same communication
space. That is, Laura wants Bob to treat both streams as belonging
to the same multimedia session.
Camarillo, et al. Expires December 27, 2011 [Page 5]
Internet-Draft Disaggregated Media in SIP June 25, 2011
2.7. Other possible use cases
This section just enumerates, for sake of completeness, other
possible use cases, similar to the one elaborated in the previous
sections.
A user wants to start or answer a call combining:
o Voice and video streams from a deskphone and application sharing
from a computer.
o Voice stream from a deskphone and video stream to/from a TV
attached to a set top box with a camera built in.
o The User Interface (UI) for the call on a mobile phone and the
audio streaming coming in/out of a speakerphone that is in the
same room where he is.
3. Existing Mechanisms to Implement Disaggregated Media
Figure 1 shows the media flow in the most generic scenario where both
the Caller and the Callee use disaggregated media, involving in the
multimedia session different devices under their control.
/----------------\ /--------------\
| ---- | | ---- |
| | UA |====================================| UA | |
| ---- | video | ---- |
| ---- | | ---- |
| | UA |=================================| UA | |
| ---- ---- | audio | ---- ---- |
| | UA |=================================| UA | |
| ---- | text | ---- |
\----------------/ \--------------/
Laura Bob
Figure 1: Media Flows in Disaggregated Media
All existing mechanisms to implement disaggregated media in SIP use a
centralized approach whereby the far end of the session receives the
same SIP signaling flow that it would receive if all the media
streams came from a single device. This makes it transparent to the
far end of the session the fact that the caller is using separate
devices for different media.
Camarillo, et al. Expires December 27, 2011 [Page 6]
Internet-Draft Disaggregated Media in SIP June 25, 2011
---- ----
| UA |\ /| UA |
---- \ / ----
\ /
---- \---- ----/ ----
| UA |-----| UA |-------------| UA |---| UA |
---- /---- SIP ----\ ----
/ \
---- / \ ----
| UA |/ \| UA |
---- ----
Alice Bob
Figure 2: Centralized scenario
Figure 2 shows the generic signaling flow common to all centralized
solutions, where a Central Node is able to manage all signaling
messages needed to coordinate the different user's devices and hide
from the far end of the session all the mechanisms used to distribute
the media among different devices.
Section 3.1, Section 3.2 and Section 3.3 analyze how different
existing mechanisms can be used to implement disaggregated media in a
centralized way.
3.1. Message Bus (Mbus)
The Message Bus (Mbus) [RFC3259] is a light-weight local coordination
protocol for developing component-based distributed applications.
Mbus provides a simple and flexible message oriented communication
channel for a group of components that may be distributed on multiple
hosts in a local network. The transport services include useful
features such as peer location, point-to-point and group
communication and security.
In a disaggregated media scenario a user can use Mbus to coordinate
the different devices under his control in a loosely coupled
conference control model and so involve them in the call. The
different devices can communicate with one another using Mbus
messages, and then let only one device, a call control engine, to
initiate, manage and terminate call control relations to other SIP
endpoints. In this case the fact that the caller is using separate
devices for different media becomes transparent to the callee.
Figure 3 shows an example of the relation between a call control
engine in an Mbus enabled conferencing system.
Camarillo, et al. Expires December 27, 2011 [Page 7]
Internet-Draft Disaggregated Media in SIP June 25, 2011
+------------------ Mbus--------------------+
| |
| +---------------+ |
| |Audio Component| |
| +---------------+ |
| | |
| +---------------+ | +---------------+
| +---------------+ | call | | SIP | SIP |
| |Video Component|-----| control |=================| User Agent |
| +---------------+ | engine | | | |
| +---------------+ | +---------------+
| |
+-------------------------------------------+
Figure 3: MBus Architecture
3.1.1. Mbus issues
The Mbus protocol introduces the following issues.
Mbus support: All the different user's devices need to support the
Mbus protocol.
Central point: Because the call control engine has a complete
control over the call, it needs to be involved during the whole
duration of the session. It cannot leave the session before the
whole session ends (unless it transfers the controller role to one
of the other user's devices).
Local network: Mbus uses multicast with a limited scope for message
transport. The multicast limits the coordination mechanism only
to groups of devices that are connected to a local network. So
Mbus can be used in a disaggregated media scenario only if all the
different devices under the user control, or at least the one the
user wants to involve in the communication, are attached to the
same local network.
3.2. Megaco (H.248)
The Megaco [RFC3525] protocol is used to establish, and terminate
calls across terminations (end points) connected to Media Gateways
(MGs). Megaco instructs Media Gateways (MG) to connect streams
coming from outside a packet network on to a packet stream such as
RTP. Master-MGC issues commands to send and receive media from
addresses, generate tones, and to modify configuration. The
architecture requires a Media Gateway Controller (MGC) controlling
the Media Gateway(s). However it does not constitute a complete
system. To establish communication between MGC(s) is necessary a
session initiation protocol. SIP is the protocol normally used to
Camarillo, et al. Expires December 27, 2011 [Page 8]
Internet-Draft Disaggregated Media in SIP June 25, 2011
establish calls across domains or across MGCs.
Megaco can be used in a disaggregated media scenario to let one of
the user's devices act as a Media Gateway Controller, coordinating
all the other devices under the user's control, which in this case
will act as Media Gateways. In this case the fact that the caller is
using separate devices for different media becomes transparent to the
callee.
3.2.1. Megaco issues
The Megaco protocol introduces the following issues.
Megaco support: All the different user's devices need to support the
Megaco protocol.
Central point: Because the Media Gateway Controller has a complete
control over the call, it needs to be involved for all the session
time. It can not leave the session before the whole session ends.
3.3. Third Part Call Control (3pcc)
3pcc [RFC3725] allows one entity (called the Controller) to setup and
manage a communications relationship between two or more other
parties using SIP.
In a disaggregated media scenario, a user can use 3pcc mechanism only
if at least one among the different devices under his control
supports this mechanism and is able to become a Controller for the
other in the call. In this case become transparent for the callee
the fact that the caller is using separate devices for different
media. In fact the Controller is a central point for the signaling
on the caller side, and has complete control over the call, making
everything in one dialog for the callee.
The call flow for disaggregated media using 3pcc is shown in
Figure 4. It is based on Flow IV documented in Section 4.4 of
[RFC3725] and recommended for calls to unknown entities, or to
entities known to represent people. The flow requires some SDP
manipulation by the Controller to convert offer2 to offer2' and
offer2'', and then to convert answer2' and answer2'' to answer2.
Camarillo, et al. Expires December 27, 2011 [Page 9]
Internet-Draft Disaggregated Media in SIP June 25, 2011
Alice Alice Alice Controller Bob
UA Media X UA Video UA Audio UA
| |(1) INVITE offer1 | |
| |no media | |
| |<-----------------| |
| |(2) 200 answer1 | |
| |no media | |
| |----------------->| |
| |(3) ACK | |
| |<-----------------| |
|(4) Invite offer1' | |
|no media | | |
|<------------------------------| |
|(5) 200 answer1' | |
|------------|----------------->| |
|(6)ACK | | |
|<-----------|------------------|(7) INVITE no SDP |
| | |----------------->|
| | |(8) 200 OK offer2 |
| |(9) INVITE offer2'|<-----------------|
| |<-----------------| |
| |(10) 200 answer2' | |
| |----------------->| |
|(11) INVITE offer2'' | |
|<------------------------------| |
|(12) 200 answer2'' | |
|------------------------------>|(13) ACK answer2 |
| |(14) ACK |----------------->|
|(15)ACK |<-----------------| |
|<------------------------------|(16) RTP |
| |(17) RTP |..................|
|(18) RTP |.....................................|
|..................................................|
Figure 4: 3pcc call flow
3.3.1. 3pcc issues
The 3pcc mechanism introduces the following issues.
Complexity: Third party call control only uses protocol mechanism
specified in [RFC3261]. However the usage of third party call
control becomes more complex when aspects of the call utilize SIP
extensions or optional features of SIP like resource reservation.
Camarillo, et al. Expires December 27, 2011 [Page 10]
Internet-Draft Disaggregated Media in SIP June 25, 2011
Central point: Because the Controller has a complete control over
the call, it needs to be involved during the whole duration of the
session. It cannot leave the session before the whole session
ends (unless it transfers the controller role to one of the other
user's devices).
User experience: 3ppc results in a suboptimal user experience
because the slave phones are not aware that they are involved in a
disaggregated media call scenario. Indeed, the slave phones
behave as they were just involved in a normal call with the
Controller. Moreover the slave phones will be alerted without any
media having been established yet.
SDP manipulation: the Controller cannot "proxy" the SIP messages
received from one of the parties. In many cases, it is required
to modify the SDP exchanged between the participants in order to
affect the changes.
4. Distributed Call Control with Actions
The loosely coupled scenarios in this section describe the discovery
of capabilities and interaction between the federated devices that
allows these devices to present themselves to the remote party as one
entity.
The federated devices utilize the Actions mechanism to allow a UA to
invoke an action on another UA.
3PCC allows the Controller to setup and manage a communications
relationship between two or more other parties using SIP. When 3PCC
is coupled with the Actions mechanism, the Controller role becomes
flexible enough to allow any of the federated parties to take that
role at any time, depending on the specifics of the use case.
All federated devices are expected to be aware of each others
capabilities and all available actions, and they are also expected to
be aware of all the dialogs of each others by subscribing to the
'dialog' event package, and have the intelligence to utilize all this
knowledge to provide solutions to a wide range of use cases, without
requiring the remote party to change.
Because there is no one entity that takes the Controller role all the
time, in the event of a sudden departure of one of the federated
devices, one of the remaining devices can take control of the
communication with the remote party and update it, based on the
capabilities of the remaining federated parties. In the case of the
departure of the Controller device and with multiple federated
devices still alive, the rest of the federated devices can utilize
the Actions mechanism to select the new Controller.
Camarillo, et al. Expires December 27, 2011 [Page 11]
Internet-Draft Disaggregated Media in SIP June 25, 2011
4.1. Answering an A/V call using Two Separate Devices example
This section describes the example use case of answering an incoming
A/V call using two separate devices, using the mechanism described in
the section above. In the following example flows the Actions
mechanism used is the one provided by the proposed new SIP INVOKE
method. The use case has Alice with a PC with a Video SIP UA and
Audio SIP Desk Phone while Bob has an integrated SIP Device with A/V.
4.1.1. Discovery of Capabilities
Both Alice's devices subscribe to the 'reg' event package of each
other, which allows each device to discover the capabilities of the
other device based on the feature tags provided by each device. The
Desk Phone knows that the PC supports Video, while the PC knows that
the Desk Phone only supports audio. The two devices also subscribe
to the 'dialog' event package of each other.
Alice Alice Proxy Bob
PC Desk Phone
| | | |
| | SUBSCRIBE reg | |
| |-------------------->| |
| | 200 OK | |
| |<--------------------| |
| SUBSCRIBE reg | | |
|------------------------------------------>| |
| 200 OK | | |
|<------------------------------------------| |
| | | |
| SUBSCRIBE dialog | | |
|-------------------->| | |
| 200 OK | | |
|<--------------------| | |
| | | |
| SUBSCRIBE dialog | | |
|<--------------------| | |
| 200 OK | | |
|-------------------->| | |
| | | |
| | | |
| | | |
Figure 5
Camarillo, et al. Expires December 27, 2011 [Page 12]
Internet-Draft Disaggregated Media in SIP June 25, 2011
4.1.2. Answering Using PC
Bob makes an A/V call to Alice, which rings both of Alice's devices.
Alice answered the call using her PC. The PC instructs the phone to
answer the call with audio only, and then the PC joins the existing
call with video, by sending an INVITE with Join to the phone, which
will then take the Video offer from the PC and add its Audio offer
and send a re-INVITE with an SDP with one audio media line and one
video media line.
Alice Alice Proxy Bob
PC Desk Phone
| | | INVITE Alice [A/V] |
| | |<--------------------|
| | INVITE Alice [A/V] | |
| |<--------------------| |
| INVITE Alice [A/V] | | |
|<------------------------------------------| |
| INVOKE Action: urn:invoke:call:answer
| ;media=audio;transducer=speaker|headset
|-------------------->| | |
| 200 OK | | |
|<--------------------| | |
| | 200 OK [Audio] | |
| |-------------------->| |
| | | 200 OK [Audio] |
| | |-------------------->|
| CANCEL | | |
|<------------------------------------------| |
| |<---dialog1------------------------------->|
| |<======audio==============================>|
| INVITE with Join [Video] | |
|-------------------->| | |
| 100 | | |
|<--------------------| | |
| | re-INVITE [A/V] | |
| |-------------------->| |
| | | re-INVITE [A/V] |
| | |-------------------->|
| | | 200 OK [A/V] |
| | 200 OK [A/V] |<--------------------|
| |<--------------------| |
| 200 OK [Video] | | |
|<--------------------| | |
|<----dialog2-------->|<---dialog1------------------------------->|
| |<======audio==============================>|
|<============================video==============================>|
Camarillo, et al. Expires December 27, 2011 [Page 13]
Internet-Draft Disaggregated Media in SIP June 25, 2011
4.1.3. Answering Using Desk Phone
The phone answers the audio call and then instructs the PC to
initiate a video call towards the phone, which the phone uses to join
the existing audio call.
Alice Alice Proxy Bob
PC Desk Phone
| | | INVITE Alice [A/V] |
| | |<--------------------|
| | INVITE Alice [A/V] | |
| |<--------------------| |
| INVITE Alice [A/V] | | |
|<------------------------------------------| |
| | | |
| | 200 OK [Audio] | |
| |-------------------->| |
| | | 200 OK [Audio] |
| | |-------------------->|
| CANCEL | | |
|<------------------------------------------| |
| | | |
| |<---dialog1------------------------------->|
| |<======audio==============================>|
| | | |
| INVOKE Action: urn:invoke:call:join;media=video;dialog=dialog1
|<--------------------| | |
| 200 OK | | |
|-------------------->| | |
| | | |
| INVITE with Join [Video] | |
|-------------------->| | |
| 100 | | |
|<--------------------| | |
| | re-INVITE [A/V] | |
| |-------------------->| |
| | | re-INVITE [A/V] |
| | |-------------------->|
| | | 200 OK [A/V] |
| | 200 OK [A/V] |<--------------------|
| |<--------------------| |
| 200 OK [Video] | | |
|<--------------------| | |
| | | |
Figure 7
Camarillo, et al. Expires December 27, 2011 [Page 14]
Internet-Draft Disaggregated Media in SIP June 25, 2011
4.1.4. Departure of One Device
In the case of a sudden departure of one of the devices, the other
device can take control over the communication with the remote party.
In the flow below, Alice's devices have a keep-alive mechanism that
allows each one of them to discover if the other is gone (the
mechanism is TBD). Let us assume that the PC discovers that the
phone is gone. The PC is aware of the dialog with Bob because of the
subscription to the dialog event package. The PC then clears
dialog2, and sends an INVITE with Replaces to Bob's phone to replace
the dialog with the phone.
Alice Alice Proxy Bob
PC Desk Phone
| | | |
|~~~~~keep-alive~~~~~~|
| | | |
|<----dialog2-------->|<---dialog1------------------------------->|
| |<======audio==============================>|
|<============================video==============================>|
| | | |
| INVITE Replaces dialog1 | |
|------------------------------------------>| |
| | | INVITE |
| | | Replaces dialog1 |
| | |-------------------->|
| | | BYE |
| | BYE |<--------------------|
| | x <-----------------| |
| | | 200 OK |
| | |<--------------------|
| 200 OK | | |
|<------------------------------------------| |
| ACK | | |
|------------------------------------------>| |
| | | ACK |
| | |-------------------->|
Figure 8
The above mechanism has its limitation, as the PC, in this case, must
be able to discover that the other federated device is gone and
replace the dialog between the Desk Phone and the remote phone before
Bob's phone tears down the dialog with the Desk Phone (dialog1).
Camarillo, et al. Expires December 27, 2011 [Page 15]
Internet-Draft Disaggregated Media in SIP June 25, 2011
5. Scenarios Not Covered by Existing Mechanisms
As discussed previously, all existing mechanisms implement
disaggregated media using a centralized approach. Scenarios not
covered by existing mechanisms include those where none of the nodes
can act as a controller because it does not support the necessary
functionality or because it will not participate in the whole session
(transferring the SIP dialog from a controller to a new one using
REFER and Replaces is complex and requires support from the far end).
These scenarios are better implemented using a more distributed
approach.
In a distributed scenario, the far end of the session receives
directly signaling messages from each of the devices involved in the
multimedia session. That means that the receiver needs to treat all
the signaling and media coming from different devices of the same
user as part of the same media session.
/------------\
| ---- ____|________________
| | UA | | \
| ---- | \ ------
| ---- | | |
| | UA |-------------------------| UA |
| ---- | | |
| ---- | / ------
| | UA |____|________________/ Bob
| ---- |
\------------/
Alice
Figure 9
Figure 5 shows the generic signaling flow in a Distributed Scenario,
where all the signaling messages go from the different user's devices
to the far end of the session.
6. Recommendations
To maximize the possibility of the adoption of this mechanism, we
recommend that the WG take the Distributed Call Control with Actions
approach defined in section 4 above.
A future work may learn from the experience we gain with the
Distributed Call Control with Actions approach and later try to
standardize the approach described in section 5 above.
Camarillo, et al. Expires December 27, 2011 [Page 16]
Internet-Draft Disaggregated Media in SIP June 25, 2011
7. Security Considerations
To be done.
8. IANA Considerations
This document does not require any actions by the IANA.
9. Informational References
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
using SIP Request-URI", RFC 3087, April 2001.
[RFC3259] Ott, J., Perkins, C., and D. Kutscher, "A Message Bus for
Local Coordination", RFC 3259, April 2002.
[RFC3261] 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.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3725] 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.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Camarillo, et al. Expires December 27, 2011 [Page 17]
Internet-Draft Disaggregated Media in SIP June 25, 2011
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Rifaat Shekh-Yusef
Avaya
250 Sidney Street
Belleville, Ontario K8N 5B7
Canada
Email: rifatyu@avaya.com
Camarillo, et al. Expires December 27, 2011 [Page 18]