Subject: [dispatch] Disaggregated Media in SIP

From: Salvatore Loreto <[email-masked]>
Date: Mon, 06 Jul 2009 19:33:21 +0300

Hi there,

I have just submitted a draft that talks of Disaggregated Media in the 
Session Initiation Protocol (SIP).
http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disaggregated-media-00.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.

cheers
Sal

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 6 Jul 2009 12:07:53 -0500

I'm glad to see this topic coming back.

I see that this draft doesn't propose a solution to problem: it list
three options, and describes why they are not adequate. I agree with
the conclusions.

We've looked at various approaches to solve this important problem 
several times before: 

- Feature ref (refer to urn: indicating specific features)
  http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00

- Remote control using REFER to requests & responses 
  http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05
  (Also, versions -04, -03,-02, -00)

- Remore control using REFER with XML body describing function
  http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01

- Remote control using MBUS
  http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 &
  http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01

On top of that there are various proprietary mechanisms, and even some legacy
PBX-CTI protocols.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
> Sent: Monday, July 06, 2009 09:33
> To: [email-masked]
> Subject: [dispatch] Disaggregated Media in SIP
> 
> Hi there,
> 
> I have just submitted a draft that talks of Disaggregated 
> Media in the Session Initiation Protocol (SIP).
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 6 Jul 2009 12:35:15 -0500

Sure.
 
That would be functionaly identical to the Feature referal using REFER to URL/URN, but using MESSAGE instead. 
 
Works for me.

