Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-00

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 4 Mar 2011 21:47:42 -0800

Hi Folks,

I just submitted this first draft of a requirements document.

Looking forward to your thoughts-

Allyn

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Friday, March 04, 2011 9:16 PM
To: Allyn Romanow (allyn)
Subject: New Version Notification for draft-romanow-clue-telepresence-requirements-00 

A new version of I-D, draft-romanow-clue-telepresence-requirements-00.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository.

Filename:	 draft-romanow-clue-telepresence-requirements
Revision:	 00
Title:		 Requirements for Telepresence Multi-Streams
Creation_date:	 2011-03-05
WG ID:		 Independent Submission
Number_of_pages: 11

Abstract:
This document discusses the problems, assumptions, and requirements
for handling multiple media streams to enable Telepresence
interoperability.  Definitions are also covered here as well.

The IETF Secretariat.

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 7 Mar 2011 14:52:03 -0500

Hi Allyn, 

Overall this is big step forward. Thanks. 

A couple of quick comments (I still need to re-read carefully)

RQMT-6: Support for H.264 baseline
This feels a bit like a media profile (and there is no corresponding one for audio). I suspect this is out of scope - since CLUE is about semantics of streams and not requirements as to what CODEC be used...

RQMT-12 talks about SDP streams. Should this say RTP streams?

Regards, 

Peter Musgrave

On 2011-03-05, at 12:47 AM, Allyn Romanow (allyn) wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Mar 2011 13:35:19 +0100

Hi,

A comment on the "Endpoint" definition.

It talks about "end system", and also refers to the "Room" definition, which at least to me relates to telepresence rooms etc.

But, I assume it also covers normal phones, hand held devices etc. I guess it would be good to mention that.

Regards,

Christer

---

From: "Cole, Jim (HP Visual Collaboration R&D)" <[email-masked]>
Date: Wed, 9 Mar 2011 21:19:15 +0000

Hi,

Regarding some of the definitions, I wonder to what extent it would be worth minimizing new terms, and instead extending existing nomenclatures. Some suggestions along these lines are below, along with a couple other comments on definitions and  the requirements themselves.

Regards,
Jim Cole

1. "Endpoint" and "Room". What is the difference between an endpoint and a SIP user agent? Could we use "multistream user agent" instead? That would give a generic term applicable to phones, desktop applications, etc. Also, if terms are used interchangeably, would it be better to try and standardize on one for the purposes of the documents?

2. "Layout" and "Source placement". Why have both, since one is aka the other? Suggest removing Source placement, and just using Layout to refer to the general task of arranging rendered streams at a receiving endpoint, whether this means mapping specific streams to specific displays, or creating a composited (mixed) presentation at the receiving endpoint.

3. "Region". Can this be clarified as to how it differs from field of view? Would an alternative be to define a spatial metric with which to describe capture field of view? Perhaps an example would be helpful.

4. "Source selection". Seems like this is a special case of the general mixing function; when streams are not combined. Instead, how about if we use the well-known term "mixer", and expand it. SIP expanded the definition from RTP to include non-RTP data. CLUE could likewise expand the definition to include multistream sessions, which could then explicitly include the simple case of source selection.

5. "Video composite". Following some of the comments above, how about this simply becoming the output of a multistream mixer?

6. REQMT-1. Is there an implied requirement to determine a (synthetic) spatial relationship between multiple endpoints?

7. REQMT-4. Just to be clear, the sender can either be the originating endpoint, or a middlebox, right?

8. REQMT-21. Since this is under "Audio", is it really referring to lipsync? Or is it a higher-level latency requirement for both audio and video. Probably need both.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Allyn Romanow (allyn)
Sent: Friday, March 04, 2011 9:48 PM
To: [email-masked]
Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-00

Hi Folks,

Allyn

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Friday, March 04, 2011 9:16 PM
To: Allyn Romanow (allyn)
Subject: New Version Notification for draft-romanow-clue-telepresence-requirements-00 

Abstract:

The IETF Secretariat.

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 9 Mar 2011 16:50:37 -0800

Hi Jim, Christer and Peter-
I'll be able to respond to your emails about requirements in the next
few days.. just haven't had a chance yet.

Thanks,
Allyn

