The focus On Mar 26, 2008, at 6:11 AM, Paul Kyzivat wrote: > I noticed something in this too: > > Rohan Mahy wrote: > >> My recommendation which I sketched out at the mic back at the San >> Diego IETF goes like this: >> Before a call is answered, a new call is composed, or a call is >> picked up / unheld the phone requests the floor and does not do >> anything with SIP signaling until it gets a floor response or >> times out. If the phone gets the floor, it proceeds with >> appropriate SIP signaling. If the phone is notified that another >> phone has the floor or the floor request times out, it plays some >> appropriate error. When the phone puts a call on hold, hangs up, >> or parks a call, it releases the floor. When a phone receives a >> join request, the focus keeps the floor. If the focus transfers >> to another endpoint, that endpoint needs to take the floor. > > Is there a mechanism if BFCP for the holder of the floor to yield > it to a particular participant? That seems to be required for the > last point. If the focus simply relinquishes the floor, in the > expectation that the transfer target will take it, there is a > window when someone else might grab it. > > Paul
The focus sends a third party FloorRequest (on behalf of the new focus), then releases its floor and the correct thing should happen. thanks, -rohan From the beginning of Section 4.1 of RFC 4582 > Floor participants request a floor by sending a FloorRequest > message > to the floor control server. BFCP supports third-party floor > requests. That is, the floor participant sending the floor request > need not be colocated with the media participant that will get the > floor once the floor request is granted. FloorRequest messages > carry > the identity of the requester in the User ID field of the common > header, and the identity of the beneficiary of the floor (in third- > party floor requests) in a BENEFICIARY-ID attribute. > > Third-party floor requests can be sent, for example, by floor > participants that have a BFCP connection to the floor control > server but that are not media participants (i.e., they do not > handle any media). _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
