Subject: RE: [Sipping] RE: Proposed resolution to index in conference-package

From: "Orit Levin" <[email-masked]>
Date: Fri, 4 Mar 2005 17:02:28 -0800

Inline. 

> > >
> > > I'm a little worried about <user> in the context of the 
> dust-up we 
> > > are having with Miguel over MSRP in conferences.
> > >
> > > AoR is not the only way to distinguish users, and "anonymous"
> > > is not an answer.  The "nickname" thing is a legitimate, used, 
> > > mechanism which is something between a real AoR and 
> Anonymous.  We 
> > > may need to cover nicknames as the reference (and 
> therefore index) 
> > > for participants.
> > 
> > I don't feel that there is a need to worry about it. The 
> user 'entity'
> > is very well defined and understood for both anonymous and regular 
> > users in all systems. The 'entity' must be unique and it is 
> achieved 
> > by numbering the anonymous users exactly as specified in 
> the standard.
> I do not agree.  If we really want to make chat room IM work 
> the way it does now, then nickname is a first class 
> identifier for a participant.  I do want the conference 
> mechanism to be the chat room mechanism, and therefore 
> believe that nickname must be acceptable as a user identifier.
> 
> Specifically, a user known by his nickname is NOT anonymous. 
> Participants may not know his AoR.
>
As it has been defined for a couple of years now, the <user> 'entity' is
the signaling (and otherwise control) means to get to this user.  From
this perspective - the focus decision to not disclosure this property to
other participants is what makes the user "anonymous". Note, that an
"anonymous" user can still be addressed by another user by sending REFER
to the focus. "Anonymous" doesn't imply anything about "why the user is
anonymous" (e.g. because the <user> hasn't been authenticated or because
the user wanted his/her identity be shielded from others). This
additional aspect is not reflected in the basic package. I will be glad
adding the clarification above to the text. 

> > 
> > Not all conferencing systems use nicknames, though. 
> Therefore we can 
> > not mandate using nicknames as the key for a <user>. If you are 
> > implementing a system that does rely on the nicknames - you can 
> > include a <nickname> sub-element under the <user> which will allow 
> > one-to-one mapping between the 'entity' value and the 
> <nickname> value.
> No, I don't think so.  At this level, there is no URI to 
> refer to the user, there is only the nickname.  You can make 
> the container have an id (a number that has no meaning) and 
> then have nicknames or uris as subelements, as long as both 
> are optional, or you can define entity as either a URI or a 
> nickname.  
>
Although technically possible, I don't see a single reason for changing
the indexing of the <users> container to another arbitrary index. (Very
much in line with your own arguments regarding other containers.) If the
focus doesn't want to expose any of the users' uris - then all users
become "anonymous". The nickname should be placed in an existing
<display-text> sub-element of a <user>.
   
> > >
> > > I'm still confused by <media>.
> > > If a template defines a media stream called "presenter", and a 
> > > participant in the proper role sends the focus an SDP 
> with the label 
> > > "presenter" on a media stream, that works.  If the conference 
> > > package subsequently shows a media stream called 
> "presenter", that 
> > > works.
> > >
> > Agreed. That is exactly how it is supposed to work. That 
> being said, 
> > it does not imply that the keys must be the "labels"! The 
> "labels" are 
> > included in all the media "containers" and also in the 
> endpoint media 
> > streams. You can make the exact described correlation using 
> this "label"
> > information.
> > 
> > "id"s are a totally different story...
> > 
> > > What is id, where does it come from, and what other things use it?
> > > If the template had a stream called "presenter" and the 
> SDP didn't 
> > > label one of its streams "presenter" is there another way 
> the focus 
> > > would understand what it was supposed to do with that 
> stream?  How 
> > > would that be related to this id thingy?  If there is a stream 
> > > called "presenter" in the template and somehow, magically, some 
> > > participant has one, how would the focus come up with this <id> 
> > > thing?  Is it unique to the conference or unique to a 
> participant in 
> > > a role?
> > >
> > The way -09 defines, "id"s are indexes being used locally 
> within each 
> > container for numbering/identifying the lines in each container 
> > independently. They don't have any meaning neither across the 
> > containers nor to the conferencing application itself.
> > 
> > I agree that it is possible to use the "label" values as 
> the keys for 
> > the media containers. It is less overhead and I don't see any 
> > potential harm. Those conferencing applications that use the global 
> > conferencing containers will need to have a concept of 
> "label" anyway. 
> > (I am in full agreement with Brian on this point.)
> > 
> > I disagree that we should be using the "label" values as 
> the indexes 
> > for the endpoint media streams, though. That is because 
> there are many 
> > basic conferencing applications around that don't use the "label" 
> > concept at all. A simple conferencing applications would typically 
> > have no need for generating media "labels" unique in the 
> context of the whole conference.
> > As a result, requiring in the conference-package that the 
> <endpoint> 
> > media streams are globally indexed would put an unnecessary 
> burden on 
> > these applications and should be avoided.
> I don't agree, or at least, I think it's a "don't care" situation.

