Subject: Re: [bfcpbis] Version Negotiation

From: "Alan Ford (alanford)" <[email-masked]>
Date: Wed, 6 Mar 2013 17:02:20 +0000

Folks,

Does anybody have any thoughts/opinions about this?

Thanks,
Alan

On 27/02/2013 12:09, "Alan Ford (alanford)" <[email-masked]> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 6 Mar 2013 23:34:04 +0000

[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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alan Ford (alanford)
> Sent: Wednesday, March 06, 2013 9:02 AM
> To: [email-masked]
> Subject: Re: [bfcpbis] Version Negotiation
> 
> Folks,
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 14 Mar 2013 14:37:55 +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

> From: Charles Eckel (eckelcu)
> Sent: Wednesday, March 06, 2013 6:34 PM
> To: Alan Ford (alanford); [email-masked]
> 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
>

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 14 Mar 2013 19:07:39 +0100

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:
>>> On 27/02/2013 12:09, "Alan Ford (alanford)"<[email-masked]>  wrote:
>>>
>>>        
>>>> Hi all,
>>>>
>>>> Some recent interop testing and discussions has raised concerns over
>>>>          
>> how
>>      
>>>> Which can then be responded to in the answer, much like RTP payload
>>>>          
>>> types.
>>>        
>>>> presented in a Hello message (otherwise Unsupported Version MUST be
>>>>          
>>> sent).
>>>        
>>>> Thoughts?
>>>>
>>>> Regards,
>>>> Alan
>>>>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Mar 2013 15:47:19 -0400

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.)

--
Jonathan Lennox
[email-masked]

---

From: "Alan Ford (alanford)" <[email-masked]>
Date: Thu, 14 Mar 2013 20:09:25 +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 = 2,
reliable = 1 assumption.

Regards,
Alan

On 14/03/2013 19:47, "Jonathan Lennox" <[email-masked]> 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.)
>
>>> 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.