Subject: Re: [clue] purpose attribute - Review of framework-03

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Mar 2012 21:48:34 +0100

Hi,

We need to keep in mind, that *IF* we are going to associate multiple streams with a single SDP m- line, and each media streams may have a different attribute value, many existing values won't work, as they are per m- line.

So, in this case, what if there are multiple streams associated with the m- line, and they all have different languages?

The same would apply also to other attributes, e.g. the direction attributes.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Espen Berger (espeberg)
Sent: 29. helmikuuta 2012 20:43
To: Roni Even; Paul Kyzivat; [email-masked]
Subject: Re: [clue] purpose attribute - Review of framework-03

I agree that we should reuse the definition from RFC4796. 

Maybe CLUE should change the name of the purpose attribute to content to follow RFC4796. Avoiding confusion is important. 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: 29. februar 2012 17:39
To: 'Paul Kyzivat'; [email-masked]
Subject: Re: [clue] purpose attribute - Review of framework-03

Hi,
RFC 4795 defines an attribute that can be used to specify the semantics of the stream. The usage is left for application specific document that will provide the interoperability specification.
It will be good to use the defined values and the IANA registry since we are also talking in CLUE about multiple streams with different content.
The framework should explain how to use the values from RFC 4795 Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Paul Kyzivat
> Sent: Wednesday, February 29, 2012 5:48 PM
> To: [email-masked]
> Subject: Re: [clue] purpose attribute - Review of framework-03
> 
> On 2/29/12 9:53 AM, Duckworth, Mark wrote:
> > Does anybody have a comment or suggestion about this idea?
> > For the framework document, I'm proposing that instead of defining
> our own values for the media capture purpose attribute, instead we 
> refer to RFC4796 and use those values that are already defined.
> 
> It appears 4796 is no less vague about the semantics of the values as 
> we have been so far. And 4796 has an IANA registry and provision to 
> add new values via another RFC, so we can add new ones if we need
them.
> 
> But its not enough if we want individual implementations and/or 
> deployments to be able to specify their own values.
> 
> Note that 4795 allows multiple instances of mediacnt-tag to be 
> attached to a single stream. (E.g. "a=content: main, speaker") This 
> could help when more than one apply to the stream. So clue might need 
> to also allow this.
> 
> 	Thanks,
> 	Paul
> 
> > Mark
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Duckworth, Mark
> >> Sent: Monday, February 13, 2012 10:47 AM
> >> To: Roni Even; [email-masked]
> >> Subject: Re: [clue] purpose attribute - Review of framework-03
> >>
> >> Hi Roni,
> >>
> >> Thanks for all the comments.  We'll start addressing different
> topics
> >> in different email threads.
> >>
> >> I was thinking the media capture purpose attribute really should
> mean
> >> the same thing as the SDP content attribute in RFC4796.  Can CLUE 
> >> just refer to
> >> RFC4796 for the definition of the purpose attribute values?  
> >> RFC4796 already has an extension mechanism, so we can add new 
> >> values when
> needed.
> >>
> >> Mark
> >>
> >> ===================================
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Roni Even
> >> Sent: Wednesday, February 08, 2012 8:49 AM
> >> To: [email-masked]
> >> Subject: [clue] Review of draft-ietf-clue-framework-03
> >>
> >> 6.  In section 6.1.1 I suggest adding one more purpose "SL" for 
> >> sign language indicating that this is the sign language 
> >> representation of the audio stream, see RFC4796.
> >>
> >> Thanks
> >> Roni Even
> >>
> >>
> >>
> >> _______________________________________________
> >> clue mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/clue
> > _______________________________________________
> > clue mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/clue
> >
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

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

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Thu, 1 Mar 2012 22:15:02 +0100

Agree, we need the flexibility to specify purpose (or content)
attributes per stream.

On useful use case would be to announce three captures with three
different content values, e.g. "speaker", "sl", "alt" (from rfc4796),
all multiplexed on the same RTP session. 

-Espen 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 1. mars 2012 21:49
To: Espen Berger (espeberg); Roni Even; Paul Kyzivat; [email-masked]
Subject: RE: [clue] purpose attribute - Review of framework-03

Hi,

We need to keep in mind, that *IF* we are going to associate multiple
streams with a single SDP m- line, and each media streams may have a
different attribute value, many existing values won't work, as they are
per m- line.

