IETF Logo Mail Archive

Re: [bfcpbis] Version Negotiation

"Alan Ford (alanford)" <alanford@cisco.com> Wed, 06 March 2013 17:02 UTC

Return-Path: <alanford@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 4FB8721F8C98 for <bfcpbis@ietfa.amsl.com>; Wed, 6 Mar 2013 09:02:22 -0800 (PST)
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 Mx-cQhqLGG1x for <bfcpbis@ietfa.amsl.com>; Wed, 6 Mar 2013 09:02:21 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BF6EE21F8C96 for <bfcpbis@ietf.org>; Wed, 6 Mar 2013 09:02:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1662; q=dns/txt; s=iport; t=1362589342; x=1363798942; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=rD4A7HxCNfI+u+C39HQE2megIAwLw8UxQWsgK/ZEQbs=; b=bc8bH8BY+3KtE8qH5tNbMfZf6ts0hxdZgTdi9KGjwDdZ6nGaubslQzmL 5H0O/22ityaldAV9LCigitqfvbb7ows5ibmqADzaBkeiS/jWR095oTYHF fYo+PwiuBUQjcMGiZkcVUUI8A2XZYWr8REGaCdAWB1RbalQ7cnLq4jXKZ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANB1N1GtJV2a/2dsb2JhbABExEaBWhZzgiwBBAEBATc0HQEIIhQ3CyUCBBMIiAsMm06hQwSOWQI4gl9hA6c7gwiCJw
X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208";a="184461826"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 06 Mar 2013 17:02:21 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r26H2LYr013719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <bfcpbis@ietf.org>; Wed, 6 Mar 2013 17:02:21 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.192]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 11:02:21 -0600
From: "Alan Ford (alanford)" <alanford@cisco.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] Version Negotiation
Thread-Index: AQHOFONLpaHXxZhH30ueQXkyHk5lCZiZU6aA
Date: Wed, 06 Mar 2013 17:02:20 +0000
Message-ID: <B8A9B6587D9897498E7F967D5F8E98791338E4DF@xmb-rcd-x08.cisco.com>
In-Reply-To: <B8A9B6587D9897498E7F967D5F8E98791338A80D@xmb-rcd-x08.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [10.61.65.243]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C31E4B7CBDFAF646ACEAD69E90431F8B@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 06 Mar 2013 17:02:22 -0000

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

v2.23.0 | Report a Bug | By Email