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

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

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