________________________________

	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: Monday, July 06, 2009 10:29
	To: Audet, Francois (SC100:3055); Salvatore Loreto; [email-masked]
	Cc: Henning Schulzrinne
	Subject: Re: [dispatch] Disaggregated Media in SIP

	>We've looked at various approaches to solve this important 
	>problem several times before
	
	Actually there is one more: IM-ing a URI to some resource, mentioned by Henning Schulzrinne (I don't recall the document or presentation).
	
	My two cents is that IM-ing a URL is the most general solution, or is it?
	
	Henry

	On 7/6/09 12:07 PM, "Francois Audet" <[email-masked]> wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jul 2009 14:23:11 -0400

Sal,

Glad to see more focus on the objectives rather than the solutions.

A few comments:

> 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 the Bob's session invitation by establishing
>    a voice session with Bob using the desk phone and the video session
>    using her multimedia phone. 

OK

>    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.

The above statement assumes the outcome that this draft is trying to 
make a case for.

>         ----                                 ----
>        | 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.

That is but one of many topologies. Others include:
- Alice has a multimedia device that supports all the media
- Alice has a device that supports *some* of the media and is
   also the controller for the other devices.
- Either of the above for Bob
- all permutations of approaches for Alice and Bob

The key is that there is a single sip session between caller and callee, 
which negotiates potentially many media sessions. The caller and callee 
may then each use whatever technique(s) desired to establish connection 
of the individual media sessions to particular devices. That may involve 
other sip signaling for some or all of the media, or not.

> 3.3.1.  3pcc issues

These are indeed issues to some extent. But its debatable whether they 
are significant issues, or how hard it is to mitigate them. To be fair 
we will have to look at issues for alternative solutions and balance them.

> 4.  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

Well, its clear that some devices will need to support some new 
functionality to aggregate the disaggregated media. Actually it seems 
that something new will need to be implemented at each end. So we are 
really only discussing *which* new functionality should be implemented 
at each end.

>    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.

If it would be possible to do a transfer at all, it should be possible 
to do a transfer involving this disaggregated media controller.

>       /------------\
>      |     ---- ____|________________
>      |    | UA |    |                \
>      |     ----     |                 \ ------
>      |   ----       |                  |      |
>      |  | UA |-------------------------|  UA  |
>      |   ----       |                  |      |
>      |     ----     |                 / ------
>      |    | UA |____|________________/   Bob
>      |      ----    |
>       \------------/
>           Alice
> 
>    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.

That shows some of the signaling paths. What it doesn't show is what is 
required to organize Alice's devices and decide which should be involved 
in the call, for which media. That is an important piece, unless it 
handled entirely by Bob.

Every one of the use cases will require some special processing and 
control signaling among the disaggregated devices before a call topology 
such as shown in figure 5 can be established.

Also, its far from clear what order of signaling would be required, and 
in which direction, to use the approach of figure 5 for each use case. 
Its quite possible that one call might be established from Bob to Alice 
and a supporting call from Alice to Bob. This would confuse 
responsibility for charging.

Another problem with figure 5 arises if it becomes necessary to transfer 
the resulting call, say from Bob to Charlie. There are then three calls 
that need to be transferred. Getting all that to happen smoothly will be 
a great challenge. Its hard enough if Charlie, like Bob, can handle all 
the media on a single device. If Charlie needs to aggregate some devices 
to handle all the media coming from Alice, then the problem becomes 
exceedingly complex.

Hence, IMO it remains far from clear that the new mechanism actually 
offers any benefits over the 3pcc mechanism. If you think it does 
(apparently you do) then I think it becomes necessary to compare the two 
in more detail. I think that requires nailing down in more detail how 
the important use cases should behave to an end user, and then how that 
behavior might be achieved using each technique. And then identifying 
gaps that need to be filled in each in order to have sufficient 
capability to achieve an equivalent and satisfactory result.

I think this analysis must also ensure that the resulting calls can work 
with other common features such as transfers, conferencing, "voice"mail, 
etc.

	Thanks,
	Paul

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 6 Jul 2009 10:28:57 -0700

Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jul 2009 16:43:14 -0400

Henry Sinnreich wrote:
> Actually there is one more: IM-ing a URI to some resource, mentioned by 
> Henning Schulzrinne (I don’t recall the document or presentation).
> 

Past suggestions by various people to send control signals (intended to 
be acted upon by automata rather than people) via IM have generally been 
rejected as inappropriate. (The exception so far has been file transfer, 
which has some control behavior and some expected human interaction.)

Now if you just want to say "Bob, please make a video call to 
sip:[email-masked] in order to see me" then I guess IM is ok. 
But IMO its not otherwise good. Its just a hack.

	Thanks,
	Paul

> ------------------------------------------------------------------------
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 6 Jul 2009 19:41:43 -0500

I think what Paul calls automata is the application on the IM client, so that would undermine what this spec and all of us in the Enterprise space have been trying to do for years.
 
I will note that the "istyping" indication is already done today with MESSAGE. And the istyping indicator is certainly an automata. And that is an RFC today, and is widly deployed.
 
I personally don't really care if its a MESSAGE, a REFER, or an INFO (although we certainly can rule out MBUS). Or a new message.
 
I don't think "other protocols" is a good answer: it has to be routable just like SIP.

	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: Monday, July 06, 2009 17:24
	To: Paul Kyzivat
	Cc: Audet, Francois (SC100:3055); Salvatore Loreto; [email-masked]
	Subject: Re: [dispatch] Disaggregated Media in SIP

	Paul Kyzivat wrote:
	>Past suggestions by various people to send control signals (intended tobe acted upon 
	>by automata rather than >people) via IM have generally been
	>rejected as inappropriate. 
	
	I am not sure how many people expect a usage scenario for IM with an automata in the middle or 
	what the deployment statistics are for such automata (I have never encountered one).  
	
	All SIP (or other protocol ) Communicator packages have IM and the URI works there very nicely.
	
	Do you have any usage statistics that justifies the assertion automata are the 
	key usage scenario and "plain person to person" IM does not count?
	
	Henry

	On 7/6/09 3:43 PM, "Paul Kyzivat" <[email-masked]> wrote:

		Henry Sinnreich wrote:
		> Henning Schulzrinne (I don't recall the document or presentation).
		>

		
		        Thanks,
		        Paul

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 6 Jul 2009 17:54:47 -0700

Francois Audet wrote:
>spec and all of us in the Enterprise space have been trying to do for years.

Now this makes sense.
But still, can you share some data of its real life usage, as compared to what is out today in various SIP Communicators? That would rule our the person-to-person IM scenarios?

>I don't think "other protocols" is a good answer: it has to be routable just like SIP.
This again makes sense to me.
(neglecting the facts about Jabber IM [such as in the IETF], Skype,  etc.)

Henry

On 7/6/09 7:41 PM, "Francois Audet" <[email-masked]> wrote:

Henry

        Thanks,
        Paul

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 6 Jul 2009 17:24:01 -0700

Henry

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2009 09:03:23 -0400

Henry Sinnreich wrote:
> key usage scenario and “plain person to person” IM does not count?
> 
> Henry

I don't know of one either.

But my observation is about using the IM message as a solution to the 
kinds of use cases that were presented in the draft, at least as I 
imagine them playing out.

My mental model is of an environment where a significant fraction of 
people have multimedia UAs, and an expectation that those various media 
will be available in calls that they make. Now add to that people who 
have support for various media, but not in a single device. They then 
want to play in that same multimedia environment.

In such a case, using IMs between people, so that they may establish 
separate calls for various media is clearly the poor man's choice - 
better than nothing but not ideal. And its especially poor if the 
"initial" call is not an IM call. Then just establishing an IM channel 
between the same two people is non-trivial.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2009 09:09:09 -0400

Francois Audet wrote:
> I think what Paul calls automata is the application on the IM client, so 
> that would undermine what this spec and all of us in the Enterprise 
> space have been trying to do for years.
>  
> I will note that the "istyping" indication is already done today with 
> MESSAGE. And the istyping indicator is certainly an automata. And that 
> is an RFC today, and is widly deployed.

It is not something that is clear cut. I can make a case for istyping - 
it is indeed a message intended for human eyes, it is just encoded 
differently from plain text so that the receiving application has more 
options in rendering it. In that respect it isn't so different from html.

> I personally don't really care if its a MESSAGE, a REFER, or an INFO 
> (although we certainly can rule out MBUS). Or a new message.

I still remain unconvinced that it is either necessary or appropriate 
for one end of a call to be involved in how the other end aggregates 
media resources for the call.

	Thanks,
	Paul

>     *From:* Henry Sinnreich [mailto:[email-masked]]
>     *Sent:* Monday, July 06, 2009 17:24
>     *To:* Paul Kyzivat
>     *Cc:* Audet, Francois (SC100:3055); Salvatore Loreto; [email-masked]
>     *Subject:* Re: [dispatch] Disaggregated Media in SIP
> 
>     Paul Kyzivat wrote:
>         problem
>         >      On top of that there are various proprietary mechanisms,
>         and even
>         >      some legacy
>         >      PBX-CTI protocols.
>         >
>         >      >  different devices under his or her control, so that
>         they are
>         >      >  treated by

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 7 Jul 2009 16:47:29 +0200

I understood the key distinction for MESSAGE method contents was not what generated it, but how it was treated on reception. The prime use of the MESSAGE method was where the contents were rendered to the user (even if they are generated by something that is an automata). If the contents were to be understood by some automata, then PUBLISH or SUBSCRIBE / NOTIFY may be more appropriate, or if there is an INVITE dialog around that pertains to the communication, then something else.

Hopever the multiple methods for similar purposes discussion in SIP never really resolved itself so I would say there is no definitive answer to this.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, July 07, 2009 2:09 PM
> To: Francois Audet
> Cc: Henry Sinnreich; [email-masked]
> > I think what Paul calls automata is the application on the 
> IM client, 
> > so that would undermine what this spec and all of us in the 
> Enterprise 
> It is not something that is clear cut. I can make a case for 
> istyping - it is indeed a message intended for human eyes, it 
> is just encoded differently from plain text so that the 
> receiving application has more options in rendering it. In 
> that respect it isn't so different from html.
> 
> I still remain unconvinced that it is either necessary or 
> appropriate for one end of a call to be involved in how the 
> other end aggregates media resources for the call.
> 
> 	Thanks,
> 	Paul
> 
> >     >Past suggestions by various people to send control 
> signals (intended
> >     tobe acted upon
> >     I am not sure how many people expect a usage scenario 
> for IM with an
> >     automata in the middle or
> >     what the deployment statistics are for such automata (I 
> have never
> >     encountered one).  
> > 
> >     All SIP (or other protocol ) Communicator packages have 
> IM and the
> >     URI works there very nicely.
> > 
> >         >  Actually there is one more: IM-ing a URI to some 
> resource,
> >         mentioned by
> >         rejected as inappropriate. (The exception so far 
> has been file
> >         transfer,
> >         sip:[email-masked] in order to see me" then 
> I guess IM
> >         is ok.
> >         >      three options, and describes why they are 
> not adequate. I
> >         agree with
> >         >      the conclusions.
> >         >
> >         >      >  Disaggregated media refers to the ability 
> for a user to
> >         create a
> >         >      >  multimedia session combining different 
> media streams,
> >         coming from
> >         >      >  Finally, this document describes 
> scenarios that are not
> >         covered by
> >         >      >  current mechanisms

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Jul 2009 10:22:04 -0500

> other end aggregates media resources for the call.

I don't understand what this statement means.

Everybody now has multiple devices these days.

With the amount of implementations of Remote Call Control 
using various proprietary mechanisms out there, it is pretty
clear that there is a need for this type of functionality.

That does not necessarily means that one end is necessarily involved
in how "the other end aggregates media resources". In my mind, it's
more of how do you share the session, and partition the media streams.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Jul 2009 10:44:18 -0500

Correct.
 
I agree with Henry. The bootstrap is typically the IM/Presence session, not the voice session. That would mean XMPP or SIMPLE.
 
To me this is a different than the "multiple device" issue, but they are quite intertwinned.
 
A scenario where you contact somebody using presence on a PC client or Web Page, or smart phone/PDA, perhaps IM, and then initiate a voice call using a desktop phone is a classic example.
 
In a "loosely coupled" model, all that you'd need from the PC Client/Web Page/Smart Phone/PDA is:

*	The ability to initiate the call using the alternate device
*	The ability to do basic control functions for the call using the primary (rich UI) interface, for that call on the alternate device: answer/terminate/hold/etc.

	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: Tuesday, July 07, 2009 08:23
	To: Paul Kyzivat
	Cc: Audet, Francois (SC100:3055); Salvatore Loreto; [email-masked]
	Subject: Re: [dispatch] Disaggregated Media in SIP

	Paul,
	
	This is getting interesting, so let's see...
	
	>better than nothing but not ideal. And its especially poor if the "initial" call is not an IM call. 
	>Then just establishing an IM channel
	
	No matter what type of communicator we use: SIP, Skype, Jabber, iChat, etc., most courteous people will first IM to ask if the other party can speak right now or later. While talking, they may also chose to add video. And if planned, also add desktop sharing.
	
	So the natural order of communications seems to be mostly: 
	Presence (or the web conference URI), IM, voice, video, desktop sharing, conferencing, but certainly it all starts with a URI for the rendezvous function.
	
	It seems we differ (or do we?) on three points:

	1.	Communicator "calls" are not the poor mans choice, 
	2.	It most often starts with presence and IM, 
	3.	The URI (or Skype name) of the other party in the address book is all that's required. Or the social network as an address book.

	Now leaving for a moment telephony aside, let's look at some new usage scenarios:

	*	People in social networks (Twitter, Facebook, etc.) 
	*	Telepresence (business) 
	*	Digital living room (consumer)

	It is a pretty safe guess that SIP PBX-style voice communications are not the right model for these emerging scenarios. I guess even contact centers for customer care may benefit from looking at the emerging Web applications for communications and especially for sharing of documents (having a URI). 
	Don't we often prefer to IM or email so as not to be tortured by IVR Hell?
	And even for voice, just to be called back by an agent?
	
	Now if we could only outlaw "automata"   :-)
	
	Henry

	On 7/7/09 8:03 AM, "Paul Kyzivat" <[email-masked]> wrote:

		

		
		        Thanks,
		        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2009 11:47:05 -0400

> more of how do you share the session, and partition the media streams.

My point is that between caller and callee there should be one sip 
session, with as many media streams as the two ends want to share. If 
you stick to that principle, then features such as various forms of 
transfer, conferencing, answering automata, etc. can all work is the 
same manner as they do when there is really only a single device.

If one, or both, ends needs to aggregate multiple devices to assemble 
its end of those media streams, then that is its problem, not a problem 
for the other end.

IMO, to a first level of approximation, 3pcc is sufficient to do that on 
one end when the devices contributing media support are sip devices. 
Certainly there is more that can be done to make that nicer, easier to 
use, etc. I'm uncertain if there is a need for standardization of that.

There may be some cases when I want to aggregate multiple devices of 
yours in order to provide you with a virtual multimedia device that I 
can then communicate with. But even then I would just view that as my 
setting up something separate for you in lieu of your doing it for 
yourself. I wouldn't view it as the normal course of events. Not one of 
Sal's use cases called for that.

	Thanks,
	Paul

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Jul 2009 10:56:48 -0500

> My point is that between caller and callee there should be 
> one sip session, with as many media streams as the two ends 
> want to share. If you stick to that principle, then features 
> such as various forms of transfer, conferencing, answering 
> automata, etc. can all work is the same manner as they do 
> when there is really only a single device.

I think that's OK for some scenarios (as per my previous email),
and low-level remote speaker/microphone/camera techniques may work.

But I don't believe it is sufficient.

In some cases, the complete opposite may be more appropriate, i.e.,
where both devices are bona fides SIP UAs with very "loosely coupled"
interactions between them.

That allows you to do things like take IM on one device and
voice on the other. Or initiate a call on one on behalf of the
other, and so forth.

But I agree with you that this must be done in a way that is
transparent to the other side. 

> If one, or both, ends needs to aggregate multiple devices to 
> assemble its end of those media streams, then that is its 
> problem, not a problem for the other end.
> 
> IMO, to a first level of approximation, 3pcc is sufficient to 
> do that on one end when the devices contributing media 
> support are sip devices. 
> Certainly there is more that can be done to make that nicer, 
> easier to use, etc. I'm uncertain if there is a need for 
> standardization of that.
> 
> There may be some cases when I want to aggregate multiple 
> devices of yours in order to provide you with a virtual 
> multimedia device that I can then communicate with. But even 
> then I would just view that as my setting up something 
> separate for you in lieu of your doing it for yourself. I 
> wouldn't view it as the normal course of events. Not one of

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2009 12:15:04 -0400

Henry Sinnreich wrote:
> Paul,
> 
> This is getting interesting, so let’s see...
> 
> No matter what type of communicator we use: SIP, Skype, Jabber, iChat, 
> etc., most courteous people will first IM to ask if the other party can 
> speak right now or later. While talking, they may also chose to add 
> video. And if planned, also add desktop sharing.

I don't think that most people consider that to be required of courteous 
people. AFAIK most people with cell phones don't send an SMS first to 
ask "can I call you?"

I think this is more a matter of differences in opinion about what the 
preferred medium of communication is. For some people it is definitely 
voice, for others IM or email. So people who consider IM their preferred 
mode of conversation may well IM first and then "escalate to voice" if 
that seems justified. I do that. And currently it often involves IMing a 
phone number. But I would much rather simply have an "add voice" button 
on my IM client.

I think we are just starting to get to the point where multimedia 
communication is common enough that we need to develop an etiquette for 
using it:
- how do we indicate and enforce our preferences of media?
- is it polite to request to receive video without offering
   to send it?
- is it ok to initiate addition of another medium to a call
   without first negotiating its use person to person via the
   existing media?

> Presence (or the web conference URI), IM, voice, video, desktop sharing, 
> conferencing, but certainly it all starts with a URI for the rendezvous 
> function.

I think that is just *your* natural order. (And probably mine too.) But 
not for the world at large. For many the natural order is: voice, then 
SMS if the voice doesn't work.

As long as people endeavor to have one URI that works for all the media 
they support, then that is indeed the starting point.

>    1. Communicator “calls” are not the poor mans choice,
>    3. The URI (or Skype name) of the other party in the address book is
>       all that’s required. Or the social network as an address book.

I've answered above. IMO there is no one answer to this.

If everyone had presence on every communication device they use, then it 
would likely be a starting point when it provided useful info. But note 
that I am unlikely to ever have presence data about all the people I 
want to communicate with.

> Now leaving for a moment telephony aside, let’s look at some new usage 
> scenarios:
> 
> It is a pretty safe guess that SIP PBX-style voice communications are 
> not the right model for these emerging scenarios. I guess even contact 
> centers for customer care may benefit from looking at the emerging Web 
> applications for communications and especially for sharing of documents 
> (having a URI).
> Don’t we often prefer to IM or email so as not to be tortured by IVR Hell?

As I noted earlier, we are in the very early stages of this because of 
the diversity of devices with varying capabilities. There currently is 
no least common denominator that is shared by all. The closest to one is 
probably still voice. And we still haven't converged the address spaces 
for these things. So its all very cumbersome.

I agree with you that there is a lot of room for progress in this space.

> Now if we could only outlaw “automata”   :-)

You can outlaw them for yourself. Personally I *like* automata that do 
useful services for me. Of note I very much like the automaton that 
answers voice calls, takes voice messages, and sends me an email with a 
text translation of the voice as well as the recorded audio.

The key is that it is an automaton that I have chosen to act as an agent 
on my behalf.

Maybe you don't want to talk to my automaton. That is fine. If you'd 
rather send me an email in the first place, that's fine too.

	Thanks,
	Paul

>     >      >  My two cents is that IM-ing a URL is the most general
>     solution, or
>     >      is it?
>     >
>     >      >      I see that this draft doesn't propose a solution to
>     problem:
>     >      it list
>     >      >      On top of that there are various proprietary
>     mechanisms, and even
>     >      >      some legacy
>     >      >      PBX-CTI protocols.
>     >      >
>     >      >      >  [mailto:[email-masked]] On Behalf Of
>     Salvatore
>     >      Loreto

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Jul 2009 10:51:57 -0500

You asked for real-life data.

I've seen many ways to achieve this type of "remote call control" functionality:

1 - Proprietary Master/Slave protocols

	This is similar to H.248, but proprietary. Specifically, when in 
      "remote control mode", the device (e.g.., a phone) sees the UA 
	(e.g. a PC client) as it's "PBX". In this mode, the Phone is not 
	a SIP UA anymore in control mode. When control is relinquished, 
	Phone re-SIPifies itself.

2 - CTI-like protocols

	Things like ECMA TR-87 (CSTA tunnelled over SIP). The two devices remain
	SIP UAs at all time, and attempt to "coordinate" their state.

3 - Layer 1/2 integration

	The device on the LAN is seen as a peripheral (i.e., remote speaker/
	microphone/camera) to the device (e.g., PC) controlling it, when
	in control mode. Typically, this is USB or Bluetooth, or some emulation
	over Ethernet. Like number 1, the Phone is not a SIP UA anymore in 
	control mode. When control is relinquished, Phone re-SIPifies itself. 

4 - SIP extensions/B2BUA

	You can do a lot directly with SIP, if you have a B2BUA, but it is
	non-trivial.

Number 3, and we don't need to standardized anything at IETF for this.

I do not think that it is adequate for all applications, and a much more 
loosely coupled mechanism is what we would need for those applications.
And by "loosely coupled", I really mean it: not media control. More like
session sharing, where each UA ultimately retains control over their own destiny.

Something akin to Feature Referal. It could be based on presence or other 
mechanisms.

	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: Monday, July 06, 2009 17:55
	To: Audet, Francois (SC100:3055); Paul Kyzivat
	Cc: Salvatore Loreto; [email-masked]
	Subject: Re: [dispatch] Disaggregated Media in SIP

	Now this makes sense. 

	Henry

		

			

			

			
			Henry

			

				

				
				        Thanks,
				        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2009 12:44:22 -0400

> transparent to the other side. 

We aren't communicating very well.
I can't piece together the things you say above into a coherent whole.

But apparently we agree on the key point - that this should be invisible 
to the other "side". Maybe we should just start there, since I don't 
think Sal agrees with that. At least his draft, and its predecessors, don't.

If we can agree that one communication session between two parties has 
one sip session *between them*, then we can work on what the 
architecture should be like at each end.

Of course you are still free to make multiple concurrent "calls" between 
the same two parties. But if you do, they are unrelated, except perhaps 
in your head.

	Thanks,
	Paul

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 7 Jul 2009 08:23:26 -0700

Paul,

Henry

        Thanks,
        Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Jul 2009 12:49:04 -0500

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, July 07, 2009 09:44
> To: Audet, Francois (SC100:3055)
> Cc: Henry Sinnreich; Salvatore Loreto; [email-masked]
> Of course you are still free to make multiple concurrent 
> "calls" between the same two parties. But if you do, they are 
> unrelated, except perhaps in your head.

Actually, the "in your head" part is important.

If it is "loosely coupled", then you don't need to do complex state synchronization,
because, as you say, it is "done in your head".

If I have my PC client, and I click "Make call" or "Answer" or something similar,
it just needs to tell my Phone to do do so.

That's what I mean by "loose coupling".

The other guy on the other end sees your Phone in this case.

For "Make call", it's just a SIP INVITE coming from the Phone.

For "Answer", the INVITE from the guy gets forked, the PC client tells the
phone to send a 200. 

We don't have to make this complicated.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2009 14:16:26 -0400

Inline

> We don't have to make this complicated.

Most of those examples aren't of multimedia at all - they are just 
remote control of a pt-pt call.

And the "in your head" part also means that call control actions, such 
ans transfer, don't work on the collection - just on an individual one. 
And recordings won't know the association between them either.

Nevertheless, I'm not opposed to such things. They all can have a place.

To get anywhere on this I think we need to concentrate on some use 
cases. The ones in Sal's draft are a reasonable starting point. For 
instance:

>    using her multimedia phone.  Two SIP dialogs need to be established:
>    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.

To address this without bothering Bob, *something* on Laura's end must 
have the intelligence to coordinate this. And then there must be some 
communications to set it all up.

- we might assume the desk phone, while media poor, is intelligent
   and can handle all the setup. This might be realistic in some cases,
   but probably not often.

- or we might assume that the softphone on her desk is smart enough
   and has a rich enough UI, to handle this. I find that more likely.

Assuming the latter, I can image it popping up a user dialog when it 
receives the INVITE, offering some options of how to handle the call.
(Of course the desk phone is probably ringing too.)
One of the options might be to recruit the desk phone for audio. So 
Laura might just need to click something to select the call setup that 
the use case describes. Then the softphone would answer the call. There 
would be some sort of signaling to incorporate the desk phone, but that 
would all be hidden from Bob. We can discuss what sorts of signaling 
would be good to accomplish this. (I think it sounds like an excellent 
task for BLISS.)

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 08 Jul 2009 10:12:04 +0100

Sal,

Thanks for writing this. The centralised approach is what I and some
others have been suggesting over the past months. It is good to see a
comparison between the centralised approach (in its various flavours)
and the distributed approach that you have been advocating for some
time.

It seems the biggest issue for deciding whether or not to work on the
distributed approach is whether there is a need for the "master" device
(the one operating SIP) to drop out of the call, while allowing the call
and certain media to continue at other devices. 

I still have a concern that with the distributed approach the remote end
of the call needs to exhibit special behaviour in order to handle the
multiple dialogs arising from the distributed approach (as Paul also
notes). So in practice, to make it work with any degree of reliability,
calls will need to go through a B2BUA that provides the necessary
aggregation. So it effectively ends up as a centralised approach anyway.

The distributed approach (section 4) is not really described in enough
detail. There still has to be some communication between Alice's UAs,
e.g., to convey information to a UA to be added to the call to allow it
to make a call to Bob and allow Bob to associate the new call with the
existing call. Also if Alice wants to clear all calls (i.e., all
components of the same call) with one button push, there needs to be
some communication between the UAs.

John

John

> Sent: 06 July 2009 17:33

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 10 Jul 2009 15:42:28 -0400

> media resources for the call.

To support this, I would say that a *primary* requirement for a solution
should be that the "other end" does not have to be aware how "this end"
is arranging for multiple media source/sinks.  Otherwise, there is no
interoperability with UAs that do not understand the aggregation scheme.

Reading some of the discussion, I realized there is already a *very*
common instance of disaggregated media:  music-on-hold.  UA X puts a
call on hold, and then arranges for the music-on-hold source to send RTP
to UA Y.  The entire design problem for music-on-hold is arranging for
UA Y *not* to have to understand what is going on.

A typical solution is
http://tools.ietf.org/html/draft-worley-service-example-03.  We've had
luck getting phone manufacturers to implement this, and there are a
number of similar schemes that other phones use.

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 20 Jul 2009 12:55:57 +0300

Hi Paul,

> that this should be invisible 
> to the other "side".

while this is of course a good thing when it can be achieved, it cannot 
be an absolute requirement for solutions to a given problem. Otherwise, 
SIP would not have mechanisms such as the Require header field. That is, 
while in many deployment scenarios you want to be able to deploy things 
incrementally taking advantage of extensions even if only one UA support 
them, in others you can actually update all your UAs to support a new 
extension.

Salvatore has described deployment scenarios where UAs can be upgraded 
to support a new extension. I think we should consider them if they can 
take advantage of extra functionality when compared with other scenarios 
where this cannot be done... that is why we included Require header 
fields in SIP's original design.

Cheers,

Gonzalo

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 20 Jul 2009 14:11:18 +0300

Hi Paul,

> architecture should be like at each end.
that would be a work to improve the centralized scenario and perhaps 
making it possible without using 3pcc
or solving the current 3pcc limitations and them to make it nicer and 
easier to use.

However I still think it would be useful to work on a decentralized 
scenario, moreover there could be scenario where knowing
how one end aggregates media resource for the call will help the other 
end to better decide how to manage (i.e. answer) the call .

thanks
Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 20 Jul 2009 14:25:42 +0300

Hi John,

see my answers in line

thanks
Sal

> and certain media to continue at other devices. 
exactly! this is one of the main 3pcc issue, but not the only one;

> aggregation. So it effectively ends up as a centralised approach anyway.
well, if the other end does not support a distributed approach then you 
can not use it.
> some communication between the UAs.
right, how the different user devices of one end coordinate and convey 
information
each other in a distributed scenario is something that needs to need to 
be analysed and describe in more
details.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jul 2009 09:05:51 -0400

Gonzalo Camarillo wrote:
> Hi Paul,
> 
>> that this should be invisible to the other "side".
> 
> SIP would not have mechanisms such as the Require header field.

I'm not trying to assert that this is a criterion that is appropriate 
for all problems - just that it is appropriate for *this* problem.

Some problems cannot be solved without the collaboration of both ends, 
and in that case, if the feature is not one that all UAs must have then 
some sort of negotiation to determine whether the two ends support it is 
needed.

But in this case it can be shown that the capability *can* be managed on 
one end without the assistance of the other end. And doing it that way 
vastly increases the interoperability over an approach that requires the 
support of both ends.

> That is, 

I still haven't seen anything showing why this approach ends up being 
"better" than the "centralized" approach. (Note that I don't agree with 
the term "centralized", because it isn't really more centralized than 
the "distributed" approach is. This would become clearer if we looked at 
all the communications necessary to establish a call with disaggregated 
media, and the various topologies of devices that might play in such 
scenarios.)

Perhaps we should back off from the signaling mechanisms for the moment 
and consider the use cases of interest in more detail, and the various 
sorts of communications between them that are necessary to establish a 
call that involves them.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jul 2009 09:20:18 -0400

> end to better decide how to manage (i.e. answer) the call .

I will try to keep an open mind, but I suspect we have a fundamental 
disagreement here. IMO there is a fundamental architectural property at 
stake here. IMO the point is as much as possible to add capabilities 
without increasing the complexity of the fundamentals - use what we have 
as building blocks when we can. Only when that is found to be fatally 
flawed should we be adding more stuff for everybody to implement.

IMO there will be many devices that want to support multimedia than 
those that have need to support disaggregated media. Its a bad thing if 
those can't participate in multimedia calls with devices that have need 
support from multiple devices to achieve multimedia capability.

I guess the one way I could buy into your "distributed" approach is to 
simply model it as a conference, where the focus is at one "end". But I 
think we discussed that once.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jul 2009 11:05:13 +0300

Hi Paul,

it is good that we agree that some problems need both ends to 
collaborate. Now, let's discuss whether or not that is the case with 
*this* problem.

> media, and the various topologies of devices that might play in such 

well, 3pcc is centralized because you have a (central) controller that 
is in control of all SIP signalling. If that controller leaves the 
session, the whole session disappears. An approach where several devices 
have their own SIP dialog with the remote devices is not centralized 
because you can remove any of them and the other sessions will remain 
unaffected.

> sorts of communications between them that are necessary to establish a 

The arguments have been discussed several times. The thing is that 3pcc 
is a complex mechanism that is not supported by most UAs. You can argue 
about its complexity, but the fact that most UAs do not support 3pcc is 
a fact.

There are folks that are willing to implement support for a correlation 
mechanism for dialogs but would not implement 3pcc because (they think) 
it is too complicated.

A second argument is that any device should be able to leave the session 
at any point. If you want the 3pcc controller to leave the session while 
the session remains established, you will need to use a complex 
combination of REFER and Replaces that very few (if any) UAs support.

Therefore, the requirement here is that the mechanism should not be so 
complicated that implementers do not actually want to implement it :o) 
... unfortunately, as we all know too well, we have a history of doing 
just that.

Cheers,

Gonzalo

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Jul 2009 13:42:31 +0100

Gonzalo,

I have already expressed opinions similar to Paul on several occasions.
Experience tells us we cannot rely on the remote UA supporting a
particular feature. Taking REFER as an example, we tend to end up with a
B2BUA terminating a REFER request, because:
- the remote UA doesn't support REFER;
- some UAs don't support REFER, so if the B2BUA sometimes needs to
terminate REFER to accommodate those UAs, it might as well always
terminate REFER;
- some UAs don't accept REFER as a matter of policy.

So B2BUAs tend to act as an anchor point and terminate REFER requests,
behaving in a 3PCC-like manner.

If the distributed form of disaggregated media goes ahead, I think that
is what will happen in practice, i.e., a B2BUA will need to act as the
anchor point. If UAs wanting to use disaggregated media are behind a
B2BUA that concentrates the multiple dialogs into a single ongoing
dialog towards the remote UA, that will work. It does indeed have the
benefit that one local UA can drop out, leaving the other local UA(s)
still in communication with the remote UA. Relying on the remote UA
supporting distributed disaggregated media I fear will prevent the
capability being used in many cases where it might be required.

As part of specifying distributed disaggregated media, we will need to
pay attention to all the interactions that can occur when both sides
attempt to use disaggregated media, particular when the two sides
simultaneously try to add or remove UAs. This sounds like a difficult
problem, but I may be wrong. Having an anchor point (thereby making it
centralised, in a way) would probably ease these problems.

John

> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: 21 July 2009 09:05
> To: Paul Kyzivat
> Cc: [email-masked]; Henry Sinnreich

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jul 2009 17:36:47 +0300

Hi John,

many UAs already support multiple SIP dialogs in parallel. Adding a 
header that instruct them to treat the media sessions related to those 
dialogs as a single one is much easier than anything you have described 
in your email.

The point is that people are going to implement something like this 
because it is fairly simple and it is needed. We can either design a 
mechanism that meets their simplicity requirement or propose complex 
mechanisms that, as usual, will not get implemented.

Cheers,

Gonzalo

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Jul 2009 16:35:14 +0100

Gonzalo,

Well, my concern is that it might not be as simple as described when
both sides use multiple UAs. If I am using 2 UAs, and you are using 2
UAs, presumably we end up with 4 dialogs - correct?

John 

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 21 July 2009 15:37
> To: Elwell, John
> Cc: Paul Kyzivat; [email-masked]; Henry Sinnreich

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jul 2009 19:23:50 +0300

Hi,

> both sides use multiple UAs. 

there are two aspects: device coordination among a user's devices and 
dialog association.

> If I am using 2 UAs, and you are using 2

Not necessarily. The draft has several use cases. For example, you can 
use a pair of SIP-enabled speakers to play out my voice and a 
SIP-enabled giant screen while I send you audio from my mobile phone and 
video from an external SIP-enabled camera. In this case, there would be 
two dialogs: one from my camera to your screen and one from my mobile 
phone to your speakers.

Cheers,

Gonzalo

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jul 2009 12:11:55 -0500

I agree with Gonzalo.

I my opinion, we need a very loosely coupled mechanism for this. Something very
simple.

People who need a "centralized" approach will continue to use 3PCC. Typically,
those are not simple UAs like phones because of complexity, but Call Centers
and the likes. This is a different problem.

> Sent: Tuesday, July 21, 2009 01:05
> To: Paul Kyzivat
> Cc: Audet, Francois (SC100:3055); Henry Sinnreich; [email-masked]
> > "better" than the "centralized" approach. (Note that I don't agree 
> > with the term "centralized", because it isn't really more 
> centralized 
> > than the "distributed" approach is. This would become clearer if we 
> > looked at all the communications necessary to establish a call with 
> > disaggregated media, and the various topologies of devices 
> that might 
> > play in such
> > scenarios.)
> 
> well, 3pcc is centralized because you have a (central) 
> controller that is in control of all SIP signalling. If that 
> controller leaves the session, the whole session disappears. 
> An approach where several devices have their own SIP dialog 
> with the remote devices is not centralized because you can 
> remove any of them and the other sessions will remain unaffected.
> 
> > Perhaps we should back off from the signaling mechanisms for the 
> > moment and consider the use cases of interest in more 
> detail, and the 
> > various sorts of communications between them that are necessary to 
> > establish a call that involves them.
> 
> The arguments have been discussed several times. The thing is 
> that 3pcc is a complex mechanism that is not supported by 
> most UAs. You can argue about its complexity, but the fact 
> that most UAs do not support 3pcc is a fact.
> 
> There are folks that are willing to implement support for a 
> correlation mechanism for dialogs but would not implement 
> 3pcc because (they think) it is too complicated.
> 
> A second argument is that any device should be able to leave 
> the session at any point. If you want the 3pcc controller to 
> leave the session while the session remains established, you 
> will need to use a complex combination of REFER and Replaces 
> that very few (if any) UAs support.
> 
> Therefore, the requirement here is that the mechanism should 
> not be so complicated that implementers do not actually want 
> to implement it :o) ... unfortunately, as we all know too 
> well, we have a history of doing just that.
> 
> Cheers,
> 
> Gonzalo
> 
>

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 21 Jul 2009 12:22:12 -0700

