Subject: [clue] Label attribute for CLUE

From: Christian Groves <[email-masked]>
Date: Wed, 22 May 2013 12:53:10 +1000

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?

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.

For CLUE I think we need to look at defining a specific SDP attribute 
for this m-line -> encoding mapping.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 10:51:53 -0400

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

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.

> 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

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

---

From: Robert Hansen <[email-masked]>
Date: Wed, 22 May 2013 16:25:49 +0100

> the clue signaling. (Those labels will be assigned by the application.)

I agree that I was using the labels for two purposes - allowing the CLUE 
messages to refer to specific m-lines, and to indicate which m-lines 
were controllable in clue, and that while the former is suitable for 
label the latter is not.

I don't think we'd require much new in SDP, though; rather than a new 
media attribute I think we just need to define a new group attribute, as 
I think this is something that falls well within RFC 5888. It allows us 
to define which streams are clue controlled, and the offer/answer rules 
match our needs nicely.

For example, an SDP with 3 video m-lines, where the second and third are 
CLUE controlled might look like:

     ...
     a=group:CLUE 2 3
     m=video 30000 RTP/AVP 96
     ...
     a=mid:1
     a=sendrecv
     m=video 30002 RTP/AVP 96
     ...
     a=mid:2
     a=sendonly
     m=video 30004 RTP/AVP 96
     ...
     a=mid:3
     a=sendonly

Rob

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 11:52:38 -0400

> were controllable in clue, and that while the former is suitable for

I think we now have consensus on this.

> to define which streams are clue controlled, and the offer/answer rules

I agree that either could serve the purpose, and they are about equal in 
the amount of work required to define the SDP extension. (An attribute 
might be a little easier, but the difference is negligible.)

The group might make the SDP a *little* smaller than attributes, 
assuming the mid values were already there for bundling. But again the 
difference is negligible. So I think this becomes a matter of taste.

What you have below *looks* fairly nice.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Thu, 23 May 2013 00:39:59 +0300

Hi,
I agree that using group works fine based on the current decision to start
with no RTP multiplexing.
 I think that if we will support more than one RTP stream per m-line (Plan
B) it will work only if all multiplexed RTP streams in the m-line are CLUE
controlled.
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Robert Hansen
> Sent: 22 May, 2013 6:26 PM
> To: [email-masked]
> Subject: Re: [clue] Label attribute for CLUE
> 
> 
> >> 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.
> > "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.)
> 
> messages to refer to specific m-lines, and to indicate which m-lines were
> controllable in clue, and that while the former is suitable for label the
latter is
> not.
media
> attribute I think we just need to define a new group attribute, as I think
this
> is something that falls well within RFC 5888. It allows us to define which
> streams are clue controlled, and the offer/answer rules match our needs
> nicely.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 18:13:10 -0400

> B) it will work only if all multiplexed RTP streams in the m-line are CLUE

I agree with your last point. But I think it would be very unwise to 
have an m-line that was "partially controlled" by clue. So I don't see 
that as an issue.

	Thanks,
	Paul