Subject: [clue] Comments on use cases

From: <[email-masked]>
Date: Wed, 23 Mar 2011 17:10:50 +0000

Hi,

After review of draft-romanow-clue-telepresence-use-cases-01.txt, below are some comments about use cases that we may want to consider, and about some needed clarifications.

1. Ad-hoc multi-stream telepresence room use case

We may want to define a use case where a multi-stream telepresence room is dynamically constituted of multiple mono-stream endpoints. The telepresence room becomes an ad-hoc multi-stream telepresence room because we rely on endpoints that have been dynamically associated to provide the multi-stream experience.
A good example is a multi-stream telepresence room constituted of several handheld telepresence devices (all being mono-stream by nature).
	
NOTE: The terms "room" and "endpoint" are considered as interchangeable in draft-romanow-clue-telepresence-requirements-01.txt. This point changes this definition, since a room could be constituted of multiple endpoints.

2. "1 to n" multipoint conference use case
Basically, the sections 4.1 and 4.2 of draft-romanow-clue-telepresence-use-cases-01.txt correspond to a "1 to 1" meeting. The section 4.3 corresponds to a "n" meeting. We may want to add the "1 to n" use case.
Examples of such use case could be remote training, university course, business meeting like "director's speech to employees", etc...
Finally, this new use is a generic version of the section 4.6, which is a (very sophisticated) sample of "1 to n" meeting. 

We can consider the following characteristics for this use case (not exhaustive):
* Distinction between main site (the main speaker) and remote sites (the participants)
* Multi-stream usage, more or less for the same principles as the ones describe in 4.6: remote sites always see the main site, remote sites and main site see a participant asking a question, etc.
* A remote site can ask for the word. The main site will see which site requests to take floor, and can choose to give the floor to a site. In other terms, this use case clarifies the need for a main site to control layout and received streams on the remote sites, in a more general manner than the sample of the section 4.6.
* Conference topology discovery (who is in the conference, and configuration/capability of each site), which could be displayed on the main site to help the user to make audio/video selection (user choice).

3. Collaboration

This draft seems to restrict the collaboration (or presentation) to the usage of video as the only mean of sharing information. Why shall it be restricted here?

In the context of telepresence where the target is (among others) the high quality of the experience, the solution of video for data collaboration is not the best, especially for technical document sharing. Using video lowers quality, requires bandwidth and does not allow participants to take control of the document in turns.

We should consider the video as one mean. And take into account the necessity of high quality experience to consider integrating and/or defining other means?

4. Heterogeneous systems

The section 4.5 about heterogeneous systems is confusing. In particular the sentence "We are not here talking about legacy systems, but rather systems built to participate in such a conference, although they are single stream only", which seems to exclude support for legacy systems?
It shall be clarified what "heterogeneous systems" means.

Can heterogeneous systems be defined as being constituted of:
* Endpoints with different configurations: not the same number of screens, cameras, microphones, loudspeaker
* Endpoints with different capabilities: not the same configuration + not the same available bandwidth, screen size, endpoint size, access network, CPU power, etc.
* Legacy (aka. traditional) endpoints: non-standard endpoints (as stated in the charter) are excluded from this category.

This remark is also valid to draft-romanow-clue-telepresence-requirements-01.txt which talks of heterogeneous systems without defining them clearly.

Regards,
Stephane Cazeaux

--
Stéphane Cazeaux
Orange Labs
+33 2 31 75 95 40
[email-masked]

---

From: "Roni Even" <[email-masked]>
Date: Wed, 23 Mar 2011 20:29:34 +0200

Hi,
See my comments inline
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sent: Wednesday, March 23, 2011 7:11 PM
> To: [email-masked]
> Subject: [clue] Comments on use cases
> 
> Hi,
> 
> After review of draft-romanow-clue-telepresence-use-cases-01.txt, below
> are some comments about use cases that we may want to consider, and
> about some needed clarifications.
> 
> We may want to define a use case where a multi-stream telepresence room
> is dynamically constituted of multiple mono-stream endpoints. The
> telepresence room becomes an ad-hoc multi-stream telepresence room
> because we rely on endpoints that have been dynamically associated to
> provide the multi-stream experience.
> A good example is a multi-stream telepresence room constituted of
> several handheld telepresence devices (all being mono-stream by
> nature).
> 
> NOTE: The terms "room" and "endpoint" are considered as interchangeable
> in draft-romanow-clue-telepresence-requirements-01.txt. This point
> changes this definition, since a room could be constituted of multiple
> endpoints.
I understand that this case involve multiple call set up and some need for
co-relation between the multiple end points which do not have a central
management entity. I am not sure that this use case is in the scope. I can
understand one endpoint making multiple calls but not this case. 

