Subject: RE: [Simple] MSRP: Contributor ID

From: "Orit Levin" <[email-masked]>
Date: Wed, 11 Aug 2004 10:57:39 -0700

I do believe that the basic MSRP "mixing" behavior should be addressed
by the MSRP set of specifications.

I think that it is not less important than the MSRP relays behavior
(especially keeping in mind the main applications being built around IM
technology).

I will be happy to provide text for the MSRP spec around this or
alternatively to submit a separate draft on this.

Orit.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, August 11, 2004 10:45 AM
To: Orit Levin
Cc: Aki Niemi; SIMPLE WG
Subject: Re: [Simple] MSRP: Contributor ID

Just to clarify: Are you saying you believe that MSRP conference focus 
behavior should be specified in the MSRP core spec?

On Aug 11, 2004, at 12:10 PM, Orit Levin wrote:

>
> Needlessly to say, I strongly disagree that this is out of scope to
> MSRP. By assuming this, we are just inviting proprietary 
> implementations
> and a lot of fun at interop events.
>
> Based on the SIPPING Conferencing Requirements and Framework, 
> conference
> unaware SIP UAs MUST be able to participate and be invited to a
> conference. What kind of experience will this participant get without
> having the real source of the message being displayed to him/her?
>
> Why do you expect from XCON to address MSRP as a special media type
and
> treat it differently - when other media types (i.e. all the RTP based
> streams) have this information in place?
>
> BTW the "whisper" functionality, according to XCON design, is being
> achieved very differently from what Aki envisions. The message is
> supposed to be "routed" based on the media policy kept in the media
> policy server - not as a result of a participant inserting the "final
> destination" information in one of the headers of a media/data stream.
>
> Cheers,
> Orit.
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf
> Of Aki Niemi
> Sent: Wednesday, August 11, 2004 8:34 AM
> To: ext Ben Campbell
> Cc: SIMPLE WG
> Subject: Re: [Simple] MSRP: Contributor ID
>
> Hi,
>
> IMO, there are two things CPIM is needed for in a conferencing 
> scenario:
>
> 1 - In your use case below, for a focus-inserted "asserted" identity
> identifying the sender of the message
>
> 2 - For routing purposes, in order to route messages based on who the
> messages were addressed to. This is to enable whispering within a
> conference (i.e., sending a certain message not to the entire
> conference, but to one or a few of the participants). This has been
> discussed before at length.
>
> Clearly, CPIM (ugly as it may be) can be made to handle both of these
> needs. Contributor-ID will only cover the first one - unless of course
> we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted
> by the client, to cover the second need.
>
> Cheers,
> Aki
>
>
> On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote:
>> Hi,
>>
>> In last week's SIMPLE meeting, Orit brought up an issue about how we
>> planned to identify contributors when MSRP is used with a conference
>> focus. Previously, we had discussed using message/cpim wrappers for
>> this purpose.
>>
>> After thinking through the use case, I think Orit may be correct that
>> cpim is unwieldy for this purpose.
>>
>> The use case I think we have in mind is, you have a text conference
>> where each participant has an independent MSRP session with the
>> conference focus. The focus acts as a reflector, forwarding messages
>> that come in on one participant session to each of the other
>> participants. It needs a way to tell the receiving parties which
>> participant sent the message. _How_ it determines what contributor ID
>> to attach to a given message is out of scope for MSRP--that problem
>> belongs to XCON.
>>
>> We had previously assumed the focus would simply wrap the inbound
>> message in a message/cpim document, and use the CPIM "from" field for
>> this purpose. This, however, is problematic for chunked messages, as
>> the focus would need to buffer the message until it had received all
>> the chunks, wrap the completed message in the cpim document, and then
>> send that message out to the other participants, possibly re-chunking
>> in the process. This does seem to me to be burdensome on the focus;
it
>
>> would be nicer if the focus could simply forward the individual
> chunks,
>> and let the endpoints deal with re-assembling them.
>>
>> Another approach would be to have the focus force the endpoints to
use
>
>> a cpim envelope. However, there may be times where the identity that
>> the focus wants to insert may be different than the identity that the
>> endpoint inserts.
>>
>> Therefore, I propose we add a new optional header called
>> Contributor-ID, which can carry a name-addr. Normal endpoints would
>> never insert this, but a conference focus could insert this header on
> a
>> per-chunk basis, and avoid the buffering requirement mentioned above.
>>
>> What do others think? Am I completely off base?
>>
>> Thanks!
>>
>> Ben.
>>
>>
>> _______________________________________________
>> Simple mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Wed, 25 Aug 2004 08:00:08 +0300

