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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Apr 2012 12:57:15 -0400

I am working on my use cases for the question about how to select which 
captures to display. But I have a gap in my understanding, and would 
like to get input from those of you with more experience in a diversity 
of telepresence systems.

My only live experience with telepresence systems is with the Cisco 
ones. I'm not aware of it having any explicit support for presentations, 
though that might just be my lack of understanding.

So I'd like to hear what *is* supported, or is *intended* to be supported.

I presume that for the most part presentations these days originate in a 
computer and are fed into the telepresence system, much like they are in 
webex - either by preloading documents to the conference controller and 
then interacting with it from a computer to have them displayed, or by 
"sharing an application" dynamically from a computer. I understand that 
in a system like webex, which is not a telepresence system. But what 
does that mean when married to a telepresence system?

Some ways I can imagine this working:

- visitors to a telepresence room bring their own computers.
   Each seat has a video connector that the visitor can connect to
   and originate a presentation stream. When active, these become
   additional captures from the room. But for others in the same
   room to see, these would then have to be treated as incoming
   captures (from where) and displayed on some display in the room.

- visitors to a telepresence room bring their own computers.
   Each such computer connects to an MCU as if it were an independent
   endpoint/room. The computer then offers up whatever it wants to
   share as a capture. The room itself also connects to the MCU,
   with its cameras as captures. The MCU sorts this all out, handles
   floor control, and decides what to advertise. So it can include
   presentations from user's computers as well as captures from the
   rooms. The local room can then display one or more presentations
   on its diplays. Or, the user's computer could also serve as a
   display for presentations so that the room's displays could be
   reserved for showing participants in other rooms.

- the telepresence room could have a personal display and controller
   at each seat. This could provide the user with a controller to
   request the floor, to review preloaded documents and request their
   display, etc. (Its a bit like the first one above.)

There seems to be a big difference if the presentation is seen as coming 
from a room that has the typical telepresence layout, or if it is seen 
coming from a separate endpoint coupled to the computer generating it, 
and whether the presentation is displayed on equipment that is part of 
the room, or by a separate endpoint.

I'd like feedback if any of the above makes sense, and whether there are 
other ways of looking at this I haven't imagined.

	Thanks,
	Paul

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 26 Apr 2012 14:33:48 -0400