I would agree with Paul and John. There's a well established way of 
handling multiple media streams in SIP - part of SIP since the 
beginning. Don't tamper with that. If someone wants to disaggregate the 
streams they should be the ones to pay for it - by dealing with the 
added complexity and the changes to the existing model.

Plus I'd be very skeptical about claims that the alternative is simple. 
For example, how do you transfer an audio+video call that is actually 
two SIP dialogs? Now all of a sudden there are additional failure modes 
because the dialogs have to be transferred separately and can succeed or 
fail independently.

Existing UAs may already support simultaneous dialogs. If they're 
independent calls then that's not at all the same thing.

Thanks,
Anders

Gonzalo Camarillo wrote:
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Gonzalo Camarillo
>>> Sent: 21 July 2009 09:05
>>> To: Paul Kyzivat
>>> well, 3pcc is centralized because you have a (central) controller 
>>> that is in control of all SIP signalling. If that controller leaves 
>>> the session, the whole session disappears. An approach where several 
>>> devices have their own SIP dialog with the remote devices is not 
>>> centralized because you can remove any of them and the other sessions 
>>> will remain unaffected.
>>>
>>> The arguments have been discussed several times. The thing is that 
>>> 3pcc is a complex mechanism that is not supported by most UAs. You 
>>> can argue about its complexity, but the fact that most UAs do not 
>>> support 3pcc is a fact.
>>>
>>> correlation mechanism for dialogs but would not implement 3pcc 
>>> because (they think) it is too complicated.
>>>
>>> A second argument is that any device should be able to leave the 
>>> session at any point. If you want the 3pcc controller to leave the 
>>> session while the session remains established, you will need to use a 
>>> complex combination of REFER and Replaces that very few (if any) UAs 
>>> support.
>>>
>>> Therefore, the requirement here is that the mechanism should not be 
>>> so complicated that implementers do not actually want to implement it 
>>> :o) ... unfortunately, as we all know too well, we have a history of 
>>> doing just that.
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jul 2009 23:40:08 -0500