I don't agree that the base MSRP spec needs to fully specify the behaviour for a conference. It is not the place to do so. There will be a separate internet draft describing the behaviour when MSRP is used in a conference, which is not an MSRP core protocol specification. The behaviour of a client or conference server in an MSRP session does not alter MSRP as a protocol and therefore does not need to be described in the base spec.

Regards,
Hisham

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Alan Johnston
> Sent: 24.August.2004 20:34
> To: Adam Roach
> Cc: [email-masked]
> At 02:49 PM 8/23/2004 -0500, Adam Roach wrote:
> >Alan Johnston wrote:
> >
> >>At 01:36 PM 8/23/2004 -0500, Adam Roach wrote:
> >>
> >>>
> >>>Source identification can be performed by correlation between the 
> >>>initial "From-Path" header element and the session 
> establishment. There 
> >>>isn't really mixing per se involved, simply message 
> switching -- so all 
> >>>we need is a mechanism to identify (a) who originated the 
> message (get 
> >>>this from CPIM), and (b) the "mixer" that sent it to you 
> (get this from 
> >>>"From-Path.")
> >>>
> >>>Does that address your concern, or did I misunderstand?
> >>
> >>
> >>I thought CPIM use was optional.   If so, this proposal seems to 
> >>break.  Remember, the SSRC is RTP is not optional - it is a 
> MUST in the 
> >>spec.  MSRP needs similar strength or interoperability 
> problems will result.
> >
> >
> >I agree.
> >
> >SSRC is mandatory in the same way that From-Path is mandatory. 
> >Semantically, they identify the same element.
> >
> >CSRC is optional in the same way that CPIM is optional. 
> Semantically, they 
> >identify the same element.
> 
> Well, CSRC is optional in RTP, which might explain why no one 
> implements it 
> today - not a good outcome that we wish to repeat.  It is not 
> critical 
> because with voice or video media, we can do the 
> identification by sound or 
> sight, so we get by.
> 
> For text, this is not possible, so I think the semantic 
> equivalent of CSRC 
> must not be optional, and must be fully defined in the base spec of 
> MSRP.  Otherwise, in a few months, XCON will send SIMPLE a 
> requirement to 
> extend MSRP in order for text chat rooms and sessions to work 
> properly.  We 
> know the requirements - why not just do it now and be done 
> with it?  'd 
> rather not leave a big mess for XCON to have to clean up.
> 
> Also, even though CSRC is optional, it is fully specified in 
> the base RTP 
> specification - we need the same thing here in MSRP.
> 
> If CPIM is the right way (not clear to me, but I don't follow SIMPLE 
> closely), the use of CPIM for CSRC needs to be mandated and 
> fully specified 
> in the base MSRP specification.
> 
> Thanks,
> Alan
> sip:[email-masked]
> 
> >/a
> >

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 26 Aug 2004 16:08:59 -0700

Paul,
The answer to "why" in each of the cases relates to the fact that
different cases belong to same architecture/possible deployment. Even
when you see a solution to one case - you are unintentionally missing
another unless you go through the exercise of defining the full
conferencing architecture.

Instead, if we step back and try to look at the problem from the top,
CPIM is a simple means for peer-to-peer private communications with
non-trusted intermediates (e.g. GW, MCUs) potentially present in the
middle. Using CPIM for communications between users and the
intermediates themselves (and still being able to use CPIM for what it
had been designed for) without defining standard ubiquitous means for
distinguishing between the cases - is close to impossible.

