Subject: [clue] Definitions

From: Stephan Wenger <[email-masked]>
Date: Fri, 13 May 2011 11:07:54 -0700

Hi folks,
Here a VERY rough initial draft.  Addressing typos, sorting to alphabetical,
and other cleanup tasks will have to wait for the my return to the office
next week.  I will submit officially only after the most embarrassing bugs
are sorted out.  No need to comment on typos, but if you have substantial
issues then send them now, and I can address them immediately.
Stephan

---

From: Roni Even <[email-masked]>
Date: Sun, 15 May 2011 09:52:48 +0300

Hi Stephan,

I am missing the "left" "right" definition. 

I also think that it will be good to state that the definitions are from the
viewpoint of the local user, this will mean that we have to say what is a
local user.

Regards

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephan Wenger
Sent: Friday, May 13, 2011 9:08 PM
To: CLUE
Subject: [clue] Definitions

Hi folks,

Stephan

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 15 May 2011 18:34:29 -0700

Hi Stephan,

This is a great start. I do not know if you volunteered to update as
well as provide the initial version of this document. In any case, here
are some comments.

> Endpoint - The logical point of final termination through
> receiving, decoding and rendering, and/or initiation through
> capturing, encoding, and sending of media streams.  An endpoint
> consists of one or more physical devices which source and sink
> media streams.  In contrast to an endpoint, a middle box, such
> as an MCU, may also send and receive media streams, but it is
> not the initiator nor the final terminator.

I am not sure we should differentiate between endpoint and MCU. The
distinction blurs in that an MCU generates and send media streams that
are not necessarily equivalent to those it received, and it receives
input from other endpoints. I think trying to distinguish them simply
makes more work and add complexity. I also think we will find that the
majority of "MCUs" are really more "endpoints" than "MCUs". 
You introduced the concept of remote. I am proposing remote == endpoint
and remove MCU.

> Media - Any data that, after suitable encoding, can be conveyed
> over RTP, including audio, video or timed text.

I think this is too general, but I am not able to suggest a good way to
improve it.

> Session - RTP session.  An association among a set of
> participants communicating with RTP.  The distinguishing feature
> of an RTP session is that each maintains a full, separate space
> of SSRC identifiers.  [RFC3550]

In this case, do we also need a term for the collection of RTP sessions
the contains the complete set media exchanged between two endpoints? 

"Layouts" vs. "Spatial Relations", what is the difference?

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephan Wenger
> Sent: Friday, May 13, 2011 11:08 AM
> To: CLUE
> Here a VERY rough initial draft.  Addressing typos, sorting to
alphabetical, and other cleanup tasks
> will have to wait for the my return to the office next week.  I will
submit officially only after the
> most embarrassing bugs are sorted out.  No need to comment on typos,
but if you have substantial

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 17 May 2011 06:17:27 +0200

Hi Charles,
Please see inline.
In summary, I'm not convinced there is need for a change, though there may
be need for more explanatory text.
Stephan

>You introduced the concept of remote. I am proposing remote == endpoint

Not sure here.
What "endpoint" attempts to express is that it is the logical entity
facing the user--the room including microphones loudspeakers, screens,
cameras, and some technical stuff that sends and receives RTP streams and
implements signaling.  We need such a definition certainly in the
requirement spec but also in the use cases.  There is also a "local"
endpoint, which prohibits the use of "remote".
I think we should leave this definition alone.

>I think this is too general, but I am not able to suggest a good way to

Again, not sure why this is too general.

>the contains the complete set media exchanged between two endpoints?

Perhaps, though I don't think we have seen that need yet.
Pm the media plane, there is really no such thing as "bundling" of media
transmission channels.  There is a logical connection between multiple
sessions, but only in the signaling.

>"Layouts" vs. "Spatial Relations", what is the difference?

A Layout is the aggregation of all spatial relations of all
capture/renderer devices at a given point in time?
"Left speaker is left from right speaker" is a spatial relation.
"Left microphone is co-located with left camera" is a spatial relation.
"Audio channel 1 is left, audio channel 2 is right, and there is only one
center camera" is a layout.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2011 08:20:32 +0200

Hi,
 
Regarding "Session - RTP session". I think we need to be explicit when we talk about sessions, because we are also most likely going to talk about SIP sessions.

Regards,

Christer

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephan Wenger
	Sent: 13. toukokuuta 2011 21:08
	To: CLUE
	Subject: [clue] Definitions

	Hi folks,
	Here a VERY rough initial draft.  Addressing typos, sorting to alphabetical, and other cleanup tasks will have to wait for the my return to the office next week.  I will submit officially only after the most embarrassing bugs are sorted out.  No need to comment on typos, but if you have substantial issues then send them now, and I can address them immediately.
	Stephan

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Wed, 18 May 2011 10:40:19 +0200

I think we should keep both endpoints and MCUs in the definition
document. 

One difference between endpoints and MCUs are how they handle media. An
endpoint usually send media representing itself and MCUs send media on
behalf of others remote endpoint connected. 

Cheers 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephan Wenger
Sent: 17. mai 2011 06:17
To: Charles Eckel (eckelcu); CLUE
Subject: Re: [clue] Definitions

Hi Charles,
Please see inline.
In summary, I'm not convinced there is need for a change, though there
may
be need for more explanatory text.
Stephan

Not sure here.
cameras, and some technical stuff that sends and receives RTP streams
and

"Audio channel 1 is left, audio channel 2 is right, and there is only
one

>> issues then send them now, and I can address them immediately.

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

---

