Subject: [dispatch] Telepresence Charter Version 3

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 25 Aug 2010 15:08:31 -0700

Folks, here is the 3rd version of the charter.

*         It incorporates a number of useful editing comments.

*         The substantive issue on this draft concerned what was meant
by 

  "Also not in scope is signaling to tell the originator to which
receivers the media streams should be sent."

After further discussion with Peter and Steve, the main discussants on
this, I've added to the list of what is included

*Which sources a receiver wants to receive.  For example, it might want
the source for the left camera, or might want the source chosen by VAD
(Voice Activity Detection).

We interpreted the out of scope sentence to mean

"Also not in scope is signaling to tell the originator to which IP
addresses the media streams should be sent."

While this seemed okay, it was felt to be unnecessary. So it was left
out of this version.

Thus we think we have "in" what counts - that the receiver might need to
say which of several RTP streams it wants to receive. And if someone has
something they want to exclude could they please try again to describe
it?

OH- and for a name. How about CLUE? 

Comments?

Allyn

Charter

CLUE ControLling mUltiple streams for TElepresence

or

MUSCAT: MUlti-Stream Control Applied to Telepresence

In the context of this WG, the term telepresence is used in a general
manner to describe systems that provide high definition, high quality
audio/video enabling a "being-there" experience.  One example is an
immersive telepresence system using specially designed and special
purpose rooms with multiple displays permitting life size image
reproduction using multiple cameras, encoders, decoders,microphones and
loudspeakers.

Current telepresence systems are based on open standards such as RTP,
SIP, H.264, the H.323 suite, however, they cannot easily interoperate
with each other without operator assistance and expensive additional
equipment which translates from one vendor to another. A major factor in
the inability of telepresence systems to interwork is that there is no
standardized way to describe and negotiate the use of the multiple
streams of audio and video that comprise the media flows.  In addition,
there is  no standardized way to exchange semantic information about
what each media stream represents.  

The WG will create specifications to enable communication of enough
information about each media stream so that each receiving system or
bridge system can make reasonable decisions about selecting and
rendering media streams. This enables systems to make display choices
that optimize the "just like being there" experience. 

This working group is chartered to specify the information about media
streams from one endpoint to another endpoint or conference bridge
including:

* Spatial relationships of cameras, displays, microphones, and

  speakers in relation to each other and to likely positions of

  participants

* Specific characteristics such as viewpoint, field of view/capture

  for camera/microphone/display/speaker so that senders and

  middleboxes can understand how best to compose streams for

  receivers and the receivers will know the characteristics of its 

  received streams

* Aspect ratio of cameras and displays

* Which sources a receiver wants to receive.  For example, it might want
the source for the left camera, or might want the source chosen by VAD
(Voice Activity Detection).

Information between sources and sinks about media stream capabilities
will be exchanged. 

The working group will define the semantics, syntax,  and transport
mechanism necessary for communicating the necessary information. It will
consider whether the existing signaling mechanisms (e. g., SDP, BFCP)
can be extended, or another messaging method should be used.  

The scope of the work includes describing relatively static relations
between entities (participants and devices). It also includes handling
more dynamic relationships, such as identifying the audio and video
streams for the current speaker. The scope includes both systems that
provide a fully immersive experience, and systems that interwork with
them and therefore need to understand the same multiple stream
semantics.  

The focus of this work is on multiple audio and video streams.  Other
media types may be considered, however development of methodologies for
them is not within the scope of this work.

Interoperation with standards compliant systems is required, such as
SIP-based video conferencing systems.  However, backwards compatibility
with existing non-standards compliant telepresence systems is not
required.

This working group is not currently chartered to work on issues of
continuous conference control including: far end camera control,
indication of fast frame update for video codecs or other rapid
switches, floor control, conference roster. 

