Subject: Re: [clue] ways of managing presentations in telepresence sessions

From: Stephen Botzko <[email-masked]>
Date: Tue, 1 May 2012 03:11:25 -0400

On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <[email-masked]>wrote:

> On 4/28/12 1:18 PM, Stephen Botzko wrote:
>
>  [sb] As I mentioned above, the existing solutions usually include a
>> screen-scrape application, so you don't have to use a video cable. This
>> is essentially the same as using Webex for presenting (but not remote
>> control).
>>
>
> How are these solutions connected? Does the captured application data go
> to the local room controller, or to an MCU in the middle of the TP session?
> Or something else?
> [sb] They are normally connected to the local room telepresence system.
> Again, the people in the local room also need to see the presentation, so
> this is the most direct and also is the most bandwidth efficient approach.
> Another aspect is that the rooms can and are used purely locally (with no
> remote systems at all), and presentations also need to work in that
> situation.  BTW I think adding requirements for support of multiple
> endpoints in the same room is an unwise path -  this is not SPLICES, and we
> have enough to do already.  I agree with folks who are saying it is out of
> scope[/sb]
>
>
>  Also, even though Webex allows remote control, in my
>> experience that feature is not used as much as simple presenting.  I am
>> not saying it has no value, just that the most common case I see is a
>> simple presentation.
>>
>
> That is my experience as well. I wasn't thinking about the
> multi-user-control aspect.
>
>
>  Supporting the video cable still has value, especially if you have guest
>> presenter who does not have access to your local network.  Most of those
>> presenters are expecting to use a projector, so they have the cables
>> with them.
>>
>
> Surely. In this case, I presume the cable connects to the local room
> controller. If there are multiple cable connectors (e.g. one at each seat)
> do they show up as multiple presentation streams? Or is there some sort of
> switch and floor control? If so, how does one manage the floor control?
> [sb] Today there is one presenter at a time.  With multiple cables, there
> is usually a button at each spot, and if you press it you become the
> presenter (most recent request wins is the policy).  Normal social
> courtesies handle conflict, so there is no real need for formal floor
> control.  This happens even in ordinary webex conferences - if someone
> grabs the ball when they shouldn't have it, people say something and it
> gets resolved.  Similarly, if someone needs the ball.   More precisely, the
> presenting video system holds the token for the room.  With H.239, the MCU
> (if there is one) grants it, using whatever policy it wants, and can revoke
> it at any time.  In point-to-point calls, the far end SHALL grant it upon
> request, so in that case the turn-taking policy is mandated in the
> standard. Multiple presenters in the same room is up to the local room
> policy - there is no standard, and in my opinion none is needed.  The token
> remains owned by the local video system, it is allowed to present whatever
> local source it wishes. [/sb]
>
 My answer on application sharing falling "out of favor" related
>> specifically to vendor support for standards-based application sharing
>> (T.120 in particular) - which I thought was responsive to your original
>> question.  Perhaps I misunderstood it.  Anyway there were several
>> reasons [and perhaps various viewpoints] on why T.120 was dropped,
>> though I think it is probably not a useful discussion for this list.  I
>> know of no other standards-based protocol for application sharing.
>>
>
> I wasn't assuming there was, other than a pure video (and maybe audio)
> stream interface. There are other fora for that sort of thing, but its my
> impression that this is largely a world of proprietary and defacto
> standards.
>
>
>  BTW, it is relatively common for web screen sharing to co-exist with the
>> videoconferencing presentation methods.  For instance, you can have a
>> stand-alone webex conference, with someone sharing their laptop screen
>> for the video participants.[/sb]
>>
>
> I have done this. But it was cumbersome. IIRC, getting the sharing to be
> visible in the room I was in required using a video cable in addition to
> using webex sharing.

[sb]With our equipment you could use the cable if you wished, but it would
not be required.  Though generally speaking, people are used to using
projectors for presenting.  Video systems are providing identical
interfaces, so they work the way people expect.  For instance, in IETF
interim meetings the Webex screen is always presented locally, frequently
using a cable.  The chairs may find that cumbersome, but they certainly
come into the meeting expecting to do it anyway.[\sb]

>
>
>     Of course that is still somewhat cumbersome, but presumably it will
>>    be improved over time. Its the UI for driving it that is cumbersome,
>>    not the output.
>>
>>    A key difference is that if the computer output is via video cable
>>    into the local room controller, then that is probably responsible
>>    for displaying it locally on a display in the room as well as
>>    sending it to the remote end. If the users connect their computers
>>    directly to the MCU, then the capture will come to the room just
>>    like anything else from the MCU.
>>
>> [sb]The standard model for videoconferencing presentations is a
>> token-controlled transmission.  If you don't have the token, you are
>> receiving. The local equipment is always responsible for display.
>> Looping the presentation back through the MCU back to the originating
>> site wastes bandwidth.
>>
>> I don't know if web conferencing solutions do this differently or not.
>> I've always assumed that when I grab the webex "ball" I stop receiving
>> desktop images.  Certainly there is no reason for the server to send
>> them back to me.[/sb]
>>
>
>        Thanks,
>        Paul
>

---

From: "Johan Ludvig Nielsen (johaniel)" <[email-masked]>
Date: Wed, 2 May 2012 14:06:53 +0200

I just want to remind you all that presentation often means video _and_
audio, for instance a movie clip with a stereo soundtrack. Sometimes
presentation means only audio. Hook up your favourite device and share a
music clip or an interesting recording.

Any presentation audio played back locally must be controlled by, or at
least be exactly (in sample sync) known to, the local telepresence
system controller. A totally separate endpoint for presentation will
therefore cause some practical problems.

By the way, one very useful effect of CLUE is the ability for receiving
endpoints to distinguish between audio from live talking sources and
presentations/recordings.

Johan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Botzko
Sent: 1. mai 2012 09:11
To: Paul Kyzivat
Cc: CLUE
Subject: Re: [clue] ways of managing presentations in telepresence
sessions

On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <[email-masked]>
wrote:

How are these solutions connected? Does the captured application data go
to the local room controller, or to an MCU in the middle of the TP
session? Or something else?

[sb] They are normally connected to the local room telepresence system.
Again, the people in the local room also need to see the presentation,
so this is the most direct and also is the most bandwidth efficient
approach.  Another aspect is that the rooms can and are used purely
locally (with no remote systems at all), and presentations also need to
work in that situation.  BTW I think adding requirements for support of
multiple endpoints in the same room is an unwise path -  this is not
SPLICES, and we have enough to do already.  I agree with folks who are
saying it is out of scope[/sb]

		Also, even though Webex allows remote control, in my
		experience that feature is not used as much as simple
presenting.  I am
		not saying it has no value, just that the most common
case I see is a
		simple presentation.

		Supporting the video cable still has value, especially
if you have guest
		presenter who does not have access to your local
network.  Most of those
		presenters are expecting to use a projector, so they
have the cables
		with them.

	Surely. In this case, I presume the cable connects to the local
room controller. If there are multiple cable connectors (e.g. one at
each seat) do they show up as multiple presentation streams? Or is there
some sort of switch and floor control? If so, how does one manage the
floor control?

	[sb] Today there is one presenter at a time.  With multiple
cables, there is usually a button at each spot, and if you press it you
become the presenter (most recent request wins is the policy).  Normal
social courtesies handle conflict, so there is no real need for formal
floor control.  This happens even in ordinary webex conferences - if
someone grabs the ball when they shouldn't have it, people say something
and it gets resolved.  Similarly, if someone needs the ball.   More
precisely, the presenting video system holds the token for the room.
With H.239, the MCU (if there is one) grants it, using whatever policy
it wants, and can revoke it at any time.  In point-to-point calls, the
far end SHALL grant it upon request, so in that case the turn-taking
policy is mandated in the standard. Multiple presenters in the same room
is up to the local room policy - there is no standard, and in my opinion
none is needed.  The token remains owned by the local video system, it
is allowed to present whatever local source it wishes. [/sb]

		My answer on application sharing falling "out of favor"
related
		specifically to vendor support for standards-based
application sharing
		(T.120 in particular) - which I thought was responsive
to your original
		question.  Perhaps I misunderstood it.  Anyway there
were several
		reasons [and perhaps various viewpoints] on why T.120
was dropped,
		though I think it is probably not a useful discussion
for this list.  I
		know of no other standards-based protocol for
application sharing.

	I wasn't assuming there was, other than a pure video (and maybe
audio) stream interface. There are other fora for that sort of thing,
but its my impression that this is largely a world of proprietary and
defacto standards.

		BTW, it is relatively common for web screen sharing to
co-exist with the
		videoconferencing presentation methods.  For instance,
you can have a
		stand-alone webex conference, with someone sharing their
laptop screen
		for the video participants.[/sb]

	I have done this. But it was cumbersome. IIRC, getting the
sharing to be visible in the room I was in required using a video cable
in addition to using webex sharing.

[sb]With our equipment you could use the cable if you wished, but it
would not be required.  Though generally speaking, people are used to
using projectors for presenting.  Video systems are providing identical
interfaces, so they work the way people expect.  For instance, in IETF
interim meetings the Webex screen is always presented locally,
frequently using a cable.  The chairs may find that cumbersome, but they
certainly come into the meeting expecting to do it anyway.[\sb]

		   Of course that is still somewhat cumbersome, but
presumably it will
		   be improved over time. Its the UI for driving it that
is cumbersome,
		   not the output.
		
		   A key difference is that if the computer output is
via video cable
		   into the local room controller, then that is probably
responsible
		   for displaying it locally on a display in the room as
well as
		   sending it to the remote end. If the users connect
their computers
		   directly to the MCU, then the capture will come to
the room just
		   like anything else from the MCU.
		
		[sb]The standard model for videoconferencing
presentations is a
		token-controlled transmission.  If you don't have the
token, you are
		receiving. The local equipment is always responsible for
display.
		Looping the presentation back through the MCU back to
the originating
		site wastes bandwidth.
		
		I don't know if web conferencing solutions do this
differently or not.
		I've always assumed that when I grab the webex "ball" I
stop receiving
		desktop images.  Certainly there is no reason for the
server to send
		them back to me.[/sb]

	       Thanks,
	       Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 May 2012 11:22:44 -0400

> presentations/recordings.

I'm not sure I understand the point you are making.
Certainly it is true that a presentation may consist of audio and video.
But its not just presentations that can contain paired audio and video.
When we have many audio and video captures, there could be several pairs.

RFC3388 provides a way (a=mid:ls) to indicate when lip sync is required.
Do we need more than that? Should advertisements indicate desirable 
audio/video pairings so that selection can take that into account?

	Thanks,
	Paul

> Johan
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Stephen Botzko
> *Sent:* 1. mai 2012 09:11
> *To:* Paul Kyzivat
> *Cc:* CLUE
> *Subject:* Re: [clue] ways of managing presentations in telepresence
> sessions
>
> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     controller. If there are multiple cable connectors (e.g. one at each
>     seat) do they show up as multiple presentation streams? Or is there
>     some sort of switch and floor control? If so, how does one manage
>     the floor control?
>
>     [sb] Today there is one presenter at a time. With multiple cables,
>     there is usually a button at each spot, and if you press it you
>     become the presenter (most recent request wins is the policy).
>     Normal social courtesies handle conflict, so there is no real need
>     for formal floor control. This happens even in ordinary webex
>     conferences - if someone grabs the ball when they shouldn't have it,
>     people say something and it gets resolved. Similarly, if someone
>     needs the ball. More precisely, the presenting video system holds
>     the token for the room. With H.239, the MCU (if there is one) grants
>     it, using whatever policy it wants, and can revoke it at any time.
>     In point-to-point calls, the far end SHALL grant it upon request, so
>     in that case the turn-taking policy is mandated in the standard.
>     Multiple presenters in the same room is up to the local room policy
>     - there is no standard, and in my opinion none is needed. The token
>     remains owned by the local video system, it is allowed to present
>     whatever local source it wishes. [/sb]
>
>     audio) stream interface. There are other fora for that sort of
>     thing, but its my impression that this is largely a world of
>     proprietary and defacto standards.
>
>     I have done this. But it was cumbersome. IIRC, getting the sharing
>     to be visible in the room I was in required using a video cable in
>     addition to using webex sharing.
>

---

From: "Johan Ludvig Nielsen (johaniel)" <[email-masked]>
Date: Thu, 3 May 2012 15:02:23 +0200

Sorry for being unclear. I am commenting on the implied option of
rendering presentation on a separate system, either on one or several
computers or a dedicated endpoint separate from the telepresence system
in the room.

My main point is that all audio belonging to a conference and being
played back in a room must be controlled by or at least known to the
audio processing unit sending audio _from_ that room. This is to avoid
echo or multi-path problems.

One example of such a problem is if a presentation in the form of a
movie with a soundtrack is played back on a computer separate from the
telepresence system in the room. The microphone system in the room will
pick up the sound from the computer's loudspeakers and happily transmit
that as voice into the conference. The presentation audio is then
delivered to other sites through two different paths with different
delays, one of them with poor quality.

The other (and totally separate) point I am making is that with CLUE we
will have the ability to send presentation audio as a separate stream,
and that we are happy about that. Today locally input presentation audio
is most often mixed with the mic signal and sent in the main audio
stream (which can be stereo). There is no H.239 equivalent for audio.

Regards
Johan

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 2. mai 2012 17:23
To: Johan Ludvig Nielsen (johaniel)
Cc: Stephen Botzko; CLUE
Subject: Re: [clue] ways of managing presentations in telepresence
sessions

On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote:
> I just want to remind you all that presentation often means video 
> _and_ audio, for instance a movie clip with a stereo soundtrack. 
> Sometimes presentation means only audio. Hook up your favourite device

> and share a music clip or an interesting recording.
>
> Any presentation audio played back locally must be controlled by, or 
> at least be exactly (in sample sync) known to, the local telepresence 
> By the way, one very useful effect of CLUE is the ability for 
> receiving endpoints to distinguish between audio from live talking 
> sources and presentations/recordings.

I'm not sure I understand the point you are making.
Certainly it is true that a presentation may consist of audio and video.
But its not just presentations that can contain paired audio and video.
When we have many audio and video captures, there could be several
pairs.

	Thanks,
	Paul

> screen-scrape application, so you don't have to use a video cable. 
> This is essentially the same as using Webex for presenting (but not 
> remote control).
>
> How are these solutions connected? Does the captured application data 
> go to the local room controller, or to an MCU in the middle of the TP 

> locally (with no remote systems at all), and presentations also need 
> to work in that situation. BTW I think adding requirements for support

> of multiple endpoints in the same room is an unwise path - this is not

>         not saying it has no value, just that the most common case I
see
>         is a
room
related
>         BTW, it is relatively common for web screen sharing to
co-exist
>         with the
laptop
>         screen

> frequently using a cable. The chairs may find that cumbersome, but 
> they certainly come into the meeting expecting to do it anyway.[\sb]
>
responsible
display.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 3 May 2012 17:25:18 +0300

Hi,
See inline
Roni

> Johan Ludvig Nielsen (johaniel)
> Sent: Thursday, May 03, 2012 4:02 PM
> To: Paul Kyzivat
> Cc: CLUE

This is not a problem of the current protocols, you can send two audio
streams in SIP and assign a different content attribute to each of them. The
issue of the local echo of the movie sound to the people audio is a local
system issue and not a standard issue. As for handling two audio streams
this will require a definition like H.239 for this case in order to achieve
interoperability.
> and that we are happy about that. Today locally input presentation
> audio is most often mixed with the mic signal and sent in the main
> audio stream (which can be stereo). There is no H.239 equivalent for
> audio.

Sending two separate audio is not a CLUE feature, it can be done by offering
two audio RTP sessions for example.

> >         presenter who does not have access to your local network.
> Most
> >         of those
> cables,
> application
> >         sharing
> >         (T.120 in particular) - which I thought was responsive to
> your
> >         original
> >         though I think it is probably not a useful discussion for
> this
> >         list. I
> sharing
> >         Of course that is still somewhat cumbersome, but presumably
> it
> will
> differently
> >         or not.
> >         desktop images. Certainly there is no reason for the server
> to
> send
> >         them back to me.[/sb]
> >
> >
> >     Thanks,
> >     Paul
> >
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 May 2012 11:59:25 -0400

> delays, one of them with poor quality.

OK, this is a good point.
So a participant sitting in a TP room could connect his computer to the 
MCU for the TP session as an independent endpoint and receive and play 
out video captures without trouble. But if it receives and plays out 
audio there might be trouble. If it were just presentation audio, and it 
was played back to headphones it might be ok. But if played back via 
speakers it could be a problem.

I suppose that is something that would have to be considered pilot error 
rather than a defect in CLUE.

> stream (which can be stereo). There is no H.239 equivalent for audio.

So yes, we have that capability. Do we have sufficient description of it 
to make it fully usable? In particular, do we have enough so that, when 
selecting which capture scene entries and captures to receive, the 
recipient will be able to identify audio/video pairs so that they can be 
selected as a pair?

	Thanks,
	Paul

>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat<[email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Thu, 3 May 2012 12:18:48 -0400

I go back to what I see is the fundamental issue:

You have two separate systems from two vendors in one room.  They interact in a way that is important to other rooms.  We don't have mechanisms to represent this.

Brian

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 3 May 2012 22:40:12 +0200

I have two separate speakerphones from two vendors in one room calling into
the same audio conference.  They interact in a way that utterly fails to
deliver usable audio to phones in other locations.  We don't have
mechanisms in SIP to represent this or prevent the bad behaviour.

This is a problem for the IETF because????

Stephen Botzko

On Thu, May 3, 2012 at 6:18 PM, Brian Rosen <[email-masked]> wrote:

> You have two separate systems from two vendors in one room.  They interact
> in a way that is important to other rooms.  We don't have mechanisms to
> represent this.
>
> Brian
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 3 May 2012 17:17:36 -0400

Because it's not a common problem, and there is no right way to do it.

Having the telepresence audio/video on one system and the presentation system on another is probably more common that having them on the same system.

Brian

On May 3, 2012, at 4:40 PM, Stephen Botzko wrote:

> I have two separate speakerphones from two vendors in one room calling into the same audio conference.  They interact in a way that utterly fails to deliver usable audio to phones in other locations.  We don't have mechanisms in SIP to represent this or prevent the bad behaviour.  
>

---

From: Roni even <[email-masked]>
Date: Fri, 4 May 2012 05:31:54 +0000

Brian,

I agree that this is a problem, but it is not a CLUE problem. I am wondering if it is for the IETF but it can be discussed in Disptach or SPLICE.

The problem is not two systems but two different applications that do not have a common API or that the presentation application is not based on any standard that allows an implementer to create one application.

Roni

________________________________
From: [email-masked] [[email-masked]] on behalf of Brian Rosen [[email-masked]]
Sent: Friday, May 04, 2012 0:17
To: Stephen Botzko
Cc: CLUE; Johan Ludvig Nielsen (johaniel)
Subject: Re: [clue] ways of managing presentations in telepresence sessions

Brian

Stephen Botzko

On Thu, May 3, 2012 at 6:18 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
I go back to what I see is the fundamental issue:

Brian

On May 3, 2012, at 10:25 AM, Roni Even wrote:

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>> From: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>]
>> Sent: 2. mai 2012 17:23
>>> *From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] *On
>> Behalf
>>
>>> Of *Stephen Botzko
>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 4 May 2012 10:26:34 +0200

Of course it is a real problem, it happens every day. The exact same issue
occurs with mixes of speaker phones, mobile phones, PCs,  and traditional
video conferencing all the time.  The problem is not unique to multi-stream
endpoints, and is not made worse by CLUE.

The only solutions that work are to (a) route the presentation audio output
into an telepresence room audio input, instead of using built-in speakers
in the presentation system and (b) disconnect the presentation audio output
and (c) mute the presentation audio output.  These solutions are physical,
and do not involve the normal signaling layers we develop in the IETF.

Detection of the echo/feedback path can in principle be done in the media
plane, though it does add complexity to each endpoint.

Detecting it through signaling is problematic, since the various devices
involved often use different protocols, and therefore have no common
knowledge of what audio conference they are in.  There are also scenarios
where the echo/feedback path occurs with *independent* audio bridges (or no
bridges at all).  And there is no ability to identify that the devices are
in the same location and that they both have open microphones or speakers.

Eliminating the echo/feedback automatically is also challenging, since you
need to identify the best devices to mute, and create a mechanism which can
block the problematic signaling path(s).  Such a mechanism can also be
exploited to launch a denial of service attack.

In my view this is clearly not a CLUE issue, and I don't see much hope for
a workable signaling solution no matter where it is done.

Stephen Botzko

On Thu, May 3, 2012 at 11:17 PM, Brian Rosen <[email-masked]> wrote:

> Having the telepresence audio/video on one system and the presentation
> system on another is probably more common that having them on the same
> system.
>
> Brian
>
> I have two separate speakerphones from two vendors in one room calling
> into the same audio conference.  They interact in a way that utterly fails
> to deliver usable audio to phones in other locations.  We don't have
>> You have two separate systems from two vendors in one room.  They
>> interact in a way that is important to other rooms.  We don't have
>> mechanisms to represent this.
>>
>> Brian
>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 4 May 2012 06:06:46 -0700

Paul asked:
   " when selecting which capture scene entries and captures to receive, the recipient
      will be able to identify audio/video pairs so that they can be selected as a
     pair?"

Yes, this is one of the functions of capture scenes.  If the provider is advertising an audio/video pair, then the provider puts the video in a capture scene entry and the audio in another capture scene entry and puts both these capture scene entries into the same capture scene.  So the consumer knows the audio and video are part of the same capture scene, so the consumer can select them both and render them together.

Mark

> Paul Kyzivat
> Sent: Thursday, May 03, 2012 11:59 AM
> > computers or a dedicated endpoint separate from the telepresence
> > system in the room.
> >
> > telepresence system in the room. The microphone system in the room
> > will pick up the sound from the computer's loudspeakers and happily
> > transmit that as voice into the conference. The presentation audio is
> > then delivered to other sites through two different paths with
> > different delays, one of them with poor quality.
> 
> So a participant sitting in a TP room could connect his computer to the MCU
> for the TP session as an independent endpoint and receive and play out
> video captures without trouble. But if it receives and plays out audio there
> might be trouble. If it were just presentation audio, and it was played back to
> headphones it might be ok. But if played back via speakers it could be a
> problem.
> 
> > The other (and totally separate) point I am making is that with CLUE
> > we will have the ability to send presentation audio as a separate
> > stream, and that we are happy about that. Today locally input
> > presentation audio is most often mixed with the mic signal and sent in
> > the main audio stream (which can be stereo). There is no H.239 equivalent
> for audio.
> 
> So yes, we have that capability. Do we have sufficient description of it to
> make it fully usable? In particular, do we have enough so that, when
> selecting which capture scene entries and captures to receive, the recipient
> will be able to identify audio/video pairs so that they can be selected as a
> pair?
> 
> 	Thanks,
> 	Paul
> 
> > Regards
> > Johan
> >
> >
> >
> >>          presenters are expecting to use a projector, so they have
> >> the
> > cables
> >>          with them.
> >>
> >>      In point-to-point calls, the far end SHALL grant it upon
> >> request,
> > so
> >>          videoconferencing presentation methods. For instance, you
> >> can
> > have a
> >>          [sb]The standard model for videoconferencing presentations
> >> is
> > a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 May 2012 09:26:55 -0400