Most traditional videoconferencing systems support H.239 (with H.323),
using a functionally equivalent method  in SIP.  The presentation video is
assigned a role (e.g., slides), and the ability to send is token-controlled
with BFCP.  All endpoints in the conference receive the presentation.  If
there is a legacy device (which doesn't support presentations) on the far
end, the sender usually chooses to send the presentation instead of the
participant video.

Computers can be connected using HDMI/Displayport/DVI/VGA directly to the
video conferencing endpoint.  Alternatively, there may be a PC application
that screen-scrapes the display and sends it to the endpoint for
distribution. These same options are used in telepresence systems.

On the receiving side, there are several options.  Sometimes the content is
displayed on a separate monitor or projector.  Sometimes the content is
composed along with participants, and placed on a single display.  In
telepresence systems, there are frequently content monitors at each seat,
all of which will display the presentation.

Application sharing was common back in the 90's (using the T.120 protocol),
but fell out of favor for a variety of reasons.

Stephen Botzko

On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat <[email-masked]>wrote:

> captures to display. But I have a gap in my understanding, and would like
> to get input from those of you with more experience in a diversity of
> telepresence systems.
>
> My only live experience with telepresence systems is with the Cisco ones.
> I'm not aware of it having any explicit support for presentations, though
> that might just be my lack of understanding.
>
> "sharing an application" dynamically from a computer. I understand that in
> a system like webex, which is not a telepresence system. But what does that
> mean when married to a telepresence system?
>
> coming from a separate endpoint coupled to the computer generating it, and
> whether the presentation is displayed on equipment that is part of the
> room, or by a separate endpoint.
>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 27 Apr 2012 13:53:43 -0700

Hi Paul,

I agree with Steve's response, but want to add something else, see below.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Thursday, April 26, 2012 12:57 PM
> To: CLUE
> Subject: [clue] ways of managing presentations in telepresence sessions
> 
> captures to display. But I have a gap in my understanding, and would like to
> get input from those of you with more experience in a diversity of
> telepresence systems.
> 
> I'm not aware of it having any explicit support for presentations, though that
> might just be my lack of understanding.
> 
> "sharing an application" dynamically from a computer. I understand that in a
> system like webex, which is not a telepresence system. But what does that

[Duckworth, Mark] Yes, a computer could make a separate connection (separate SIP call) to the MCU, but I don't see how the MCU can "sort this all out" as if it knows something about the computer being used by the same people in the same telepresence room that is also connected to the MCU.  The "telepresence room endpoint" and the "computer endpoint" would be totally independent, and the MCU would treat them independently.  Is that what you mean?

> There seems to be a big difference if the presentation is seen as coming from
> a room that has the typical telepresence layout, or if it is seen coming from a
> separate endpoint coupled to the computer generating it, and whether the
> presentation is displayed on equipment that is part of the room, or by a
> separate endpoint.
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Apr 2012 17:10:58 -0400

> [Duckworth, Mark] Yes, a computer could make a separate connection (separate SIP call) to the MCU, but I don't see how the MCU can "sort this all out" as if it knows something about the computer be…

I wasn't imagining that the MCU could figure out, on its own, that the 
computer was in the same room as another telepresence endpoint. But what 
it can work out is that it has another source of captures - in this case 
perhaps just a single capture marked as a presentation. If there are a 
lot of presentations coming in to the MCU this way then there may be a 
need for floor control. But if there is only one at a time, maybe not.

Presumably that computer, with a UI being controlled by the user, can 
make its own decisions about what it wants to receive from the MCU. If 
the room is providing interesting displays of everything interesting, 
then maybe it won't receive anything.

It would be more "interesting" if the computers of individual users also 
used a camera to send a capture containing an image of the user. Then it 
would indeed get complicated to sort out - captures from the room 
cameras plus captures from the cameras of computers belonging to 
individual users. I wasn't contemplating discussing that right now.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Apr 2012 17:20:01 -0400

On 4/26/12 2:33 PM, Stephen Botzko wrote:
> using a functionally equivalent method  in SIP.  The presentation video
> is assigned a role (e.g., slides), and the ability to send is
> token-controlled with BFCP.  All endpoints in the conference receive the
> presentation.  If there is a legacy device (which doesn't support
> presentations) on the far end, the sender usually chooses to send the
> presentation instead of the participant video.
>
> Computers can be connected using HDMI/Displayport/DVI/VGA directly to
> the video conferencing endpoint.  Alternatively, there may be a PC
> application that screen-scrapes the display and sends it to the endpoint
> for distribution. These same options are used in telepresence systems.
>
> On the receiving side, there are several options.  Sometimes the content
> is displayed on a separate monitor or projector.  Sometimes the content
> is composed along with participants, and placed on a single display.  In
> telepresence systems, there are frequently content monitors at each
> seat, all of which will display the presentation.
>
> Application sharing was common back in the 90's (using the T.120
> protocol), but fell out of favor for a variety of reasons.

What is it that webex uses for application sharing? AFAIK that is not 
falling out of favor. I would much rather use webex application sharing 
than be forced to plug a video connector into my computer.

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.

	Thanks,
	Paul