Well, that particular example is already supported in SIP with
the REFER method. This is not an issue.

It's other things, like, "please answer dialog X" or "please
kill dialog Y" that are an issue. 

> [mailto:[email-masked]] On Behalf Of Anders Kristensen
> Sent: Tuesday, July 21, 2009 12:22
> To: Gonzalo Camarillo
> I would agree with Paul and John. There's a well established 
> way of handling multiple media streams in SIP - part of SIP 
> since the beginning. Don't tamper with that. If someone wants 
> to disaggregate the streams they should be the ones to pay 
> for it - by dealing with the added complexity and the changes 
> to the existing model.
> 
> For example, how do you transfer an audio+video call that is 
> actually two SIP dialogs? Now all of a sudden there are 
> additional failure modes because the dialogs have to be 
> transferred separately and can succeed or fail independently.
> 
> Existing UAs may already support simultaneous dialogs. If 
> they're independent calls then that's not at all the same thing.
> 
> Thanks,
> Anders
> 
> Gonzalo Camarillo wrote:
> > Hi John,
> > 
> > dialogs as a single one is much easier than anything you have 
> > described in your email.
> > 
> >> particular feature. Taking REFER as an example, we tend to end up 
> >> with a B2BUA terminating a REFER request, because:
> >> So B2BUAs tend to act as an anchor point and terminate REFER 
> >> requests, behaving in a 3PCC-like manner.
> >>
> >> If the distributed form of disaggregated media goes ahead, I think 
> >> that is what will happen in practice, i.e., a B2BUA will 
> need to act 
> >> as the anchor point. If UAs wanting to use disaggregated media are 
> >> behind a B2BUA that concentrates the multiple dialogs into 
> a single 
> >> ongoing dialog towards the remote UA, that will work. It 
> does indeed 
> >> have the benefit that one local UA can drop out, leaving the other 
> >> local UA(s) still in communication with the remote UA. 
> Relying on the 
> >> remote UA supporting distributed disaggregated media I fear will 
> >> prevent the capability being used in many cases where it 
> might be required.
> >>
> >> As part of specifying distributed disaggregated media, we 
> will need 
> >> to pay attention to all the interactions that can occur when both 
> >> sides attempt to use disaggregated media, particular when the two 
> >> sides simultaneously try to add or remove UAs. This sounds like a 
> >> difficult problem, but I may be wrong. Having an anchor point 
> >> (thereby making it centralised, in a way) would probably 
> ease these problems.
> >>
> >> John
> >>
> >>> centralized because you can remove any of them and the other 
> >>> sessions will remain unaffected.
> >>>
> >>> session while the session remains established, you will 
> need to use 
> >>> a complex combination of REFER and Replaces that very few 
> (if any) 
> >>> UAs support.
> >>>
> >>> so complicated that implementers do not actually want to 
> implement 
> >>> it

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 21 Jul 2009 22:23:05 -0700

