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

["Orit Levin" <oritl at microsoft.com>]

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: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org]
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP