Re: [splices] draft-loreto-splices-disaggregated-media-00

["Elwell, John" <[e-mail]>]

I still don't like the fact that there is impact on Bob's UA. Even though that impact might only be session correlation, this could be quite complex. It sounds to me like Bob's UA, on deciding that two SIP dialogs relate to the same session, must somehow merge the two session descriptions (SDP). In the simple case, where one session is audio only and the other is video only, it might be relatively simple, e.g., an assumption that the two need to be lip-synched could be made. But we surely would need to deal with more complex cases, e.g., an additional video stream for presentations, floor control of the presentation stream or other streams, multiple audio and/or video channels for telepresence, grouped media spanning more than one contributing session description, etc.. Multimedia SIP UAs will have no incentive to implement extensions to cover session correlation and merging, so this will constrain interoperability.

John

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Salvatore Loreto
> Sent: 18 November 2010 14:34
> To: Paul Kyzivat
> Cc: [e-mail]
> Subject: Re: [splices] draft-loreto-splices-disaggregated-media-00
> 
> Hi Paul,
> 
> thanks for the comments,
> see my answers in line.
> 
> 
> On 9/16/10 9:36 PM, Paul Kyzivat wrote:
> > I guess the point of the draft is to advocate for the mechanism in
> > section 4 / Figure 5. Right?
> 
> more precisely the draft advocates a scenario where none of the nodes 
> can act as a "controller".
> 
> In Fig.5 (on section 
> http://tools.ietf.org/html/draft-loreto-splices-disaggregated-
> media-00#page-11 
> )
> describes only one end (Alice) as distributed, but the idea can be 
> generalized where both the ends
> are distributed.
> 
> > But ISTM that this doesn't address the use cases. Most of them start
> > with something like:
> >
> >      Bob interacts, using his voice-only phone, with his PC 
> and starts
> >      live video stream to Laura's multimedia phone.
> >
> > IOW, Bob's phone must still have some special behavior, to act as a
> > "controller" or "coordinator". Also, for this scenario to work, the
> > "smart" end (Alice's phone in most of the examples) also has to have
> > functionality to support this. The rest of Bob's devices also need
> > special behavior too, to interact with Bob's phone, taking 
> instructions
> > to play in this environment.
> 
> in loosely coupled scenarios, the entity acting as the 
> controller could 
> be the human user.
> That is, the human user (Bob) could know he has two devices 
> involved in 
> the same call
> and there two sessions, one with a phone and another with the 
> softclient 
> in the laptop.
> Maybe we do not have lip synchronization and things like that,
> but as long as the media streams are loosely coupled, the 
> session could 
> be as well.
> 
> > I guess the minimum those devices might need is the ability 
> to support
> > REFER. But its more than that - they need to know what to do with a
> > REFER that isn't replacing an existing call - what media to involve,
> > etc. That isn't something that can be expected by default 
> of a device,
> > like a PC, that has sip functionality.
> 
> The ability to support REFER can help,
> but as you have pointed out there would be the need to standardize a 
> different usage for it.
> 
> lets consider the following strawman  scenario where
> Alice has three UAs and
> Bob has only one.
> 
> 1) Alice UA-1  starts a voice session with  Bobs UA.
> this session contains a supervisor-id of some kind that will 
> be used in 
> potential further
> sessions between Alice and Bob, either started from Bob to Alice or 
> again from Alice to Bob.
> 
> 2) Alice adds video.
> Alice UA-1 sends a REFER to Alice UA-2 capable of video.
> The REFER points to Bob's address.
> The same REFER also include the above supervisor-id.
> 
> 3) Alice UA-2 uses REFER information to send the INVITE#2 towards Bob.
> 
> 4) Bob's session supervisor extracts the supervisor ID from session#2 
> and direct this session
> locally to the already running SIP session#1 application, 
> which expands 
> its user window with the media
> of session#2
> 
> > I think this approach is really much like the 3pcc 
> approach, except that
> > it has the controller reside with the *other* participant.
> 
> not really,
> it is totally different from the 3pcc approach,
> in fact it is a distributed approach where neither ends need a 
> centralize controller
> (e.g. a master device)
> 
> > One of the other problems with the 3pcc approach is that 
> the controller
> > can't get out of the call unless it can transfer its 
> responsibilities to
> > some other controller. (I guess there could easily be cases 
> where there
> > is only one device with controller capability that the user 
> controls.)
> >
> > A hybrid solution could be that if the user needs to take 
> his controller
> > out of the call, and the other participant in the call has 
> controller
> > capability, then the user could transfer the controller 
> responsibilities
> > to the other user, thus turning the call from figure 2 to figure 5.
> 
> This does not work in the case both participants use several UAs.
> 
> > However, I'm not convinced that is even an important use 
> case. If you
> > have a device smart enough to act as controller to set up 
> figure 5, then
> > I think its smart enough to act as a controller in one of the
> > centralized approaches.
> 
> Receiving side does not require to act as controller.
> In the approach described in the above strawman the receiving 
> side only 
> needs
> to look up the communication context reference in the INVITE#2.
> 
> >   And I have difficulty thinking of cases where
> > you need to take that device out of the call and yet still have more
> > than one device remaining that need to be coordinated.
> >
> > IMO the centralized approaches are much preferable. A key 
> point is that
> > they only involve one end. IOW, if *I* want to involve 
> multiple devices
> > in my call, I can do so without a requirement for the other 
> participant
> > in the call to know anything about that. That seems 
> critical, because
> > there probably won't be a lot of these devices (at least at 
> first) so it
> > better not require a pair to be useful.
> 
> not to put any requirements of the other participant would be ideal.
> In reality what we can do is to minimize the requirements on 
> the other 
> participant.
> The strawman solution above the requirement would be just implement
> a supervision session to check if the incoming invite can be 
> correlated to
> an existing session or not.
> 
> > The harder question (and the one that this group could address) is
> > *which* coordination mechanism(s) to define.
> 
> it may be to see what people think about the possibility that 
> the entity
> acting as the controller is just the human user.
> 
> 
> cheers
> /Sal
> 
> > In principle it isn't required that there be only one. You 
> could use one
> > mechanism for your devices, and I could use a different one 
> for mine and
> > we could still communicate just fine. But that would lead 
> to all sorts
> > of interop issues among devices on a single end. So I think 
> there should
> > at least be one preferred to implement mechanism.
> >
> > 	Thanks,
> > 	Paul
> >
> > On 9/16/2010 1:26 PM, Salvatore Loreto wrote:
> >>    Hi there,
> >>
> >> in order to continue the "/loosely coupled sip devices/" 
> discussion ,
> >> I have just submitted a new version of the "/Disaggregated 
> Media in the
> >> Session Initiation Protocol (SIP)/":
> >>
> >> 
> http://datatracker.ietf.org/doc/draft-loreto-splices-disaggreg
> ated-media/
> >>
> >> The previous version of the draft was discussed in DISPATCH WG.
> >>
> >> comments and feedback are very welcome
> >>
> >> cheers
> >> /Sal
> >>
> >> --
> >> Salvatore Loreto
> >> www.sloreto.com
> >>
> >>
> >>
> >> _______________________________________________
> >> splices mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/splices
> _______________________________________________
> splices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/splices
>