> the REFER method. This is not an issue.

Are you saying that in this example a single REFER will work because the 
triggered INVITE will contain both audio and media streams? Maybe so. 
However, other aspects of transfer flows will be impacted. The Replaces 
header field can refer to just one dialog, for example.

Anders

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Jul 2009 08:56:54 +0300

Hi,

> beginning. Don't tamper with that. 

yes, it exists in an imaginary world that some IETFers live in. If you 
check in the real world, no UAs support that type of functionality. If 
we IETF specs to become irrelevant, continuing living in such imaginary 
world and ignoring reality is the best way forward.

> because the dialogs have to be transferred separately and can succeed or 

We have mechanisms to deal with transfers of a single dialog. That is 
what you would do; exactly the same as in the 3pcc model: you transfer 
each dialog to its new location.

> independent calls then that's not at all the same thing.

That is exactly my point. Existing UAs *already* support multiple 
dialogs. Presenting the video stream established by one dialog and the 
IM stream established by the other one as if they were a single session 
is *very* simple and, at the protocol level, it can also be implemented 
with a simple mechanism. All the alternatives given (e.g., 3pcc) are not 
currently supported and are way more complex.

Cheers,

Gonzalo

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Jul 2009 01:11:08 -0500

That is correct. I don't see separating audio and video for a single call
to be desireable (for example).

