1 / 10

BFCP draft-ietf-xcon-bfcp-02.txt

BFCP draft-ietf-xcon-bfcp-02.txt. Gonzalo.Camarillo@ericsson.com. Section 3: Scope. Check that it is consistent with the conferencing framework. Authentication. Digest SDP carries the first nonce To save one RTT The server can provide the nonce for the next request

race
Télécharger la présentation

BFCP draft-ietf-xcon-bfcp-02.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BFCPdraft-ietf-xcon-bfcp-02.txt Gonzalo.Camarillo@ericsson.com

  2. Section 3: Scope • Check that it is consistent with the conferencing framework

  3. Authentication • Digest • SDP carries the first nonce • To save one RTT • The server can provide the nonce for the next request • Typically not used if TLS is employed • TLS • Servers MUST support it • Clients SHOULD support it • Alternative • Mandate TLS and do basic instead of digest

  4. Transactions • Client-initiated transactions • Client send request (over TCP) and waits for response • No timeouts defined for clients • Alternative • Define application-layer timers and error-recovery mechanisms

  5. Several Ongoing Floor Requests • BFCP allows clients to have several ongoing floor requests on the same floor • Servers can keep clients from doing so • Does not add complexity • We would define Request ID anyway • Combination of User ID and Floor ID would be enough if only one request was allowed, but using implicit identifiers is a bad idea

  6. To be Done • IANA Considerations • Security Considerations • SDP format for BFCP • WG item in MMUSIC

  7. Volunteers to Review the Draft • We need a few people to commit to review the whole spec

  8. Event Package for Floor Info (1) • draft-ekim-sipping-conf-floor-package-00 • Richer Information than BFCP FloorInfo = (FIXED-HEADER) [TRANSACTION-ID] (USER-ID) [FLOOR-ID] *( (FLOOR-REQUEST-ID) [BENEFICIARY-ID] [USER-DISPLAY-NAME] [USER-URI] *(FLOOR-ID) [HUMAN-READABLE-INFO] [PRIORITY] (REQUEST-STATUS) ) [NONCE]

  9. Event Package for Floor Info (2) • UAs that do not implement BFCP • E.g., listening, but not participating • BFCP allows clients to • Request floors • Be informed about the status of a floor • Will all floor control protocols include this functionality?

  10. Event Package for Floor Info (3) • BFCP provides a simple mechanism to be informed about the status of a floor • Up to the server when to generate notifications and which information to include (e.g., the 10 first floor requests in the queue) • The event package would make it possible to use throttles, partial notifications, filters, etc…

More Related