Subject: [Sipping] Conference Package -09?

From: "Orit Levin" <[email-masked]>
Date: Wed, 2 Feb 2005 18:49:40 -0800

Guys,
I wished that the latest comments have been posted a month ago (before
and during the last call with the rest of the comments), but you have
convinced me that all of them together deserve refreshing the draft.
 
I completely agree that the package needs to define exactly what each
piece if information means. That being said, it does not need to specify
how "a complete" conference application uses it. It is up to each
application to specify what information to use and how to generate and
populate it. (In this sense, the package can mention examples only.) One
of these applications is the sipping-cc-conferencing. Another is going
to be the standard XCON, which will define how to actually use the
information in the context of its architecture. (It will most probably
add more information to the package.)
 
I don't see a problem to resolve the two "real issues" that Cullen
pointed out, add clarifications that Cullen asked for, revise the "media
entries" per Brian, and also clean the "editorial" mistakes (such as the
usage of "proto" instead of "media" and the "label" examples).
 
My proposal to resolve the XML issues is as follows:
 
1. Add an optional attribute (called "call") to be used as a secondary
key to the "endpoint" element. This is just an index with values (1, 2
,3 , ...) to be generated by the Conferencing server which wants to
present the status information not per "endpoint", but per "call" (i.e.
per a signaling dialog). It is up to the server to decide in what
resolution to present the information to a specific package subscriber.
The subscriber will be able to understand both "resolutions" by
inspecting the provided keys.
 
2. Don't use the "mid" values as the key for the "media" element.
Instead, make the Conferencing server to populate the media "id"
attribute as an index counting the media streams (i.e. with values (1, 2
,3 , ...) ). Add a new optional sub-element to the "media" element
containing the actual "mid" values being used in SDP (if needed).
 
3. Use plain index as a key to the media entries, move "media" (i.e. the
old "proto") as a sub-element, add a new sub-element "label". 
 
4. Rename all the "proto"s to something more appropriate (e.g. "type").
 
Guys and the chairs, please, let me know ASAP whether we have a majority
here so that I can go ahead, make the changes, resubmit the draft, and
keep 3GPP happy.
 
Orit. 

_______________________________________________
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: Wed, 2 Feb 2005 22:52:57 -0500

Generally, I think this is a good idea.  See details in line:

  _____  

