Subject: RE: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-bfcp-01.txt - comment

From: "Even, Roni" <[email-masked]>
Date: Mon, 6 Jun 2005 14:42:51 +0300

Hi,
I am resending my comments

I have some concerns about the offer answer model usage for defining the
floor control server.

1. Assume we have a point to point call between two endpoints, EPA and
EPB. EPA offers a BFCP m line with confide and userid attributes
suggesting to become the BFCP server for a specific media. Now EPB wants
to be the floor control server for that media and to reject the offer.
Does it reject the m line with port 0 and offers a new BFCP m line. Is
there some way to break such tie if both sides want to be the BFCP
server.

2. In the above case does EPB need to keep the floor-id defined in the
offer from EPA so that the media line will have the same labels.

3. Now suppose that EPB is the current floor server. And EPA wants to
become the floor control server. The questions are as in 1 and 2. An
example for such a case is if EPA is also an MCU and another party, EPC,
called EPA and now it's a three way where EPA is the MCU and EPB and EPC
are connected to it. It is logical in this case to have the floor
control server on EPA.

Thanks

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Colin Perkins
Sent: Thursday, May 26, 2005 2:12 PM
To: IETF MMUSIC working group
Subject: [MMUSIC] Working group last call:
draft-ietf-mmusic-sdp-bfcp-01.txt

This is to announce a working group last call on the SDP format for BFCP
streams. Please send any final comments on this draft to the list before
10th June 2005. If no substantive issues are raised by that time, we
will request the IESG publish this document as a proposed standard RFC.

Colin

On 4 May 2005, at 20:47, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Multiparty Multimedia Session Control

> Working Group of the IETF.
>
>     Title        : Session Description Protocol (SDP) Format for
>               Binary Floor Control Protocol (BFCP) Streams
>     Author(s)    : G. Camarillo
>     Filename    : draft-ietf-mmusic-sdp-bfcp-01.txt
>     Pages        : 15
>     Date        : 2005-5-4
>
> This document specifies how to describe BFCP streams in SDP session
>    descriptions.  User agents using the offer/answer model to 
> establish
>    BFCP streams use this format in their offers and their answers.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-01.txt

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

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 27 Jun 2005 18:32:16 +0300

Hi Roni,

> there some way to break such tie if both sides want to be the BFCP

We need to decide the granularity of this negotiation. I would say that 
we do not want to have a finer granularity than the BFCP stream level. 
That is, we do not want to negotiate for every floor which endpoint acts 
as the floor control server.

What about an attribute that allows an endpoint to state, for a given 
BFCP stream, whether:

1) I want to act only as a floor control server
2) I want to act only as a floor control client
3) I could act as a server or a client, you decide
4) I want to act as a floor control server, and maybe as a client as 
well if you decide so

The syntax could be something like:

a=floor-control: only-server
a=floor-control: only-client
a=floor-control: any
a=floor-control: both

Would this meet the requirements of your application?

> offer from EPA so that the media line will have the same labels.

Floor IDs are local to the endpoint. Therefore, they need not be the 
same in the offer and in the answer.

> are connected to it. It is logical in this case to have the floor

With the attribute above this is cover. EPA would issue a new offer with 
the new attribute set to "only-server".

Thanks,

Gonzalo