From: <[email-masked]>
Date: Wed, 18 May 2011 10:46:35 +0000

I don't think that we want to limit the "endpoint" definition to entities facing a user. We could have entities not facing a user (e.g. an automata), but which are sending/receiving media, and which need to understand characteristics of the remote, and could maybe have also some characteristics. I don't think we want to exclude such cases.

Relying on the "participant" definition of RFC4353, a telepresence conference will be composed of "participants", where a participant is connected to the conference through an "endpoint". In telepresence, the participant will have to be aware of the endpoint, in particular when the participant needs to inform the remote of the characteristics of its endpoint.

Thus my proposition is to clarify that "endpoint" defines the entity through which a participant (we do not limit to entity facing a user) is connected to a telepresence conference.

In the same manner, we could also use the "mixer" word instead of "MCU".

Most of requirements should then apply on the participant or mixer (typically, a participant will describe characteristics of its endpoint).

Regards,
Stephane.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Espen Berger (espeberg)
Envoyé : mercredi 18 mai 2011 10:40
À : Stephan Wenger; Charles Eckel (eckelcu); CLUE
Objet : Re: [clue] Definitions

Cheers 

-Espen 

-----Original Message-----

Hi Charles,
Please see inline.

Not sure here.

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 18 May 2011 07:59:57 +0200

Hi Stephane,
Very good point.

Quoting from RFC 4353

[...]   
        Participant: The software element that connects a user or automata
to
        a conference.  It implements, at a minimum, a SIP user agent, but
        may also implement non-SIP-specific mechanisms for additional
        functionality.
[...]

My understanding of "endpoint" is that an endpoint encompasses ALL
equipment in a telepresence room.  I believe that there are cases where we
can have multiple SIP user agents (Uas) in one room.  Think of a bunch of
codec boxes in a rack, all having their own UA.  Is this the common
understanding of the group?

To ask the question differently, do we have an agreement that there is a
single SIP UA in one room?

Guidance, please.

Thanks,
Stephan

On 5.18.2011 12:46 , "[email-masked]"
<[email-masked]> wrote:

>I don't think that we want to limit the "endpoint" definition to entities
>facing a user. We could have entities not facing a user (e.g. an
>automata), but which are sending/receiving media, and which need to
>understand characteristics of the remote, and could maybe have also some
>characteristics. I don't think we want to exclude such cases.
>
>Relying on the "participant" definition of RFC4353, a telepresence
>conference will be composed of "participants", where a participant is
>connected to the conference through an "endpoint". In telepresence, the
>participant will have to be aware of the endpoint, in particular when the
>participant needs to inform the remote of the characteristics of its
>endpoint.
>
>Thus my proposition is to clarify that "endpoint" defines the entity
>through which a participant (we do not limit to entity facing a user) is
>connected to a telepresence conference.
>
>Most of requirements should then apply on the participant or mixer
>(typically, a participant will describe characteristics of its endpoint).
>
>
>Regards,
>Stephane.
>
>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 18 May 2011 08:00:44 +0200

Agreed.  Will remove "session" definition, and rely on documents
copy-pasting from the definitions to make this important distinction.
Stephan

On 5.18.2011 08:20 , "Christer Holmberg" <[email-masked]>
wrote:

>Hi,
> 
>Regarding "Session - RTP session". I think we need to be explicit when we
>talk about sessions, because we are also most likely going to talk about
>SIP sessions.
>
>Regards,
>
>Christer
>
>
>alphabetical, and other cleanup tasks will have to wait for the my return
>to the office next week.  I will submit officially only after the most
>embarrassing bugs are sorted out.  No need to comment on typos, but if
>you have substantial issues then send them now, and I can address them
>immediately.
>	Stephan
>
>

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 18 May 2011 11:16:36 -0400

In-line -
Stephen Botzko

On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger <[email-masked]> wrote:

> Although these are all examples of spatial relations, I think we need to be
very careful to distinguish microphones and audio channels (and cameras
/video channels).  Lots of audio systems use microphone arrays and beam
forming to get pickup in various parts of the room, and in principle you
could use similar techniques for video.

So in practice, I think it is essential that we describe relationships of
streams, and not capture/render devices.

Also, do we mean the "left camera" is physically located on the left, or
that it shows participants on the left?  I think the latter is the intent,
and that it needs to be clear.  Another reason perhaps to avoid talking
about camera placement.

---

From: "Gorzynski, Mark E (The Right One)" <[email-masked]>
Date: Wed, 18 May 2011 16:00:37 +0000

*        Agree with the point (Botzko) that "spatial relations" should refer to streams not devices.

*        Also agree with the point (stated in several places) that left-right should be clear and be defined with respect to a user facing the displays.  This will of course require being careful about maintaining this convention when a stream is received.  At a sender, a stream may be thus defined as from the right-most display.  But when it is received and rendered on a display, that final destination will use the receiver's point of view.  Thus a stream at Sender A may be labeled A-Right and then sent to receiver B for output to display B-Left.  I would not re-label the stream from A to match the receiver convention.  Thus streams might be labeled with respect to the sender convention.

*        We also should be careful when considering spatial relationships to not make the system specific to odd or even numbers of streams in a spatial relationship.  Using left-right or
-2,-1,0,1,2 or such things may assume a centered system where one stream is on a center axis or that there is a clear sense of when "right" begins.  This is not always true.  For example a system with an even number of displays and a camera above each display.  Thus it may be most efficient to use the sense of "left" to create a beginning of a spatial relationship and order streams from that beginning, 0,1,2,...  Thus we may label a stream from the right-most display of a sender A as coming from A.2  If that stream is sent to a receiver for output on a left most display, that left most display destination may be B.0.