In my mind, the term "disaggregated media" is a misnomer. It's really
"loosely coupled control" that is useful.

> From: Anders Kristensen [mailto:[email-masked]] 
> Sent: Tuesday, July 21, 2009 22:23
> Cc: Gonzalo Camarillo; Henry Sinnreich; [email-masked]
> > Well, that particular example is already supported in SIP with the 
> > REFER method. This is not an issue.
> 
> Are you saying that in this example a single REFER will work 
> because the triggered INVITE will contain both audio and 
> media streams? Maybe so. 
> However, other aspects of transfer flows will be impacted. 
> The Replaces header field can refer to just one dialog, for example.
> 
> Anders
> 
> > 
> > It's other things, like, "please answer dialog X" or "please kill 
> > dialog Y" that are an issue.
> > 
> >> beginning. Don't tamper with that. If someone wants to 
> disaggregate 
> >> the streams they should be the ones to pay for it - by 
> dealing with 
> >> the added complexity and the changes to the existing model.
> >>
> >> two SIP dialogs? Now all of a sudden there are additional failure 
> >> modes because the dialogs have to be transferred 
> separately and can 
> >> succeed or fail independently.
> >>
> controller

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Jul 2009 09:21:39 +0300

Hi,

> to be desireable (for example).

exactly. Regular UAs would continue establishing multi-stream sessions 
as usual (i.e., using a single dialog). You would only have multiple 
dialogs when multiple SIP-enabled devices are involved in the communication.