From: Orit Levin [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2005 9:50 PM
To: sipping; Cullen Jennings; Brian Rosen
Cc: Rohan Mahy; Dean Willis; Gonzalo Camarillo
Subject: Conference Package -09?

Guys,

I wished that the latest comments have been posted a month ago (before and
during the last call with the rest of the comments), but you have convinced
me that all of them together deserve refreshing the draft.

I completely agree that the package needs to define exactly what each piece
if information means. That being said, it does not need to specify how "a
complete" conference application uses it. It is up to each application to
specify what information to use and how to generate and populate it. (In
this sense, the package can mention examples only.) One of these
applications is the sipping-cc-conferencing. Another is going to be the
standard XCON, which will define how to actually use the information in the
context of its architecture. (It will most probably add more information to
the package.)

I don't see a problem to resolve the two "real issues" that Cullen pointed
out, add clarifications that Cullen asked for, revise the "media entries"
per Brian, and also clean the "editorial" mistakes (such as the usage of
"proto" instead of "media" and the "label" examples).

1. Add an optional attribute (called "call") to be used as a secondary key
to the "endpoint" element. This is just an index with values (1, 2 ,3 , ...)
to be generated by the Conferencing server which wants to present the status
information not per "endpoint", but per "call" (i.e. per a signaling
dialog). It is up to the server to decide in what resolution to present the
information to a specific package subscriber. The subscriber will be able to
understand both "resolutions" by inspecting the provided keys.

2. Don't use the "mid" values as the key for the "media" element. Instead,
make the Conferencing server to populate the media "id" attribute as an
index counting the media streams (i.e. with values (1, 2 ,3 , ...) ). Add a
new optional sub-element to the "media" element containing the actual "mid"
values being used in SDP (if needed).

3. Use plain index as a key to the media entries, move "media" (i.e. the old
"proto") as a sub-element, add a new sub-element "label". 

I don't understand 2 & 3.  I think there are a set of prototypical labels
for media defined in the template, described for a participant in SDP and
shown as status in the conference package.  I don't think there is any
grouping of these media streams that is meaningful; specifically, I don't
think "mid" is a grouping that matters to the conferencing system.  While I
could see a mid value occurring in an SDP offer, I would not expect to see
more than one in an answer.  If someone believes that is possible, could you
give an example?  I don't think there is any grouping of media, but I think
there is usefulness in hierarchical structures (specifically role.stream,
but there are other examples that don't have such simplistic relationships
in the hierarchy).  I'm willing to let the hierarchy wait until we work out
the template stuff in xcon and not make it part of this effort.  Again, if
there is an example of some kind of media container concept that we need now
in the conferencing package, could you give an example?

For what its worth, if you centrally mixed a ViPr, the streams defined for a
normal participant would be: (all unidirectional)

LargeVideoOut

SmallVideoOut1

SmallVideoOut2

SmallVideoOut3

SmallVideoOut4

VideoIn

AudioOutLeft

AudioOutRight

AudioIn

While you could imagine grouping the SmallVideoOut1-4, it doesn't get you
much to do that.

I think each stream will have a unique label, so that label is the key to
the streams of a participant.

I understand reluctance to use the term in SDP (which is "media"), and
"type" is a reasonable choice.  I'm assuming the text would state that it is
content of the media line in the SDP.

Guys and the chairs, please, let me know ASAP whether we have a majority
here so that I can go ahead, make the changes, resubmit the draft, and keep
3GPP happy.

Orit.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 06 Feb 2005 17:23:10 -0800

I would prefer to use the existing unique identifiers that we have instead
of having the focus create new identifiers that need to be mapped. Having
multiple names for things that could be named with one name always seems to
cause complications. I am also not keen on having primary and secondary keys
for a situation where we could do it with a single key.

So here is my proposal

The key for a user is the SIP AOR (as it is in the 08 draft - no change
here)
The key for a endpoint is is the CallID
The key for a media stream is the mid (as it is in the 08 draft).

The hierarch here is that a conference has users, each users has one or more
calls (refereed to as endpoints), and each call has some number of media
streams. If you do this life is very clear. This is what you can discover
from SIP signaling that the focus will know about and be able to report. The
focus can not actually figure out if two calls are to the same endpoint or
not - SIP does not, and should not, reveal this. That is why the CallID, not
the contact should be the index. There are a long list of why using the
contact will not work with situations involving B2BUA including a very
important B2BUA known as the PSTN. Are two PSTN calls coming thought the
same GW the same endpoint or not?

I could be convinced the key for the media stream should be the label not
the mid. I'm not sure which it should be but assume there was a good reason
to choose mid. Can we add some text explaining why this choice?

Cullen

On 2/2/05 6:49 PM, "Orit Levin" <[email-masked]> wrote:

> during the last call with the rest of the comments), but you have convinced me
> that all of them together deserve refreshing the draft.
>  
> I completely agree that the package needs to define exactly what each piece if
> information means. That being said, it does not need to specify how "a
> specify what information to use and how to generate and populate it. (In this
> sense, the package can mention examples only.) One of these applications is
> the sipping-cc-conferencing. Another is going to be the standard XCON, which
> will define how to actually use the information in the context of its
> architecture. (It will most probably add more information to the package.)
>  
> out, add clarifications that Cullen asked for, revise the "media entries" per
> Brian, and also clean the "editorial" mistakes (such as the usage of "proto"
> instead of "media" and the "label" examples).
>  
> 1. Add an optional attribute (called "call") to be used as a secondary key to
> the "endpoint" element. This is just an index with values (1, 2 ,3 , ...) to
> be generated by the Conferencing server which wants to present the status
> information not per "endpoint", but per "call" (i.e. per a signaling dialog).
> It is up to the server to decide in what resolution to present the information
> to a specific package subscriber. The subscriber will be able to understand
> both "resolutions" by inspecting the provided keys.
>  
> make the Conferencing server to populate the media "id" attribute as an index
> counting the media streams (i.e. with values (1, 2 ,3 , ...) ). Add a new
> optional sub-element to the "media" element containing the actual "mid" values
> being used in SDP (if needed).
>  
> Guys and the chairs, please, let me know ASAP whether we have a majority here
> so that I can go ahead, make the changes, resubmit the draft, and keep 3GPP
> happy.
>  
> Orit. 
>  
>  
>  
>