Re: [XCON] draft on MSRP conferencing

[Miguel Garcia <Miguel.An.Garcia at nokia.com>]

Inline.

Adam Roach wrote:

> Miguel Garcia wrote:
>
> > 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.
>
>
>
> Yes, I think these are good requirements, and I believe that these 
> requirements are equally applicable to audio sidebars. E.g.:
>
>    * It must be possible to send audio to one or more participants of
>      the conference
>    * It may be possible that the sender sends audio to conference
>      participants who are anonymous and have not published a routable
>      SIP URI.

Miguel-> I agree, these requirements should be identically applicable to RTP


> > 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.
>
>
>
> No; you should use the same mechanism that any conference would use to 
> indicate a subset of recipients for *any* kind of media (audio, video, 
> streaming text, IM, anything).
>
> DO NOT SPECIAL-CASE INSTANT MESSAGES.

Miguel-> Hold on. I agree with the intention of treating all the media 
in the same way, no matter whether it is RTP or MSRP. But, certainly we 
cannot be restricted by the limitations of RTP and make MSRP limited in 
the same way. Actually, both protocols differ substantially. For 
instance, MSRP typically contains a route of MSRP relays to visit, 
something that is not possible to do with RTP.

So we have already go around some RTP limitations in MSRP. We didn't 
limit MSRP because of RTP, in the same way we shouldn't limit private 
messaging in MSRP because of RTP.

Considering that we agree on the requirement to distribute private media 
to a subset of the roaster, one can also think of extending RTP to 
include this kind of routing meta data. By doing this, the mechanism 
would be similar to both MSRP and RTP (this seems to be your requirement).

> There will be a general purpose way to handle sending media to a subset 
> of participants in a conference. If you define *anything* for a 
> particular media type that makes it a special case, then you will end up 
> with two ways to do thing: the general purpose way that works for all 
> media, and the special case the works for only one kind of media.

If we find out a simple general mechanism to handle sending media to a 
subset of  participants in a conference, great, then we don't need this 
draft. I am still trying to understand how such mechanism could work 
with RTP without further extensions... unless you are thinking of 
establishing new sessions to distribute media to subsets of 
participants. This would be an overkill.

> This would, as I said before, be a senseless increase in protocol 
> complexity and consequently a barrier to interoperability.

I disagree here. The protocol's complexity is not increased heavily, the 
draft currently proposes a new method and a new header. I wouldn't 
consider a new method and a new header an "increase in protocol 
complexity", taking into account the benefit. It does not create a 
barrier to interoperability, because the draft does not require an 
extension to receive private messages. The extension is only required to 
the sender and the MSRP switch.

/Miguel

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