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

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 1 May 2002 18:08:23 -0600

Hi Sanjoy!

Thanks for the comments. My responses are inline. I'm sure Orit and others in the design team will further clarify the framework and application requirement issues you raise here.

--Andy

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

A meta-application is *not* about having SIP and non-SIP applications co-exist (though it might help indirectly). Any time you have a need to do inter-UA dialog correlation around a conference a choice needs to be made. Either you are going to limit participation to a single application "provider" or you allow for multiple applications to be provided by different servers. If you don't have a way to communicate the list of applications and participants in each, then you cannot allow for multiple applications. This doesn't mean you have to have a meta-application in all conferences but if you don't allow for it, the framework will be largely pointless as you will have to do out-of-band coordination among applications and we'll be back to square one again.

> I do agree with the 
> definition of (multiple types of) data planes and data 
> control plane under the SIP conferencing application. 

There may be more than one SIP conferencing app, in which case the definition of these planes is per 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. 

The hierarchy is a hierarchy of signaling. So signaling for what happens in a dialog (including media control) is separable from signaling the controls the presentation space and views (like indications to the mixer as to who should be muted or which video stream to feed out, etc), but in all cases there is signaling going on. The hierarchy shows that some signaling will affect only a dialog while others may have direct or indirect effect on all dialogs associated with a conference applications (or group of applications under a meta application)

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

Either model is supportable in this framework. But there isn't a method to do this in-band today so of course this is one of our requirements.

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

This would happen with application-specific signaling (though this would expected to be a well-known application) to manipulate the presentation space and views accordingly.

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

Don't confuse the mixing topology from the dialog topology and either with the application topology (for events and operations specific to the application. They are not equivalent. With that in mind, the initial application defined here is a basic centralized conference, yes.

> [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?

Potentially the center participant could be contributing media to the presentation space as well.

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

The identifier is needed to obtain conference events, participant lists, etc. (perhaps through a SIP events subscription, but that's not for a requirements draft to decide). It's possible that the same identifier could be used to join as well, but that's a different issue.

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

SDP is one possible answer. This is a requirements draft -- it isn't going to proscribe solutions.

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

The application provider is the center participant--already deterministic. But when multiple participants want to provide apps, the motivation for a meta-application appears. The meta-application in general is just a tool for exposing applications and participants.

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

Agreed. This will have some application-specific attributes, though.

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

(Orit and Roni may have a different take on this, but here's my view) Certain classes of requirements will be useful and applicable across multiple applications (kinda like sub-packages for SIP Events). So a floor control sub-application "package" might be something that multiple applications might make use of.

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

I think Orit is referring to the notion that the media plane appears as in indirect result of signaling, whereas a data plane is directly manipulated.

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

This is part of the motivation around meta applications, but it was agreed in the BoF that we weren't going to tackle this scenario yet (as long as we didn't preclude it from happening)

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

Are you talking about a sidebar-type thing or something else?

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

I'm not sure what you mean here. Do you mean the media connection to the application (i.e. push or pull the media)? 

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

I suppose this is a presumed requirement, although your example may be confusing. Some standards like T.120 cover multiple layers of the hierarchy.

> V) Conference Chair requirements: 
> -Enable a Chair to allow a participant 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 

Some of these are on Petri's list (separate draft covering chair control also just released). 

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

These are probably application-specific requirements, but I agree with them.

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

_______________________________________________
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