Subject: [XCON] Floor Control Draft

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 May 2004 10:20:08 +0300

Folks,

we have just submitted the initial version of an I-D defining a floor 
control protocol. Until it appears in the archives, you can fetch it from:

http://standards.ericsson.net/gonzalo/papers/draft-camarillo-xcon-bfcp-00.txt

This is a preliminary version. We want to get your comments: is this 
approach OK overall? have we missed anything? etc. It would be great to 
start discussions on this topic as soon as possible, so that we can have 
an interesting session in Boston.

We have installed an issue tracker to keep track of the open issues 
related to this draft. It is available at:

http://s99.piuha.net/cgi-bin/roundup.cgi/floor-control/

Please, go through the open issues in the tracker before making your 
comments (we have introduced a bunch of them already). If your comments 
relate to an already open issue, reference it in your mail. This will 
make it easier to keep track of all your comments.

Note that OMA needs a floor control protocol for its Push-To-Talk 
service. If people collaborate sending comments, we believe we can move 
this fast enough.

Thanks,

Gonzalo

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

---

From: Xiaotao Wu <[email-masked]>
Date: Fri, 7 May 2004 10:03:07 -0400 (EDT)

In FloorRequest, should there be a parameter indicating privacy
preference? The floor requester may request to talk anonymously so in
FloorStatus, his name may be shown as 'Anonymous'.

In FloorStatus, should there be some parameters indicating who is the
floor chair, and how many people can hold the floor at the same time?
Maybe a separate message should be used for this.

Is that necessary to have a separate 'Ping' message for floor control?
Should we just use the existing 'Ping' mechanisms, like the ping messages
in session setup protocols.

Thanks!

-Xiaotao

===========================================================
Name      : Xiaotao Wu
Email     : [email-masked]
Homepage  : http://www.cs.columbia.edu/~xiaotaow
Phone     : (212)939-7054,  Fax: (801)751-0217
Phone-PC  : (212)939-7133
SIP       : sip:[email-masked]
Office    : Room 506, Mudd building, West 120th
===========================================================

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2004 12:19:23 -0400

Comments at end.

	Thanks,
	Paul

> make it easier to keep track of all your comments.

I did a quick read thru of draft-camarillo-xcon-bfcp-00, and I have a 
bunch of questions, some general, some detailed:

The relationship between requests and responses is pretty loosely 
specified. I think that implicitly there are transactions, but this 
isn't clear. Does each client request have exactly one response? (I 
think not - I think any floor request can have multiple responses.) How 
does a client know when a request is done and can be forgotten? (Related 
to Issue 9)

Are FloorStatus messages sent spontaneously by the server? There seems 
to be no way to request a FloorStatus message. This seems necessary for 
a client (especially a chair) to understand the state of the floors. 
Also, there seems to be no way to request a FloorRequestStatus. This is 
needed in order to fully interpret a FloorStatus message. (Related to 
issue 4, but more general - needed by non-chairs too.)

How does the client learn his userid? Presumably this needs to be tied 
back to CPCP and/or the conference event package, or something in the 
dialog between a participant and the conference.

In the Introduction the Userid is described as being 32 bits, but in the 
USER-ID attribute it is 16 bits. Which is it?

RequestIds are supposed to be assigned by the client as random numbers. 
Is there any provision for what happens when the same value is reused? 
Do they only have to be unique for a single user, or over all users? If 
only for a single user, why do that have to be random? (Wouldn't it be 
sufficient to require them to be unique?)

How does the client learn the valid floor numbers and their 
significance? (Need to know this in order to know what floor to request.)

How does the client learn the significance of the different priority 
values? (They may be related to some particular rules of order.) All 
participants need to have a common understanding before priority can be 
used in a useful way.

What does USER-URI identify about the user? Is it a sip AOR, a mailto 
uri, a contact address, or what? Can this field be used more than once 
to identify multiple features of the user? (Perhaps this should be the 
same as the User URI in CPCP.)

How does the atomic method of handling multiple floor requests affect 
queuing? Can you be at the front of a queue and still have the floor 
granted to someone behind you because you're not at the head of the 
queue for some other floor?

