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

["Allyn Romanow (allyn)" <[e-mail]>]

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:[e-mail]]
> Sent: Saturday, December 11, 2010 1:36 PM
> To: [e-mail] 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
> 
>