Subject: Re: [maitai] draft-romanow-dispatch-telepresence-use-cases-01

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 13 Dec 2010 15:43:28 -0800

Hi Peter, 

Indeed, the use cases are not complete. I'm trying to find time to
propose a couple of additional cases. The thing about it is whether the
different use cases would cause us to need to describe more or
differently in order to be interoperable.

> -----Original Message-----
> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Saturday, December 11, 2010 1:36 PM
> To: [email-masked] list; Allyn Romanow (allyn)
> Subject: Re: draft-romanow-dispatch-telepresence-use-cases-01
> 
> Hi Allyn,
> 
> I was re-reading this and thought of a couple of additions I think
> might be useful.
> 
> In section 4.2 - asymmetric, the discussion focuses on 3d3c (three
> display, 3 camera) to 1d1c.
> 
> I think that it would be useful to consider 3p3c to 2p2c - since this
> brings up some interesting decisions which do not occur otherwise.
> e.g If room 1 had cameras A, B, C (l to r) and room 2 has displays D
> and E (l to r) there are now issues about maintaining gaze angle in
the
> views from room A when rendering on D and E which do not occur in the
> 3d3c-1d1c example...
> 
[AR]  I'm not sure what "3p3c" and "2p2c" means, but I assume it's a
typo and you meant 3displays 3 cameras to 2 displays 2 cameras? If you
feel that there are dynamics that are involved going from 3 to 3 that
would not be in play going between 3 and 1, then please, by all means
write them up. If the differences would impact what needs to be
described between different systems, then it's worth adding.

> Also, in the section 4.3 about multipoint, there are alternatives to a
> classic, central MCU:
> 1) An endpoint may elect to act as an MCU and allow a 2-party call to
> grow to include a third party. In this case the mixing point has it's
> own content it wishes to inject/select. (We may decide this is best
> though of as an independent MCU - although it may have impact on the
> signalling if a call which started as a point-to-point suddenly
becomes
> point-to-MCU).
How does this effect what info needs to be passed?
> 
> 2) Three endpoints may elect to make a mesh of calls (each calls the
> other) - so each endpoint maintains two active calls and no MCU is
> present.
> 
Okay, again, we need to make sure that necessary info is passed. I'm not
sure how these architectural difference impact that.

Best,
Allyn
> Regards,
> Peter Musgrave

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 13 Dec 2010 20:29:56 -0500

Inline...

Peter

> described between different systems, then it's worth adding.

Sorry, 3d3c (I use panel and display interchangeably). 

The issue I am trying to encompass is that when a room with cameras (L to R, facing displays) A B C is rendered on two displays the sensible choices are CB, BA and (maybe) CA (again L to R facing displays in receiving room) so that when the people on camera C turn towards the others in the room the gaze angles are maintained on the far end displays and they turn towards the image of the people provided by camera B.

I agree this is not necessarily impacting how the physical setup of the rooms is conveyed, but does affect decisions made about what to render where. This specific decision does not arise in the examples of 3 to 1 and 3 to 3 in the existing doc. 

> How does this effect what info needs to be passed?
I think it raises an issue about the fact that what may start as a description of endpoint (which is describing only it's cameras as a video source) then changes when that endpoint choses to act as an MCU. It either needs to change it's description mid-call - or find some way of conveying the additional video it has from the third endpoint within the stream it has already described. (In some cases it may elect to send both it's camera and the video from the third endpoint - so it will in effect have an additional "camera")

This starts to become word soup...I will try and make some pictures and see if I can express the idea better in that form.