Regards
Mark Gorzynski

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Botzko
Sent: Wednesday, May 18, 2011 8:17 AM
To: Stephan Wenger
Cc: CLUE
Subject: Re: [clue] Definitions

In-line -
Stephen Botzko
On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger <[email-masked]<mailto:[email-masked]>> wrote:
Hi Charles,
Please see inline.
In summary, I'm not convinced there is need for a change, though there may
be need for more explanatory text.
Stephan

Not sure here.

Although these are all examples of spatial relations, I think we need to be very careful to distinguish microphones and audio channels (and cameras /video channels).  Lots of audio systems use microphone arrays and beam forming to get pickup in various parts of the room, and in principle you could use similar techniques for video.

So in practice, I think it is essential that we describe relationships of streams, and not capture/render devices.

Also, do we mean the "left camera" is physically located on the left, or that it shows participants on the left?  I think the latter is the intent, and that it needs to be clear.  Another reason perhaps to avoid talking about camera placement.

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>Of Stephan Wenger

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

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 18 May 2011 09:06:08 +0200

Inline.
Stephan

From:  "Gorzynski, Mark E (The Right One)" <[email-masked]>
Date:  Wed, 18 May 2011 16:00:37 +0000
To:  CLUE <[email-masked]>
Subject:  Re: [clue] Definitions

·        Agree with the point (Botzko) that ³spatial relations² should refer
to streams not devices.

Got it.  

·        Also agree with the point (stated in several places) that
left-right should be clear and be defined with respect to a user facing the
displays.  This will of course require being careful about maintaining this
convention when a stream is received.  At a sender, a stream may be thus
defined as from the right-most display.  But when it is received and
rendered on a display, that final destination will use the receiver¹s point
of view.  Thus a stream at Sender A may be labeled A-Right and then sent to
receiver B for output to display B-Left.  I would not re-label the stream
from A to match the receiver convention.  Thus streams might be labeled with
respect to the sender convention.

Got it.  Had already private conversation with Roni on the same point, with
a similar solution.  Will word-smith accordingly.

·        We also should be careful when considering spatial relationships to
not make the system specific to odd or even numbers of streams in a spatial
relationship.  Using left-right or
-2,-1,0,1,2 or such things may assume a centered system where one stream is
on a center axis or that there is a clear sense of when ³right² begins.
This is not always true.  For example a system with an even number of
displays and a camera above each display.  Thus it may be most efficient to
use the sense of ³left² to create a beginning of a spatial relationship and
order streams from that beginning, 0,1,2,Š  Thus we may label a stream from
the right-most display of a sender A as coming from A.2  If that stream is
sent to a receiver for output on a left most display, that left most display
destination may be B.0.

Agreed, but I don't think this is a "definitions" thing.  It's more a
convention that may best live in a protocol spec.  Right?

Regards
Mark Gorzynski

 
In-line - 
Stephen Botzko

Not sure here.

 
>>> >> issues then send them now, and I can address them immediately.
 
_______________________________________________ clue mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/clue

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 18 May 2011 12:06:52 -0400

I note we have at least one use case where users in the same room are facing
in different directions.

Stephen Botzko

On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) <
[email-masked]> wrote:

> ·        Agree with the point (Botzko) that “spatial relations” should
> refer to streams not devices.
>
>
>
> rendered on a display, that final destination will use the receiver’s point
> ·        We also should be careful when considering spatial relationships
> to not make the system specific to odd or even numbers of streams in a
> spatial relationship.  Using left-right or
> on a center axis or that there is a clear sense of when “right” begins.
> use the sense of “left” to create a beginning of a spatial relationship and
> order streams from that beginning, 0,1,2,…  Thus we may label a stream from
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Stephen Botzko
> *Sent:* Wednesday, May 18, 2011 8:17 AM
> *To:* Stephan Wenger
> *Cc:* CLUE
> *Subject:* Re: [clue] Definitions
>
>
>
> In-line -
> Stephen Botzko
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 18 May 2011 10:26:41 -0700

Stephan,

My understanding is an endpoint has a single SIP UA.  And there would be only one endpoint in a room.

Mark

> Sent: Wednesday, May 18, 2011 2:00 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
>         Participant: The software element that connects a user or automata to
> >De : [email-masked] [mailto:[email-masked]] De la part
> de
> >Espen Berger (espeberg)
> Of

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2011 13:31:45 -0400

Regarding left/right/...,

Is "theater in the round" out of scope?
If not, then left and right get dicy.

	Thanks,
	Paul

