Subject: [XCON] draft-sandbakken-xcon-bfcp-udp-00.txt

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 10 Oct 2007 14:36:44 +0200

We have an implementation of BFCP over UDP that we hope can be a
starting point of a standardized version.

May we draw your attention to a new Internet Draft:

http://www.ietf.org/internet-drafts/draft-sandbakken-xcon-bfcp-udp-00.tx
t

Geir Arne

 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 10 Oct 2007 15:40:16 +0300

Hi,

this was explicitly discussed when we started developing BFCP and the 
consensus was to build a simple protocol that would not include 
different transports. That is why later versions of the specification 
removed support for different transports.

Cheers,

Gonzalo

Geir Arne Sandbakken wrote:
> http://www.ietf.org/internet-drafts/draft-sandbakken-xcon-bfcp-udp-00.txt
> 
>  
> 
> Geir Arne
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
>

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 10 Oct 2007 15:53:13 +0200

We use BFCP to floor control our main video and as token control of our
second presentation video stream.  It is a very important protocol for
us.

The need for using UDP as transport presented itself when we wanted to
deploy into an existing infrastructure that had RTP proxies for NAT and
firewall traversal.  Using TCP as a transport was not an option without
serious upgrades to the proxies, and a possible implementation of
ICE-TCP.  

Adding BFCP over UDP in such a proxy is trivial, and adjusting our
implementation to support it in the endpoints was minor work. The
solution is successfully deployed with very little effort.

My view is that we do not want to change BFCP as such, but present an
extension with a slightly different behavior when using UDP as
transport.  The TCP transport should be the baseline, and ICE should be
addressed in the draft. 

Thanks,
Geir Arne

> Hi,
> 
> we have carefully considered the alternatives when deciding
> to define BFCP for TCP only.  It would be nice if you could
> expand further on the motivation and point out why TCP is
> truly unsuitable for this purpose.  And you will need to
> address the issues of how to keep NAT bindings alive.  Will
> you it over ICE (the spec does not make any mention of this).
> 
> I would very much hope that we will not need yet another
> spec for a trivial protocol, since then we will also have
> to define a baseline for interoperability (which can only
> be TCP, IMHO) and so on.
> 
> Cheers,
> Joerg
> 
> 
------------------------------------------------------------------------

---

From: Joerg Ott <[email-masked]>
Date: Wed, 10 Oct 2007 15:50:38 +0300

Hi,

Cheers,
Joerg