[bfcpbis] Version Negotiation
"Alan Ford (alanford)" <alanford@cisco.com> Wed, 27 February 2013 12:09 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 C97E321F854D for <bfcpbis@ietfa.amsl.com>; Wed, 27 Feb 2013 04:09:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgbaU0KzXtWt for <bfcpbis@ietfa.amsl.com>; Wed, 27 Feb 2013 04:09:31 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1894C21F8484 for <bfcpbis@ietf.org>; Wed, 27 Feb 2013 04:09:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1361966971; x=1363176571; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=LcSu63wRBGbfsMHVGL9MO9fhFw6MKsKDCGxwA35lzQQ=; b=dh2Gw09/mzlt+QWjgfH8SHa0nMzoRIFcocQaQ3+LXlvPajR0Cp1Wy66p P9oc/0GxbGob02nyEheAH0dm08eNY03VVGUCsux53Wcbb7rwn2IZ5n6NE q2giVCsHpV1L7RgMf2lzDn3RiO9Yf9IuhnOhV2uw+qy2QLDpeM/KcWJm/ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAK/2LVGtJXHA/2dsb2JhbABEwhZ5FnOCIQEEOlEBKhRCJwQbiAudMKEDjmODF2EDpyuDCIIn
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; d="scan'208";a="181765779"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 27 Feb 2013 12:09:30 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1RC9UYL011670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <bfcpbis@ietf.org>; Wed, 27 Feb 2013 12:09:30 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.192]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 06:09:30 -0600
From: "Alan Ford (alanford)" <alanford@cisco.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: Version Negotiation
Thread-Index: AQHOFONLpaHXxZhH30ueQXkyHk5lCQ==
Date: Wed, 27 Feb 2013 12:09:29 +0000
Message-ID: <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.147.93.94]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8340A795A6C79E4FB0EFEEDEC26F3494@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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, 27 Feb 2013 12:09:31 -0000
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] Version Negotiation Alan Ford (alanford)
- Re: [bfcpbis] Version Negotiation Alan Ford (alanford)
- Re: [bfcpbis] Version Negotiation Charles Eckel (eckelcu)
- Re: [bfcpbis] Version Negotiation Charles Eckel (eckelcu)
- Re: [bfcpbis] Version Negotiation Tom Kristensen
- Re: [bfcpbis] Version Negotiation Jonathan Lennox
- Re: [bfcpbis] Version Negotiation Alan Ford (alanford)