> Yes, this is one of the functions of capture scenes.  If the provider is advertising an audio/video pair, then the provider puts the video in a capture scene entry and the audio in another capture…

Perhaps that is part of the answer, but maybe not all of it.

Is it the case that all captures from the same scene should be 
synchronized? (That seems plausible to me.)

I guess that suggests that captures from *different* scenes need not be 
synchronized.

Suppose there are two presentation video captures and two presentation 
audio captures in the same scene. And suppose a receiver can't handle 
two. If it selects one of the videos, how does it select the audio that 
matches it?

I guess at one level it could attempt to correlate them by spatial 
position. Or, perhaps whatever attribute it uses to select one of the 
videos can be used to select one of the audios. (I think that falls back 
to having additional attribute(s) to describe the source and/or content 
of a capture. We've already discussed that.)

	Thanks,
	Paul

---

From: "Johan Ludvig Nielsen (johaniel)" <[email-masked]>
Date: Fri, 4 May 2012 16:29:48 +0200

I fully agree with Stephen. I have pointed out a challenge in having
several endpoints in the same room connected to the same conference (or
another for that matter). Implying that I think it should be avoided,
not that we should solve it.

Regards

Johan

Sent: 4. mai 2012 10:27
To: Brian Rosen

Of course it is a real problem, it happens every day. The exact same
issue occurs with mixes of speaker phones, mobile phones, PCs,  and
traditional video conferencing all the time.  The problem is not unique
to multi-stream endpoints, and is not made worse by CLUE.  

The only solutions that work are to (a) route the presentation audio
output into an telepresence room audio input, instead of using built-in
speakers in the presentation system and (b) disconnect the presentation
audio output and (c) mute the presentation audio output.  These
solutions are physical, and do not involve the normal signaling layers
we develop in the IETF.

Detection of the echo/feedback path can in principle be done in the
media plane, though it does add complexity to each endpoint.

Detecting it through signaling is problematic, since the various devices
involved often use different protocols, and therefore have no common
knowledge of what audio conference they are in.  There are also
scenarios where the echo/feedback path occurs with independent audio
bridges (or no bridges at all).  And there is no ability to identify
that the devices are in the same location and that they both have open
microphones or speakers.

Eliminating the echo/feedback automatically is also challenging, since
you need to identify the best devices to mute, and create a mechanism
which can block the problematic signaling path(s).  Such a mechanism can
also be exploited to launch a denial of service attack.

In my view this is clearly not a CLUE issue, and I don't see much hope
for a workable signaling solution no matter where it is done. 

Stephen Botzko

Brian

I have two separate speakerphones from two vendors in one room calling
into the same audio conference.  They interact in a way that utterly
fails to deliver usable audio to phones in other locations.  We don't
have mechanisms in SIP to represent this or prevent the bad behaviour.  

Stephen Botzko

Brian

>> computers or a dedicated endpoint separate from the telepresence
system
will
>> The other (and totally separate) point I am making is that with CLUE
we

---

From: Brian Rosen <[email-masked]>
Date: Fri, 4 May 2012 11:02:10 -0400

Sorry, I wasn't clear.

I'm not proposing to solve the audio problem of prerecorded audio interacting with room audio.

I'm observing that in most cases, today, there is a presentation system that is independent of the audio/video system.  Endpoints for both are in the same room.  They interact (floor control for example).  We don't have any way to describe or handle this in CLUE.

It's not the same problem as multiple audio or video systems in the same room either.

Brian

On May 4, 2012, at 4:26 AM, Stephen Botzko wrote:

> Of course it is a real problem, it happens every day. The exact same issue occurs with mixes of speaker phones, mobile phones, PCs,  and traditional video conferencing all the time.  The problem is not unique to multi-stream endpoints, and is not made worse by CLUE.  
> 
> The only solutions that work are to (a) route the presentation audio output into an telepresence room audio input, instead of using built-in speakers in the presentation system and (b) disconnect the presentation audio output and (c) mute the presentation audio output.  These solutions are physical, and do not involve the normal signaling layers we develop in the IETF.
> 
> Detection of the echo/feedback path can in principle be done in the media plane, though it does add complexity to each endpoint.
> 
> Detecting it through signaling is problematic, since the various devices involved often use different protocols, and therefore have no common knowledge of what audio conference they are in.  There are also scenarios where the echo/feedback path occurs with independent audio bridges (or no bridges at all).  And there is no ability to identify that the devices are in the same location and that they both have open microphones or speakers.
> 
> Eliminating the echo/feedback automatically is also challenging, since you need to identify the best devices to mute, and create a mechanism which can block the problematic signaling path(s).  Such a mechanism can also be exploited to launch a denial of service attack.
> 
> In my view this is clearly not a CLUE issue, and I don't see much hope for a workable signaling solution no matter where it is done. 
> 
> Stephen Botzko
>

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 4 May 2012 11:48:29 -0400

On Fri, May 4, 2012 at 11:02 AM, Brian Rosen <[email-masked]> wrote:
> I'm observing that in most cases, today, there is a presentation system that
> is independent of the audio/video system.  Endpoints for both are in the
> same room.  They interact (floor control for example).  We don't have any
> way to describe or handle this in CLUE.
>

As I said on the call, to me our job is to figure out what information
is needed, what can realistically  be obtained and how to best relay
it,  and stay out of the rest.

Regards
Marshall

> into an telepresence room audio input, instead of using built-in speakers in
> the presentation system and (b) disconnect the presentation audio output and
> (c) mute the presentation audio output.  These solutions are physical, and
> do not involve the normal signaling layers we develop in the IETF.
>
> where the echo/feedback path occurs with independent audio bridges (or no
> In my view this is clearly not a CLUE issue, and I don't see much hope for a
> workable signaling solution no matter where it is done.
>
> Stephen Botzko
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 4 May 2012 10:36:47 -0700

Hi Paul,
Comments inline.
Mark

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Paul Kyzivat
> Sent: Friday, May 04, 2012 9:27 AM
> To: [email-masked]
> >     " when selecting which capture scene entries and captures to 
> > receive,
> the recipient
> >        will be able to identify audio/video pairs so that they can 
> > be selected as
> a
> >       pair?"
> >
> > Yes, this is one of the functions of capture scenes.  If the 
> > provider is
> advertising an audio/video pair, then the provider puts the video in a 
> capture scene entry and the audio in another capture scene entry and 
> puts both these capture scene entries into the same capture scene.  So 
> the consumer knows the audio and video are part of the same capture 
> scene, so the consumer can select them both and render them together.
> >
> > Mark
> 
> Is it the case that all captures from the same scene should be synchronized?
> (That seems plausible to me.)
 
[Duckworth, Mark] No not always, for example an MCU that creates a scene that can have media captures from multiple different endpoints in the same scene.

> I guess that suggests that captures from *different* scenes need not 
> be synchronized.

[Duckworth, Mark] Correct.
 
> audio captures in the same scene. And suppose a receiver can't handle two.
> If it selects one of the videos, how does it select the audio that matches it?
> 
> videos can be used to select one of the audios. (I think that falls 
> back to having additional
> attribute(s) to describe the source and/or content of a capture. We've 
> already discussed that.)

[Duckworth, Mark] Yes, the consumer can do that.  But I would say a provider that is interested in better interoperability with less capable devices would also advertise a capture scene entry with a single video capture and another with a single audio capture if at all possible.