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:49:36 +0300

Gonzalo,
OK, I understand it now. So if the offer has a=any the answer cannot be
any. 

What is the meaning of both, is it for an offer like "any" or is it an
answer to "any" that says I want to be a server but you can later ask me
to be a client.

I think you can make the changes accordingly with an example and it will
be OK for me.

Roni

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Monday, July 04, 2005 3:30 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,

clarifications inline:

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

"any".

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

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

> 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

It does both, answers with "a=floor-control: only-server" and includes
the 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.

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.

> 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

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

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