Re-use of existing protocols and backwards compatibility with existing
systems is an important factor for the working group to consider. The
work will closely coordinate with the appropriate areas and working
groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.

 Milestones  

 Nov 2010 Submit information draft to IESG on use cases and requirements

 Nov 2011 Submit standards track specification to IESG on indicating

          spatial relationships of screens, cameras (including variable

          field of view and orientation), speakers and microphones. This

          includes, semantics, language and transport.

 Apr 2011 Submit standards track specification to IESG on indicating the

          "usage" of a stream as define in charter.

---

From: Alex Eleftheriadis <[email-masked]>
Date: Wed, 25 Aug 2010 18:29:15 -0400

Hi Allyn, all. I raised the issue originally, and I am fine with the clarification in the new version.

Regarding the name, I will repeat my original preference for CLUE.

Regards,

Alex

On Aug 26, 2010, at 1:08 AM, Allyn Romanow (allyn) wrote:

•         It incorporates a number of useful editing comments.
•         The substantive issue on this draft concerned what was meant by
  “Also not in scope is signaling to tell the originator to which receivers the media streams should be sent.”

After further discussion with Peter and Steve, the main discussants on this, I’ve added to the list of what is included

*Which sources a receiver wants to receive.  For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection).

We interpreted the out of scope sentence to mean
“Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent.”

While this seemed okay, it was felt to be unnecessary. So it was left out of this version.

Thus we think we have “in” what counts – that the receiver might need to say which of several RTP streams it wants to receive. And if someone has something they want to exclude could they please try again to describe it?

Comments?

Allyn

Charter

In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience.  One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders,microphones and loudspeakers.

Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video that comprise the media flows.  In addition,  there is  no standardized way to exchange semantic information about what each media stream represents.

The WG will create specifications to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience.

This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including:

* Which sources a receiver wants to receive.  For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection).

Information between sources and sinks about media stream capabilities will be exchanged.

The working group will define the semantics, syntax,  and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extended, or another messaging method should be used.

The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics.

The focus of this work is on multiple audio and video streams.  Other media types may be considered, however development of methodologies for them is not within the scope of this work.

Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems.  However, backwards compatibility with existing non-standards compliant telepresence systems is not required.

This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster.

Re-use of existing protocols and backwards compatibility with existing systems is an important factor for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.

 Milestones

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Aug 2010 19:55:43 -0400

Seems good to me.

I have no preference on WG name.

	Thanks,
	Paul

Allyn Romanow (allyn) wrote:
> Folks, here is the 3^rd  version of the charter.
> 
>  
> 
> ·         It incorporates a number of useful editing comments.
> 
> ·         The substantive issue on this draft concerned what was meant by
> 
>   “Also not in scope is signaling to tell the originator to which 
> receivers the media streams should be sent.”
> 
>  
> 
> this, I’ve added to the list of what is included
> 
>  
> 
> “Also not in scope is signaling to tell the originator to which IP 
> addresses the media streams should be sent.”
> 
>  
> 
> Thus we think we have “in” what counts – that the receiver might need to 
> something they want to exclude could they please try again to describe it?
> 
>  
> 
> them and therefore need to understand the same multiple stream semantics.  
> 
>  
> 
> with existing non-standards compliant telepresence systems is not required.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 26 Aug 2010 01:56:41 -0400

You could also do:
MALT - Multi-stream Application Language for Telepresence, or maybe Multi-stream Attributes for Lifelike Telepresence
COCKTAIL - Communication and Correlation of Key Telepresence Attributes for Interoperable Links
MAITAI - Multi-stream Attributes for Improving Telepresence Application Interoperability
TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike Applications
MOJITO - Multi-stream Orientation for Joining of Interoperable Telepresence Operations
I'm getting too thirsty to continue...

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Allyn Romanow (allyn)
Sent: Wednesday, August 25, 2010 6:09 PM
To: DISPATCH list
Subject: [dispatch] Telepresence Charter Version 3

*     The substantive issue on this draft concerned what was meant by
  "Also not in scope is signaling to tell the originator to which receivers the media streams should be sent."

After further discussion with Peter and Steve, the main discussants on this, I've added to the list of what is included

We interpreted the out of scope sentence to mean
"Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent."

