Subject: RE: [Sipping] draft-levin-sipping-conferencing-requirements-00.tx t

From: "Sanjoy Sen"<[email-masked]>
Date: Wed, 1 May 2002 16:41:45 -0500

Hi,

Some comments/questions -

I fail to see the value of the Meta-Application and a SIP Conference
application below it in a framework which is expected to deal only with SIP.
I do agree with the definition of (multiple types of) data planes and data
control plane under the SIP conferencing application. 

	Section 3. Hierarchical Application Signaling Model

[SS] The use of the term 'signaling' is confusing because you talk about
data & media planes in this section.

	Section 3. ...
	A Chair Control Application is responsible for arbitration of a 
   Conference Chair role. 

[SS] Do you envisage changing of Conference Chair role happening using SIP
or out-of-band?

	Section 3. ...
	A Chair Control Application is responsible for arbitration of a 
   Conference Chair role. In this example, only the Conference Chair is 
   responsible for adding and deleting conferencing participants "to" 
   and "from" both of the conferences.  

[SS] If the Conference Chair wants to control the media data planes, e.g.,
mute the audio for certain users, how can that be represented by this model?

	4. SIP Star Conferencing Application 
    
   SIP Star Conferencing Applications fit the Hierarchal Application 
   Signaling Model defined above. 

[SS] This section talks about the conference topology. I fail to see how
this can be fitted to the hierarchical application signaling model in
Section 3. I would assume that a single conferencing session is represented
by a star in your model.

[SS] Role of "Center Participant": Do you see any other role except bridging
and anchoring of data planes and sending/receiving commands and sending out
informative notifications?

	SIP Star Conferencing Requirements 
  
   ... One of the examples for using the Conference Identifier 
   is upon joining a specific conference. 
[SS] Did you mean - for joining a specific conference?

	Conference description SHOULD be standardized. 
[SS] Is SDP not enough?

	Center Participant SHALL be able to convey a current Conference Role

   of each of the participants (i.e. Center Participant vs. Edge 
   Participant) to other participants in the Conference.
[SS] Another issue is how does the center participant gets determined if the
conference topology changes, e.g., if we want to move from an end-party
mixed ad-hoc conference to a conference server. That is, the determination
of Center participant and the Edge participant must be deterministic.

	A procedure for moving a Center Participant role from a current 
   Center to another Participant SHALL be defined. 
[SS] A similar procedure will probably be needed for switching the
conference chair role (e.g., if the chair has to leave the conference).

	We envision that additional requirements (such as floor control, 
   conferencing management, etc.) will be grouped according to their 
   subjects and defined as Sub-applications of the SIP Star Conferencing 
   Application. 
[SS] Please clarify with an example. Does this imply multiple conference
subgroups under a conference chair and application of, say, Floor control to
each such group? 

	Media Plane is a private case of Data Plane.
[SS] What is private plane?

[SS] Additional Requirements: I think that the following requirements need
to be addressed in this draft-

I) Ability to merge two existing conference sessions to create a new
conference session. This may require that a Center Participant in an ongoing
conference assume the role of a Edge Participant in the merged conference.

II) Ability of an endpoint to REFER another endpoint to a subset of the
conference data planes

III) For connection oriented data planes, ability for each endpoint in a
point-to-point session to determine who would initiate the connection 

IV) Proper correlation through the layers of the hierachical conference
model (e.g, T.120 is a data plane under SIP)

V) Conference Chair requirements:

-Enable a Chair to allow a particpant to see only a subset of the data
planes (e.g.,  participate in audio conference but not application sharing).
-Ability for the Chair to mute/unmute a participant or a port
-Ability for the Chair to lock/unlock a conference 
-Ability for the Chair and conferees to receive notification before the
conference ends 
-Ability for the Chair to extend the conference duration

VI) Application collaboration requirements:
-Ability to perform application sharing function in a deterministic manner
(this would require the users to request/grant control on the shared
application in a coordinated fashion)
-Ability to request transfer of shared application state in case the
conference host moves (e.g., if a conference changes from being end-point
mixed to a conference server). 

Thanks,
Sanjoy

