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