Subject: RE: [Sipping] RE: Conference Package -09?

From: "Orit Levin" <[email-masked]>
Date: Thu, 3 Feb 2005 12:31:22 -0800

Brian, I agree with your comments.
Regarding (4) - Yes, absolutely. The text will say that the "type" value
is the SDP "media".

Regarding (2) and (3):
 
I don't see any specific usage for carrying the "mid" values in the
Package - just for completeness. I am perfectly OK with removing them
all together (one can always add them later).
I would like to keep the media description "containers" inside the basic
package. I suggest indexing the entries by just "an index" that MUST
have unique values for a specific container (instead of "proto" as at
this moment). This basic information is needed for any conference to
present the subscribers with the information about what media streams
are supported and being used. That is regardless having multiple streams
of the same "type" and complex template topologies.

This will allow XCON to define its own usage of these containers, i.e.,
what the actual key value is (e.g. the "label" values but we can not be
sure about this at this moment) and add more sub-elements. Or,
alternatively, to define additional container(s) with hierarchal
structure - if needed.

For the SIPPING basic package I agree with Roni that we should add the
"label" as a sub-element to the media containers, and this is up to the
majority decision.

Orit. 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Brian Rosen
	Sent: Wednesday, February 02, 2005 7:53 PM
	To: Orit Levin; 'sipping'; 'Cullen Jennings'
	Cc: 'Rohan Mahy'; 'Gonzalo Camarillo'; 'Dean Willis'
	Subject: [Sipping] RE: Conference Package -09?

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

	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.

	4. Rename all the "proto"s to something more appropriate (e.g.
"type").

	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. 

_______________________________________________
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: "Even, Roni" <[email-masked]>
Date: Sat, 5 Feb 2005 01:22:35 +0200

Orit,

I am not sure I follow you suggested changes in 2 and 3. 

My point is that at the conference level you have  a list of
conference-media-type used by the available media type and the
active-media.

For each endpoint you have a list of media-type. How do you co-relate
which conference-media-type is which in the endpoint media-type.

Which elements are you suggesting to change.

Roni Even

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Orit Levin
Sent: Thursday, February 03, 2005 4:50 AM
To: sipping; Cullen Jennings; Brian Rosen
Cc: Rohan Mahy; Gonzalo Camarillo; Dean Willis
Subject: [Sipping] 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).

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.

---

From: "Orit Levin" <[email-masked]>
Date: Fri, 4 Feb 2005 15:40:41 -0800

Roni, as per my earlier reply to Brian, I suggested using plain indexing
(1, 2, 3 ) for all media "containers": available, active, and for the
endpoints' media. That is instead of the "proto" being used as the key
in the conference containers. (The endpoint "media" uses "id" as the key
already.)
 
The indexing is local per container, i.e. it is not being used for
correlation of media streams. The correlation among the streams in
different containers is achieved using the "label". I will add the
"label" sub-element for both conference containers, as you suggested.
("Label" exists already in the endpoint media.)
 
Orit.

	From: Even, Roni [mailto:[email-masked]] 
	Sent: Friday, February 04, 2005 3:23 PM
	To: Orit Levin; sipping; Cullen Jennings; Brian Rosen
	Cc: Rohan Mahy; Gonzalo Camarillo; Dean Willis
	Subject: RE: [Sipping] Conference Package -09?

	Orit,

	For each endpoint you have a list of media-type. How do you
co-relate which conference-media-type is which in the endpoint
media-type.

	Roni Even

On Behalf Of Orit Levin

	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.

	Orit.

---

From: "Even, Roni" <[email-masked]>
Date: Sat, 5 Feb 2005 01:56:14 +0200

Orit,

Thanks for the explanation. Looks good

Roni

From: Orit Levin [mailto:[email-masked]] 
Sent: Saturday, February 05, 2005 1:41 AM
To: Even, Roni; sipping; Cullen Jennings; Brian Rosen
Cc: Rohan Mahy; Gonzalo Camarillo; Dean Willis
Subject: RE: [Sipping] Conference Package -09?

Orit.

	Orit,

	Roni Even

	Guys,

	Orit.

---

From: "Orit Levin" <[email-masked]>
Date: Mon, 7 Feb 2005 00:08:23 -0800

I would like to understand the full proposal.

A single user can use multiple devices running different signaling
protocols (theoretically even from a single device).

What do you mean by the CallID? The SIP CallID?

I have the following concerns with your proposal:

1.	SIP CallID is not general enough. How do you ensure key
uniqueness across different protocols?
2.	Having a concept of an endpoint - is an important property of
many signaling protocols. SIP is still working on it (i.e. on GRUU). We
have discussed this requirement over the last year and we agreed to
reflect it in the package. (For those who don't want to or doesn't
support it - the user AOR can be repeated as the endpoint URI. It makes
sense to add this clarification to the text.)

In general, the dialog information is more sensitive than the endpoint
URI and one of the repeatedly expressed requirements was to keep it
optional.

I don't see real technical problem with using indexes as keys. This is
the safest and widely used technique. These indexes are used in the
context of the XML document only. They should not be used beyond it
(e.g. in SDP or complementary XCON protocols).

Again, I feel OK with correcting the mistakes, clarifying text, and
satisfying Cullen's requirement by "promoting" the dialog - as long as
it remains optional.

I feel very uncomfortable with redesigning the package unless we have a
WG majority and/or I hear explicitly from the WG chairs.

Orit.

From: Cullen Jennings [mailto:[email-masked]] 
Sent: Sunday, February 06, 2005 5:23 PM
To: Orit Levin; sipping; Brian Rosen
Cc: Rohan Mahy; Dean Willis; [email-masked]
Subject: Re: Conference Package -09?

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:

Guys,

Orit.