RE: [XCON] Proposed small fixes to BFCP

["Even, Roni" <roni.even at polycom.co.il>]

Hi guys,
I may open here a can of worms, but when looking at an implementation that includes BFCP as described in http://www.ietf.org/internet-drafts/draft-even-xcon-pnc-01.txt, we encountered the issue of NAT traversal. The pnc draft addresses multipoint cases but may also be used in a point to point case where one of the endpoints is the BFCP server. Since BFCP is only defined for TCP we feel that there is currently a lack of support for TCP based NAT traversal solutions. Maybe we can consider allowing BFCP over UDP.
Thanks
Roni Even 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo at ericsson.com]
> Sent: Friday, April 21, 2006 4:36 PM
> To: XCON
> Cc: alan at sipstation.com; Keith Drage; Adam Roach; Joerg Ott
> Subject: [XCON] Proposed small fixes to BFCP
> 
> Folks,
> 
> while implementing our BFCP stack (the 'running code' part of the
> protocol), we have discovered a couple of relatively minor bugs in the
> BFCP spec that need to be fixed. They are probably too big to be fixed
> thru RFC editor notes. My suggestion would be to remove the draft from
> the queue, perform the changes I propose below, and send it back to the
> queue. Opinions?
> 
> 
> Section 5.3.9 defines the ChairAction message. That message can contain
> several floors (which belong to the same floor request operation) but
> can only provide a single queue position (within the REQUEST-STATUS
> attribute) for all of them. We need to be able to provide different
> queue positions for different floors (e.g., second for floor 1 and third
> for floor 2). In order to do this, we need to define a new grouped
> attribute called FLOOR-REQUEST-STATUS whose definition would be the
> following:
> 
> Attribute header:
> 
>       0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |x x x x x x x|M|    Length     |           Floor ID            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Attribute ABNF:
> 
>   FLOOR-REQUEST-STATUS =   (FLOOR-REQUEST-STATUS-HEADER)
>                            (REQUEST-STATUS)
>                            [STATUS-INFO]
>                           *[EXTENSION-ATTRIBUTE]
> 
> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute
> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)'
> 
> The same for the already existing ChairAction message.
> 
> 
> Additionally, we would define a new grouped attribute called
> OVERALL-REQUEST-STATUS, whose definition would be almost identical to
> the FLOOR-REQUEST-STATUS attribute. The only difference is that this one
> would carry a Floor Request ID instead of a Floor ID. This attribute
> would be used within the FLOOR-REQUEST-INFORMATION attribute, whose ABNF
> would become:
> 
> OLD:
> 
>     FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
>                                   (REQUEST-STATUS)              <--
>                                 1*(FLOOR-ID)                    <--
>                                   [BENEFICIARY-INFORMATION]
>                                   [REQUESTED-BY-INFORMATION]
>                                   [PRIORITY]
>                                   [PARTICIPANT-PROVIDED-INFO]
>                                   [STATUS-INFO]                 <--
>                                  *[EXTENSION-ATTRIBUTE]
> 
> NEW:
> 
>     FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
>                                   (OVERALL-REQUEST-STATUS)
>                                 1*(FLOOR-REQUEST-STATUS)
>                                   [BENEFICIARY-INFORMATION]
>                                   [REQUESTED-BY-INFORMATION]
>                                   [PRIORITY]
>                                   [PARTICIPANT-PROVIDED-INFO]
>                                  *[EXTENSION-ATTRIBUTE]
> 
> 
> 
> Then, we would need to add a brief discussion on queues, indicating that
> the queue positions in the OVERALL-REQUEST-STATUS attribute refer to
> positions in a global queue for floor requests and that queue positions
> in the FLOOR-REQUEST-STATUS attribute refer to positions in a queue for
> floor requests for a particular floor. Of course, implementations are
> free to implement (or provide information about) one, both, or none of
> these queue types.
> 
> The ChairAction message would become:
> 
> OLD:
> 
>     ChairAction  =   (COMMON-HEADER)
>                    1*(FLOOR-ID)             <--
>                      (FLOOR-REQUEST-ID)
>                      (REQUEST-STATUS)       <--
>                      [STATUS-INFO]
>                     *[EXTENSION-ATTRIBUTE]
> 
> NEW:
> 
>     ChairAction  =   (COMMON-HEADER)
>                    1*(FLOOR-REQUEST-STATUS)
>                      (FLOOR-REQUEST-ID)
>                      [STATUS-INFO]
>                     *[EXTENSION-ATTRIBUTE]
> 
> 
> A different issue (more easily fixable than the issue above) is that the
> FloorRequest and the FloorQuery messages should carry 1*(FLOOR-ID)
> instead of *(FLOOR-ID).
> 
> Cheers,
> 
> Gonzalo
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon