Subject: [clue] capture attributes - content attribute

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Tue, 22 May 2012 11:12:34 -0700

Folks, 

Earlier we changed  the capture attribute "purpose" with values
presentation and main to content attribute taken from RFC 4976 with
content types slides, main, speaker, 

Initially, when this came up,  I thought it was a simple change and it
had the appeal of using an existing RFC, so I wasn't opposed to it.
However, in working on a proof of concept implementation, this seemed to
have issues and  I feel we should stay with purpose and main and
presentation, or at the most, change it to content with main and slides
as did the IMTC SIP Parity WG for Role Based Video Streams.

My primary reason for wanting to define only main and presentation (or
content attributes main and slides from the full list in RFC 4796) is
similar to the reasoning from the SIP Parity WG - that in a conference
It can easily create  confusion and lack of non-interoperability - for
example one system may use main and another speaker when referring to
the same situation.    This same view was actually expressed in the Role
Based Video Stream work in IMTC SIP Parity WG which decided  to support
only main and slides.  

Here is what is in the RBVS document on this topic (of course they
aren't using the attributes for audio, just video).

Unlike H.239 where there are only two channel roles, "live" and
"presentation", in SIP, there are more roles, and it is possible that
endpoints and MCUs will have to deal with the situation where all of the
participants in a call do not designate the same roles for their
channels.  For example, one endpoint in a multipoint conference may use
the "speaker" and "slides" roles for its video channels, while another
may use "main" and "alt" for its video channels.   Since there are no
mechanisms to enable MCUs and endpoints to interoperate in this type of
situation, all SIP-based endpoints conforming to the RBVS "Best
Practices" Profile MUST use the attributes as specified in this section.
[ i.e., main and slides] The handling of other 'content' attribute
values is considered out of scope.

Although I'm okay with using just slides and main from the content
attribute, I feel that purpose: presentation, main map better to audio
than do slides and main.

I noticed today during the CLUE WG meeting that people reverted to
speaking about purpose main and presentation instead of the new content
attribute categories.. which is just an anecdote suggesting that we
stick with what we first had.

Of course, I'm assuming that we add any values to purpose (or content)
as they arise.

Thoughts?

---

From: John Leslie <[email-masked]>
Date: Tue, 22 May 2012 14:42:20 -0400

> as did the IMTC SIP Parity WG for Role Based Video Streams.

   "Main" leaves me cold, to tell truth; "Presentation" may be marginally
better than "slides" -- but I can't see this as worth revisiting.

   Whatever we do needs to be extensible, and "speaker" will likely
deserve distinctions, not absorbtion into another content type.

   (For a few examples of where we may want to expand, consider "panel"
and "moderator"...)

> the same situation.

   I don't believe we can avoid such issues -- even if we were to limit
ourselves to only one allowed content-type. ;^)

--
John Leslie <[email-masked]>

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Tue, 22 May 2012 11:56:51 -0700

Hi John,
My point wasn't really the name of the attributes, sorry if I expressed
it poorly.

It was to not use the full list of RFC 4796 attributes, but to limit to
2 of them...
OR, I even prefer just going back to purpose with main and
presentation.. but don't really object to content attributes if we sort
out ones that make sense to me.

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2012 11:42 AM
> To: Allyn Romanow (allyn)
> Cc: CLUE
> Subject: Re: [clue] capture attributes - content attribute
> 
> > However, in working on a proof of concept implementation, this
seemed
> to

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 May 2012 19:09:11 -0400

Allyn,

I'd like to understand better what the problem was that you encountered.

I guess you must have had a situation when one impl used "speaker" and 
another used "main" for captures that were topologically and 
semantically equivalent. I understand how that could be a problem. But 
it seems like a problem that arises from insufficient definition of what 
the "purpose" values *mean*. That may mean we need to find a way to 
supplement the definitions from 4976.

In rooms where the arrangement is always a line of people facing a line 
of screens and cameras there may not be a need for more than two 
purposes. But other arrangements, such as ones that have a distinguished 
speaker/presenter, may need more.

	Thanks,
	Paul