On the RTP note, RTP is different from MSRP in many aspects:

- RTP doesn't use CPIM and as a result doesn't have this problem to
start from :-)
- SSRC is used as a stream identifier only. In the core RTP, there is no
multiplexing inside the UDP connection (which is 1-to-1 with the RTP
session). In MSRP, the from-path value is used as the part of the "MSRP
session identifier" for multiplexing inside a TCP tunnel.
- in addition to the RTP "mixer" mode being implemented today, RTP also
defines the "translator" mode - which is much closer to what happening
in IM conferencing case. It this mode, the original SSRC is PRESERVED by
translators (and the CSRC list is not created because it doesn't have
any meaning at all). As it was stated earlier, voice and video
conferencing vendors got away with it only because the user can guess
the source by his/her voice or video. This doesn't work for IM unless an
advanced conferencing protocol (e.g. XCON) is being used by ALL
participants.

Orit.   

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, August 26, 2004 12:00 PM
> To: Orit Levin
> Cc: Ben Campbell; Adam Roach; Alan Johnston; [email-masked]
> Orit Levin wrote:
> >>If
> >>the message already had a cpim wrapper, then the focus 
> could choose to 
> >>leave it alone, or put it inside yet another wrapper.
> >>(You can have nested cpim wrappers.)
> >>
> > 
> > To accommodate the end-to-end encrypted CPIM, it will need to be 
> > something like:
> > If the message already had a cpim wrapper and the destination is 
> > conference-aware, then the focus puts it inside yet another clear 
> > wrapper (that is in order to provide mapping to conferencing 
> > extensions).
> > If the message already had a cpim wrapper and the destination is 
> > conference-unaware (e.g. doesn't use XCON) leave it alone 
> (that is in 
> > order to not confuse the receiving client with conferencing 
> > information vs. peer-to-peer information).
>  >
> > This is VERY DIFFERENT from the existing today conferencing 
> > architecture where the focus logic is NOT dependant on the 
> > participant's ability to understand or actively support 
> conferencing extensions and protocols.
> 
> I don't understand why you are splitting out different 
> behaviors for conference aware and unaware participants.
> 
> If the focus wants to ensure that messages are properly 
> identified as to source, then it will either have to add a 
> CPIM wrapper, or else inspect and approve one that is already 
> present. If the message is encrypted e2e so that the focus 
> can't decrypt, then it doesn't matter whether the encrypted 
> body is CPIM or not. Either way the focus will have to wrap 
> the encrypted body in a new CPIM wrapper.
> 
> It can only avoid this if it doesn't feel it is necessary to 
> identify the message sender. It will be up to the conference 
> arch to decide about that. Maybe it will depend on whether 
> the recipient is conference aware, maybe not.
> 
> > Yet "MY MAJOR PROBLEM" with using CPIM wrapper for 
> conferencing/focus 
> > can be summarised as following:
> > There is no (well-defined simple) way in the CPIM header to 
> > distinguish whether a particular CPIM is being used for 
> intermediate 
> > (e.g. focus,
> > GW) vs. for peer-to-peer needs. A user may have very 
> different privacy 
> > policies regarding each.  In the case of conference-unaware 
> user - the 
> > UA will not even have the ability to distinguish between 
> the two cases.
> 
> Why should there be? there isn't any way to do this for 
> RTP/RTCP. There isn't any ability to have both kinds. And it 
> is up to the mixer whether it preserves the IDs provided by 
> the sender or puts in artificial ones. 
> The recipient can't tell which is the case.
> 
> > Which identity will the user put in the requested CPIM header? The 
> > private (for peer-to-peer) or the public for the focus use? How the 
> > receiving participant (which can be conference unaware as 
> well) will 
> > undertsand what kind of identity he is looking at?
> 
> If there are multiple unsigned and unencrypted identities, 
> then the recipient should probably display them all, or maybe 
> none of them if it is untrusting. If some or all of the 
> identities are signed, then it could choose to only display 
> ones signed by somebody it trusts.
> 
> 	Paul
> 
>