Subject: [XCON] Comments on the draft-ietf-xcon-floor-control-req-00.txt

From: "Jan Holm (AL/EAB)" <[email-masked]>
Date: Thu, 1 Apr 2004 11:06:30 +0200

Hi all,

I am working with Push-To-Talk over Cellular (PoC) applications and looking into the floor control aspects.

It looks like the requirements in this draft is close to the requirments for PoC. However when reading through the document I get the impression that 2 concepts are mixed (and that may be very logical and natural to do that):

1) There is a concept of a Concerence application. This concepts provides features like moderators, moderator control outside a conference mixing equipment, giving information about participants, etc. It can be expected that this part of the protocol may be byte consuming, and that it would best be expressed with some kind of xml schema.

2) There is a concept of floor control. Thisconcept provides floor requests, floor grant, floor revoke, etc. type of functionality. It can be expected that this protocol do not have to carry a lot of information. The name of the method (like "Floor request" would more or less be sufficent in many of the cases.

From PoC point of view the last part is the part that, at least in the early phases, would be of interest.

The question is is it possible to divide the requirement document into 2 parts. A Conference application part and a floor control part.

This approach could make it possible to create 2 protocols 

Below follows some more detailed question about some of the requirements.
-------------------------------------------------------------------------
   REQ-2: It MUST be possible to group several media sessions in a
   conference together so that one floor applies to the group.

Q: Does the above imply that the following combinations of floor and media can be defined:

     1) All media type have a seperate floor. One can speak and one can send video.
     2) Combine several media types for one floor and all media types granted at the same time.
     3) Combine several media types for one floor but only one media granted at at the same time.

--------------------------------------------------------------------
   REQ-3: It MUST be possible to define who is allowed to create, change
   and remove a floor in a conference. We assume that the conference
   owner always has this privilege and may also authorize other
   entities, via the conference policy.

Q: Can this requirement be removed since it has nothing to do with floor control.

---------------------------
REQ-17: Bandwidth and terminal limitations SHOULD be taken into
   account in order to ensure that floor control can be efficiently used
   in mobile environments.

   It should be noted that efficient communication by means of minimal
   sized messages may contradict the desire to express reasons for
   requesting a floor (as per REQ-6) along with other information.
   Therefore, a floor control protocol SHOULD be designed in a way that
   it allow for expressive as well as minimal messaging, as (negotiable)
   configuration option and/or selectable on a per-message basis.

Comment: Can a seperate less byte consuming protocol be developed for the floor control in order to support the above requirment.

---------------------------------
REQ-20: There MAY be operations to manipulate the request set
   available for floor chair(s).

Q: What does this requirement mean?

/Regards Jan Holm

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: [email-masked]
Date: Thu, 1 Apr 2004 15:53:45 +0300

Hi Jan,

Thanks for the comments. See inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Jan Holm (AL/EAB)
> Sent: 01 April, 2004 12:07
> To: [email-masked]'
> Subject: [XCON] Comments on the 
> draft-ietf-xcon-floor-control-req-00.txt
> 
> 
> Hi all,
> 
> I am working with Push-To-Talk over Cellular (PoC) 
> applications and looking into the floor control aspects.
> 
> It looks like the requirements in this draft is close to the 
> requirments for PoC. However when reading through the 
> document I get the impression that 2 concepts are mixed (and 
> that may be very logical and natural to do that):
> 
> 1) There is a concept of a Concerence application. This 
> concepts provides features like moderators, moderator control 
> outside a conference mixing equipment, giving information 
> about participants, etc. It can be expected that this part of 
> the protocol may be byte consuming, and that it would best be 
> expressed with some kind of xml schema.
> 
> 2) There is a concept of floor control. Thisconcept provides 
> floor requests, floor grant, floor revoke, etc. type of 
> functionality. It can be expected that this protocol do not 
> have to carry a lot of information. The name of the method 
> (like "Floor request" would more or less be sufficent in many 
> of the cases.

This may be true in applications like PoC but in conferencing context
floor control requests are expected to carry more information (e.g. the topic
of the question so moderator may decide to grant you the floor sooner in the case 
of long queue).

> 
> From PoC point of view the last part is the part that, at 
> least in the early phases, would be of interest.
> 
> 
> The question is is it possible to divide the requirement 
> document into 2 parts. A Conference application part and a 
> floor control part.

This is already separated. Conference application (policy protocol) takes
care of mixer control, floor creation, appointing moderator etc. 
Some of the (conf appl) requirements are also mentioned in this draft 
but they will be moved to annex or separate section 
(since they are covered in CPCP-reqs).

> This approach could make it possible to create 2 protocols 

Luckily, we are already creating two protocols: CPCP and FCP. 

> Below follows some more detailed question about some of the 

Yes (2 separate floors).

>      2) Combine several media types for one floor and all media types granted at the same time.

Yes (common floor).

>      3) Combine several media types for one floor but only one media granted at at the same time.

No (if you are granted the common floor, they are reserved for you and it is up to you to use or not to use them)

>    REQ-3: It MUST be possible to define who is allowed to 
> create, change and remove a floor in a conference. We assume that the conference

Yes, it will be moved to annex or separate section.

>    account in order to ensure that floor control can be 
> efficiently used in mobile environments.
> 
>    Therefore, a floor control protocol SHOULD be designed in 
> a way that it allow for expressive as well as minimal messaging, as 
> (negotiable)configuration option and/or selectable on a per-message basis.
> 
> Comment: Can a seperate less byte consuming protocol be 
> developed for the floor control in order to support the above 
> requirment.

It may be difficult (since there may be many parameters and a lot of
additional info in floor requests and responses).

This is floor request queue manipulation in the server ("set" if used instead of queue).

--
Petri