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

From: "Orit Levin" <[email-masked]>
Date: Thu, 3 Mar 2005 16:26:25 -0800

Guys,
We really need to close this package during this IETF.
After -09 submission, Cullen raised a single <endpoint> indexing issue.
Cullen and I talked and agreed on a middle ground approach that Cullen
summarized in his previous mail. I see this topic as "closed". I will
need to submit the -10 right after the IETF to reflect this change.

Brian refers to different elements with their keys. I am providing my
preferences regarding them below. I don't consider neither of them as an
architectural showstopper. It is just a matter of preference, based on a
particular conferencing application one has in mind. Both ways meet the
same requirements and work well.

I am actually agreeing with Brian on the media containers indexing, but
I have been hesitant in the past to change the definitions because of
additional interested parties that may not like them.

Please, see the details inline. I would rather ask the parties to
express their preferences for this "last open issue" on the list before
the meeting. This way I could prepare the final text and upload it for
everyone's review before the next week.

Thanks a lot,
Orit. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: Friday, February 25, 2005 10:26 AM
> To: 'Cullen Jennings'; 'sipping'
> Cc: 'Alan Johnston'; 'Rohan Mahy'; Orit Levin; 'Roni Even'
> Subject: [Sipping] RE: Proposed resolution to index in 
> conference-package
> 
> 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.

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

> Brian
> 
> 
> 
> > -----Original Message-----
> > From: Cullen Jennings [mailto:[email-masked]]
> > Sent: Friday, February 25, 2005 1:08 PM
> > To: sipping
> > Cc: Orit Levin; Alan Johnston; Rohan Mahy; Brian Rosen; Roni Even
> > Subject: Proposed resolution to index in conference-package
> > 
> > 
> > Orit and I talked for awhile on this one and I think we have a 
> > proposal that seems like it should meet everyone's needs 
> with regards 
> > to the keys to index some of the things in the conference package.
> > 
> > 
> > No change in <user> definition: <user> is indexed by a unique 
> > attribute called 'entity' of type URI which contains an AOR 
> for the user.
> > 
> > <endpoint> definition is changed to somewhat between -08 
> and -09 but 
> > better than both:  <endpoint> is indexed by a single unique 
> attribute 
> > called 'entity' of type string which is generated by the server and 
> > meaningful to it. If the server wants, it may use things 
> like GRUU for 
> > this. The endpoint also contains *optional* fields as in 
> -09 that are 
> > not part of the index and contain the sip call-id, contact,  and to 
> > and from tags.
> > 
> > No change in <media> definition: media is indexed by a unique 
> > attribute called 'id' of type string. This 'id' is NOT the 
> SDP label necessarily.
> > <media> contains *optional* sub-element <label> as in -09.
> > 
> > Can anyone think of a reason why with would not work?
> > 
> > Thank, Cullen
> > 
> 
> 
> 
> 
> _______________________________________________
> 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: Fri, 4 Mar 2005 10:45:21 -0500

Inline

> From: Orit Levin [mailto:[email-masked]]
> Sent: Thursday, March 03, 2005 7:26 PM
> To: Brian Rosen; Cullen Jennings; sipping
> Cc: Alan Johnston; Rohan Mahy; Roni Even
> Subject: RE: [Sipping] RE: Proposed resolution to index in conference-
> package
> 
> Guys,
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.

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

> these applications and should be avoided.
I don't agree, or at least, I think it's a "don't care" situation.
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.

Brian