> "loosely coupled control" that is useful.

yes, that would be a valid term as well.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jul 2009 10:08:53 -0400

Gonzalo,

I haven't seen any response to Anders' issue about what happens if both 
ends want to use disaggregated media.

Nor have I seen any explanation of where the control resides that 
initiates and coordinates the inclusion of multiple media sources into 
call. *Something* must be capable of saying "I want device X to join 
call Y using media Z". That is still a centralized point of control even 
if it isn't directly in the resulting sip signaling flow. Either it is 
using some exotic form of REFER to cause this to happen, or else it is 
using some kind of private signaling.

Also, if a multimedia call is received by a UAS, and the UAS needs to 
use disaggregated media to cope with the offered media types, how will 
that work? Will some of the media be refused initially, and then offered 
back in a new INVITE going in the reverse direction?

There are a *lot* of details here that need to be worked out for this 
approach to be functional. OTOH, if the "centralized" approach is used 
then it all devolves to use of stuff we already have.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jul 2009 10:12:52 -0400

> world and ignoring reality is the best way forward.

I had this functionality working in about 2002. We didn't productize it, 
but it was functional.

	Thanks,
	Paul

>> Plus I'd be very skeptical about claims that the alternative is 
>> simple. For example, how do you transfer an audio+video call that is 
>> actually two SIP dialogs? Now all of a sudden there are additional 
>> failure modes because the dialogs have to be transferred separately 
>> and can succeed or fail independently.
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Jul 2009 10:17:02 -0500

> Sent: Wednesday, July 22, 2009 07:09
> To: Gonzalo Camarillo
> Cc: Audet, Francois (SC100:3055); Anders Kristensen; Henry 
> Sinnreich; [email-masked]
> I haven't seen any response to Anders' issue about what 
> happens if both ends want to use disaggregated media.
> 
> Nor have I seen any explanation of where the control resides 
> that initiates and coordinates the inclusion of multiple 
> media sources into call. *Something* must be capable of 
> saying "I want device X to join call Y using media Z". That 
> is still a centralized point of control even if it isn't 
> directly in the resulting sip signaling flow. Either it is 
> using some exotic form of REFER to cause this to happen, or 
> else it is using some kind of private signaling.

I don't think we need/want the "...using media Z" part.

I truely believe that this makes it too complicated.

Again, loose coupling.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Jul 2009 18:54:16 +0300

Hi Paul,

> I had this functionality working in about 2002. We didn't productize it, 

yes, I also have a lot of proof-of-concept prototypes in my lab that 
implement stuff that never makes it into a product for different reasons 
;o)... as a matter of fact, I can have a student implement a header that 
correlates two dialogs on top of a UA that already supports multiple 
dialogs in no time.

However, this is not what we are discussing here. We are discussing 
specifications that will see actual deployment.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jul 2009 12:51:02 -0400

> I don't think we need/want the "...using media Z" part.

Well, as I understand them, most or all of the use cases in the draft 
would require some sort of instruction to the secondary device to tell 
it what media to use, because it would otherwise use media that the use 
case assumes it will not use.

> I truely believe that this makes it too complicated.

All the more reason to ensure we agree on a goal set of use cases so we 
can be sure there is a mechanism sufficiently rich to support them 
without being unnecessarily complicated. Its no good to do something 
simple if it doesn't solve a problem.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Jul 2009 12:33:31 -0500

The more I hear from the mailing list, the more I think we 
might have more than one goal.

So we may need multiple solutions. 

> Sent: Wednesday, July 22, 2009 09:51
> Cc: Gonzalo Camarillo; Anders Kristensen; Henry Sinnreich; 
> [email-masked]
> >> I haven't seen any response to Anders' issue about what happens if 
> >> both ends want to use disaggregated media.
> >>
> >> initiates and coordinates the inclusion of multiple media sources 
> >> into call. *Something* must be capable of saying "I want 
> device X to 
> >> join call Y using media Z". That is still a centralized point of 
> >> control even if it isn't directly in the resulting sip signaling 
> >> flow. Either it is using some exotic form of REFER to 
> cause this to 
> >> happen, or else it is using some kind of private signaling.
> > 
> Well, as I understand them, most or all of the use cases in 
> the draft would require some sort of instruction to the 
> secondary device to tell it what media to use, because it 
> would otherwise use media that the use case assumes it will not use.
> 
> All the more reason to ensure we agree on a goal set of use 
> cases so we can be sure there is a mechanism sufficiently 
> rich to support them without being unnecessarily complicated. 
> Its no good to do something simple if it doesn't solve a problem.
> 
> 	Thanks,
> 	Paul
> 
> > Again, loose coupling.
> > 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 Jul 2009 13:41:46 +0300

Hi Paul,

> into call. *Something* must be capable of saying "I want device X to
> flow. Either it is using some exotic form of REFER to cause this to

yes, you could use REFER as you suggest, although (as Francois also
pointed out) I would remove the "using media Z" bit. When we designed
REFER, we agreed not to include that type of stuff because applications
typically know what to include based on the context in which the REFER
is received.

You could also use some type of private signalling if you want. There is
nothing that precludes that. If you want to use your proprietary 
protocol for local coordination, you can do that.

>  use disaggregated media to cope with the offered media types, how
> will that work? Will some of the media be refused initially, and then
> offered back in a new INVITE going in the reverse direction?

Yes, this could be implemented like that.

>  approach to be functional.