> Stephen Botzko
>
>
>
> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I am working on my use cases for the question about how to select
>     which captures to display. But I have a gap in my understanding, and
>     would like to get input from those of you with more experience in a
>     diversity of telepresence systems.
>
>     ones. I'm not aware of it having any explicit support for
>     presentations, though that might just be my lack of understanding.
>
>     I presume that for the most part presentations these days originate
>     in a computer and are fed into the telepresence system, much like
>     they are in webex - either by preloading documents to the conference
>     controller and then interacting with it from a computer to have them
>     displayed, or by "sharing an application" dynamically from a
>     computer. I understand that in a system like webex, which is not a
>     telepresence system. But what does that mean when married to a
>     telepresence system?
>
>     There seems to be a big difference if the presentation is seen as
>     coming from a room that has the typical telepresence layout, or if
>     it is seen coming from a separate endpoint coupled to the computer
>     generating it, and whether the presentation is displayed on
>     equipment that is part of the room, or by a separate endpoint.
>
>     I'd like feedback if any of the above makes sense, and whether there
>     are other ways of looking at this I haven't imagined.
>
>             Thanks,
>             Paul
>     _________________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/clue
>     <https://www.ietf.org/mailman/listinfo/clue>
>
>

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 27 Apr 2012 17:30:36 -0400

On Fri, Apr 27, 2012 at 5:20 PM, Paul Kyzivat <[email-masked]> wrote:
> falling out of favor. I would much rather use webex application sharing than
> be forced to plug a video connector into my computer.
>
> improved over time. Its the UI for driving it that is cumbersome, not the
> output.
>

Since this is true, and since it is very hard to change such behavior,
this raises the question :

Is there a CLUE role for metadata exchange with applications such as
Webex? Or, are
we going to be condemned to running separate asynchronous conferences
for data and telepresence ?

I am not sure of the answer, but I did want to raise the question.

Regards
Marshall

> 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.
>
>        Thanks,
>        Paul
>
>> Stephen Botzko
>>
>>
>>

---

From: "Roni Even" <[email-masked]>
Date: Sat, 28 Apr 2012 11:05:17 +0300

Hi,
Steve in his response mentioned that the there is a data collaboration
standard which is T.120 that was used in the past but is not used today. The
presentation stream is not for collaboration but just presentation and works
well in TP rooms equipped with monitors for the presentation stream.

As for application sharing like WebEx or Meetecho all these solution are
stimulus based and there is no standard for these solutions. Most of the
video conferencing providers have such solution with some integration to the
video conference.
I do not think that Clue should work on this integration since there is no
standard application sharing to integrate with.
There was a proposal to work on application sharing in MMUSIC and AVT couple
of years ago (I think Jonathan had a draft with Henning) based on RTP level.
There was also a later draft
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 but none
of this progressed.

Roni

> Marshall Eubanks
> Sent: Saturday, April 28, 2012 12:31 AM
> To: Paul Kyzivat
> Cc: CLUE
> Subject: Re: [clue] ways of managing presentations in telepresence
> sessions
> 
> >> Most traditional videoconferencing systems support H.239 (with
> >> H.323), using a functionally equivalent method  in SIP.  The
> >> presentation video is assigned a role (e.g., slides), and the
> ability
> >> to send is token-controlled with BFCP.  All endpoints in the
> >> conference receive the presentation.  If there is a legacy device
> >> (which doesn't support
> >> application that screen-scrapes the display and sends it to the
> >> endpoint for distribution. These same options are used in
> telepresence systems.
> >>
> >> On the receiving side, there are several options.  Sometimes the
> >> content is displayed on a separate monitor or projector.  Sometimes
> >> the content is composed along with participants, and placed on a
> >> single display.  In telepresence systems, there are frequently
> >> content monitors at each seat, all of which will display the
> presentation.
> >>
> > falling out of favor. I would much rather use webex application
> > sharing than be forced to plug a video connector into my computer.
> >
> Webex? Or, are we going to be condemned to running separate
> asynchronous conferences for data and telepresence ?
> 
> > 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.
> >
> >        Thanks,
> >        Paul
> >
> >> Stephen Botzko
> >>
> >>
> >>

---

From: Brian Rosen <[email-masked]>
Date: Sat, 28 Apr 2012 09:16:43 -0400

Most of the commercial web share systems download a piece of java that grabs the screen update commands.

I agree that using these services is interesting, but passing control would be nice and aligning rosters would be nice and …

That means some reasonable protocol that webex et. al. could use to do that.

I def wouldn't want to try to do what webex does some other way in an MCU.

Brian

On Apr 27, 2012, at 5:20 PM, Paul Kyzivat wrote:

> What is it that webex uses for application sharing? AFAIK that is not falling out of favor. I would much rather use webex application sharing than be forced to plug a video connector into my computer.
> 
> 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.
> 
> 	Thanks,
> 	Paul
> 
>> Stephen Botzko
>> 
>> 
>>

---

From: Stephen Botzko <[email-masked]>
Date: Sat, 28 Apr 2012 13:18:39 -0400

> than be forced to plug a video connector into my computer.

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

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.

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]

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