Thus we think we have "in" what counts - that the receiver might need to say which of several RTP streams it wants to receive. And if someone has something they want to exclude could they please try again to describe it?

Comments?

Allyn

Charter

 Milestones

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Aug 2010 09:26:31 +0200

Allyn,

Should it be made clear that the work should be based on SIP/SDP (+RTP/H.264, of course)? Since both SIP and H.323 are mentioned in the second paragraph, the only CLUE to the work being SIP/SDP-based is the mention of SIPCORE and MMUSIC later.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Allyn Romanow (allyn)
> Sent: 25 August 2010 23:09
> To: DISPATCH list
>   "Also not in scope is signaling to tell the originator to 
> which receivers the media streams should be sent."
> 
>  
> 
> After further discussion with Peter and Steve, the main 
> discussants on this, I've added to the list of what is included
> 
>  
> 
> *Which sources a receiver wants to receive.  For example, it 
> might want the source for the left camera, or might want the 
> source chosen by VAD (Voice Activity Detection).
> 
>  
> 
> "Also not in scope is signaling to tell the originator to 
> which IP addresses the media streams should be sent."
> 
>  
> 
> Thus we think we have "in" what counts - that the receiver 
> might need to say which of several RTP streams it wants to 
> receive. And if someone has something they want to exclude 
> could they please try again to describe it?
> 
>  
> 
> In the context of this WG, the term telepresence is used in a 
> general manner to describe systems that provide high 
> definition, high quality audio/video enabling a "being-there" 
> experience.  One example is an immersive telepresence system 
> using specially designed and special purpose rooms with 
> multiple displays permitting life size image reproduction 
> using multiple cameras, encoders, decoders,microphones and 
> loudspeakers.
> 
>  
> 
> Current telepresence systems are based on open standards such 
> as RTP, SIP, H.264, the H.323 suite, however, they cannot 
> easily interoperate with each other without operator 
> assistance and expensive additional equipment which 
> translates from one vendor to another. A major factor in the 
> inability of telepresence systems to interwork is that there 
> is no standardized way to describe and negotiate the use of 
> the multiple streams of audio and video that comprise the 
> media flows.  In addition,  there is  no standardized way to 
> exchange semantic information about what each media stream 
> represents.  
> 
>  
> 
> The WG will create specifications to enable communication of 
> enough information about each media stream so that each 
> receiving system or bridge system can make reasonable 
> decisions about selecting and rendering media streams. This 
> enables systems to make display choices that optimize the 
> "just like being there" experience. 
> 
>  
> 
> This working group is chartered to specify the information 
> about media streams from one endpoint to another endpoint or 
> conference bridge including:
> 
>  
> 
> * Which sources a receiver wants to receive.  For example, it 
> might want the source for the left camera, or might want the 
> source chosen by VAD (Voice Activity Detection).
> 
>  
> 
>  
> 
> The working group will define the semantics, syntax,  and 
> transport mechanism necessary for communicating the necessary 
> information. It will consider whether the existing signaling 
> mechanisms (e. g., SDP, BFCP) can be extended, or another 
> messaging method should be used.  
> 
>  
> 
> The scope of the work includes describing relatively static 
> relations between entities (participants and devices). It 
> also includes handling more dynamic relationships, such as 
> identifying the audio and video streams for the current 
> speaker. The scope includes both systems that provide a fully 
> immersive experience, and systems that interwork with them 
> and therefore need to understand the same multiple stream semantics.  
> 
>  
> 
> The focus of this work is on multiple audio and video 
> streams.  Other media types may be considered, however 
> development of methodologies for them is not within the scope 
> of this work.
> 
>  
> 
> Interoperation with standards compliant systems is required, 
> such as SIP-based video conferencing systems.  However, 
> backwards compatibility with existing non-standards compliant 
> telepresence systems is not required.
> 
>  
> 
> This working group is not currently chartered to work on 
> issues of continuous conference control including: far end 
> camera control, indication of fast frame update for video 
> codecs or other rapid switches, floor control, conference roster. 
> 
>  
> 
> Re-use of existing protocols and backwards compatibility with 
> existing systems is an important factor for the working group 
> to consider. The work will closely coordinate with the 
> appropriate areas and working groups including OPS Area, AVT, 
> MMUSIC, MEDIACTRL, XCON, and SIPCORE.
> 
>  
> 
>  Milestones  
> 
>  
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 26 Aug 2010 09:36:37 +0200

