Re: [bfcpbis] Version Negotiation

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Thu, 14 March 2013 14:37 UTC

Return-Path: <eckelcu@cisco.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 3B7F011E8185 for <bfcpbis@ietfa.amsl.com>; Thu, 14 Mar 2013 07:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 ilZgiMTWzuBO for <bfcpbis@ietfa.amsl.com>; Thu, 14 Mar 2013 07:37:56 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 712F211E8192 for <bfcpbis@ietf.org>; Thu, 14 Mar 2013 07:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3390; q=dns/txt; s=iport; t=1363271876; x=1364481476; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=6HDKfHyFB27vruNXu8TvPFXXHF1FQWaqgu0BxSX30Wc=; b=FhZ2csGwhKZJ0XNVjiWoaWfZxxjVdY9IL6POAH/LTG50jKc/cAn7xvof rEHJEnLgmqIFMqCXUa0o9uydy/zIaLcdlwLQTCSotbCijEoiRBuMCjhkr P2NProt5ucYh9Nu9YbxA1pTmIVqrKOJpmVbQX32v+JvT8B7lOmbJ6UM98 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAD/gQVGtJXG+/2dsb2JhbABExHiBYhZ0gioBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCIgMDMEiBI5fJgsNgllhA6dagwqCKA
X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187453932"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2013 14:37:55 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2EEbthn004702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <bfcpbis@ietf.org>; Thu, 14 Mar 2013 14:37:55 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 09:37:55 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Alan Ford (alanford)" <alanford@cisco.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] Version Negotiation
Thread-Index: AQHOFONLpaHXxZhH30ueQXkyHk5lCZiZU6aAgAAHNfCAC/zwkA==
Date: Thu, 14 Mar 2013 14:37:55 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D458D@xmb-aln-x08.cisco.com>
References: <B8A9B6587D9897498E7F967D5F8E98791338A80D@xmb-rcd-x08.cisco.com> <B8A9B6587D9897498E7F967D5F8E98791338E4DF@xmb-rcd-x08.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.150.145]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Tom Kristensen \(tomkrist\)" <tomkrist@cisco.com>
Subject: Re: [bfcpbis] Version Negotiation
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: Thu, 14 Mar 2013 14:37:57 -0000

Any other opinions/concerns/proposals for this? Note that there is no BFCPBIS session at IETF 86, so it will not be covered in an official meeting. So this mailing list thread is the best place.
If not, we will ask our esteemed editor to take a stab at addressing this in the draft.

Cheers,
Charles

> -----Original Message-----
> From: Charles Eckel (eckelcu)
> Sent: Wednesday, March 06, 2013 6:34 PM
> To: Alan Ford (alanford); bfcpbis@ietf.org
> Subject: RE: [bfcpbis] Version Negotiation
> 
> [as an individual]
> 
> Hi Alan,
> 
> I like your idea. I think it will help and remove much of the guesswork when
> both sides support the SDP BFCP version attribute. I think in addition to
> what you specified, we also need to indicate what version of BFCP to
> assume if no BFCP version attribute is received. I think we would also need
> to specify that the version indicated in a Hello/HelloAck takes precedence
> over any default value that was assumed due to the absence of an SDP BFCP
> version attribute.
> 
> Cheers,
> Charles
> 
> > -----Original Message-----
> > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On
> > Behalf Of Alan Ford (alanford)
> > Sent: Wednesday, March 06, 2013 9:02 AM
> > To: bfcpbis@ietf.org
> > Subject: Re: [bfcpbis] Version Negotiation
> >
> > Folks,
> >
> > Does anybody have any thoughts/opinions about this?
> >
> > Thanks,
> > Alan
> >
> > On 27/02/2013 12:09, "Alan Ford (alanford)" <alanford@cisco.com> wrote:
> >
> > >Hi all,
> > >
> > >Some recent interop testing and discussions has raised concerns over
> how
> > >we determine the BFCP version to use, for both now and for future
> > >versions.
> > >
> > >At the moment, we don't say much about this in the drafts. We define an
> > >"Unsupported Version" error, but that's about it. The implication
> > >therefore is that a UA would try sending BFCP version=2, and if no
> > >response is received, it would try again with version=1 if it supported
> > >it. This is unreliable and slow.
> > >
> > >It would seem much better to declare supported versions in an SDP
> > >attribute. I propose something in 4583bis that specifies an attribute like
> > >this:
> > >
> > >  bfcp-version-attribute = "a=bfcpver:" bfcp-version *(SP bfcp-version)
> > >  bfcp-version           = token
> > >
> > >Which can then be responded to in the answer, much like RTP payload
> > types.
> > >(At the moment that's not restricted to numeric values only, so we don't
> > >restrict future things here.) Essentially by declaring support for a
> > >version in the SDP, a sender is saying they are willing to speak this
> > >version if it is received.
> > >
> > >I also think we also need to tighten the text in the drafts slightly. In
> > >S13.7 of 4582bis, we should say that a HelloAck MUST echo the version
> > >presented in a Hello message (otherwise Unsupported Version MUST be
> > sent).
> > >
> > >Thoughts?
> > >
> > >Regards,
> > >Alan
> > >
> > >_______________________________________________
> > >bfcpbis mailing list
> > >bfcpbis@ietf.org
> > >https://www.ietf.org/mailman/listinfo/bfcpbis
> >
> > _______________________________________________
> > bfcpbis mailing list
> > bfcpbis@ietf.org
> > https://www.ietf.org/mailman/listinfo/bfcpbis