>> <mailto:[email-masked]>**> wrote:
>>
>>    ______________________________**___________________
>>    clue mailing list
>>    https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>    <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>> >
>>
>>
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Apr 2012 12:15:24 -0400

My thought was not about the application sharing mechanism details. What 
I was thinking is that the shared application would in some way be 
mapped to a presentation capture.

The point that seems to matter the most is how this appears in the 
telepresence session topology.

The share might show up as a capture from the room where the person 
doing the sharing resides. This implies that there is a connection 
between the computer doing the sharing to the controller for the room. 
And then the room controller will be deciding how to advertise it. E.g. 
it could display it on a screen in its own room and advertise it in the 
room scene with the position of that screen. Or the room controller 
could advertise the share as a presentation capture in a separate scene.

Or the share might show up as a capture from a separate endpoint 
corresponding to the computer doing the sharing. Because this means 
there are at least three endpoints involved, it will require an MCU. And 
then the MCU will need to figure out what to advertise in order to make 
that capture available to all the rooms.

ISTM that either of these approaches could be made to work. But if the 
computer doing the sharing is connecting over the web then it seems much 
more natural to me that it would be to a common point for the session, 
rather than to the room controller.

I don't know how much of this it makes sense to address as  part of 
CLUE, but I don't think we can ignore it entirely.

	Thanks,
	Paul

On 4/28/12 4:05 AM, Roni Even wrote:
>> On Fri, Apr 27, 2012 at 5:20 PM, Paul Kyzivat<[email-masked]>
>> wrote:
>>>>     [email-masked]<mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Apr 2012 12:44:25 -0400

> I def wouldn't want to try to do what webex does some other way in an MCU.

As I just said in another reply, its not clear to me exactly how much we 
need to address in CLUE, but I think its more than none. I certainly 
think we need to leave things relatively open for innovation in user 
interfaces and implementation techniques.

I can see how an evolved webex server could connect to a CLUE MCU. But 
that would be a bit of a hack, since one would then have to configure a 
webex session and a CLUE conference separately. Or there could be a 
hybrid MCU that supports both CLUE and webex. And RTCWEB will presumably 
lead to other options for a computer to do its own sharing by creating a 
video stream from an application window and sending it off to a CLUE 
MCU. And presumably there are many other possibilities.

	Thanks,
	Paul