Ho Allyn,

I like the charter as it is now. I would just clarify the definition of the third milestone (April 2011), on the 'usage' of a stream. As to the name, both proposals are ok, even though I have a slight preference for MUSCAT over CLUE.

Simon

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 26 Aug 2010 11:00:06 +0200

Hi Allyn,

I'm ok with the charter as well. I'd only suggest making it clearer that the backwards compatibility with existing systems/protocols the WG would like to achieve is limited to standard solutions, otherwise it might look like a conflict with the previous sentence about non-standard systems retro-compatibility being out of scope.

L.

On Thu, 26 Aug 2010 09:36:37 +0200

-- 
Lorenzo Miniero <[email-masked]>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 26 Aug 2010 08:35:12 -0400

COCKTAIL .

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Thursday, August 26, 2010 1:57 AM
To: Allyn Romanow (allyn); DISPATCH list
Subject: Re: [dispatch] Telepresence Charter Version 3

You could also do:

MALT - Multi-stream Application Language for Telepresence, or maybe
Multi-stream Attributes for Lifelike Telepresence

COCKTAIL - Communication and Correlation of Key Telepresence Attributes for
Interoperable Links

MAITAI - Multi-stream Attributes for Improving Telepresence Application
Interoperability

TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike
Applications

MOJITO - Multi-stream Orientation for Joining of Interoperable Telepresence
Operations

I'm getting too thirsty to continue.

-hadriel

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Allyn Romanow (allyn)
Sent: Wednesday, August 25, 2010 6:09 PM
To: DISPATCH list
Subject: [dispatch] Telepresence Charter Version 3

.       It incorporates a number of useful editing comments.

.       The substantive issue on this draft concerned what was meant by 

  "Also not in scope is signaling to tell the originator to which receivers
the media streams should be sent."

After further discussion with Peter and Steve, the main discussants on this,
I've added to the list of what is included

*Which sources a receiver wants to receive.  For example, it might want the
source for the left camera, or might want the source chosen by VAD (Voice
Activity Detection).

"Also not in scope is signaling to tell the originator to which IP addresses
the media streams should be sent."

While this seemed okay, it was felt to be unnecessary. So it was left out of
this version.

Thus we think we have "in" what counts - that the receiver might need to say
which of several RTP streams it wants to receive. And if someone has
something they want to exclude could they please try again to describe it?

Comments?

Allyn

Charter

or

 

In the context of this WG, the term telepresence is used in a general manner
to describe systems that provide high definition, high quality audio/video
enabling a "being-there" experience.  One example is an immersive
telepresence system using specially designed and special purpose rooms with
multiple displays permitting life size image reproduction using multiple
cameras, encoders, decoders,microphones and loudspeakers.

Current telepresence systems are based on open standards such as RTP, SIP,
H.264, the H.323 suite, however, they cannot easily interoperate with each
other without operator assistance and expensive additional equipment which
translates from one vendor to another. A major factor in the inability of
telepresence systems to interwork is that there is no standardized way to
describe and negotiate the use of the multiple streams of audio and video
that comprise the media flows.  In addition,  there is  no standardized way
to exchange semantic information about what each media stream represents.  

The WG will create specifications to enable communication of enough
information about each media stream so that each receiving system or bridge
system can make reasonable decisions about selecting and rendering media
streams. This enables systems to make display choices that optimize the
"just like being there" experience. 

  participants

  received streams

* Which sources a receiver wants to receive.  For example, it might want the
source for the left camera, or might want the source chosen by VAD (Voice
Activity Detection).

Information between sources and sinks about media stream capabilities will
be exchanged. 