I would have loved to discuss all those details earlier (we submitted
our first draft about this a long time ago) but folks did not want to
even consider using something else than 3pcc. Once we agree that 3pcc is
not the only way to do things, we can work out the details.

Note that when we introduced SIP more than 10 years ago many people did
not like the fact that media was simply loosely coupled with the
signalling. They wanted a tighter coupling... it seems we will have to
go through similar discussions once more ;o)

You wrote in another message:

> All the more reason to ensure we agree on a goal set of use cases so
> we can be sure there is a mechanism sufficiently rich to support them

Yes, agreeing on use cases would be great. That's why the draft has a 
section with use cases. Fell free to propose new ones or send comments 
on the existing ones.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jul 2009 09:37:01 -0400

> not the only way to do things, we can work out the details.

I find the *use cases* interesting and worthy of discussing independent 
of the mechanism used to achieve them. Either approach requires some 
coordination among the disaggregated devices. With the 3pcc approach 
there is the possibility of using sip to do the coordination, but its 
still worth investigation since that may not provide the dieal user 
experience.

So I'm not really conceding that the proposed solution is necessary, or 
even desirable to address the use cases. But I do think that 
investigating the use cases is a good way to get beyond individual 
opinions on the subject.

> section with use cases. Fell free to propose new ones or send comments 

I didn't comment because I liked them.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 23 Jul 2009 14:13:14 -0400

> because you can remove any of them and the other sessions will remain 

It's true that if the implementation is a single dialog, then the UA at
each end must remain in the call.  For a UA to replace itself with
another UA would require a transfer-like process.

The difficulty (under either implementation) is to transfer the "state"
information (which media stream goes to which destination) from one
controller to another.  That need is obvious in the centralized
approach, but it seems to me that it would also be needed in the
decentralized approach.

> about its complexity, but the fact that most UAs do not support 3pcc is 

This does not seem to be true to me.  Phones that support MOH from an
external server are doing 3pcc.  In addition, we expect phones to
support REFER and INVITE-with-Replaces.

> combination of REFER and Replaces that very few (if any) UAs support.

As a matter of course, we expect our customers to buy phones that
support both of these.

I suspect the use case that truly distinguishes these implementations is
where there is a "controller" at one end, that is, a UA that understands
the aggregation, but there is no controller at the other end.

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 Jul 2009 16:47:41 +0300

Hi Paul,

yes, let's focus on the use cases and how they could be implemented.

Cheers,

Gonzalo

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 24 Jul 2009 12:11:01 +0300

> approach, but it seems to me that it would also be needed in the
the need or not to transfer the "state" really depends on how the 
decentralized approach will be designed.

for example:
In a "loosely coupled control" approach, as Francois is proposing, you 
don't have any "state" information that
need to be transferred from one to another because you don't have a real 
controller.
Another possibility would be to have a "fully distributed approach", 
where the "information state" does not reside
in one single UA, but is in somehow spread among all the UAs involved in 
the disaggregate media.

/Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jul 2009 09:02:53 -0400

> need to be transferred from one to another because you don't have a real 

I don't understand that.

Suppose Alice calls Bob using her voice phone. Then she arranges for her 
laptop to join the call with Bob to add voice. (Bob has a video phone.)

Then Bob decides to do a consultative transfer of the call to Charlie. 
Because Bob's phone is a video phone, its UI presumably treats this as a 
single call, even if there are actually two calls behind the scenes. So 
Bob first puts the call with Alice on hold. It already has to know to do 
this on two separate calls. Then it calls Charlie, who also has a video 
phone. So there is an audio+video call from Bob to Charlie. Then Bob 
asks to complete the transfer. What does it do? Normally it would send a 
REFER to Charlie's phone, asking it to do an INVITE/Replaces to Alice. 
But there are two calls to Alice.

The "state" of the call, that it is distributed across two dialogs, is 
important info that needs to be transferred to Charlie given this 
implementation approach. With the "centralized" approach that state 
resides in Alice's realm and is of no concern to either Bob or Charlie.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 26 Jul 2009 14:22:10 +0300

Hi,

> think we discussed that once.

that is how it is modeled when only one of the ends is distributed. What 
we discussed was that the semantics of join were intended for 
conferences and that even though this was very similar, it was not the 
same thing... but the model is valid.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jul 2009 09:23:04 -0400

Gonzalo Camarillo wrote:
>> simply model it as a conference, where the focus is at one "end". But 
>> I think we discussed that once.
> 

If the model is valid, then I think the mechanisms that go with it 
should be valid too.

The conferencing mechanism could be used for either the "distributed" or 
"centralized" approach. Then there needs to be a focus somewhere, and 
the difference between the approaches is where it resides - at your own 
end, or at the "other" end.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 09:55:16 +0200

Hi Paul,

yes, what you say is totally correct when one of the endpoints is not 
distributed. That case should be relatively-easy to resolve. The case 
where both ends are distributed is, of course, more "interesting" ;o)

Cheers,

Gonzalo

Paul Kyzivat wrote:
> 
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>>> I guess the one way I could buy into your "distributed" approach is 
>>> to simply model it as a conference, where the focus is at one "end". 
>>> But I think we discussed that once.
>>
>> that is how it is modeled when only one of the ends is distributed. 
>> What we discussed was that the semantics of join were intended for

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 28 Jul 2009 11:26:34 +0300

Paul Kyzivat wrote:
>>>> the session, the whole session disappears. An approach where 
>>>> several devices have their own SIP dialog with the remote devices 
>>>> is not centralized because you can remove any of them and the other 
>> In a "loosely coupled control" approach, as Francois is proposing, 
>> you don't have any "state" information that
>> need to be transferred from one to another because you don't have a 
>> real controller.
>
> I don't understand that.
>
> Suppose Alice calls Bob using her voice phone. Then she arranges for 
> her laptop to join the call with Bob to add voice. (Bob has a video 
> phone.)
>
> Because Bob's phone is a video phone, its UI presumably treats this as 
> a single call, even if there are actually two calls behind the scenes. 
> So Bob first puts the call with Alice on hold. It already has to know 
> to do this on two separate calls. Then it calls Charlie, who also has 
> a video phone. So there is an audio+video call from Bob to Charlie. 
> Then Bob asks to complete the transfer. What does it do? Normally it 
> would send a REFER to Charlie's phone, asking it to do an 
> INVITE/Replaces to Alice. But there are two calls to Alice.
>

in the "disaggregated media" approach the state of the call will still 
reside in Alice's realm,
however there will be some difference with the "centralized" approach 
because you don't have a controller and the state of the call
is distributed among the different UAs present in the Alice's realm.

Thanks
/Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2009 08:47:19 -0400

> where both ends are distributed is, of course, more "interesting" ;o)

I don't understand at all how the "distributed" model works when both 
ends want to be distributed.

	Thanks,
	Paul

>>> conferences and that even though this was very similar, it was not 
>>> the same thing... but the model is valid.
>>
>> The conferencing mechanism could be used for either the "distributed" 
>> or "centralized" approach. Then there needs to be a focus somewhere, 
>> and the difference between the approaches is where it resides - at 
>> your own end, or at the "other" end.
>>
>>     Thanks,
>>     Paul
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 15:32:46 +0200

Hi Paul,

yes, I agree we need to add use cases where both ends are distributed to 
the draft so that we understand this type of scenario in a better way.

Cheers,

Gonzalo

Paul Kyzivat wrote:
>>>>> to simply model it as a conference, where the focus is at one 
>>>>> "end". But I think we discussed that once.
>>>>