On 5/18/2011 12:00 PM, Gorzynski, Mark E (The Right One) wrote:
> ·Agree with the point (Botzko) that “spatial relations” should refer to
> streams not devices.
>
> ·Also agree with the point (stated in several places) that left-right
> should be clear and be defined with respect to a user facing the
> displays. This will of course require being careful about maintaining
> this convention when a stream is received. At a sender, a stream may be
> thus defined as from the right-most display. But when it is received and
> rendered on a display, that final destination will use the receiver’s
> point of view. Thus a stream at Sender A may be labeled A-Right and then
> sent to receiver B for output to display B-Left. I would not re-label
> the stream from A to match the receiver convention. Thus streams might
> be labeled with respect to the sender convention.
>
> ·We also should be careful when considering spatial relationships to not
> make the system specific to odd or even numbers of streams in a spatial
> -2,-1,0,1,2 or such things may assume a centered system where one stream
> is on a center axis or that there is a clear sense of when “right”
> begins. This is not always true. For example a system with an even
> number of displays and a camera above each display. Thus it may be most
> efficient to use the sense of “left” to create a beginning of a spatial
> relationship and order streams from that beginning, 0,1,2,… Thus we may
> label a stream from the right-most display of a sender A as coming from
> A.2 If that stream is sent to a receiver for output on a left most
> display, that left most display destination may be B.0.
>
> Regards
>
> Mark Gorzynski
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Stephen Botzko
> Although these are all examples of spatial relations, I think we need to
> be very careful to distinguish microphones and audio channels (and
> cameras /video channels). Lots of audio systems use microphone arrays
> and beam forming to get pickup in various parts of the room, and in
> principle you could use similar techniques for video.
>
> So in practice, I think it is essential that we describe relationships
> of streams, and not capture/render devices.
>
> that it shows participants on the left? I think the latter is the
> intent, and that it needs to be clear. Another reason perhaps to avoid
> talking about camera placement.
>
>      >
>      >Cheers,
>      >Charles
>      >
>      >
>      >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On Behalf
>      >Of Stephan Wenger
>     [email-masked] <mailto:[email-masked]>

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 18 May 2011 13:34:01 -0400

That is my understanding also.

BTW, there are some interesting interoperability issues that arise if you
change the single UA assumption, due to the left/right reversal.  If you use
multiple devices in the room, you can either wire the left camera and the
left display to the same codec, *or* you can wire the left camera and the
right display to the same codec.  Both designs work, but they are not
interoperable with each other.

Stephen Botzko

On Wed, May 18, 2011 at 1:26 PM, Duckworth, Mark <[email-masked]

---

From: "Gorzynski, Mark E (The Right One)" <[email-masked]>
Date: Wed, 18 May 2011 18:10:44 +0000

Regarding complex environments where users are seated in multiple directions or in the round, can we consider the convention direction as relative to facing a media system like a display?  Is there at least a clock-wise sense to media acquisition and reproduction where there as a counter-clockwise most element and that is first (left most)?  This is still pushing the concept of a single-dimension to order.

>From a stream generation point of view, there may indeed be media streams with no logical order / spatial relation relative to other streams generated by the same endpoint.  Can we support both ordered / spatially related and unordered  un-spatially related streams from end points?  Do we need a higher dimensional (greater than 1 dimension) means of specifying order?

Mark Gorzynski

From: Stephen Botzko [mailto:[email-masked]]
Sent: Wednesday, May 18, 2011 9:07 AM
To: Gorzynski, Mark E (The Right One)
Cc: CLUE
Subject: Re: [clue] Definitions

I note we have at least one use case where users in the same room are facing in different directions.

Stephen Botzko
On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) <[email-masked]<mailto:[email-masked]>> wrote:

Regards
Mark Gorzynski

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stephen Botzko
Sent: Wednesday, May 18, 2011 8:17 AM
To: Stephan Wenger
Cc: CLUE
Subject: Re: [clue] Definitions

In-line -
Stephen Botzko

Not sure here.

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 18 May 2011 14:32:21 -0400

I am wondering if the correct way to think about this is that the spatial
relationships identify the proper rendering.  That is, the left stream is
intended to appear to the immediate left of the center stream. That would be
similar to your suggestion (though the "display" word isn't explicit).

Alternatively, we could use the "stage left" theatrical convention (treating
the displays as the stage).  That defines the streams from the perspective
of the sender. The left stream appears on the audience's right, but is
sourced from the left side of the sending system.  That has the benefit of
being a well established term.

The educational use case (which is one where the professor and the class are
facing each other in the same room) is essentially un-ordered as written.
Though it could be made partially ordered, by having multiple video streams
cover the local classroom and also substituting a panel discussion for the
professor.

Stephen Botzko.

On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) <
[email-masked]> wrote:

> Regarding complex environments where users are seated in multiple
> directions or in the round, can we consider the convention direction as
> relative to facing a media system like a display?  Is there at least a
> clock-wise sense to media acquisition and reproduction where there as a
> counter-clockwise most element and that is first (left most)?  This is still
> pushing the concept of a single-dimension to order.
>
>
>
> From a stream generation point of view, there may indeed be media streams
> with no logical order / spatial relation relative to other streams generated
> by the same endpoint.  Can we support both ordered / spatially related and
> unordered  un-spatially related streams from end points?  Do we need a
> higher dimensional (greater than 1 dimension) means of specifying order?
>
>
>
> Mark Gorzynski
>
>
>
> *From:* Stephen Botzko [mailto:[email-masked]]
> *Sent:* Wednesday, May 18, 2011 9:07 AM
> *To:* Gorzynski, Mark E (The Right One)
>
> *Cc:* CLUE

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 18 May 2011 12:19:54 +0200

Of these alternatives, I'm in favor of "stage left".  I don't like a
protocol expressing something (like a "to be rendered left" property) over
which the protocol has no control.
Let me also forget to ignore the edu use case for now.  We are talking about
definitions to be used throughout a set of documents.  If one of the
definitions happens to be inapplicable, the spec can always phrase around.
Stephan

From:  Stephen Botzko <[email-masked]>
Date:  Wed, 18 May 2011 14:32:21 -0400
To:  "Gorzynski, Mark E (The Right One)" <[email-masked]>
Cc:  CLUE <[email-masked]>
Subject:  Re: [clue] Definitions

Stephen Botzko.