The working group will define the semantics, syntax,  and transport
mechanism necessary for communicating the necessary information. It will
consider whether the existing signaling mechanisms (e. g., SDP, BFCP) can be
extended, or another messaging method should be used.  

The scope of the work includes describing relatively static relations
between entities (participants and devices). It also includes handling more
dynamic relationships, such as identifying the audio and video streams for
the current speaker. The scope includes both systems that provide a fully
immersive experience, and systems that interwork with them and therefore
need to understand the same multiple stream semantics.  

The focus of this work is on multiple audio and video streams.  Other media
types may be considered, however development of methodologies for them is
not within the scope of this work.

Interoperation with standards compliant systems is required, such as
SIP-based video conferencing systems.  However, backwards compatibility with
existing non-standards compliant telepresence systems is not required.

This working group is not currently chartered to work on issues of
continuous conference control including: far end camera control, indication
of fast frame update for video codecs or other rapid switches, floor
control, conference roster. 

Re-use of existing protocols and backwards compatibility with existing
systems is an important factor for the working group to consider. The work
will closely coordinate with the appropriate areas and working groups
including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.

 Milestones

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Aug 2010 09:53:50 -0600

I think this charter has some pretty serious issues with being way to wide open on what the scope is. The fact we are actually discussing if we need to add  in "Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent”  should be a huge hint that we have the scope much too broad. As I said a week ago .... 

Begin forwarded message:

> From: Cullen Jennings <[email-masked]>
> Date: August 18, 2010 11:16:22 AM MDT

> Main point:
> When I read this charter and ask myself what is out of scope, it seems that anything that is "the information about media streams from one endpoint to another endpoint or conference bridge including" would be in scope. I realize a few more things are taken our of scope later but the resulting space includes just about everything that MMUSIC does, and much of what SIP does. Because of the "anything and everything" approach I don't think this is a charter that will result in work that gets done quickly. From the point of view of being broad enough to do the need work, I think it's fine but from the point of view of being narrow enough to limit the work to something that is possible to complete, it seems pretty bad. I suspect that IESG would likely look at this as a "blank cheque" charter and ask for some changes to it. My suggestion would be just to change the "including (but not limited to):" in 3rd paragraph to be 
> 
> This working group is chartered to specify the following information about media streams from one endpoint to another endpoint:
> 

Note I am not arguing that there any given piece of work you should not do - I'm just encouraging you to say what problems you are going to do.

I would encourage you to specify what this working group is going to do, like you have in the bullet points, and stop leaving it open to do anything including the stuff in bullet points. We should do our best to avoid charters that are so unspecific that they overlap with existing WGs in ways that leave huge questions about which WG a new piece of work should go to. 

Cullen <with my DISPATCH co-chair hat on>

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 26 Aug 2010 09:36:08 -0700

Hi John,
Good catch. I thought we had done this earlier, but it isn't there now.

How is this text?

The WG will create specifications for SIP-based conferencing systems to
enable communication of 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, August 26, 2010 12:27 AM
> Subject: RE: Telepresence Charter Version 3
> 
> Allyn,
> 
> Should it be made clear that the work should be based on 
> SIP/SDP (+RTP/H.264, of course)? Since both SIP and H.323 are 
> mentioned in the second paragraph, the only CLUE to the work 
> being SIP/SDP-based is the mention of SIPCORE and MMUSIC later.
> 
> John
> 
> 
> discussants on 
> > *Which sources a receiver wants to receive.  For example, it might 
> > want the source for the left camera, or might want the 
> source chosen 
> might need 
> > to say which of several RTP streams it wants to receive. And if 
> > someone has something they want to exclude could they 
> please try again 
> > to describe it?
> > 
> >  
> > 
> > audio/video enabling a "being-there"
> > experience.  One example is an immersive telepresence system using 
> > specially designed and special purpose rooms with multiple displays 
> > permitting life size image reproduction using multiple cameras, 
> > encoders, decoders,microphones and loudspeakers.
> > 
> >  
> >

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 26 Aug 2010 14:14:18 -0400