>>> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat<[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Apr 2012 12:56:52 -0400

On 4/28/12 1:18 PM, Stephen Botzko wrote:

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

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

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

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

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

>     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.
>
>     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.
>
> receiving. The local equipment is always responsible for display.
> Looping the presentation back through the MCU back to the originating
> site wastes bandwidth.
>
> desktop images.  Certainly there is no reason for the server to send
> them back to me.[/sb]

	Thanks,
	Paul

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 30 Apr 2012 13:49:30 -0400

Here is a potential use case :

There is a telepresence session and an associated webex-like computer
sharing session.

At some time, person X has the floor on the computer sharing session
(i.e., they are the presenter).

I want to see person X on screen. (Or, maybe, I am the chair, and I
want every telepresence participant to see
person X on their screen.) I want to see X even if he or she is not
talking  for a bit, so just doing voice switching is not enough.

After a while, person Y starts displaying viewgraphs from their
computer (i.e., they are now the presenter).

I want the presenter screen to switch to showing person Y.

Right now, all of this would be manual and very cumbersome to do, and
yet I think it is an option people would want.

Is publishing an XML scheme for describing this enough ? Could the
telepresence system join the computer sharing session?
Or can the computer sharing session join the telepresence as a
participant, albeit a non-media producing or consuming participant?

Regards
Marshall

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Apr 2012 14:19:49 -0400

Thanks Marshall - this is a good use case. I'm inserting questions inline.

> talking  for a bit, so just doing voice switching is not enough.

Are you talking about the *computer* screen? Or one of the screens in 
the TP room? And are you just talking about displaying the presenter, or 
the presentation as well?

I think its reasonable to expect that some but not all of the 
participants in the room(s) will have a computer connected into the 
webex-like session. Those that don't will still want to see the 
presentation.

I can see how the people with computers could use those as supplemental 
displays, so that they could see more captures than are available in the 
room as a whole. Presumably they wouldn't bother to locally display a 
capture that is already being displayed on a room screen.

	Thanks,
	Paul

> participant, albeit a non-media producing or consuming participant?

I think either of these is *possible*, without any explicit support for 
it. But the coordination to do so could be cumbersome. We need to figure 
out if there is some mechanism we need to specify to make this convenient.

	Thanks,
	Paul

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

---

From: Roni even <[email-masked]>
Date: Mon, 30 Apr 2012 19:09:38 +0000

Paul,
I think that the video conference based on SIP and the application sharing are two separate application with vendor specific API between the two entities. If you can describe the application sharing in SIP / SDP there may be a CLUE integration. in all other cases this is not up to CLUE and I do not think that there is a such standard integration even for a non CLUE SIP endpoint and application sharing
BTW" from the CLUE charter "This working group is not currently chartered to work on issues of
  continuous conference control including: far end camera control, floor
  control, conference roster."

I think we have currently enough work in CLUE without this topic
Roni

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Monday, April 30, 2012 19:15
To: Roni Even
Cc: 'CLUE'
Subject: Re: [clue] ways of managing presentations in telepresence sessions

        Thanks,
        Paul

On 4/28/12 4:05 AM, Roni Even wrote:
>> be

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 30 Apr 2012 15:21:48 -0400

Dear Paul;

On Mon, Apr 30, 2012 at 2:19 PM, Paul Kyzivat <[email-masked]> wrote:
> Are you talking about the *computer* screen? Or one of the screens in the TP
> room? And are you just talking about displaying the presenter, or the
> presentation as well?

No, I was talking about

- video screens display people
- computer screens display someone's desktop (or application or...)

So, this is really about unified floor control. When I give someone
the floor, I want to
see their face on the screen, and their presentation on my laptop.
And, I want to
do this once, not have to fuss with two autonomous systems.

I don't care if I do it through the presentation system or through the
telepresence system*, but the implication to me is that
one has to be the driver, the other driven, and they have to talk to each other.

* My mental image was doing this through the telepresence system but
thinking about it doing it through the presentation system may have
some advantages, for example in authentication.

>
> I think its reasonable to expect that some but not all of the participants
> in the room(s) will have a computer connected into the webex-like session.

Maybe. In lots of IETF meetings (to give one example) being in the
webex session is close to being essential.

> Those that don't will still want to see the presentation.

That's a different but related use case, as is the use case where I am
at the train station, have audio and webex, but
no telepresence. "It would be nice" to have the webex display
something of the telepresence session, assuming I have the bandwidth.

> capture that is already being displayed on a room screen.

This is interesting but not the use case I had in mind.

Regards
Marshall

> I think either of these is *possible*, without any explicit support for it.
> But the coordination to do so could be cumbersome. We need to figure out if
> there is some mechanism we need to specify to make this convenient.
>
>        Thanks,
>        Paul
>
>
>> Regards
>> Marshall
>>
>>> to
>>> seat)

---

From: John Leslie <[email-masked]>
Date: Mon, 30 Apr 2012 16:14:19 -0400

Marshall Eubanks <[email-masked]> wrote:
> the floor, I want to see their face on the screen, and their
> presentation on my laptop. And, I want to do this once, not have to
> fuss with two autonomous systems.

   Whether or not this is in CLUE scope, I endorse Marshall's desire.

   I don't believe the presenation screen should be easily confused with
a telepresence screen; and there are real use-cases where "the" laptop
screen is the right place for it.

--
John Leslie <[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Apr 2012 16:15:48 -0400

I agree with this - you bring your laptop to the room, or there is a desktop in the room for you, and you connect that to the presentation sharing system.  The audio/video is connected to a different system.  The challenge is to interwork these so change in presenter affects both.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Apr 2012 18:01:18 -0400

> I agree with this - you bring your laptop to the room, or there is a desktop in the room for you, and you connect that to the presentation sharing system.  The audio/video is connected to a differe…

I agree with this.

But I also think there needs to be a parity for presentations regardless 
of how they are brought in. There should be the same options for viewing 
a presentation regardless of whether it is captured from a video jack or 
over the web via application sharing. Either way there should be the 
option to show it on one of the screens in the various rooms.

Of course it should also be possible for those participants who are 
connected to the sharing application to view this on their computers. 
And if everybody in a room is viewing the presentation from their own 
computer then the room system need not display it.

This all points to some needs:

- the sharing application to provide the shared info, as a presentation.
   This suggests that it be connected as a CLUE endpoint.

- Some mechanism to identify to the CLUE system who is sourcing a
   presentation stream - which I guess means correlating a presentation
   stream to one or more other captures that contain the presenters.
   This could be hard if the endpoint sending the presentation stream
   is not the system sending the captures of the presenters.

	Thanks,
	Paul

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

---

From: "Roni Even" <[email-masked]>
Date: Tue, 1 May 2012 01:07:37 +0300

Paul,
My suggestion is to start with this integration for any video or audio SIP
conference before going into CLUE.
There is no such solution for this because there is no standard API between
the application sharing and the SIP conference bridge.
This topic can be discussed in DISPATCH
I fail to see why we are discussing it here. This is defiantly not in the
scope since these application sharing are not using RTP, SDP or SIP
Roni

> Sent: Tuesday, May 01, 2012 1:01 AM
> To: Brian Rosen
> Cc: CLUE
> > I agree with this - you bring your laptop to the room, or there is a
> desktop in the room for you, and you connect that to the presentation
> sharing system.  The audio/video is connected to a different system.
> The challenge is to interwork these so change in presenter affects
> both.
> 
> I agree with this.
> 
> But I also think there needs to be a parity for presentations
> regardless of how they are brought in. There should be the same options
> for viewing a presentation regardless of whether it is captured from a
> video jack or over the web via application sharing. Either way there
> should be the option to show it on one of the screens in the various
> rooms.
> 
> >>>> There is a telepresence session and an associated webex-like
> >>>> computer sharing session.
> >>>>
> >>>> At some time, person X has the floor on the computer sharing
> >>>> session (i.e., they are the presenter).
> >>>>
> >>>> want every telepresence participant to see person X on their
> >>>> screen.) I want to see X even if he or she is not talking  for a
> >>>> bit, so just doing voice switching is not enough.
> >>>
> >>>
> >>> Are you talking about the *computer* screen? Or one of the screens
> >>> in the TP room? And are you just talking about displaying the
> >>> presenter, or the presentation as well?
> >>
> >> No, I was talking about
> >>
> >> presentation on my laptop.
> >> And, I want to
> >> I don't care if I do it through the presentation system or through
> >> the telepresence system*, but the implication to me is that one has
> >> to be the driver, the other driven, and they have to talk to each
> other.
> >>
> webex-like session.
> >> That's a different but related use case, as is the use case where I
> >> am at the train station, have audio and webex, but no telepresence.
> >> "It would be nice" to have the webex display something of the
> >> telepresence session, assuming I have the bandwidth.
> >>
> >>>
> >>> I can see how the people with computers could use those as
> >>> supplemental displays, so that they could see more captures than
> are
> >>> available in the room as a whole. Presumably they wouldn't bother
> to
> >>> locally display a capture that is already being displayed on a room
> screen.
> >>
> >>>> Right now, all of this would be manual and very cumbersome to do,
> >>>> and yet I think it is an option people would want.
> >>>>
> >>> But the coordination to do so could be cumbersome. We need to
> figure
> >>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul
> Kyzivat<[email-masked]>
> >>>>   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?
> >>>>>
> >>>>>
> >>>>>> 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?
> >>>>>
> >>>>>
> >>>>>> (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.
> >>>>>
> >>>>>
> >>>>>> 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'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: Mon, 30 Apr 2012 21:27:48 -0400

> scope since these application sharing are not using RTP, SDP or SIP

Roni,

I've been trying to walk a fine line here. I'm not proposing that we 
should discuss application sharing APIs, etc. But we do have 
presentation captures as part of CLUE, and I think we should not assume 
that they always come from sticking hard copy under a presentation 
camera or by plugging a computer into a video connector.

It may be sufficient to acknowledge that computers used by participants 
to provide presentations might connect as independent CLUE endpoints.

I'm trying to understand the rudiments of this to make a realistic use 
case involving presentations.

	Thanks,
	Paul

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 30 Apr 2012 21:57:05 -0700

I agree with Roni, most of this discussion is out of scope. We can leave
it to vendors to figure out how they want to use CLUE. The important
thing is that the CLUE specification allows various types of endpoints -
that it makes sense for different types of endpoints, such as software
only. I believe that it currently does, though more scrutiny is always a
good thing.

This would mean stating rather precisely what Paul feels is missing from
how CLUE handles presentation.

Allyn

> Roni even
> Sent: Monday, April 30, 2012 12:10 PM
> To: Paul Kyzivat; Roni Even
> Cc: 'CLUE'
> I think that the video conference based on SIP and the application
> sharing are two separate application with vendor specific API between
> the two entities. If you can describe the application sharing in SIP /
> SDP there may be a CLUE integration. in all other cases this is not up
> to CLUE and I do not think that there is a such standard integration
> even for a non CLUE SIP endpoint and application sharing
> > video conferencing providers have such solution with some
integration
> to the
> > There was a proposal to work on application sharing in MMUSIC and
AVT
> couple
> > of years ago (I think Jonathan had a draft with Henning) based on
RTP
> level.
> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of
> >>>> Computers can be connected using HDMI/Displayport/DVI/VGA
directly
> for
> >>>>     which captures to display. But I have a gap in my
> understanding,
> >>>> and
> >>>>     would like to get input from those of you with more
experience
> >>>>     So I'd like to hear what *is* supported, or is *intended* to
> be
> >>>>     supported.
> >>>>
> >>>>     controller and then interacting with it from a computer to
> have
> >>>> them
> >>>>     computer. I understand that in a system like webex, which is
> not
> >> a
> >>>>       Each seat has a video connector that the visitor can
connect
> >>>>       endpoint/room. The computer then offers up whatever it
wants
> >>>>       presentations from user's computers as well as captures
from
> >> the
> >>>>       request the floor, to review preloaded documents and
request
> >>>> their
> >>>>     There seems to be a big difference if the presentation is
seen
> as
> >>>>     coming from a room that has the typical telepresence layout,
> or
> >> if
> >>>>     I'd like feedback if any of the above makes sense, and
whether
> >>>> there

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 30 Apr 2012 22:07:03 -0700

Hi -
I agree with Brian's first main point 

> the sharing application to provide the shared info, as a presentation.

I think our job is to make sure the CLUE spec works for different types
of endpoints, rather than invent new telepresence systems that do
presentation in new and interesting ways; nor do I think we should
consider the details of integration that particular proprietary
conferencing system such as webex may or may not want to do. IMO, our
job is to make sure that CLUE is able to allow interoperability and a
reasonable experience to any system that chooses to use it. Does that
make sense? 

> Sent: Monday, April 30, 2012 3:01 PM
> To: Brian Rosen
> Cc: CLUE
> regardless
> >> On Mon, Apr 30, 2012 at 2:19 PM, Paul
> computer
> in the TP
> >> one has to be the driver, the other driven, and they have to talk
to
> each other.
> participants
> am
> supplemental
> >>> room as a whole. Presumably they wouldn't bother to locally
display
> >>> I think either of these is *possible*, without any explicit
support
> for it.
> figure out if
> include a
> data go
> >>>>> the local room controller, or to an MCU in the middle of the TP
> session?
> >>>>> Or
> >>>>> something else?
> >>>>>
> >>>>>
> >>>>>> not saying it has no value, just that the most common case I
see
> is a
> have guest
> room
> some sort
> >>>>> of
> original
> audio)
> with the
> sharing to be
> >>>>>>     A key difference is that if the computer output is via
video
> cable
> receiving

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 30 Apr 2012 22:09:25 -0700

Agree-

Integration is out of scope..

If someone feels there is something missing in CLUE for presentation,
that's in scope.

Thanks,
Allyn

> Roni Even
> Sent: Monday, April 30, 2012 3:08 PM
> To: 'Paul Kyzivat'; 'Brian Rosen'
> Cc: 'CLUE'
> > >>> Thanks Marshall - this is a good use case. I'm inserting
> questions
> > inline.
> > >>>
> > >>>
> > >>>> I want to see person X on screen. (Or, maybe, I am the chair,
> and
> > I
> > >>>>>> specifically to vendor support for standards-based
application
> > >>>>>>     Of course that is still somewhat cumbersome, but
> presumably
> > it will
> > >>>>>>     for displaying it locally on a display in the room as
well
> > >>>>>>     directly to the MCU, then the capture will come to the
> room
> > just
> > >>>>>> I don't know if web conferencing solutions do this
differently
> > or not.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 1 May 2012 08:13:08 +0300

Hi Paul,
I suggest you start by describing the use case explaining the integration
between the application sharing application and the video conference
infrastructure.
Still since this is not defined even for regular SIP conference I am not
sure why we are discussing non-standard integration here.
All you can say that there may be application sharing and that the
application sharing application may need to interact with the CLUE
environment.

As for he use case, you can start by explaining how when someone gets the
presentation token he become the presenter in the video conference. My
assumption is that this is done by the external API to the MCU.
Roni

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2012 4:28 AM
> To: Roni Even
> Cc: 'Brian Rosen'; 'CLUE'
> > My suggestion is to start with this integration for any video or
> audio
> > SIP conference before going into CLUE.
> > There is no such solution for this because there is no standard API
> > between the application sharing and the SIP conference bridge.
> > This topic can be discussed in DISPATCH I fail to see why we are
> > discussing it here. This is defiantly not in the scope since these
> > application sharing are not using RTP, SDP or SIP Roni
> 
> Roni,
> 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Paul Kyzivat
> >> regardless of how they are brought in. There should be the same
> >> options for viewing a presentation regardless of whether it is
> >> captured from a video jack or over the web via application sharing.
> >> Either way there should be the option to show it on one of the
> >> screens in the various rooms.
> >>
> >>>> * My mental image was doing this through the telepresence system
> >>>> but thinking about it doing it through the presentation system may
> >>>> have some advantages, for example in authentication.
> >>>>
> >>>>>
> >>>>>> Is publishing an XML scheme for describing this enough ? Could
> >>>>>> the telepresence system join the computer sharing session?
> >>>>>>>> that feature is not used as much as simple presenting.  I am
> >>>>>>>> see is
> >>>>>>> room controller. If there are multiple cable connectors (e.g.
> >>>>>>> one at each
> >>>>>>> seat)
> >>>>>>>> token-controlled transmission.  If you don't have the token,
> >>>>>>>> you are receiving. The local equipment is always responsible
> >>>>>>>> for
> >> display.