On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One)
<[email-masked]> wrote:
> Regarding complex environments where users are seated in multiple directions
> or in the round, can we consider the convention direction as relative to
> facing a media system like a display?  Is there at least a clock-wise sense to
> media acquisition and reproduction where there as a counter-clockwise most
> element and that is first (left most)?  This is still pushing the concept of a
> single-dimension to order.
>  
> From a stream generation point of view, there may indeed be media streams with
> no logical order / spatial relation relative to other streams generated by the
> same endpoint.  Can we support both ordered / spatially related and unordered
> un-spatially related streams from end points?  Do we need a higher dimensional
> (greater than 1 dimension) means of specifying order?
>  
> Mark Gorzynski
>  
> On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One)
> <[email-masked]> wrote:
> 
> ·        Also agree with the point (stated in several places) that left-right
> should be clear and be defined with respect to a user facing the displays.
> This will of course require being careful about maintaining this convention
> when a stream is received.  At a sender, a stream may be thus defined as from
> the right-most display.  But when it is received and rendered on a display,
> that final destination will use the receiver¹s point of view.  Thus a stream
> at Sender A may be labeled A-Right and then sent to receiver B for output to
> display B-Left.  I would not re-label the stream from A to match the receiver
> convention.  Thus streams might be labeled with respect to the sender
> convention.
> 
>  
> 
> -2,-1,0,1,2 or such things may assume a centered system where one stream is on
> a center axis or that there is a clear sense of when ³right² begins.  This is
> not always true.  For example a system with an even number of displays and a
> camera above each display.  Thus it may be most efficient to use the sense of
> ³left² to create a beginning of a spatial relationship and order streams from
> that beginning, 0,1,2,Š  Thus we may label a stream from the right-most
> display of a sender A as coming from A.2  If that stream is sent to a receiver
> for output on a left most display, that left most display destination may be
> B.0.
> 
>  
> 
> Regards
> Mark Gorzynski
>  
> 
>  
>  
>  
> very careful to distinguish microphones and audio channels (and cameras /video
> channels).  Lots of audio systems use microphone arrays and beam forming to
> get pickup in various parts of the room, and in principle you could use
> similar techniques for video.
> 
> Also, do we mean the "left camera" is physically located on the left, or that
> it shows participants on the left?  I think the latter is the intent, and that
> it needs to be clear.  Another reason perhaps to avoid talking about camera
> placement.
>  
>> 
>>> >
>>> >Cheers,
>>> >Charles
>>> >
>>> >

---

From: "Gorzynski, Mark E (The Right One)" <[email-masked]>
Date: Wed, 18 May 2011 19:30:47 +0000

I agree with a preference for "stage left" creating a 0 start to an order.  Thus streams 0,1,2,... are sender oriented.   It is evident to a receiver then that the order must be retained from the new rendering perspective.

Mark

From: Stephan Wenger [mailto:[email-masked]]
Sent: Wednesday, May 18, 2011 3:20 AM
To: Stephen Botzko; Gorzynski, Mark E (The Right One)
Cc: CLUE
Subject: Re: [clue] Definitions

Of these alternatives, I'm in favor of "stage left".  I don't like a protocol expressing something (like a "to be rendered left" property) over which the protocol has no control.
Let me also forget to ignore the edu use case for now.  We are talking about definitions to be used throughout a set of documents.  If one of the definitions happens to be inapplicable, the spec can always phrase around.
Stephan

From: Stephen Botzko <[email-masked]<mailto:[email-masked]>>
Date: Wed, 18 May 2011 14:32:21 -0400
To: "Gorzynski, Mark E (The Right One)" <[email-masked]<mailto:[email-masked]>>
Cc: CLUE <[email-masked]<mailto:[email-masked]>>
Subject: Re: [clue] Definitions

I am wondering if the correct way to think about this is that the spatial relationships identify the proper rendering.  That is, the left stream is intended to appear to the immediate left of the center stream. That would be similar to your suggestion (though the "display" word isn't explicit).

Alternatively, we could use the "stage left" theatrical convention (treating the displays as the stage).  That defines the streams from the perspective of the sender. The left stream appears on the audience's right, but is sourced from the left side of the sending system.  That has the benefit of being a well established term.

The educational use case (which is one where the professor and the class are facing each other in the same room) is essentially un-ordered as written.  Though it could be made partially ordered, by having multiple video streams cover the local classroom and also substituting a panel discussion for the professor.

Stephen Botzko.
On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) <[email-masked]<mailto:[email-masked]>> wrote:
Regarding complex environments where users are seated in multiple directions or in the round, can we consider the convention direction as relative to facing a media system like a display?  Is there at least a clock-wise sense to media acquisition and reproduction where there as a counter-clockwise most element and that is first (left most)?  This is still pushing the concept of a single-dimension to order.

Mark Gorzynski

From: Stephen Botzko [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, May 18, 2011 9:07 AM
To: Gorzynski, Mark E (The Right One)

Cc: CLUE

Stephen Botzko

Regards
Mark Gorzynski

In-line -
Stephen Botzko

Not sure here.

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

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 18 May 2011 15:56:17 -0400

Works for me.

Stephen Botzko

On Wed, May 18, 2011 at 6:19 AM, Stephan Wenger <[email-masked]> wrote:

> Let me also forget to ignore the edu use case for now.  We are talking
> about definitions to be used throughout a set of documents.  If one of the
> Alternatively, we could use the "stage left" theatrical convention
> (treating the displays as the stage).  That defines the streams from the
> perspective of the sender. The left stream appears on the audience's right,
> but is sourced from the left side of the sending system.  That has the
> benefit of being a well established term.
>
> The educational use case (which is one where the professor and the class
> are facing each other in the same room) is essentially un-ordered as
> written.  Though it could be made partially ordered, by having multiple
> video streams cover the local classroom and also substituting a panel
> discussion for the professor.
>
> Stephen Botzko.
>
>> is on a center axis or that there is a clear sense of when “right” begins.
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Stephen Botzko
>> be very careful to distinguish microphones and audio channels (and cameras

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 18 May 2011 13:41:50 -0700

I have been thinking that a single dimension to the spatial ordering is enough, and can be used even for the "in the round" case as Mark G suggests.  A two dimensional example is a video wall with a two dimensional array of displays, but I'm not sure if this is in scope for CLUE.

I like the "stage left" idea too.

Mark Duckworth

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Botzko
Sent: Wednesday, May 18, 2011 2:32 PM
To: Gorzynski, Mark E (The Right One)
Cc: CLUE
Subject: Re: [clue] Definitions

Stephen Botzko.

Mark Gorzynski

Cc: CLUE

Stephen Botzko

Regards
Mark Gorzynski

In-line -
Stephen Botzko

Not sure here.

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 18 May 2011 16:51:40 -0400

I think supporting the "in the round" case implies something other than
simple numbering to convey the spatial relationships - you need something
like a directed graph with a syntax that allows a loop.  This could also
describe an MxN video wall.

The way I read the charter, both "in the round" and MxN video walls are in
scope.  Though we would need to decide how important they are.

Stephen Botzko

On Wed, May 18, 2011 at 4:41 PM, Duckworth, Mark <[email-masked]

> I have been thinking that a single dimension to the spatial ordering is
> enough, and can be used even for the “in the round” case as Mark G suggests.
>  A two dimensional example is a video wall with a two dimensional array of
> displays, but I’m not sure if this is in scope for CLUE.
>
>
>
> I like the “stage left” idea too.
>
>
>
> Mark Duckworth
>
>
>
>
>
> *Sent:* Wednesday, May 18, 2011 2:32 PM
>

---

From: <[email-masked]>
Date: Thu, 19 May 2011 07:17:10 +0000

Hi Mark, Stephan,

On my side, I think we should consider cases where we have several SIP UAs in a single telepresence room. 

Another discussion is to define the relation between an endpoint and a SIP UA. IMO, we should define an endpoint as composed of one single SIP UA, and the endpoint represents all equipment associated to the SIP UA (including multi-screen/camera).

Thus we should consider cases where a telepresence room is composed of several endpoints. As I suggested in a previous mail, I think that such cases will necessarily exist, with proprietary implementations (thus not interoperable) in MCU to associate several endpoints so that they form a single telepresence room. That's why we should consider these cases to have interoperability rules.

Stephane. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Duckworth, Mark
Envoyé : mercredi 18 mai 2011 19:27
À : Stephan Wenger; [email-masked]
Objet : Re: [clue] Definitions

Stephan,

Mark

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 19 May 2011 07:09:56 -0400

I am confused about how CLUE can make interoperability with proprietary
systems a requirement [or a consideration].

There is quite broad consensus among manufacturers that a single UA is the
right approach for standardization.  The systems in the room need to be
highly integrated to create the telepresence experience, and external
telepresence MCUs need to have explicit knowledge about what systems are in
what rooms, and how the systems are arranged within the room.  Coordinated
management of the endpoints is problematic.  Even simple dialing between
rooms becomes complicated.

Stephen Botzko

On Thu, May 19, 2011 at 3:17 AM, <[email-masked]>wrote:

> Another discussion is to define the relation between an endpoint and a SIP
> UA. IMO, we should define an endpoint as composed of one single SIP UA, and
> the endpoint represents all equipment associated to the SIP UA (including
> multi-screen/camera).
>
> Thus we should consider cases where a telepresence room is composed of
> several endpoints. As I suggested in a previous mail, I think that such
> cases will necessarily exist, with proprietary implementations (thus not
> interoperable) in MCU to associate several endpoints so that they form a
> single telepresence room. That's why we should consider these cases to have
> interoperability rules.
>
>
> Stephane.
>

---

From: aravind sethuraman <[email-masked]>
Date: Thu, 19 May 2011 07:24:58 -0400

why would an end point want to expose more than one SIP UA / or point of entry?
why would a subsystem of a room be in a part of a call if the entire room is not a call

we have multiple codecs and multiple control panels but there is a single point of entry which behaves as a SIP UA.....the rest, within the room can be proprietary or something else...
but endpoint -endpoint interoperabilithy has to be as thought between multi-media capture/decode capable SIP UAs ......
we cannot presume an end-point to have multiple SIP UAs.....

my 2 cents...

aravind

>>>>> issues then send them now, and I can address them immediately.

Aravind Sethuraman
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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 May 2011 14:04:02 +0200

Hi,

I would allow multiple SIP UAs to represent a room, we would have to deal with issues on how to correlate multiple SIP sessions, and how to related media streams within them, associated with that room, which could become very complicated.

In addition, it would make interoperability - not only between CLUE- and legacy endpoints, but also between CLUE endpoints represented by a different number of SIP UAs.

So, I wuold really recommend to not go that way. I think we will have enough issues to solve even without it :)

OF COURSE, one can have multiple SIP UAs in a PHYSICAL room. But, in that case each SIP UA would represent a separate telepresence room, and would be seen and treated as different endpoints.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of aravind sethuraman
Sent: 19. toukokuuta 2011 14:25
To: [email-masked]
Cc: [email-masked]
Subject: Re: [clue] Definitions

my 2 cents...

aravind

On May 19, 2011, at 3:17 AM, <[email-masked]> wrote:

> de Duckworth, Mark Envoyé : mercredi 18 mai 2011 19:27 À : Stephan 
> Wenger; [email-masked] Objet : Re: [clue] Definitions
> 
> Stephan,
> 
>> equipment in a telepresence room.  I believe that there are cases 
>> where we can have multiple SIP user agents (Uas) in one room.  Think 
>> of a bunch of codec boxes in a rack, all having their own UA.  Is 
>> this the common understanding of the group?
>> 
>> To ask the question differently, do we have an agreement that there 
>> is a single SIP UA in one room?
>> 
>> Guidance, please.
>> 
>> Thanks,
>> Stephan
>> 
>> 
>> 
>> 
>>> conference will be composed of "participants", where a participant 
>>> is connected to the conference through an "endpoint". In 
>>> telepresence,
>> the
>>> participant will have to be aware of the endpoint, in particular 
>>> when
>> the
>>> through which a participant (we do not limit to entity facing a 
>>> user)
>> is
>>> À : Stephan Wenger; Charles Eckel (eckelcu); CLUE Objet : Re: [clue] 
>>> Definitions
>>> 
>>> endpoint usually send media representing itself and MCUs send media 
>>> on behalf of others remote endpoint connected.
>>> 
>>> Cheers
>>> 
>>> -Espen
>>> 
>>> 
>>> In summary, I'm not convinced there is need for a change, though 
>>> there may be need for more explanatory text.
>>> Stephan
>>> 
>>>> This is a great start. I do not know if you volunteered to update 
>>>> as well as provide the initial version of this document. In any 
>>>> case,
>> here
>>>> are some comments.
>>>> 
>>>>> media streams.  In contrast to an endpoint, a middle box, such as 
>>>>> an MCU, may also send and receive media streams, but it is not the 
>>>>> initiator nor the final terminator.
>>>> 
>>>> are not necessarily equivalent to those it received, and it 
>>>> receives input from other endpoints. I think trying to distinguish 
>>>> them simply makes more work and add complexity. I also think we 
>>>> will find that
>> the
>>> facing the user--the room including microphones loudspeakers, 
>>> screens, cameras, and some technical stuff that sends and receives 
>>> RTP streams and implements signaling.  We need such a definition 
>>> certainly in the requirement spec but also in the use cases.  There 
>>> is also a "local"
>>>> I think this is too general, but I am not able to suggest a good 
>>>> way
>> to
>>>> improve it.
>>> 
>>>>> Session - RTP session.  An association among a set of participants 
>>>>> communicating with RTP.  The distinguishing feature of an RTP 
>>>>> session is that each maintains a full, separate space of SSRC 
>>>>> identifiers.  [RFC3550]
>>>> 
>>> transmission channels.  There is a logical connection between 
>>> multiple sessions, but only in the signaling.
>>> 
>>>> 
>>>> 
>>> "Audio channel 1 is left, audio channel 2 is right, and there is 
>>> only one center camera" is a layout.
>>> 
>>>> 
>>>> Cheers,
>>>> Charles
>>>> 
>>>> 

Aravind Sethuraman
Software Architect

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 May 2011 14:05:30 +0200

"If we would allow multiple SIP UAs to represent a room", that is :)

Sorry for the mess.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 19. toukokuuta 2011 15:04
To: 'aravind sethuraman'; [email-masked]
Cc: [email-masked]
Subject: Re: [clue] Definitions

Hi,

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of aravind sethuraman
Sent: 19. toukokuuta 2011 14:25
To: [email-masked]
Cc: [email-masked]
Subject: Re: [clue] Definitions

my 2 cents...

aravind

Aravind Sethuraman
Software Architect

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 19 May 2011 06:48:54 +0200

To summarize this very useful discussion, I believe the definitions should
reflect (only) the case where a single SIP UA represents a "room" at a
given time.  "Room" being anything from a multi-codec telepresence studio
sold for hundreds of thousands down to the screen of a mobile device.
If there were cases where we choose to divert from this assumption, the
related definition(s) would simply not be used.
I'm going to produce and upload the -00 draft today, reflecting the
outcome of the discussions as well as I can.
Stephan

On 5.19.2011 14:05 , "Christer Holmberg" <[email-masked]>
wrote:

>Christer Holmberg
>I would allow multiple SIP UAs to represent a room, we would have to deal
>with issues on how to correlate multiple SIP sessions, and how to related
>media streams within them, associated with that room, which could become
>very complicated.
>
>In addition, it would make interoperability - not only between CLUE- and
>legacy endpoints, but also between CLUE endpoints represented by a
>different number of SIP UAs.
>
>So, I wuold really recommend to not go that way. I think we will have
>enough issues to solve even without it :)
>
>OF COURSE, one can have multiple SIP UAs in a PHYSICAL room. But, in that
>case each SIP UA would represent a separate telepresence room, and would
>be seen and treated as different endpoints.
>
>Regards,
>
>Christer
>
>
> 
>
>aravind sethuraman
>we have multiple codecs and multiple control panels but there is a single
>point of entry which behaves as a SIP UA.....the rest, within the room
>can be proprietary or something else...
>but endpoint -endpoint interoperabilithy has to be as thought between
>multi-media capture/decode capable SIP UAs ......
>> Another discussion is to define the relation between an endpoint and a
>>SIP UA. IMO, we should define an endpoint as composed of one single SIP
>>UA, and the endpoint represents all equipment associated to the SIP UA
>>(including multi-screen/camera).
>> 
>>single telepresence room. That's why we should consider these cases to
>>have interoperability rules.
>> 
>> 
>> Stephane. 
>> 
>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
>
>