WFN - in fact, I really like this.

Marshall

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Aug 2010 20:24:28 +0200

That's fine.

John

> From: Marshall Eubanks [mailto:[email-masked]] 
> Sent: 26 August 2010 19:14
> To: Allyn Romanow (allyn)
> Cc: Elwell, John; IETF DISPATCH list
> which IP

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 26 Aug 2010 15:39:19 -0700

Hi Cullen,

In order to restrict the scope of the charter, how would it be to
replace

	This working group is chartered to specify the information about
media streams from one 	endpoint to another endpoint or conference
bridge including:

By your suggested sentence

	This working group is chartered to specify the following
information about media streams 	from one endpoint to another
endpoint:
?

Allyn

-----Original Message-----
From: Cullen Jennings (fluffy) 
Sent: Thursday, August 26, 2010 8:54 AM
To: Allyn Romanow (allyn)
Cc: DISPATCH list; Mary Barnes
Subject: Re: Telepresence Charter Version 3

I think this charter has some pretty serious issues with being way to
wide open on what the scope is. The fact we are actually discussing if
we need to add  in "Also not in scope is signaling to tell the
originator to which IP addresses the media streams should be sent"
should be a huge hint that we have the scope much too broad. As I said a
week ago .... 

> Main point:
> When I read this charter and ask myself what is out of scope, it seems
that anything that is "the information about media streams from one
endpoint to another endpoint or conference bridge including" would be in
scope. I realize a few more things are taken our of scope later but the
resulting space includes just about everything that MMUSIC does, and
much of what SIP does. Because of the "anything and everything" approach
I don't think this is a charter that will result in work that gets done
quickly. From the point of view of being broad enough to do the need
work, I think it's fine but from the point of view of being narrow
enough to limit the work to something that is possible to complete, it
seems pretty bad. I suspect that IESG would likely look at this as a
"blank cheque" charter and ask for some changes to it. My suggestion
would be just to change the "including (but not limited to):" in 3rd
paragraph to be 
> 
> This working group is chartered to specify the following information
about media streams from one endpoint to another endpoint:

Note I am not arguing that there any given piece of work you should not
do - I'm just encouraging you to say what problems you are going to do.

I would encourage you to specify what this working group is going to do,
like you have in the bullet points, and stop leaving it open to do
anything including the stuff in bullet points. We should do our best to
avoid charters that are so unspecific that they overlap with existing
WGs in ways that leave huge questions about which WG a new piece of work
should go to.

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 26 Aug 2010 16:30:38 -0700

WRT my previous note suggesting the change to Cullen's sentence, 
people should be clear that everything not in the charter is out of
scope. 
So please think about anything that you think we need to cover which is
not now explicitly called out in the charter.

thanks

-----Original Message-----
From: Cullen Jennings (fluffy) 
Sent: Thursday, August 26, 2010 8:54 AM
To: Allyn Romanow (allyn)
Cc: DISPATCH list; Mary Barnes
Subject: Re: Telepresence Charter Version 3

about media streams from one endpoint to another endpoint:

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 28 Aug 2010 07:27:42 -0600

Yah, I think that would solve my biggest concern about it. 

> Cullen <with my DISPATCH co-chair hat on>

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Sep 2010 08:56:42 +0200

Hi,
 
A question for clarification.
 
The proposed charter says that there exists telepresence systems based on different standards (SIP, H.xxx etc), and that today expensive
interworking equipment is required in order for these systems to interop.
 
But, how can you prevent such interworking? If whatever we specify is supposed to be backward compatible with standards compliant systems, you cannot assume that every system will support e.g. SIP.
 
Regards,
 
Christer

> Sent: 27. elokuuta 2010 2:31
> To: Cullen Jennings (fluffy)
> Cc: DISPATCH list
> WRT my previous note suggesting the change to Cullen's 
> sentence, people should be clear that everything not in the 
> charter is out of scope. 
> So please think about anything that you think we need to 
> cover which is not now explicitly called out in the charter.
> 
> thanks
>