Subject: Re: [bfcpbis] 4583bis: SDP bfcpver attribute

From: Alan Ford <[email-masked]>
Date: Fri, 4 May 2018 08:27:03 +0100

Hi all,

Apologies, for some reason I totally missed this mail. I think the intention was for bfcpver to be included in both; prior to Christer’s recent clarification text this was not so obvious with the way the text flowed. Now it is, I think this needs correction.

Changing text to support this would be simple, just changing in the offer (13.1) section:

   When the offerer creates an initial offer, the offerer MUST associate
   an SDP 'floorctrl' attribute (Section 5 <https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-22#section-5>) with the 'm' line.

To:

   When the offerer creates an initial offer, the offerer MUST associate
   an SDP 'floorctrl' attribute (Section 5 <https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-22#section-5>) and an SDP 'bfcpver' attribute
   (Section 8) with the 'm' line.

And removing the line about bfcpver from the bullet point list.

And for the answer section (13.2), move the bfcpver bullet point to the first list.

Ultimately the bfcpver attribute is informational; we do not specify any algorithms. Endpoints will decide what version to use based on what is shared and thus what is known about the peer’s capabilities. But it would remove any ambiguity to have this explicitly stated by both ends.

Regards,
Alan

> On 27 Mar 2018, at 06:07, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> There is a way to determine a default value of the attribute is not present, so that is not a problem.
> 
> The question is whether the floor control server should care about a value sent (either explicit or implicit default) by the floor control client or not, or whether the only one sending a valid value is the floor control server.
> 
> I am fine either way, but if both the client and server send it we will need additional procedures. So, it would probably be easiest to keep the text saying that only the server sends it.
> 
> Regards,
> 
> Christer 
> 
> Sent from my iPhone
> 
> On 27 Mar 2018, at 6.43, Charles Eckel (eckelcu) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> (as an individual)
>>  
>> Hi Christer,
>>  
>> The offer/answer language used for confid, userid, and floorid, was used for bfcpver as well. I do not see any harm in a floor control client including a bfcpver attribute in an SDP offer or answer, but the draft is currently silent on this.
>> If I had it to do over, I would probably opt for being explicit that the bfcpver attribute is required in all offers and answers, but I do not think we can make that change now. The example is okay as is. It would also be fine to remove the bfcpver attribute from the answer in which he answerer is a client.
>> Alternatively, I suppose we could as that the bfcpver is optional (i.e. MAY include) when acting as a floor control client. Thoughts?
>>  
>> Charles
>>  
>> From: bfcpbis <[email-masked] <mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked] <mailto:[email-masked]>>
>> Date: Monday, March 26, 2018 at 12:14 AM
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> Subject: [bfcpbis] 4583bis: SDP bfcpver attribute
>>  
>> Hi, <>
>>  
>> I would like to clarify the usage of the SDP ‘bfcpver' attribute.
>>  
>> According to the procedures, the attribute is only inserted by the floor control server. I double checked this in older versions of 4583bis. However, in the examples of older versions the attribute is included in an SDP answer, even if the answerer indicates that it will be floor control client.
>>  
>> So, what is the correct way?
>>  
>> Regards,
>>  
>> Christer
>>  
>>  
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 May 2018 08:06:17 +0000

Hi,

> Apologies, for some reason I totally missed this mail. I think the intention was for bfcpver to be
> included in both; prior to Christer's recent clarification text this was not so obvious with the way
> the text flowed. Now it is, I think this needs correction.
>

>   an SDP 'floorctrl' attribute (Section 5<https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-22#section-5>) with the 'm' line.
>
> To:
>

>   an SDP 'floorctrl' attribute (Section 5<https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-22#section-5>) and an SDP 'bfcpver' attribute

> Ultimately the bfcpver attribute is informational; we do not specify any algorithms. Endpoints will
> decide what version to use based on what is shared and thus what is known about the peer's capabilities.
> But it would remove any ambiguity to have this explicitly stated by both ends.

Regarding the algorithms, if the offerer indicates versions X, Y, Z, I think the answerer has to indicate a subset of those - it the answerer does not support any of the versions it should not accept the BFCP establishment. Sure, we could allow the answerer to also include versions not included by the offerer, for endpoints must use versions that both endpoints have indicated support of.

Regards,

Christer

On 27 Mar 2018, at 06:07, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer
Sent from my iPhone

On 27 Mar 2018, at 6.43, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
(as an individual)

Hi Christer,

Charles

From: bfcpbis <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 26, 2018 at 12:14 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bfcpbis] 4583bis: SDP bfcpver attribute

Hi,

I would like to clarify the usage of the SDP 'bfcpver' attribute.

Regards,

Christer

_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Alan Ford <[email-masked]>
Date: Fri, 4 May 2018 09:33:16 +0100

Hi,

> On 4 May 2018, at 09:06, Christer Holmberg <[email-masked]> wrote:
> 
> > decide what version to use based on what is shared and thus what is known about the peer’s capabilities. 
> Regarding the algorithms, if the offerer indicates versions X, Y, Z, I think the answerer has to indicate a subset of those – it the answerer does not support any of the versions it should not accept the BFCP establishment. Sure, we could allow the answerer to also include versions not included by the offerer, for endpoints must use versions that both endpoints have indicated support of.

We could specify that, but as you say, there is no harm in an endpoint presenting more - the one which is used must be mutually supported. But I have no problem adding that to the 13.2 list, in order words:

 o  MUST associate a 'bfcpver' attribute with the 'm’ line, containing a subset of the versions presented in the offer.

Regards,
Alan

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 May 2018 11:01:35 +0000

Hi,

I can go other way, so I’d like to hear what others think.

Charles?

Regards,

Christer

From: Alan Ford <[email-masked]<mailto:[email-masked]>>
Date: Friday 4 May 2018 at 11:33
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Charles Eckel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bfcpbis] 4583bis: SDP bfcpver attribute

Hi,

Regards,
Alan