---

From: <[email-masked]>
Date: Thu, 19 May 2011 15:41:57 +0000

Hi Stephen,

Please see inline.

Stéphane.

De : Stephen Botzko [mailto:[email-masked]]
Envoyé : jeudi 19 mai 2011 13:10
À : CAZEAUX Stephane RD-BIZZ-CAE
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [clue] Definitions

I am confused about how CLUE can make interoperability with proprietary systems a requirement [or a consideration].
[SC] We all agree that interoperability with proprietary systems is explicitly out of scope of the charter. This is not the purpose of the discussion here (sorry if I was confusing on that point).

There is quite broad consensus among manufacturers that a single UA is the right approach for standardization.
[SCa] I am ok with this consensus. Actually, the suggestion to support telepresence rooms made of multiple SIP UAs does not intend to replace the single SIP UA approach. Instead, it intends to be an alternative.
The systems in the room need to be highly integrated to create the telepresence experience, and external telepresence MCUs need to have explicit knowledge about what systems are in what rooms, and how the systems are arranged within the room.
[SCa] I do not agree with this argument. CLUE targets any endpoint from a full and high-cost telepresence room to a simple handheld device. I don't think that we can have the same level of integration, thus telepresence experience, with all endpoints.
Quoting draft-romanow-clue-telepresence-use-cases-01.txt (section 4.6.)
"
The importance of this example is that the multiple video streams are
   not used to create an immersive conferencing experience with
   panoramic views at all the site.  Instead the multiple streams are
   dynamically used to enable full participation of remote students in a
   university class.
"
This use case is interesting, especially because it leverages the telepresence multi-screen. We could have cases where we setup endpoints in the main site, with endpoints that all have different capabilities. For instance: one endpoint presents a regular HD video of the participants, another with a 3D video of a concept, etc... But a the end, all these endpoints are in the same telepresence room, and obviously in a same telepresence conference (btw. I don't see the case where these endpoints are connected to different conferences). If we don't consider the alternative of having multiple SIP UA (i.e. multiple endpoints) in a same room, I don't think we can realize such (advanced) cases.

Coordinated management of the endpoints is problematic.  Even simple dialing between rooms becomes complicated.

Stephen Botzko
On Thu, May 19, 2011 at 3:17 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mark, Stephan,

Stephane.

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Duckworth, Mark
Envoyé : mercredi 18 mai 2011 19:27
À : Stephan Wenger; [email-masked]<mailto:[email-masked]>
Objet : Re: [clue] Definitions

Stephan,

Mark

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Stephan Wenger
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> On 5.18.2011 12:46 , "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> >De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part
> de
> >Espen Berger (espeberg)

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 19 May 2011 11:51:25 -0400

Oddly enough I wrote the use case you quote.  I don't see the need for
multiple SIP UAs to realize it. If you've ever operated multiple endpoints
independently in the same room, you'll realize that you get echo and
potentially other problems.

I think we should go with Stephan's recommendation for now.  Explicitly use
a single SIP UA for this set of definitions, and we can deal with other
cases later on.

Stephen.

On Thu, May 19, 2011 at 11:41 AM, <[email-masked]>wrote:

>  Hi Stephen,
>
>
>
> Please see inline.
>
>
>
>
>
> Stéphane.
>
>
>
> *De :* Stephen Botzko [mailto:[email-masked]]
> *Envoyé :* jeudi 19 mai 2011 13:10
> *À :* CAZEAUX Stephane RD-BIZZ-CAE
> *Cc :* [email-masked]; [email-masked]; [email-masked]
> *Objet :* Re: [clue] Definitions
>
>
>
> [SC] We all agree that interoperability with proprietary systems is
> explicitly out of scope of the charter. This is not the purpose of the
> discussion here (sorry if I was confusing on that point).
>
>
> right approach for standardization.
>
> [SCa] I am ok with this consensus. Actually, the suggestion to support
> telepresence rooms made of multiple SIP UAs does not intend to replace the
> single SIP UA approach. Instead, it intends to be an alternative.
>
> The systems in the room need to be highly integrated to create the
> telepresence experience, and external telepresence MCUs need to have
> explicit knowledge about what systems are in what rooms, and how the systems
> are arranged within the room.
>
> [SCa] I do not agree with this argument. CLUE targets any endpoint from a
> full and high-cost telepresence room to a simple handheld device. I don’t
> think that we can have the same level of integration, thus telepresence
> experience, with all endpoints.
>
> “
> “
> This use case is interesting, especially because it leverages the
> telepresence multi-screen. We could have cases where we setup endpoints in
> the main site, with endpoints that all have different capabilities. For
> instance: one endpoint presents a regular HD video of the participants,
> another with a 3D video of a concept, etc… But a the end, all these
> endpoints are in the same telepresence room, and obviously in a same
> telepresence conference (btw. I don’t see the case where these endpoints are
> connected to different conferences). If we don’t consider the alternative of
> having multiple SIP UA (i.e. multiple endpoints) in a same room, I don’t
> think we can realize such (advanced) cases.
>
>
>
>
>
>
>
> Coordinated management of the endpoints is problematic.  Even simple
> dialing between rooms becomes complicated.
>
>
>
> Stephen Botzko
>