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

From: "Even, Roni" <[email-masked]>
Date: Mon, 4 Jul 2005 15:18:29 +0300

Hi, Gonzalo,
Thanks, but I am not sure I understand how it works.

What will an EP that can also serve as floor server offer. Currently
there is no conference. Will is offer "any" or "server only". 

1. if it sent "any"
We have EPA who offered with  a=floor-control: any ; Does it also offer
a confid and userid for the case that the other side will want to be a
client?

Now does EPB answer with "a=floor-control: only-server" if it wants to
be the server, or does is just answer with confid and userid

 Now EPA wants to become the floor server, that means that it needs to
close the current BFCP channel and offer a new one with "server only".
Now what do we know about EPB, can EPB become a client if it sent
"server only" in the initial answer.

My view is that probably both sides in this case need to have
"a=floor-control: any" in the offer and answer and that the initial
offer should include the confid and userid. If the answer wants to be a
client it will not send confid and userid but if it wants to be a server
is will have in the answer a confid and userid. If you think that this
is how it should work than maybe we can have some text with example

Roni

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Monday, June 27, 2005 6:32 PM
To: Even, Roni
Cc: Colin Perkins; IETF MMUSIC working group
Subject: Re: [MMUSIC] Working group last call:
draft-ietf-mmusic-sdp-bfcp-01.txt - comment

Hi Roni,

thanks for the comments on the draft. Answers inline:

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

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?

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

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

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

With the attribute above this is cover. EPA would issue a new offer with

the new attribute set to "only-server".

Thanks,

Gonzalo

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 04 Jul 2005 15:29:52 +0300

Hi Roni,

> there is no conference. Will is offer "any" or "server only".

"any".

> a confid and userid for the case that the other side will want to be a

Yes, it includes the confid and userid just in case.

> be the server, or does is just answer with confid and userid

It does both, answers with "a=floor-control: only-server" and includes 
the confid and userid.

> "server only" in the initial answer.

This is standard offer/answer behavior. You agree on a set of 
parameters, and if you want to change them at a later stage, you issue a 
new offer... but you cannot be sure that the new offer will be 
acceptable. The same situation applies to codecs, for instance. To 
resolve those issues, we have extensions to express capabilities.

> is how it should work than maybe we can have some text with example

This parameter should make the selection of the client and server roles 
explicit. What you are looking for is a way for expressing your 
capabilities. There are already extensions for doing that, which in any 
case is an orthogonal problem.

Therefore, the value "any" would only be used in offers, not in answers.

If this is OK with you, I can edit the draft accordingly and add an 
example as you suggest.

Cheers,

Gonzalo