Re: [XCON] draft on MSRP conferencing

[Adam Roach <adam at nostrum.com>]

Miguel Garcia wrote:

> The new DISTSEND method allows to have more than one "recipient 
> target", as opposed to the SEND method that assumes a single target.


SEND assumes a single target in exactly the same way that RTP assumes a 
single target: it assumes that you send it to one place. If that one 
place then acts as a conference server in some way and re-transmits the 
media to one or more other destinations, then it all works. Just like 
you don't need to put special information in RTP packets indicating who 
should hear them, you don't need to put special information in your MSRP 
message indicating who should read them. The "From-Path" and "To-Path" 
headers in MSRP are simply a *routing* *mechanism*. That's why, for 
example, MSRP URIs don't include user names, or persist over time, or 
look like something that a human could be expected to type in. They're a 
protocol mechanism for routing, and nothing more.

> DISTSEND allows anything in the Distribution header, including but not 
> limited to a SIP URI that represents a sidebar.


This is a complete mismatch with the way that MSRP works otherwise.

> It is not the intention of the draft to add an alternative mechanism 
> to sending MSRP messages to a sidebar, but obviously a sidebar can be 
> a potential target of the DISTSEND method as any other participant's URI.


Once again, you need to think of MSRP "streams" in the same way as you 
think of RTP "streams." There isn't a way to put information in an RTP 
packet to say you want to target a particular set of recipients or a 
particular sidebar.

Whatever mechanism you use to set up the sidebar tells you how to send 
media to it.

> You also mention the sidebar mechanisms that XCON will be developing. 
> Unfortunately I haven't found written information about that, perhaps 
> I missed it. So I just took into considerations the written stuff 
> about sidebars, which is basically in the SIPPING Conferencing 
> Framework, indicating that a sidebar is a conference within a 
> conference identified by a SIP URI. If there is something else we 
> would need to align let me know it.


The conversations about how to do sidebars are still ongoing, so I can't 
tell you for sure what the conclusion will be. It will probably take a 
while for these conversations to settle out, because we have some 
fundamental questions about the overall model still that would need to 
be answered first. (See, for example, the "Discussion Point" messages I 
posted two weeks ago.)

In any case, when we do get around to defining the concrete sidebar 
mechanisms, they *must* talk about how to send media that is destined 
for the sidebar. This will probably -- and this is a prediction, not 
necessarily a suggestion -- take the form of a separate session (from a 
call signaling perspective) with its own ports to which media is sent. 
Under these circumstances, where you send the MSRP message (or RTP 
packet) determines who can read the IM (or hear the audio) it contains.

My fundamental point is that what works for other media streams must 
work for MSRP. If you start adding special mechanisms into MSRP to do 
sidebarring, then you *will* have multiple mechanisms to do the same 
thing. In protocols, having multiple ways of doing things is bad. It 
leads to lower interoperability. It creates a combinatorial explosion of 
combinations to test. In the final equation, it makes the protocol much 
more likely to be rejected by the implementation community.

/a

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon