Subject: RE: [Simple] MSRP: Contributor ID

From: "Orit Levin" <[email-masked]>
Date: Tue, 24 Aug 2004 16:52:07 -0700

I am back from my one week vacation :-)
I can see at least two independent major problems when using CPIM
wrapper for MSRP conferencing:

1. Let's assume that CPIM support is mandatory but CPIM use is optional
as per Paul. If the sender is a conference-unaware participant, there is
no way to "negotiate" or to request the sender to wrap the MSRP message
(unless we add "something" mandatory to the core MSRP). This contradicts
"draft-ietf-sipping-conferencing-requirements":
 
3.4.1 Participation of a Conference-unaware User Agent
REQ -1: Focus MUST be able to invite and disconnect an RFC 3261
compliant only SIP user agent to and from a SIP conference. 

REQ -2: RFC 3261 compliant only SIP user agent MUST be able to dial-in a
particular SIP conference. In this case, only the human knows that
he/she is connected to the conference. 

2. Let's assume that the sender is a conference-aware participant who
also wants to convey its private identity in an encrypted CPIM header to
its peer(s). This is the original purpose for using CPIM and it must be
possible to convey the identity without letting any intermediate,
including the focus, to learn it. The collison problem here is that 
- the CPIM content is the peer-to-peer application information and, as
such, is transport independent and can be encrypted
- the missing from MSRP "Source ID" is the transport protocol identity
and can't be encrypted in order to be used by intermediates
Any focus (e.g. operated by XCON) must be able to include some
well-defined user identity in its (XCON, conferencing package)
communications with the participants. This well-defined identity must be
visible to the focus and must also be attached to the MSRP messages sent
from the focus. As a result, two CPIM headers will be needed in this
scenario to resolve the collision (one in clear and the other
encrypted).

The mechanism TBD in the core MSRP needs to address these two scenarios.

Orit. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, August 24, 2004 11:34 AM
> To: Alan Johnston
> Cc: Adam Roach; [email-masked]
> Subject: Re: [Simple] MSRP: Contributor ID
> 
> 
> 
> Alan Johnston 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.
> 
> Support of CPIM is necessary for interop, but use isn't necessary.
> 
> If it is required in some context, e.g. in inputs to a 
> conference mixer, then it is simple to negotiate a 
> requirement for a CPIM wrapper on every message.
> 
> 	Paul
> 
> 
> _______________________________________________
> 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: Adam Roach <[email-masked]>
Date: Wed, 25 Aug 2004 08:31:16 -0500

>no way to "negotiate" or to request the sender to wrap the MSRP message

Yes, there is. In the SDP, you can indicate that the only unwrapped type 
that you accept is CPIM. This forces the remote endpoint to always send 
CPIM-wrapped messages.

>communications with the participants.
>

This correlation is provided by the first element in the From-Path.

/a