From alanford@cisco.com Wed Mar 6 09:02:22 2013 Return-Path: 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 ; 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 ; 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 ; 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 ; 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)" To: "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Version Negotiation Thread-Index: AQHOFONLpaHXxZhH30ueQXkyHk5lCZiZU6aA Date: Wed, 6 Mar 2013 17:02:20 +0000 Message-ID: In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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)" 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=3D2, and if no >response is received, it would try again with version=3D1 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 =3D "a=3Dbfcpver:" bfcp-version *(SP bfcp-version= ) > bfcp-version =3D 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 From eckelcu@cisco.com Wed Mar 6 15:34:28 2013 Return-Path: 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 8460B11E80FE for ; Wed, 6 Mar 2013 15:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 1c859OK3iUJq for ; Wed, 6 Mar 2013 15:34:27 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F0C9811E80A4 for ; Wed, 6 Mar 2013 15:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2722; q=dns/txt; s=iport; t=1362612867; x=1363822467; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=24tg8i8RwgB2zmjKVWl4VnFjzswSkDflGc2uBKs4Hao=; b=g4w3lpDSyd+gTjME/d4K7m4MMwYVneWAdlYhcSNLaSAXCJnz1D9/hnI0 nudZ1ZKydmlEvUIvckO5Ce443HadfwfYUQuXfWkDRfAhzS3kQr20P3RSN VmG9B75eoR7j+WSWhuzpMWEvtVQd7WaQL45wyVI3BkGDRF77tLkBFici3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACHSN1GtJXHB/2dsb2JhbABDxD+BXxZzgisBAQEEAQEBNzQXBAIBCBEEAQEBChQJBycLFAkIAgQBEgiICgEMu2gEjlsmEgaCWWEDpzuDCYIn X-IronPort-AV: E=Sophos;i="4.84,798,1355097600"; d="scan'208";a="184613496" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 06 Mar 2013 23:34:04 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r26NY4wm028485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Mar 2013 23:34:04 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 17:34:04 -0600 From: "Charles Eckel (eckelcu)" To: "Alan Ford (alanford)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Version Negotiation Thread-Index: AQHOFONLpaHXxZhH30ueQXkyHk5lCZiZU6aAgAAHNfA= Date: Wed, 6 Mar 2013 23:34:04 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047C81B8@xmb-aln-x08.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.63] Content-Type: text/plain; charset="us-ascii" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:34:28 -0000 [as an individual] Hi Alan, I like your idea. I think it will help and remove much of the guesswork whe= n 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 assum= e if no BFCP version attribute is received. I think we would also need to s= pecify 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 versi= on attribute. Cheers, Charles=20 > -----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 >=20 > Folks, >=20 > Does anybody have any thoughts/opinions about this? >=20 > Thanks, > Alan >=20 > On 27/02/2013 12:09, "Alan Ford (alanford)" wrote: >=20 > >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=3D2, and if no > >response is received, it would try again with version=3D1 if it supporte= d > >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 li= ke > >this: > > > > bfcp-version-attribute =3D "a=3Dbfcpver:" bfcp-version *(SP bfcp-versi= on) > > bfcp-version =3D 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 >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Thu Mar 14 07:37:57 2013 Return-Path: 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 ; 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 ; 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 ; 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 ; 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)" To: "Alan Ford (alanford)" , "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: 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\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 BFCPB= IS 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 i= n 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 >=20 > [as an individual] >=20 > Hi Alan, >=20 > I like your idea. I think it will help and remove much of the guesswork w= hen > 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 ne= ed > to specify that the version indicated in a Hello/HelloAck takes precedenc= e > over any default value that was assumed due to the absence of an SDP BFCP > version attribute. >=20 > Cheers, > Charles >=20 > > -----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)" 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 a= n > > >"Unsupported Version" error, but that's about it. The implication > > >therefore is that a UA would try sending BFCP version=3D2, and if no > > >response is received, it would try again with version=3D1 if it suppor= ted > > >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 =3D "a=3Dbfcpver:" bfcp-version *(SP bfcp-ver= sion) > > > bfcp-version =3D 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 From tomkrist@cisco.com Thu Mar 14 11:07:41 2013 Return-Path: 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 D8D0111E8155 for ; Thu, 14 Mar 2013 11:07:41 -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 uFDtz3kY8fRu for ; Thu, 14 Mar 2013 11:07:41 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED5C11E8110 for ; Thu, 14 Mar 2013 11:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3689; q=dns/txt; s=iport; t=1363284461; x=1364494061; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=B6+WM8/ddZWGmfwhE2d1mBfiasV1YnWbYQhrGU9p/xE=; b=K3zr4ssbAzBqZItnCMyd7uA6WAb+h2agrhthqzpTMa8QWj4uxozayPxM JIks69GNJVRtz2TayXaZoERSGwmecVl1Y/bkrTOnOOc6DTOk8khLkrh61 31o56MTBMNYV/4AzgQL/bLtaLsbY1aHi4NTlOZJOdkDiYTXjfYkV+A5bB s=; X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187557089" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 14 Mar 2013 18:07:40 +0000 Received: from [10.47.39.8] ([10.47.39.8]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2EI7dAu023035; Thu, 14 Mar 2013 18:07:39 GMT Message-ID: <514211EB.1020400@cisco.com> Date: Thu, 14 Mar 2013 19:07:39 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C08828047D458D@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047D458D@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" , "Alan Ford \(alanford\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:07:42 -0000 Please, shout if you disagree! I support Alan's suggestion on how to solve the issue, with the additional comment made by Charles. -- Tom On 03/14/2013 03:37 PM, Charles Eckel (eckelcu) wrote: > 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)" 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 >>> From jonathan@vidyo.com Thu Mar 14 12:47:32 2013 Return-Path: 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 2104711E8257 for ; Thu, 14 Mar 2013 12:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599] 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 STZDAIgv-tYo for ; Thu, 14 Mar 2013 12:47:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 7755B11E8251 for ; Thu, 14 Mar 2013 12:47:25 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id F2343416D33; Thu, 14 Mar 2013 09:53:27 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B5ACA416C8A; Thu, 14 Mar 2013 09:53:24 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Thu, 14 Mar 2013 15:46:50 -0400 From: Jonathan Lennox To: Tom Kristensen Date: Thu, 14 Mar 2013 15:47:19 -0400 Thread-Topic: [bfcpbis] Version Negotiation Thread-Index: Ac4g7L1UrVS4zx0BTYC2iH4FvctHhA== Message-ID: <2D921ECB-6FCD-4D7F-9B55-9D28B4A11ED8@vidyo.com> References: <92B7E61ADAC1BB4F941F943788C08828047D458D@xmb-aln-x08.cisco.com> <514211EB.1020400@cisco.com> In-Reply-To: <514211EB.1020400@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , "Alan Ford \(alanford\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:47:32 -0000 I don't understand how the mis-match occurs -- the bfcpbis draft says that = the version number is always 1 for reliable transports, and always 2 for un= reliable transports. Is the problem occurring with interop with pre-standa= rdized BFCP-over-UDP? That said, I don't have any problem with signaling the version field in SDP= , especially for future compatibility. (Though the version number field is= also the STUN demux point, so changing the version -- at least for UDP -- = won't be so easy.) On Mar 14, 2013, at 2:07 PM, Tom Kristensen wrote: > Please, shout if you disagree! >=20 > I support Alan's suggestion on how to solve the issue, with the=20 > additional comment made by Charles. >=20 > -- Tom >=20 > On 03/14/2013 03:37 PM, Charles Eckel (eckelcu) wrote: >> Any other opinions/concerns/proposals for this? Note that there is no BF= CPBIS 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 thi= s in the draft. >>=20 >> Cheers, >> Charles >>=20 >>=20 >>> -----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 >>>=20 >>> [as an individual] >>>=20 >>> Hi Alan, >>>=20 >>> 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 precede= nce >>> over any default value that was assumed due to the absence of an SDP BF= CP >>> version attribute. >>>=20 >>> Cheers, >>> Charles >>>=20 >>>=20 >>>> -----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 >>>>=20 >>>> Folks, >>>>=20 >>>> Does anybody have any thoughts/opinions about this? >>>>=20 >>>> Thanks, >>>> Alan >>>>=20 >>>> On 27/02/2013 12:09, "Alan Ford (alanford)" wrote= : >>>>=20 >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> Some recent interop testing and discussions has raised concerns over >>>>>=20 >>> how >>>=20 >>>>> we determine the BFCP version to use, for both now and for future >>>>> versions. >>>>>=20 >>>>> 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=3D2, and if no >>>>> response is received, it would try again with version=3D1 if it suppo= rted >>>>> it. This is unreliable and slow. >>>>>=20 >>>>> It would seem much better to declare supported versions in an SDP >>>>> attribute. I propose something in 4583bis that specifies an attribute= like >>>>> this: >>>>>=20 >>>>> bfcp-version-attribute =3D "a=3Dbfcpver:" bfcp-version *(SP bfcp-ver= sion) >>>>> bfcp-version =3D token >>>>>=20 >>>>> Which can then be responded to in the answer, much like RTP payload >>>>>=20 >>>> types. >>>>=20 >>>>> (At the moment that's not restricted to numeric values only, so we do= n'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. >>>>>=20 >>>>> 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 >>>>>=20 >>>> sent). >>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> Regards, >>>>> Alan >>>>>=20 >>>>> _______________________________________________ >>>>> bfcpbis mailing list >>>>> bfcpbis@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>=20 >>>> _______________________________________________ >>>> bfcpbis mailing list >>>> bfcpbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>=20 >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis >=20 -- Jonathan Lennox jonathan@vidyo.com From alanford@cisco.com Thu Mar 14 13:09:48 2013 Return-Path: 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 B0BB211E8103 for ; Thu, 14 Mar 2013 13:09:48 -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 8g5B2XQq-Th0 for ; Thu, 14 Mar 2013 13:09:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CD06B21F8D26 for ; Thu, 14 Mar 2013 13:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5482; q=dns/txt; s=iport; t=1363291788; x=1364501388; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3m1XBeHI6KyMMjMinaNOfJDXb16kd/r4ffNjif8Fymw=; b=bE5y64phv0vsvxWs4VKrU4QcWdEh2YOLc+3xUHhe3Kl2SfoQ50YaM8D/ 6YeJRlFixkgkBZEhGktQYLf939AB3rDgC6+j7XMwcGoncSVnz8QK060Wu RyDM6/YAn3nQMwp0zKlpZynOq98NfVs8w8a555DCVTfLi1PuBSUWoD5h/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAItQlGtJV2c/2dsb2JhbABDxQKBZRZ0gisBAQEEAQEBNzQLDAYBCBEEAQEBChQJLgsUCQgCBAENBQiIDAzBcASOZSYLBwaCWWEDp1qDCoIo X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187386950" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2013 20:09:47 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EK9lx0013224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 20:09:47 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 15:09:25 -0500 From: "Alan Ford (alanford)" To: Jonathan Lennox , "Tom Kristensen (tomkrist)" Thread-Topic: [bfcpbis] Version Negotiation Thread-Index: AQHOFONLpaHXxZhH30ueQXkyHk5lCZiZU6aAgAAHNfCAC/zwkIAAj+CAgAAb2YCAAAZeAA== Date: Thu, 14 Mar 2013 20:09:25 +0000 Message-ID: In-Reply-To: <2D921ECB-6FCD-4D7F-9B55-9D28B4A11ED8@vidyo.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.160.103] Content-Type: text/plain; charset="us-ascii" Content-ID: <5522B8CF3C142C4ABDAB6302A442946B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:09:48 -0000 Hi Jonathan, Regrettably yes, the issue arose when dealing with the pre-standarization version. And, as soon as this issue was identified, it seemed that the spec was missing this important step of negotiation for future compatibility, as you say. It seems a logical step to remove ambiguity and also increase flexibility (potentially even providing the ability to signal experimental values). As Charles says, we also need to specify how to handle the lack of this attribute. I think that is just a case of reiterating the unreliable =3D 2, reliable =3D 1 assumption. Regards, Alan On 14/03/2013 19:47, "Jonathan Lennox" wrote: >I don't understand how the mis-match occurs -- the bfcpbis draft says >that the version number is always 1 for reliable transports, and always 2 >for unreliable transports. Is the problem occurring with interop with >pre-standardized BFCP-over-UDP? > >That said, I don't have any problem with signaling the version field in >SDP, especially for future compatibility. (Though the version number >field is also the STUN demux point, so changing the version -- at least >for UDP -- won't be so easy.) > >On Mar 14, 2013, at 2:07 PM, Tom Kristensen wrote: > >> Please, shout if you disagree! >>=20 >> I support Alan's suggestion on how to solve the issue, with the >> additional comment made by Charles. >>=20 >> -- Tom >>=20 >> On 03/14/2013 03:37 PM, Charles Eckel (eckelcu) wrote: >>> 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. >>>=20 >>> Cheers, >>> Charles >>>=20 >>>=20 >>>> -----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 >>>>=20 >>>> [as an individual] >>>>=20 >>>> Hi Alan, >>>>=20 >>>> 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. >>>>=20 >>>> Cheers, >>>> Charles >>>>=20 >>>>=20 >>>>> -----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 >>>>>=20 >>>>> Folks, >>>>>=20 >>>>> Does anybody have any thoughts/opinions about this? >>>>>=20 >>>>> Thanks, >>>>> Alan >>>>>=20 >>>>> On 27/02/2013 12:09, "Alan Ford (alanford)" >>>>>wrote: >>>>>=20 >>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> Some recent interop testing and discussions has raised concerns over >>>>>>=20 >>>> how >>>>=20 >>>>>> we determine the BFCP version to use, for both now and for future >>>>>> versions. >>>>>>=20 >>>>>> 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=3D2, and if no >>>>>> response is received, it would try again with version=3D1 if it >>>>>>supported >>>>>> it. This is unreliable and slow. >>>>>>=20 >>>>>> It would seem much better to declare supported versions in an SDP >>>>>> attribute. I propose something in 4583bis that specifies an >>>>>>attribute like >>>>>> this: >>>>>>=20 >>>>>> bfcp-version-attribute =3D "a=3Dbfcpver:" bfcp-version *(SP >>>>>>bfcp-version) >>>>>> bfcp-version =3D token >>>>>>=20 >>>>>> Which can then be responded to in the answer, much like RTP payload >>>>>>=20 >>>>> types. >>>>>=20 >>>>>> (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. >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>> sent). >>>>>=20 >>>>>> Thoughts? >>>>>>=20 >>>>>> Regards, >>>>>> Alan >>>>>>=20 >>>>>> _______________________________________________ >>>>>> bfcpbis mailing list >>>>>> bfcpbis@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>=20 >>>>> _______________________________________________ >>>>> bfcpbis mailing list >>>>> bfcpbis@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>=20 >>=20 >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >>=20 > >-- >Jonathan Lennox >jonathan@vidyo.com > >