On 5/22/12 2:56 PM, Allyn Romanow (allyn) wrote:
>> Allyn Romanow (allyn)<[email-masked]>  wrote:
>>>
>> John Leslie<[email-masked]>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Tue, 22 May 2012 21:46:34 -0700

Hi Paul,
I'd like to just define the ones we have need for and leave definition
of others for when there is a recognized need. 
I don't have a real problem with doing what the SIP parity group did -
restricting usage to slides (which seems odd for audio) and main.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Tuesday, May 22, 2012 4:09 PM
To: [email-masked]
Subject: Re: [clue] capture attributes - content attribute

Allyn,

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Thu, 24 May 2012 00:26:32 +0300

Hi Allyn,
My understanding is that RFC 4796 defines an attribute that can be used to
provide semantics to the stream. Yet in order to have interoperability there
need to be a specific profile that will describe the behavior expected when
a specific content value is offered. An example is using the presentation
and main in "H.239" like SIP usage.

The framework needs to recommend the values that will be used for the room
"main" and for the presentation. (personally I do not like the name slides)
and how to interoperate when they are received. As for the rest, if we have
usage we will need to specify how to use them in CLUE applications.

Roni 

> Allyn Romanow (allyn)
> Sent: Tuesday, May 22, 2012 9:57 PM
> To: John Leslie
> Cc: CLUE
> >    "Main" leaves me cold, to tell truth; "Presentation" may be
> > marginally better than "slides" -- but I can't see this as worth
> > revisiting.
> >

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 23 May 2012 14:44:33 -0700

Hi Roni,
Sounds good to me...

Couple of questions of clarification-
What values do you think we might have for main and presentation? I took
them to be the values of "purpose" or content.

And, do you think we will have a profile that describes behavior
expected when a content value is offered-beyond what is in the framework
doc?

thanks