Is it a "don't care" situation for all the media indexes and we can
close this topic without touching the media definitons of -09?
...Or are you referring to some particular subset of the media
information. If so, could you, please, clarify the part that you
strongly disagree with, really want to be changed, and want continue
discussing on the list and in the meeting?
 
> If you have an XCON conference, then you always have labels.
> It may not be necessary, even in an XCON conference to have 
> the participants label their streams, especially if they only 
> contribute one stream for each possible media type.  In that 
> case, as in the case of a conference server that is not XCON 
> compliant, the focus can make up any name it likes (including 
> "1", "2" or "3") to use for the element id.  There is no need 
> for another indexing element.  The only reason you need them 
> is to correlate streams in active and available, and the 
> label is a unique identifier.
> 
When you define an "index" in the package you must define its scope. All
systems will have to apply to this definition. You can not say that
"label" is the media index for endpoint media streams  without mandating
it being unique in the context of the whole conference for every system.
... And this is a big and unnecessary burden to those simple
conferencing system which will not use the available and active
containers.
> Brian
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Mar 2005 08:13:31 -0500

Orit

> adding the clarification above to the text.

I think you are missing the point.

Yes, we can bend the URI into something we can use.
Should we?

I think not.  I think there is no reason to force the reference to
a participant to be a URI.  All we need to be able to do is to
represent a participant in the package, and either a URI or a nickname is a
reasonable way to do this.  I rather like the way most IM systems work,
and I think that it might work very well in a video conference.  I don't
think bending anonymous URIs for this purpose is a useful artifice.

There is no other reason in SIP conferencing to be able to have one
participant refer to another by a URI.  There aren't any mechanisms that
need this.

> <display-text> sub-element of a <user>.
Actually, I agree that creating a new index is not a good idea.
Here, there aren't two containers that need a common element correlator.
We don't need an index at all.

> discussing on the list and in the meeting?
All we need is an identifier that is common to the two media containers.
Anything that appears in both that can be used to relate them when they
appear in both containers will do.  The label serves that purpose.

> conferencing system which will not use the available and active
Yes, the label has to be unique within the conference.
They have to be unique per function, not per participant, right?
However, it's the focus that is supplying the NOTIFY here.
I'm not sure I understand what you are worried about.

If there is a template, the template defines the labels, and participants
would need to use those labels if they wanted things to work.

On simple conferences, I don't think you would see labels on the participant
SDP, but if you did the focus is free to ignore them and supply whatever
labels it likes on the NOTIFY, since they have no defined meaning in the
conference.  

Let's take an example.
Suppose there are no labels, but there is a single audio in and audio out
from each participant.

It's always confusing what the reference point for in and out is (focus or
participant).  Let's say two participants self-label streams "audio-in" and
"audio-out" but exchange the direction (one labels them with respect to
itself, the other labels them with respect to the server).  I would say that
the focus, in the NOTIFY, could ignore the labels used on the participant
SDP.  I would say it would be VERY confusing if it reproduced them the way
the participants labeled them.  I would go so far as to say that labels
applied when there is no template are explicitly ignored by the focus, and
the focus is free to use whatever labels it likes in the NOTIFY (as long as
they are unique)

Brian