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

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jul 2011 14:26:23 -0400

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

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.

Even more interestingly, I note that the transfer-of-control approach in 
section 4.1.4 can be applied equally well to any central-control model. 
MBUS, for example. Or MEGACO. So the statement "transferring the SIP 
dialog from a controller to a new one using REFER and Replaces is 
complex and requires support from the far end" isn't really true -- 
everyone can use the section 4.1.4 INVITE/Replaces approach to move 
control around. The INVOKE-based approach described in this document is 
hardly unique in this respect.

On top of this, the analysis in section 3.1.1 and 3.2.1 both have the 
rather gonzo "issue" of "you need to implement the protocol." That's 
true of *any* solution -- INVOKE included -- so it's hardly a 
distinguishing factor. If you want to try to quantify the ease of 
implementation, that might be a useful discussion. But simply saying 
"you have to implement something" is always, always, always true for a 
new mechanism.

So, once you make a more honest analysis of the other protocols, section 
3.1.1 actually ends up looking like this:

    The Mbus protocol introduces the following issue:

    Local network:  Mbus uses multicast with a limited scope for message
       transport.  The multicast limits the coordination mechanism only
       to groups of devices that are connected to a local network.  So
       Mbus can be used in a disaggregated media scenario only if all the
       different devices under the user control, or at least the one the
       user wants to involve in the communication, are attached to the
       same local network.

And section 3.2.1 looks like this:

    The Megaco protocol introduces the following issues:

    None.

/a

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 26 Jul 2011 17:36:02 -0400

> From: Adam Roach [[email-masked]]
> 

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.

> any of the described solutions. Even the INVOKE-based one being proposed

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