> From: Roni Even [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2012 2:27 PM
> To: Allyn Romanow (allyn); 'John Leslie'
> Cc: 'CLUE'
> Subject: RE: [clue] capture attributes - content attribute
> 
> Hi Allyn,
> My understanding is that RFC 4796 defines an attribute that can be
used
> > > > Initially, when this came up,  I thought it was a simple change
> and
> > it
> > > > My primary reason for wanting to define only main and
presentation
> > (or
> > > > content attributes main and slides from the full list in RFC
4796)
> > is
> > > > It can easily create  confusion and lack of non-interoperability
-
> > for
> > > > example one system may use main and another speaker when
referring

---

From: "Roni Even" <[email-masked]>
Date: Thu, 24 May 2012 00:49:34 +0300

Hi Allyn,
I see no problem for the "main" value if we say this is the capture scene of
the TP room. As for presentation or slides I think that it will be good to
clarify if we want an H.239 like behavior or if it is just a presentation
conveyed as a video stream without any token. If we want the first one it
will be good if Charles can look at having a document we can reference here
(publically available).

Roni

> From: Allyn Romanow (allyn) [mailto:[email-masked]]
> Sent: Thursday, May 24, 2012 12:45 AM
> To: Roni Even; John Leslie
> Cc: CLUE
> What values do you think we might have for main and presentation? I
> took them to be the values of "purpose" or content.
> 
> expected when a content value is offered-beyond what is in the
> framework doc?
> 
> thanks
> 
> > provide semantics to the stream. Yet in order to have
> interoperability
> > there need to be a specific profile that will describe the behavior
> > expected when a specific content value is offered. An example is
> using
> > the presentation and main in "H.239" like SIP usage.
> >
> > The framework needs to recommend the values that will be used for the
> > room "main" and for the presentation. (personally I do not like the
> > name
> > slides)
> > and how to interoperate when they are received. As for the rest, if
> we
> > have usage we will need to specify how to use them in CLUE
> > applications.
> >
> > Roni
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > Allyn Romanow (allyn)
> > > It was to not use the full list of RFC 4796 attributes, but to
> limit
> > to
> > > 2 of them...
> > > > > presentation, or at the most, change it to content with main
> and
> > > > slides

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 May 2012 19:06:25 -0400

> will be good if Charles can look at having a document we can reference here

There has been frequent discussion of deferring to BFCP for the things 
it does. It has floor control. So I've been assuming that explicit floor 
control for presentations ('slides') would be that way. It will no doubt 
take some work to specify how CLUE and BFCP cooperate.

Were you thinking we would use something else?

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 24 May 2012 15:15:59 -0700

I think it would be good for CLUE to have easy interoperability with existing devices that follow the IMTC document for Role Based Video Streams.  So it makes sense to me for CLUE to have one attribute with only two specific values, that map directly to the content attribute values of main and slides that are used for RBVS.  I don't care too much what we name we give to it, as long as somehow it is specified how to map it to the RBVS usage.

For extensibility, if we add more possible values than just main and slides, would we want to relate it to RBVS somehow?  For example if there is a "speaker" but no "main", would the speaker be treated as "main"?  Or if there is a "speaker" and "main", then the legacy RBVS system should see the "main" one but not "speaker"?

Or would it be better for extensibility to have a separate attribute name which can take on more new values?  For example:
  Attribute: content - possible values: {main, slides}
 Attribute: clue-extensible-role - possible values: {speaker, sign language, audience, ...}

A media capture could use both attributes, for example content=main, clue-extensible-role=audience.  Would that work?  Do you see a significant difference between extending it this way, rather than adding more possible values to the content attribute?

Adding more roles seems related to Ticket #8 also.  People (including me) have suggested using such additional role attributes to distinguish between multiple capture scenes.

Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of Allyn Romanow (allyn)
Sent: Tuesday, May 22, 2012 2:13 PM
To: CLUE
Subject: [clue] capture attributes - content attribute

Folks,
Earlier we changed  the capture attribute "purpose" with values presentation and main to content attribute taken from RFC 4976 with content types slides, main, speaker,

Initially, when this came up,  I thought it was a simple change and it had the appeal of using an existing RFC, so I wasn't opposed to it. However, in working on a proof of concept implementation, this seemed to have issues and  I feel we should stay with purpose and main and presentation, or at the most, change it to content with main and slides as did the IMTC SIP Parity WG for Role Based Video Streams.

My primary reason for wanting to define only main and presentation (or content attributes main and slides from the full list in RFC 4796) is similar to the reasoning from the SIP Parity WG - that in a conference It can easily create  confusion and lack of non-interoperability - for example one system may use main and another speaker when referring to the same situation.    This same view was actually expressed in the Role Based Video Stream work in IMTC SIP Parity WG which decided  to support only main and slides.

Here is what is in the RBVS document on this topic (of course they aren't using the attributes for audio, just video).

Unlike H.239 where there are only two channel roles, "live" and "presentation", in SIP, there are more roles, and it is possible that endpoints and MCUs will have to deal with the situation where all of the participants in a call do not designate the same roles for their channels.  For example, one endpoint in a multipoint conference may use the "speaker" and "slides" roles for its video channels, while another may use "main" and "alt" for its video channels.   Since there are no mechanisms to enable MCUs and endpoints to interoperate in this type of situation, all SIP-based endpoints conforming to the RBVS "Best Practices" Profile MUST use the attributes as specified in this section. [ i.e., main and slides] The handling of other 'content' attribute values is considered out of scope.

Although I'm okay with using just slides and main from the content attribute, I feel that purpose: presentation, main map better to audio than do slides and main.

I noticed today during the CLUE WG meeting that people reverted to speaking about purpose main and presentation instead of the new content attribute categories.. which is just an anecdote suggesting that we stick with what we first had.

Of course, I'm assuming that we add any values to purpose (or content) as they arise.

Thoughts?

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 25 May 2012 13:59:33 -0700

The IMTC best practice document for role based video streams (RBVS) has
been shared via a liaison statement with the RAI areas. It is not a
publically available document at this time. Publishing as a publically
available document is a work item scheduled to be completed this
calendar year.

My recommendation would be to reuse the existing RFC 4796 content
attribute.
For interworking with existing implementations, use the values of "main"
and "slides" to represent main video and content. This is consistent
with IMTC's recommendations for RBVS.
If/when there is a desire to extend the set of values beyond these two,
either:
- provide guidance on how to additional values already defined in RFC
4796
- define new values per extensibility outlined in RFC 4796, and provide
guidance on how to use these values

For now, it seems the restricted set containing only "main" and "slides"
is sufficient, even if not ideal.

Cheers,
Charles

> Duckworth, Mark
> Sent: Thursday, May 24, 2012 3:16 PM
> To: [email-masked]
> I think it would be good for CLUE to have easy interoperability with
> existing devices that follow the IMTC document for Role Based Video
> Streams.  So it makes sense to me for CLUE to have one attribute with
> only two specific values, that map directly to the content attribute
> values of main and slides that are used for RBVS.  I don't care too
> much what we name we give to it, as long as somehow it is specified
how
> to map it to the RBVS usage.
> 
> 
> 
> For extensibility, if we add more possible values than just main and
> slides, would we want to relate it to RBVS somehow?  For example if
> there is a "speaker" but no "main", would the speaker be treated as
> "main"?  Or if there is a "speaker" and "main", then the legacy RBVS
> system should see the "main" one but not "speaker"?
> 
> 
> 
> Or would it be better for extensibility to have a separate attribute
> name which can take on more new values?  For example:
> 
> A media capture could use both attributes, for example content=main,
> clue-extensible-role=audience.  Would that work?  Do you see a
> significant difference between extending it this way, rather than
> adding more possible values to the content attribute?
> 
> 
> 
> Adding more roles seems related to Ticket #8 also.  People (including
> me) have suggested using such additional role attributes to
distinguish
> between multiple capture scenes.
> 
> 
> 
> Mark
> 
> 
> 
> 
> 
> However, in working on a proof of concept implementation, this seemed
> to have issues and  I feel we should stay with purpose and main and
> the same situation.    This same view was actually expressed in the
> Role Based Video Stream work in IMTC SIP Parity WG which decided  to
> support only main and slides.
> 
> 
> 
> endpoints and MCUs will have to deal with the situation where all of
> the participants in a call do not designate the same roles for their
> Practices" Profile MUST use the attributes as specified in this
> section. [ i.e., main and slides] The handling of other 'content'
> attribute values is considered out of scope.
> 
> 
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 May 2012 19:02:33 -0400

> available document is a work item scheduled to be completed this

I don't understand what you mean about it being shared via a liaison 
statement. Does that mean its available to some IETF people in some way?

What semantics does it ascribe to "main" and "slides"?
If we adopt "slides" but use it more generally to denote a video stream 
that might contain a rendition of a presentation more general than 
slides, are we abusing it?

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Fri, 25 May 2012 18:18:04 -0500

Any official liaison statements should end up being posted here:
https://datatracker.ietf.org/liaison/

There was an LS sent to the SIPCORE mailing list:
http://www.ietf.org/mail-archive/web/sipcore/current/msg04522.html
But, was about the Security document, which was attached to the email.
Charles, can you please point us to the LS with regards to the Role Based
Video document.  I know it was mentioned in one of the chair charts in a
DISPATCH session, but we consider things like that as FYIs as opposed to an
LS.

The LS on the security document should have been forwarded by the chairs to
[email-masked] so it could be posted on the liaison webpage.  I think
the secretariat forwards any LS that it they receive to the appropriate WG
chairs, ADS, etc.

We also don't seem to have an IETF liaison to IMTC - the need for such is
likely something that needs to be discussed elsewhere (i.e., on the RAI
list or even on the IAB list).

Mary.

On Fri, May 25, 2012 at 6:02 PM, Paul Kyzivat <[email-masked]> wrote:

> that might contain a rendition of a presentation more general than slides,
> are we abusing it?
>
>        Thanks,
>        Paul
>
>
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>
>> Of
>>
>>> Duckworth, Mark
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>
>> Of
>>
>>> Allyn Romanow (allyn)
>>> presentation, or at the most, change it to content with main and
>>>
>> slides
>>
>>> channels.  For example, one endpoint in a multipoint conference may
>>>
>> use
>>
>>> mechanisms to enable MCUs and endpoints to interoperate in this type
>>>
>> of
>>
>>> speaking about purpose main and presentation instead of the new
>>>
>> content
>>
>> ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>