[bfcpbis] More comments on RFC 4582
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 16 April 2012 10:58 UTC
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1239521F86FA for <bfcpbis@ietfa.amsl.com>; Mon, 16 Apr 2012 03:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.189
X-Spam-Level:
X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wVC0eooRltn for <bfcpbis@ietfa.amsl.com>; Mon, 16 Apr 2012 03:58:07 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA2AB21F873E for <bfcpbis@ietf.org>; Mon, 16 Apr 2012 03:58:06 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-86-4f8bfb3d70e7
Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3B.BC.25560.D3BFB8F4; Mon, 16 Apr 2012 12:58:05 +0200 (CEST)
Received: from [131.160.36.128] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 12:58:05 +0200
Message-ID: <4F8BFB3C.7040207@ericsson.com>
Date: Mon, 16 Apr 2012 13:58:04 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
References: <49DD8DED.3010908@ericsson.com>
In-Reply-To: <49DD8DED.3010908@ericsson.com>
X-Enigmail-Version: 1.4
X-Forwarded-Message-Id: <49DD8DED.3010908@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: [bfcpbis] More comments on RFC 4582
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2012 10:58:08 -0000
Hi, below you can find another old email with more comments on RFC 4582. Cheers, Gonzalo -------- Original Message -------- Subject: BFCP over UDP Date: Thu, 09 Apr 2009 08:55:57 +0300 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> To: XCON <xcon@ietf.org> CC: xcon-chairs@tools.ietf.org, Geir Arne Sandbakken <geir.sandbakken@tandberg.com> Hi, the following (expired) draft was presented in the XCON session in San Francisco: http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt The agreement was that given the problems TCP has with NATs (the P2PSIP WG is currently discussing the same issue) it would be a good idea to define a more NAT-friendly transport for BFCP. The proposal was to simply use UDP (this is what existing deployments do). Since BFCP messages can be rather long, we would need an applicability statement saying which types of messages cannot be used over UDP. In order to specify the new UDP-based transport we can either put together a new draft or revise the BFCP specification. I got the action point to list the things that could be fixed in a potential revised BFCP spec. These are the contents of my notes. Of course, if someone knows of more issues, please let us know: o When a user performs a third-party floor request the beneficiary of the floor is not informed when the floor is granted. This may not be a problem because endpoints using third-party floor requests probably have different means to get in synch but we may want to add some text about this. o We do not have errors for an unsupported version of the protocol or for wrong message length. We do not have a general error either. o When we get more experience on queue management from real deployments, it would be nice to explaining it further in the spec. o UserStatus UserStatus = (COMMON-HEADER) [BENEFICIARY-INFORMATION] 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1 *[EXTENSION-ATTRIBUTE] o A message may need to be longer than the maximum message length supported by the protocol o A rather small number of typos As you can see, at this point there are not so many things to fix... so, the simplest way forward may be to simply specify a new UDP-based transport for BFCP. In any case, I would like to get feedback from folks operating BFCP deployments. A different alternative (the one the P2PSIP WG is looking at) would be to either use a UDP encapsulation for TCP or to specify a new transport protocol... but these alternatives may be more complex than just using UDP. Comments? Thanks, Gonzalo
- [bfcpbis] More comments on RFC 4582 Gonzalo Camarillo
- Re: [bfcpbis] More comments on RFC 4582 Tom Kristensen
- Re: [bfcpbis] More comments on RFC 4582 Charles Eckel (eckelcu)
- Re: [bfcpbis] More comments on RFC 4582 Lorenzo Miniero
- Re: [bfcpbis] More comments on RFC 4582 Tom Kristensen
- Re: [bfcpbis] More comments on RFC 4582 Lorenzo Miniero
- Re: [bfcpbis] More comments on RFC 4582 Chelliah Sivachelvan (chelliah)
- [bfcpbis] rfc4583bis TLS SDP example - Re: More c… Tom Kristensen
- Re: [bfcpbis] rfc4583bis TLS SDP example - Re: Mo… Charles Eckel (eckelcu)
- Re: [bfcpbis] rfc4583bis TLS SDP example - Re: Mo… Tom Kristensen
- Re: [bfcpbis] rfc4583bis TLS SDP example - Re: Mo… Tom Kristensen