> From: Cole, Jim (HP Visual Collaboration R&D) [mailto:[email-masked]]
> Sent: Wednesday, March 09, 2011 1:19 PM
> Cc: [email-masked]
> Subject: RE: [clue] FW: New Version Notification
fordraft-romanow-clue-
> telepresence-requirements-00
> 
> Hi,
> 
> Regarding some of the definitions, I wonder to what extent it would be
> worth minimizing new terms, and instead extending existing
> nomenclatures. Some suggestions along these lines are below, along
with
> a couple other comments on definitions and  the requirements
> themselves.
> 
> Regards,
> Jim Cole
> 
> 1. "Endpoint" and "Room". What is the difference between an endpoint
> and a SIP user agent? Could we use "multistream user agent" instead?
> That would give a generic term applicable to phones, desktop
> applications, etc. Also, if terms are used interchangeably, would it
be
> better to try and standardize on one for the purposes of the
documents?
> 
> 2. "Layout" and "Source placement". Why have both, since one is aka
the
> other? Suggest removing Source placement, and just using Layout to
> refer to the general task of arranging rendered streams at a receiving
> endpoint, whether this means mapping specific streams to specific
> displays, or creating a composited (mixed) presentation at the
> receiving endpoint.
> 
> 3. "Region". Can this be clarified as to how it differs from field of
> view? Would an alternative be to define a spatial metric with which to
> describe capture field of view? Perhaps an example would be helpful.
> 
> 4. "Source selection". Seems like this is a special case of the
general
> mixing function; when streams are not combined. Instead, how about if
> we use the well-known term "mixer", and expand it. SIP expanded the
> definition from RTP to include non-RTP data. CLUE could likewise
expand
> the definition to include multistream sessions, which could then
> explicitly include the simple case of source selection.
> 
> 5. "Video composite". Following some of the comments above, how about
> this simply becoming the output of a multistream mixer?
> 
> 6. REQMT-1. Is there an implied requirement to determine a (synthetic)
> spatial relationship between multiple endpoints?
> 
> 8. REQMT-21. Since this is under "Audio", is it really referring to
> lipsync? Or is it a higher-level latency requirement for both audio
and
> video. Probably need both.
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Allyn Romanow (allyn)
> A new version of I-D, draft-romanow-clue-telepresence-requirements-
> 00.txt has been successfully submitted by Allyn Romanow and posted to
> the IETF repository.
>

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 14 Mar 2011 01:46:39 -0700

Hi Christer, 
The reference to room has been deleted, and the requirements are pretty
explicit about including hand held devices, so I hope this will be clear
now.

Thanks,
Allyn

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2011 4:35 AM
> To: Allyn Romanow (allyn); [email-masked]
> Subject: Telepresence requirements: Endpoint definition [was: New
> Version Notification for draft-romanow-clue-telepresence-requirements-
> 00]
> 
> 
> Hi,
> 
> It talks about "end system", and also refers to the "Room" definition,
> which at least to me relates to telepresence rooms etc.
>

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 14 Mar 2011 01:49:47 -0700

Hi Peter,

Responses below-

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Monday, March 07, 2011 11:52 AM
> Subject: Re: [clue] FW: New Version Notification for draft-romanow-
> clue-telepresence-requirements-00
> 
> Hi Allyn,
> 
> This feels a bit like a media profile (and there is no corresponding
> one for audio). I suspect this is out of scope - since CLUE is about
> semantics of streams and not requirements as to what CODEC be used...

Yep, my bad. I removed it.
> RQMT-12 talks about SDP streams. Should this say RTP streams?

Removed 12. I felt it was more of a solution than a requirent.

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 14 Mar 2011 01:54:07 -0700

HI Jim,

Thanks for your good comments. Responses inline below

1. "Endpoint" and "Room". What is the difference between an endpoint and
a SIP 
user agent? Could we use "multistream user agent" instead? That would
give a 
generic term applicable to phones, desktop applications, etc. Also, if
terms 
are used interchangeably, would it be better to try and standardize on
one for 
the purposes of the documents?

you're right. deleted room.

2. "Layout" and "Source placement". Why have both, since one is aka the
other? 
Suggest removing Source placement, and just using Layout to refer to the

general task of arranging rendered streams at a receiving endpoint,
whether 
this means mapping specific streams to specific displays, or creating a 
composited (mixed) presentation at the receiving endpoint.

yes. deleted source placement and used your words in dfn of layout.
thanks

3. "Region". Can this be clarified as to how it differs from field of
view? 
Would an alternative be to define a spatial metric with which to
describe 
capture field of view? Perhaps an example would be helpful.

yes, you're right. Region is used in the design or model draft which
will be sent out in about a week. 
working on it also). I can't think how to fix this right at the moment,
in time to get it into the next draft due tomorrow. But i think that
once we consider the design doc, we can definitely improve this. It is a
key concept.

4. "Source selection". Seems like this is a special case of the general
mixing 
function; when streams are not combined. Instead, how about if we use
the 
well-known term "mixer", and expand it. SIP expanded the definition from
RTP 
to include non-RTP data. CLUE could likewise expand the definition to
include 
multistream sessions, which could then explicitly include the simple
case of 
source selection.

I think this and the following comment are good ideas. However, I'm not
yet sure how we want to use the RTP mixer concept since it includes how
it is to be implemented with SSRC and CSRC. It seems to me a bit
premature to assume things that have to to with solutions. So, let's
hold off on this pending solution discussion. okay?

5. "Video composite". Following some of the comments above, how about
this 
simply becoming the output of a multistream mixer? see last comment

6. REQMT-1. Is there an implied requirement to determine a (synthetic)
spatial 
relationship between multiple endpoints?

Sorry, i did not understand this comment. I changed "spatial"
information to "layout" information. However, perhaps you could further
explain this to me. 

7. REQMT-4. Just to be clear, the sender can either be the originating 
endpoint, or a middlebox, right?
yes. I added this to the text.

8. REQMT-21. Since this is under "Audio", is it really referring to
lipsync? 
Or is it a higher-level latency requirement for both audio and video.
Probably 
need both.
I'm not sure what you mean. We should discuss.