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

[[e-mail]]

Hi Jan,

Thanks for the comments. See inline.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of ext
> Jan Holm (AL/EAB)
> Sent: 01 April, 2004 12:07
> To: '[e-mail]'
> 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 
> 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.

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

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

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

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

 
> ---------------------------------
> REQ-20: There MAY be operations to manipulate the request set
>    available for floor chair(s).
> 
> Q: What does this requirement mean?


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

--
Petri


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