> Basically, the sections 4.1 and 4.2 of draft-romanow-clue-telepresence-
> use-cases-01.txt correspond to a "1 to 1" meeting. The section 4.3
> corresponds to a "n" meeting. We may want to add the "1 to n" use case.
> Examples of such use case could be remote training, university course,
> business meeting like "director's speech to employees", etc...
> Finally, this new use is a generic version of the section 4.6, which is
> a (very sophisticated) sample of "1 to n" meeting.
> 
> * Multi-stream usage, more or less for the same principles as the ones
> describe in 4.6: remote sites always see the main site, remote sites
> and main site see a participant asking a question, etc.
> * A remote site can ask for the word. The main site will see which site
> requests to take floor, and can choose to give the floor to a site. In
> other terms, this use case clarifies the need for a main site to
> control layout and received streams on the remote sites, in a more
> general manner than the sample of the section 4.6.
> * Conference topology discovery (who is in the conference, and
> configuration/capability of each site), which could be displayed on the
> main site to help the user to make audio/video selection (user choice).

I think that is a subset of multipoint which is application driven. What is
known as "lecture mode". The addition is the floor control that is part of
the conference. The participant switching is application driven.
> 
> 
> 3. Collaboration
> 
> This draft seems to restrict the collaboration (or presentation) to the
> usage of video as the only mean of sharing information. Why shall it be
> restricted here?
> 
> In the context of telepresence where the target is (among others) the
> high quality of the experience, the solution of video for data
> collaboration is not the best, especially for technical document
> sharing. Using video lowers quality, requires bandwidth and does not
> allow participants to take control of the document in turns.
> 
> We should consider the video as one mean. And take into account the
> necessity of high quality experience to consider integrating and/or
> defining other means?

Data collaboration is important but can suggest a standard data
collaboration protocol.

> 
> 
> 4. Heterogeneous systems
> 
> The section 4.5 about heterogeneous systems is confusing. In particular
> the sentence "We are not here talking about legacy systems, but rather
> systems built to participate in such a conference, although they are
> single stream only", which seems to exclude support for legacy systems?
> * Endpoints with different configurations: not the same number of
> screens, cameras, microphones, loudspeaker
> * Endpoints with different capabilities: not the same configuration +
> not the same available bandwidth, screen size, endpoint size, access
> network, CPU power, etc.
> * Legacy (aka. traditional) endpoints: non-standard endpoints (as
> stated in the charter) are excluded from this category.
> 
> This remark is also valid to draft-romanow-clue-telepresence-
> requirements-01.txt which talks of heterogeneous systems without
> defining them clearly.
> 
> 
> 
> Regards,
> Stephane Cazeaux
> 
> 
> --
> Stéphane Cazeaux
> Orange Labs
> +33 2 31 75 95 40
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Aravind Sethuraman <[email-masked]>
Date: Thu, 24 Mar 2011 22:12:38 -0400

hello all,
1.can we not define endpoint or a room to be the entity that comprises of spatially related end points but at a given time will participate in a single telepresence call? (conference/conversation etc). I doubt there will be a case where say a 3 screen room, 2 screens will be in a separate telepresence call and the presentation will be in another telepresence call. And it is important to delineate between a telepresence call WITH setting up SIP session, ie, in a single telepresence call , there could be N SIP sessionbs established. Therefore, a room and endpoint,imho, should not be thought of as different but a room is a type of endpoint.

2. I do not know why should there be a necessary of classifying a main speaker. It can be a type of call in which certain endpoints are only in send only mode and others are in receive only mode (along with the 3rd mode, Send and Receive). As Roni correctly said, it is a subset of application driven multipoint.

my 2 cents...

Aravind Sethuraman
Chief Software Architect
Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM aravindsraman