So, in this case, what if there are multiple streams associated with the
m- line, and they all have different languages?

The same would apply also to other attributes, e.g. the direction
attributes.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Espen Berger (espeberg)
Sent: 29. helmikuuta 2012 20:43
To: Roni Even; Paul Kyzivat; [email-masked]
Subject: Re: [clue] purpose attribute - Review of framework-03

Maybe CLUE should change the name of the purpose attribute to content to
follow RFC4796. Avoiding confusion is important. 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: 29. februar 2012 17:39
To: 'Paul Kyzivat'; [email-masked]
Subject: Re: [clue] purpose attribute - Review of framework-03

Hi,
RFC 4795 defines an attribute that can be used to specify the semantics
of the stream. The usage is left for application specific document that
will provide the interoperability specification.
It will be good to use the defined values and the IANA registry since we
are also talking in CLUE about multiple streams with different content.
The framework should explain how to use the values from RFC 4795 Roni

them.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Mar 2012 22:17:36 +0100

Hi,

> all multiplexed on the same RTP session.

In that case we cannot use existing attributes, but we would have to specify something new, which allows to give values e.g. per SSRC.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: 1. mars 2012 21:49
To: Espen Berger (espeberg); Roni Even; Paul Kyzivat; [email-masked]
Subject: RE: [clue] purpose attribute - Review of framework-03

Hi,

Regards,

Christer

-----Original Message-----

-Espen

-----Original Message-----

Hi,

them.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 16:43:22 -0500

Christer,

I think the proposal is to adopt the names used in 4296. Then they could 
be used in the content attribute when that makes sense, but also be used 
in the clue-specific messages even if they aren't SDP.

Your point about multiple streams on one m-line applies to many SDP 
elements.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 17:14:16 -0500

> all multiplexed on the same RTP session.

Agree with the above. But I'm a bit confused about the distinction 
between "speaker" and "main". In a typical 3-screen telepresence system, 
would the captures for those screens be "main" or "speaker"? Or maybe 
both, since there are likely to be speakers in each capture, and no 
"designated" main speaker.

Or maybe the use of "speaker" should be reserved for cases where there 
is a designated speaker or leader, and then used to mark the capture 
containing that person. But then it might also still be "main" as well.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 1 Mar 2012 14:33:16 -0800

Yes, I agree with Paul, my proposal meant to use the mediacnt values from RFC4796 as the possible values for the "purpose" media capture attribute in CLUE.  This attribute wouldn't necessarily be communicated via SDP.

Somebody else suggested changing the name of the "purpose" attribute to "content", to be a closer match with RFC4796, which sounds good to me.

Mark

> Paul Kyzivat
> Sent: Thursday, March 01, 2012 4:43 PM
> To: Christer Holmberg
> Cc: [email-masked]
> I think the proposal is to adopt the names used in 4296. Then they could be
> used in the content attribute when that makes sense, but also be used in the
> clue-specific messages even if they aren't SDP.
> 
> different attribute value, many existing values won't work, as they are per
> m- line.
> >
> > So, in this case, what if there are multiple streams associated with the m-
> line, and they all have different languages?
> >
> > Of Espen Berger (espeberg)
> > Maybe CLUE should change the name of the purpose attribute to content
> to follow RFC4796. Avoiding confusion is important.
> >
> > -Espen
> >
> >
> > Of Roni Even
> > RFC 4795 defines an attribute that can be used to specify the semantics of
> the stream. The usage is left for application specific document that will
> provide the interoperability specification.
> > It will be good to use the defined values and the IANA registry since we are
> also talking in CLUE about multiple streams with different content.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 19:14:14 -0500

> Somebody else suggested changing the name of the "purpose" attribute to "content", to be a closer match with RFC4796, which sounds good to me.

I also suggest allowing multiple values of this per capture. As with 
a=content, this would mean that the content of the stream has all of these.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Mar 2012 07:16:52 +0100

Hi, 

> I think the proposal is to adopt the names used in 4296. Then they could be used in the content 
> attribute when that makes sense, but also be used in the clue-specific messages even if they aren't SDP.
>
> Your point about multiple streams on one m-line applies to many SDP elements.

Yes.

Regards,

Christer