How does ChairAction work with floor requests for multiple floors? The 
chair request can only specify one floor when specifying the request to 
be acted upon. Does this break the atomicity? (Maybe ChairAction 
shouldn't mention a floor.) (Related to Issue 14)

Using FloorReleaase to cancel a FloorRequest has a potential problem. It 
means that you can't request the floor (again) while you hold the floor. 
This is something that might be desired. (E.g. You hold the floor, but 
there is a queue behind you. You may want to enter the queue again for 
another subject before yielding the floor. (This can be fixed by having 
FloorRelease include the requestId of the request for the floor.)

What happens if a client issues some requests that haven't yet been 
responded to, and then loses the connection? The client can reconnect, 
but the server won't know where to send the response. Does the server 
cancel the request if it can't send a response? It would be sad to be in 
queue for a long time and then lose that position because your 
connection dropped. (Related to Issue 5)

Finally, I am curious why this binary protocol format was chosen over 
some other. (E.g. xml or some other text format.)

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 10 May 2004 13:36:13 +0300

Hi:

A few comments after my first browse through the document.

- I would recommend to add a figure, in section 4, which gives a 
high-level overview of the packet format, e.g., containing the header 
and a bunch of attributes.

- The ChairAction message is overwhelming me. This seems to be a kind of 
open message without clear semantics. The semantics are inside the 
message itself, if I understand correctly. Is it so that the "real" 
semantics of the message are in the Request-Status attribute? If that is 
correct, why not calling the message SetFloor or something similar. Who 
cares if the guy sending the message is a chair or not, it will be 
authenticated (I guess) at the server

- Authentication mechanism: so is it so that the authentication 
mechanism is based on the knowledge of a shared secret, namely a 
user-token combination that serves as authentication? And you send it 
over TCP in the clear? It sounds a ver weak authentication mechanism. 
Perhaps it's worthy to investigate something more sofisticated based on 
hashes.

- Most protocol specifications place mandatory attributes above optional 
ones. BFCP seems to fail in, e.g., FloorStatus, where the Request-Status 
attribute is located at the end.

- Typo: ChairAction (section 5.5) seems to duplicate User-ID and 
Request-ID attributes.

- Typo: Section 7.3 suddently speaks about SFTP.

Regards,

      Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 May 2004 00:46:39 -0400

Some general comments:

* Its not clear to me that there is really a need for a BFCP URI. BFCP 
doesn't make sense as a stanalone protocol, it needs to be set up by 
something else. So, just like there is no RTP URI, I dont see a need for 
a BFCP URI

* is there a reason for allowing multiple transports for this protocol? 
I think this has introduced a lot of complexity into sip, and in 
hindsight, I think it is far more beneficial to pick one. Its not 
obvious whether it should be UDP or TCP. If we think that we'll have 
centralized servers for this (that are publically addressable), tcp is 
probably better. But, if we think floor control will often run peer to 
peer (that is, the floor control server is colocated with an endpoint), 
UDP might be easier from a nat perspective, since you could avoid relays.

* handling of the TOKEN parameter was really unlear. Generally, the 
security features in bfcp are not clear and need to be worked. I'd 
recommend taking a look at stun, which is a good example of how to 
provide authentication and integrity based on an out-of-band shared 
secret in a TLV protocol.

* I agree with Paul that the meaning of the various IDs is unclear. I'd 
suggest separating out transaction IDs (request/response) from other 
types of identifiers. Again, another mistake we made in rfc2543 that was 
corrected in 3261.

* A major issue we need to work is how the various parameters that are 
needed here (the userid, conferenceid, floorid, token) are determined 
from the conferencing framework. Are these signaled in SIP/SDP? THrough 
CPCP? Do we assume that the focus and floor control server are 
colocated? If not, seems like some kind of connection is required.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Alan Johnston <[email-masked]>
Date: Wed, 12 May 2004 09:52:29 -0500

Jonathan,

Thanks for raising these good points.  See my comments below.

Thanks
Alan Johnston
(not as chair)

At 12:46 AM 5/12/2004 -0400, Jonathan Rosenberg wrote:
>something else. So, just like there is no RTP URI, I dont see a need for a 
>BFCP URI

We need offer/answer and SDP for RTP because there are so many parameters 
to negotiate - IP address, port number, codec, bit rate, etc.  I don't see 
any such negotiation for floor control.  I really hope that the floor 
control protocol is simple enough that just passing a URI is sufficient for 
a client to set up the session.

I'm interested in others view of the use of SDP.  This was the approach 
discussed in 
http://www.softarmor.com/wgdb/docs/draft-wu-sipping-floor-control-03.txt 
and should be considered.

>* is there a reason for allowing multiple transports for this protocol? I 
>think this has introduced a lot of complexity into sip, and in hindsight, 
>I think it is far more beneficial to pick one. Its not obvious whether it 
>should be UDP or TCP. If we think that we'll have centralized servers for 
>this (that are publically addressable), tcp is probably better. But, if we 
>think floor control will often run peer to peer (that is, the floor 
>control server is colocated with an endpoint), UDP might be easier from a 
>nat perspective, since you could avoid relays.

I am also not comfortable with multiple transport protocols - this seems 
more complex than necessary.

I'm interested in the peer-to-peer uses of floor control you 
mention.  Currently they are not described in our scenarios document or in 
the floor control requirements - can you give some examples?

>recommend taking a look at stun, which is a good example of how to provide 
>authentication and integrity based on an out-of-band shared secret in a 
>TLV protocol.
>
>suggest separating out transaction IDs (request/response) from other types 
>of identifiers. Again, another mistake we made in rfc2543 that was 
>corrected in 3261.
>
>needed here (the userid, conferenceid, floorid, token) are determined from 
>the conferencing framework. Are these signaled in SIP/SDP? THrough CPCP?

I would prefer CPCP or the conference package but I'm interested in others 
opinions.  This is an important issue to get resolved.

>Do we assume that the focus and floor control server are colocated? If 
>not, seems like some kind of connection is required.

The decomposition of a conference service and any protocols needed between 
the elements are not in scope for XCON.

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 May 2004 16:03:57 -0500

Alan Johnston wrote:

>> something else. So, just like there is no RTP URI, I dont see a need 
>> for a BFCP URI
> 
> 
> We need offer/answer and SDP for RTP because there are so many 
> parameters to negotiate - IP address, port number, codec, bit rate, 
> etc.  I don't see any such negotiation for floor control.  I really hope 
> that the floor control protocol is simple enough that just passing a URI 
> is sufficient for a client to set up the session.
> 

  . . .

> I'm interested in the peer-to-peer uses of floor control you mention.  
> Currently they are not described in our scenarios document or in the 
> floor control requirements - can you give some examples?

I have a mobile phone behind a NATwall. I INVITE you to a push-to-mumble 
(TM) session, which requires floor control. I include ine the INVITE  a 
floor control URI. Unfortunately, it's behind my NATwall, so you can't 
talk to it. I need to know the call failed, and preferably why. As far 
as I can tell now, the offer-answer negotiation succeeded, then nothing 
happened.

Better yet, the call didn't fail, because the same tricks that got our 
RTP through the NATwall also got our floor-control through the NATwall.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 May 2004 00:39:06 -0400

> is sufficient for a client to set up the session.

I dont think the choice of URI or not is driven by the amount of 
parameters. After all, a URI can have lots and lots of parameters. The 
choice is based on whether connecting to a floor control server makes 
sense outside of the context of any specific call or conference. I dont 
think it does. I think there will always be some kind of call or 
confernece, and as such, I see little value for a URI.

-Jonathan R.

---

From: Alan Johnston <[email-masked]>
Date: Thu, 13 May 2004 16:04:12 -0500

At 04:03 PM 5/12/2004 -0500, Dean Willis wrote:
>>to negotiate - IP address, port number, codec, bit rate, etc.  I don't 
>>see any such negotiation for floor control.  I really hope that the floor 
>>control protocol is simple enough that just passing a URI is sufficient 
>>for a client to set up the session.
>talk to it. I need to know the call failed, and preferably why. As far as 
>I can tell now, the offer-answer negotiation succeeded, then nothing happened.

OK - so the UA used STUN/TURN and provides public transport addresses in 
the SDP - hence the media session works.

The same approach could be used by the UA to ensure that the floor control 
URI it creates is routable.  Alternatively, the URI could be made routable 
using DNS ( e.g. bfcp:myserver.dyndns.org).  If the UA is smart enough to 
"fix" the IP addresses in the SDP, it can be smart enough to fix them in 
the floor control URI.

In my mind, the more compelling reason is tighter coupling with the SIP 
dialog.  If the floor control channel is setup using SIP it is more tightly 
coupled than if it is completely separate.   However, taking this argument 
further, it suggest that a CPCP control channel should be negotiated using 
SIP instead of using XCAP (a separate protocol)...

Do others have thoughts, opinions on this?  It is important we decide this 
issue soon...

Thanks,
Alan Johnston
MCI
sip:[email-masked]

>Better yet, the call didn't fail, because the same tricks that got our RTP 
>through the NATwall also got our floor-control through the NATwall.
>
>--
>Dean
>

---

From: Aki Niemi <[email-masked]>
Date: Fri, 14 May 2004 10:31:01 +0300

ext Alan Johnston wrote:
<snip />

> dialog.  If the floor control channel is setup using SIP it is more 
> tightly coupled than if it is completely separate.   However, taking 
> this argument further, it suggest that a CPCP control channel should be 
> negotiated using SIP instead of using XCAP (a separate protocol)...

The CPCP control channel isn't supposed to be negotiated using XCAP. 
XCAP is used to implement that control channel, but the XCAP URI is 
delivered to the participants of a conference by other means. One such 
mean is the conference-info event package, and we've also proposed using 
the Call-Info header to "negotiate" that channel using SIP. See:

http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00.txt

> Do others have thoughts, opinions on this?  It is important we decide 
> this issue soon...

I think negotiating the floor control channel in the offer-answer is the 
way to go. How often will a floor control server be behind a NAT anyway?

Cheers,
Aki

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 14 May 2004 11:18:33 +0300

Folks,

as a side note, regarding the discussion SDP vs. CPCP to establish the 
floor control channel, if we eventually decide to use SDP, one thing we 
will need to discuss is whether we want to use URIs (the bfcp draft 
currently defines them) or a more RTP-looking approach (i.e., providing 
the port number like we do with RTP streams).

Just in case we decided to use the latter, I have just submitted a new 
revision of the comedia draft to MMUSIC.

http://standards.ericsson.net/gonzalo/papers/draft-ietf-mmusic-sdp-comedia-06.txt

Note that this does not mean that I am advocating its use for floor 
control. I am just trying to be on the safe side covering one of the 
possible outcomes of this discussion. In any case, the comedia draft is 
needed for other stuff, regardless of our decision regarding floor control.

If you have any comments on the comedia draft, please send them to me 
and to the MMUSIC mailing list.

Regards,

Gonzalo