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

["Worley, Dale R (Dale)" <[e-mail]>]

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

We don't have any mechanism for one controller to tell another
controller to take over the coordination role.  We should define that.

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.

Dale