Re: [splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis

[Salvatore Loreto <[e-mail]>]

Hi Adam and Dale,

see in line... my answers


On 7/27/11 12:36 AM, Worley, Dale R (Dale) wrote:
>> From: Adam Roach [[e-mail]]
>>
>> Section 4.1.4 of draft-loreto-splices-disaggregated-media-02 currently
>> describes a (rather clever) way to move a SIP session from one client in
>> a disaggregated system to another, so as to allow the device that owns
>> the SIP association with the far-end to be removed from the call.
>>
>> I like it. It actually does a good job of showing that the system in
>> question actually isn't an all-entities-are-equal federation of peer
>> devices. In fact, it *does* have a critical central controller of sorts,
>> and we need to be able to take steps to move that critical central
>> controller functionality around. (This is inherent in any system that
>> requires no support from the far end, since someone needs to own the SIP
>> session).
> And the method generalizes:  A new controller can replace an old
> controller by sending an INVITE-with-Replaces to both the far end of
> the call and to all the UA participants on controller's end of the
> call.
>
> As section 4.1.4 notes, this can be done even if the old controller
> has died, as long as the new controller has obtained all the dialog
> identifiers beforehand.  (Although the dialog event package does not
> have any way of indicating "This dialog is to control an additional UA
> for dialog XXX." -- We should define appropriate extensions.)

Dale, do we really need it?
we can derive the information from the fact that a dialog is between
a UA and the Controller
and we can guess which is the Controller as the common UA endpoint
among all the existing dialogs.


> We don't have any mechanism for one controller to tell another
> controller to take over the coordination role.  We should define that.
true.
at moment only the controller can decide to pass the role to another one,
the Controller role can not be take over.
More we do not have an algorithm to decide who among all the UAs
has to take over the role.

> Section 3.1.1 says:
>
>     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.
>
> "Central point" is clear and accurate.
>
> I'm not sure I fully understand "User experience".  The secondary UAs
> don't have to be aware that they're part of an aggregation, yes, but
> presumably they could be made aware of it if they implemented suitable
> extensions to INVITE.  The complaint about being altered is not clear
> to me -- of course, to add a UA into a call, it has to be alerted
> somehow, or the user has to cause it to initiate a call, or some
> remote-control mechanism has to cause it to initiate a call.  This is
> unavoidable, but also shared by every other SIP-based mechanism.
>
> In regard to "SDP manipulation", the controller does have to
> manipulate SDP.  But in any possible mechanism, some device must take
> the descriptions of the media available from the the UAs and combine
> them into an understanding of all the available media.  (Even in the
> architecture of section 5, where the far-end UA is controlling the
> aggregation, the far-end UA must integrate the SDPs provided by the
> aggregated UAs in order to determine how to connect the avaialble
> media streams to its rendering facilities.)  Once that is done,
> expressing that understanding in, e.g., an SDP offer, is not
> particularly difficult.
>
>> However, then we get into section 5. I'm not sure what section 5 is
>> trying to talk about, since it discusses a model that is not relevant to
>> any of the described solutions. Even the INVOKE-based one being proposed
>> by this document.
> I think the key is "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" -- the envisioned
> architecture of section 5 puts the work of coordination on the far-end
> UA, which is necessary if none of the aggregated UAs is capable of
> being a controller.
>
> IMO, section 5 lacks detail on how an additional UA is recruited into
> the aggregation; in the other 3 scenarios, the user activates some
> special function of the controlling UA.
we haven't done any progress on section 5 as back in Prague there has
been consensus not to work, at least for the time being, on the scenario
that would put requirements on the far end.
The consensus was on progress the work on a way to lighter the 
3PCC/Controller
mechanism.

cheers
Sal

-- 
Salvatore Loreto
www.sloreto.com