> -----Original Message-----
> From: Orit Levin [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 5:20 PM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> Subject: [Sipping] 
> draft-levin-sipping-conferencing-requirements-00.txt
> 
> 
> We submitted this morning a 
> "Conferencing Requirements for SIP Based Applications" draft
> which is based on the direction discussed during a 
> "Conferencing Lunch" in
> Minneapolis.
> Till the draft appears in the IETF directory, please, pick up 
> a copy for
> your review at
> ftp://ftp.radvision.com/Standards/ 
> <ftp://ftp.radvision.com/Standards/> 
> 
> Abstract 
>     
>    At present, SIP signaling sessions under a conferencing 
> application 
>    must rely on out-of-band signaling for participant information and 
>    conference manipulation. This document suggests an integrated 
>    approach that defines a Hierarchal Application Signaling Model and 
>    allows SIP to support both basic and complex applications based on 
>    more basic applications. As example conferencing applications, a 
>    general "SIP Star Conferencing Application" and a more specialized 
>    "SIP Star Real Time Multimedia Conferencing Application" 
> are defined 
>    within this Hierarchical Application Signaling Model. This 
> document 
>    identifies requirements for SIP entities that participate or host 
>    these applications. 
>    A future document will suggest the mapping of the requirements to 
>    corresponding protocols and their primitives. 
> 
> Best Regards,
> Orit Levin
> Chief Architect
> RADVISION Inc.
> TEL: +1.201.529.4300 x 230
> FAX: +1.201.529.3516
> 
> 
> _______________________________________________
> 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: Orit Levin <[email-masked]>
Date: Wed, 1 May 2002 23:53:18 -0400

Hi Sanjoy!
Thanks a lot, indeed, for your detailed notes.
My take on your questions is below, inside the text.
BR,
Orit .
 
-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Wednesday, May 01, 2002 5:42 PM
To: 'Orit Levin'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; Sanjoy Sen
Subject: RE: [Sipping] draft-levin-sipping-conferencing-requirements-00.tx t

Hi, 
Some comments/questions - 
I fail to see the value of the Meta-Application and a SIP Conference
application below it in a framework which is expected to deal only with SIP.
I do agree with the definition of (multiple types of) data planes and data
control plane under the SIP conferencing application. 
OL: The Meta-application is just the root of the proposed hierarchy model.
The whole reason for "defining" the model was to achieve understanding among
us by using an agreed "model" and associated terminology. Each one of us had
a set of requirements in different area/plane/layer/application. It was very
hard to express the requirements without referring to some model. A
Conferencing application, in general, is a complicated beast having many
aspects to it. Therefore, we needed means to express a modular application
approach. Hopefully, the examples illustrate why we needed to go out of a
single Conferencing application. As Andy mentioned, the "other applications"
would be mostly  SIP applications. For example, a SIMPLE-based IM
application... and its GROUP feature.
        Section 3. Hierarchical Application Signaling Model 
[SS] The use of the term 'signaling' is confusing because you talk about
data & media planes in this section. 
OL: The name refers to the fact that only "the signaling plane" of the
application is a part of the Hierarchy. The Data Plane is always an "end
node". I agree that it may be not clear enough.
        Section 3. ... 
        A Chair Control Application is responsible for arbitration of a 
   Conference Chair role. 
[SS] Do you envisage changing of Conference Chair role happening using SIP
or out-of-band? 
OL: Either way. Model allows for both.
        Section 3. ... 
        A Chair Control Application is responsible for arbitration of a 
   Conference Chair role. In this example, only the Conference Chair is 
   responsible for adding and deleting conferencing participants "to" 
   and "from" both of the conferences.  
[SS] If the Conference Chair wants to control the media data planes, e.g.,
mute the audio for certain users, how can that be represented by this model?
OL: In this specific example, I would expect that the current Chair identity
would be transferred as follows (up and down the tree):
 Chair Control App -> Meta App -> Conferencing App -> Floor Control App
        4. SIP Star Conferencing Application 
    
   SIP Star Conferencing Applications fit the Hierarchal Application 
   Signaling Model defined above. 
[SS] This section talks about the conference topology. I fail to see how
this can be fitted to the hierarchical application signaling model in
Section 3. I would assume that a single conferencing session is represented
by a star in your model.
OL: It fits as a compliant component within the model. It also has
sub-applications and data planes.
[SS] Role of "Center Participant": Do you see any other role except bridging
and anchoring of data planes and sending/receiving commands and sending out
informative notifications?
OL: Not at this moment. But it seems to me that the Center is potentially
capable of doing "everything" with these general definitions.
        SIP Star Conferencing Requirements 
  
   ... One of the examples for using the Conference Identifier 
   is upon joining a specific conference. 
[SS] Did you mean - for joining a specific conference?
OL: Yes, this is what I meant. 
        Conference description SHOULD be standardized. 
[SS] Is SDP not enough?
OL: My understanding is that SDP description is placeholder for text, which
(in case of SIP) relates to a SIP dialog (not a Conference). Anyway, there
are two open questions here: (1) syntax and semantics of the string, (2) how
to convey it/ where to encode it.
        Center Participant SHALL be able to convey a current Conference Role

   of each of the participants (i.e. Center Participant vs. Edge 
   Participant) to other participants in the Conference. 
[SS] Another issue is how does the center participant gets determined if the
conference topology changes, e.g., if we want to move from an end-party
mixed ad-hoc conference to a conference server. That is, the determination
of Center participant and the Edge participant must be deterministic.
OL: Agreed 100%. I was thinking that in a normal case you couldn't move the
center without doing it through the current center itself, and the Center
failure scenario should be addressed as well.
        A procedure for moving a Center Participant role from a current 
   Center to another Participant SHALL be defined. 
[SS] A similar procedure will probably be needed for switching the
conference chair role (e.g., if the chair has to leave the conference).
OL: Yes. But I would use the model in this case and see a "Conference Chair"
protocol as a separate application. It can be defined as a sub-application
of a conferencing application or related to it by the Meta-application
means.
        We envision that additional requirements (such as floor control, 
   conferencing management, etc.) will be grouped according to their 
   subjects and defined as Sub-applications of the SIP Star Conferencing 
   Application. 
[SS] Please clarify with an example. Does this imply multiple conference
subgroups under a conference chair and application of, say, Floor control to
each such group?
OL: You can take a look at the "Floor Control" draft referred in the
"Conferencing Draft". In general, I would say that a sub-application uses
the SIP/SDP dialogs (forming the SIP Conference) for transferring
sub-application primitives and information. The reason for doing it is that
these sub-applications need an ability to address innate SIP/SDP objects
(such as media streams). If this reason doesn't exist, I wouldn't overload
SIP signaling (even in the expense of additional transport layer
connections).
        Media Plane is a private case of Data Plane. 
[SS] What is private plane? 
OL: I meant that "Media Plane" is a specific (a type of ) "Data Plane", for
example Audio Plane is a type of Data Plane.
[SS] Additional Requirements: I think that the following requirements need
to be addressed in this draft- 
I)                    Ability to merge two existing conference sessions to
create a new conference session. This may require that a Center Participant
in an ongoing conference assume the role of a Edge Participant in the merged
conference.
OL: This is again a good test for the "model". You can do it either via
Meta-application or by manipulating the Presentation Spaces. The
functionality you get would be different, of cause. But, this way, we are
capable of describing what we want to achieve.
II) Ability of an endpoint to REFER another endpoint to a subset of the
conference data planes 
OL: Yes. This one exists, but not explicitly enough.
II)                  For connection oriented data planes, ability for each
endpoint in a point-to-point session to determine who would initiate the
connection 
OL: I am not sure, whether it is a "conferencing" feature. But definitely we
should discuss this and the rest below for the next round. 
III)                Proper correlation through the layers of the hierachical
conference model (e.g, T.120 is a data plane under SIP)
OL: Yes. 
IV)                Conference Chair requirements:
OL: Again, I can just repeat from the draft: "We envision that additional
requirements (such as floor control, conferencing management, etc.) will be
grouped according to their subjects and defined as Sub-applications of the
SIP Star Conferencing Application."
 And, I hope, seeing you in Las Vegas!
Orit. 
-Enable a Chair to allow a particpant to see only a subset of the data
planes (e.g.,  participate in audio conference but not application sharing).
-Ability for the Chair to mute/unmute a participant or a port 
-Ability for the Chair to lock/unlock a conference 
-Ability for the Chair and conferees to receive notification before the
conference ends 
-Ability for the Chair to extend the conference duration 
VI) Application collaboration requirements: 
-Ability to perform application sharing function in a deterministic manner
(this would require the users to request/grant control on the shared
application in a coordinated fashion)
-Ability to request transfer of shared application state in case the
conference host moves (e.g., if a conference changes from being end-point
mixed to a conference server). 
Thanks, 
Sanjoy 
 
> From: Orit Levin [ mailto:[email-masked] <mailto:[email-masked]> ]

> ftp://ftp.radvision.com/Standards/ <ftp://ftp.radvision.com/Standards/>  
> < ftp://ftp.radvision.com/Standards/ <ftp://ftp.radvision.com/Standards/>
> 
> 
> Abstract 
>     
<https://www1.ietf.org/mailman/listinfo/sipping>