Subject: Re: [clue] Label attribute for CLUE

From: Christian Groves <[email-masked]>
Date: Thu, 06 Jun 2013 21:17:43 +1000

Hello Paul,

I'm not saying the use of label is not possible, I just don't think it's 
ideal. Please see my replies below.

Regards, Christian

On 23/05/2013 12:51 AM, Paul Kyzivat wrote:
> On 5/21/13 10:53 PM, Christian Groves wrote:
>> Hello
>>
>> We discussed in yesterday's virtual interim meeting about the use of the
>> a=label: in the signalling flows.
>>
>> My concern is with regards to the scope of the label attribute. Section
>> 4/RFC4574 says "The new attribute can be attached to 'm' lines in
>> multiple SDP documents allowing the application to logically group the
>> media streams across SDP sessions when necessary."
>>
>> Considering an MCU case my understanding is that any identities used in
>> CLUE only have scope to a particular advertisement. i.e. the MCU can use
>> the same Scene and capture ids in Advertisements to different endpoints.
>>
>> If label has the scope over multiple SDP sessions does this mean that
>> the CLUE strings used with label would have to be unique across all SDP
>> sessions in a MCU or gateway?
>
> I think you are reaching to far!
>
> I don't know why that statement is in the RFC. It appears to be an 
> example of how it might be used. But I see nothing normative about 
> that statement regarding the scope of the label value.
[CNG] I don't know its there either but its there so it must have a purpose.
>
> My interpretation is that an application that participates in multiple 
> SDP sessions could use the same label values in the SDP it generates 
> for those sessions. The uniqueness of the values across multiple SDP 
> documents, whether describing one or several sessions, is determined 
> by the application.
[CNG] The "application"... what if there are multiple applications? ie. 
you happily implemented BFCP which allocates it own labels without care. 
Then you add CLUE which uses the same label space... your BFCP stack 
needs to be updated to account for CLUE labels etc...

>
>> Also RFC4796 section 3 on the Content Attribute indicates that a new
>> attribute was required because of a problem of backward compatibility.
>> Would this apply to a clue attribute also? For example if the endpoint
>> uses BFCP which uses label it would have to make sure labels for CLUE
>> didn't overlap. Also existing BFCP processing would just see a label
>> string. It wouldn't know that a=label:CLUE1 is not to be considered.
>
> As I read 4796, the backward compatibility issue would have arisen if 
> some *dedicated* label values were identified for the purpose.
>
> The same would be true if clue tried to specify dedicated label 
> values. That is why I was objecting to rob's proposal that the label 
> prefix of "clue." be used to signal that the m-line is "clue 
> controlled". Jonathan agreed with me on that. I think we agreed that 
> if we need to signal that m-lines are clue controlled we will need 
> something new in SDP. But that doesn't affect using labels as the 
> means for referencing m-lines from the clue signaling. (Those labels 
> will be assigned by the application.)
>
>     Thanks,
>     Paul
>
>> For CLUE I think we need to look at defining a specific SDP attribute
>> for this m-line -> encoding mapping.
>>
>> Regards, Christian
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>