RE: [XCON] draft on MSRP conferencing

["Brian Rosen" <br at brianrosen.net>]

I'm (mostly) with Adam.  MSRP is not at all special, and will be treated
like audio and video in conferences.  Sidebars are how you have "private"
conversations within a conference, and that's how you should have "private"
MSRP conversations.  I don't think we will need anything special in the
mechanisms for MSRP.  I would reword REQ-10 to say that sidebars with
Instant Messaging must be provided for.

I do not agree with REQ-14.  You send the message to the mixer, and it sends
it to the participants in the sidebar.  The mixer knows the SIP URIs.  We
need a common sidebar mechanism that uses a common way to refer to
participants.  

Brian

> -----Original Message-----
> From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of
> Miguel Garcia
> Sent: Tuesday, February 22, 2005 3:13 PM
> To: Adam Roach
> Cc: XCON mailing list; Aki Niemi
> Subject: Re: [XCON] draft on MSRP conferencing
> 
> Hi Adam:
> 
> I would like first start asking if you agree with the requirements,
> particularly requirements 10 and 14, that say:
> 
> REQ-10:
>      It must be possible to send a message to one or more participants
> of the conference (private instant message).
> 
> REQ-14:
>      On sending private messages, it might be possible that the creator
> sends private messages to participants who have only revealed their
> nickname, but not their routable SIP URI.
> 
> 
> These two requirements made us thought of the addition of a new DISTSEND
> method to MSRP. It clearly indicates which recipients would be getting a
> copy of the message. We ended up defining a new method, as opposed to
> use SEND, because MSRP does not offer a capabilities negotiation
> mechanism. So you wouldn't like to SEND what you consider is a private
> message, and find out that the MSRP switch has distributed to the whole
> conference because it didn't understand the extensions proposed in the
> draft.
> 
> Now, if we agree that a new MSRP method and the new header is the right
> way to implement private messaging, then one can think of what could be
> present in the Distribution header field: MSRP URL? Well, not so useful,
> they are not persistent URLs as you mentioned. A nickname (expressed as
> a URN)? Yes, that is what REQ-14 is all about. A SIP URI of a
> participant? Yes, the creator of the message might have learnt that SIP
> URI from the conference event package, but it does not know the current
> MSRP URL of the endpoint, besides that such MSRP URL identifies the
> session the recipient has established with the MSRP switch, not with the
> creator.
> 
> So once we are in this stage, since a sidebar is identified by a SIP
> URI, it occurred to me that the creator of a private message could
> address the sidebar and a number of participants, in a private message.
> If it ends up that a sidebar is a totally separated session with no
> connection with the main conference, I would remove sidebars from the
> list of possible recipients, but I hope we are not then introducing a
> requirement to distinguish which URI represents a sidebar, which one a
> regular participant. It is certainly not my intention to bring two
> possible implementations of sidebars.
> 
> BR,
> 
>          Miguel
> 
> 
> Adam Roach wrote:
> > 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
> 
> --
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
> 




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