Subject: [dispatch] Telepresence charter version 4

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 8 Sep 2010 14:10:23 -0700

Folks, 

Here is the fourth version of the charter for work on multiple streams
for Telepresence.

It addresses issues brought up on the mailing list. There is a list of
the changes at the end of the text.

Comments?

------

MALT - 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

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 for SIP-based conferencing systems 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 entity to another entity:

* 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

*Usage of the stream, for example whether the stream is presentation, or
document camera output

* 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 SIP and related standards for audio and video is
required.  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. 

Reuse of existing protocols and backwards compatibility with
SIP-compliant audio/video endpoints  are important factors 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  indicating
spatial relationships 

of  screens  cameras (including variable field of view and orientation),
speakers and microphones; and the "usage" of a stream as defined in the
charter.  Semantics, language and transport mechanism will be specified.

List of changes V3 to V4

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

[instead of The WG will create specifications to enable
communication...]

This working group is chartered to specify the information about media
streams from one entity to another entity 

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

[added] *Usage of the stream, for example whether the stream is
presentation, or document camera output

Interoperation with SIP and related standards for audio and video is
required.  

[instead of Interoperation with standards compliant systems is required,
such as SIP-based conferencing systems.]

Reuse of existing protocols and backwards compatibility with
SIP-compliant audio/video endpoints  are important factors for the
working group to consider.

[instead of Reuse of existing protocols backwards compatibility with
existing systems is  an important  factor for the working group to
consider.]

Milestones

Nov 2011 Submit standards track specification to IESG  indicating
spatial relationships of screens, cameras (including variable

field of view and orientation), speakers and microphones; and the
"usage" of a stream as defined in the charter e Semantics, language and
transport will be specified.

[Instead of 

Nov 2011 Submit standards track specification to IESG  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: "James M. Polk" <[email-masked]>
Date: Wed, 08 Sep 2010 16:31:23 -0500

At 04:10 PM 9/8/2010, Allyn Romanow (allyn) wrote:
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CB4F9A.43210F17"
>Content-class: urn:content-classes:message
>
>Folks,
>Here is the fourth version of the charter for 
>work on multiple streams for Telepresence.
>
>It addresses issues brought up on the mailing 
>list. There is a list of the changes at the end of the text.
>
>Comments?

a couple in-line below

james

>
>------
>
>
>
>MALT – 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
>
>
>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.

The use of the word "they" in above sentence can 
be mistaken to mean either TP systems or the open standards listed.

I suggest

         s/they/these systems

to make it clearer which you are referring to.

>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.

Is this text true if the TP systems have only 2 endpoints in the session?

I agree this becomes tricky when you get to 3 or 
more endpoints - but that isn't clear in the above text.

>In addition,  there is no standardized way to 
>exchange semantic information about what each media stream represents.
>
>The WG will create specifications for SIP-based 
>conferencing systems 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 entity to another entity:
>
>   Speakers – in relation to each other and to likely positions of
>   participants
>
>   for camera/microphone/display/speaker – so that senders and
>*Usage of the stream, for example whether the 
>stream is presentation, or document camera output
>
>* 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 SIP and related standards 
>for audio and video is required.  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.
>
>Reuse of existing protocols and backwards 
>compatibility with SIP-compliant audio/video 
>endpoints  are important factors 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 2011 Submit standards track specification to 
>IESG  indicating spatial relationships
>of  screens  cameras (including variable field 
>of view and orientation), speakers and 
>microphones; and the “usage” of a stream as 
>defined in the charter.  Semantics, language and 
>transport mechanism will be specified.
>
>
>
>List of changes V3 to V4
>
>The WG will create specifications for SIP-based 
>conferencing systems to enable communication..
>[instead of The WG will create specifications to enable communication…]
>
>This working group is chartered to specify the 
>information about media streams from one entity to another entity
>[instead of  This working group is chartered to 
>specify the information about media streams from 
>one endpoint to another endpoint or conference bridge including:]
>
>
>[added] *Usage of the stream, for example 
>whether the stream is presentation, or document camera output
>
>Interoperation with SIP and related standards 
>for audio and video is required.
>[instead of Interoperation with standards 
>compliant systems is required, such as SIP-based conferencing systems.]
>
>Reuse of existing protocols and backwards 
>compatibility with SIP-compliant audio/video 
>endpoints  are important factors for the working group to consider.
>[instead of Reuse of existing protocols 
>backwards compatibility with existing systems 
>is  an important  factor for the working group to consider.]
>
>Milestones
>Nov 2011 Submit standards track specification to 
>IESG  indicating spatial relationships of screens, cameras (including variable
>field of view and orientation), speakers and 
>microphones; and the “usage” of a stream as 
>defined in the charter e Semantics, language and transport will be specified.
>
>[Instead of
>Nov 2011 Submit standards track specification to 
>IESG  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.
>
>
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: stephen botzko <[email-masked]>
Date: Wed, 8 Sep 2010 18:02:21 -0400

I agree this becomes tricky when you get to 3 or more endpoints - but that
isn't clear in the above text.

It is absolutely true with 2 endpoints in a call.  There is no standard way
for the endpoints to know how to map the incoming audio/video streams to
their displays and speakers.

Stephen Botzko

On Wed, Sep 8, 2010 at 5:31 PM, James M. Polk <[email-masked]> wrote:

>> Here is the fourth version of the charter for work on multiple streams for
>> Telepresence.
>>
>> It addresses issues brought up on the mailing list. There is a list of the
>> changes at the end of the text.
>>
>> Comments?
>>
>
> a couple in-line below
>
> james
>
>
>
>> ------
>>
>>
>>
>> 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
>>
>>
>> immersive telepresence system using specially designed and special purpose
>> rooms with multiple displays permitting life size image reproduction using
>> 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.
>>
>
> The use of the word "they" in above sentence can be mistaken to mean either
> TP systems or the open standards listed.
>
> I suggest
>
>        s/they/these systems
>
>  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.
>>
>
> I agree this becomes tricky when you get to 3 or more endpoints - but that
> isn't clear in the above text.
>
>  In addition,  there is no standardized way to exchange semantic
>> information about what each media stream represents.
>>
>> 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.
>>
>> Information between sources and sinks about media stream capabilities will
>> be exchanged.
>>
>> consider whether the existing signaling mechanisms (e. g., SDP, BFCP) can be
>> extended, or another messaging method should be used.
>>
>> 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
>> media types may be considered, however development of methodologies for them
>> is not within the scope of this work.
>>
>> continuous conference control including: far end camera control, indication
>> of fast frame update for video codecs or other rapid switches, floor
>> control, conference roster.
>>
>> Reuse of existing protocols and backwards compatibility with SIP-compliant
>> audio/video endpoints  are important factors for the working group to
>> consider. The work will closely coordinate with the appropriate areas and
>> Nov 2011 Submit standards track specification to IESG  indicating spatial
>> relationships
>> speakers and microphones; and the “usage” of a stream as defined in the
>> Reuse of existing protocols and backwards compatibility with SIP-compliant
>> audio/video endpoints  are important factors for the working group to
>> consider.
>> Nov 2011 Submit standards track specification to IESG  indicating spatial
>> relationships of screens, cameras (including variable
>> field of view and orientation), speakers and microphones; and the “usage”
>> of a stream as defined in the charter e Semantics, language and transport
>> will be specified.
>>
>> [Instead of
>> Nov 2011 Submit standards track specification to IESG  indicating spatial
>> relationships of screens, cameras (including variable

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 08 Sep 2010 18:38:29 -0500

At 05:02 PM 9/8/2010, stephen botzko wrote:
>It is absolutely true with 2 endpoints in a 
>call.  There is no standard way for the 
>endpoints to know how to map the incoming 
>audio/video streams to their displays and speakers.

ok ok - I wasn't thinking (about 3-screen to 
3-screen) when I wrote this comment... sorry

james

>Stephen Botzko
>
>On Wed, Sep 8, 2010 at 5:31 PM, James M. Polk 
><<mailto:[email-masked]>[email-masked]> wrote:
>Interoperation with SIP and related standards for audio and video is required.
><mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>[email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 8 Sep 2010 22:55:00 -0400

On Sep 8, 2010, at 7:38 PM, James M. Polk wrote:

>> I agree this becomes tricky when you get to 3 or more endpoints - but that isn't clear in the above text.
>> >>>
>> 
>> It is absolutely true with 2 endpoints in a call.  There is no standard way for the endpoints to know how to map the incoming audio/video streams to their displays and speakers.
> 
> ok ok - I wasn't thinking (about 3-screen to 3-screen) when I wrote this comment... sorry
> 

Much less 3 screen to 4 screen, or 2 screen to 3 screen.

Marshall

> james
> 
> 
>> Stephen Botzko
>> 
>> On Wed, Sep 8, 2010 at 5:31 PM, James M. Polk <<mailto:[email-masked]>[email-masked]> wrote:
>> Here is the fourth version of the charter for work on multiple streams for Telepresence.
>> 
>> It addresses issues brought up on the mailing list. There is a list of the changes at the end of the text.
>> 
>> Comments?
>> 
>> 
>> a couple in-line below
>> 
>> james
>> 
>> 
>> 
>> ------
>> 
>> 
>> 
>> 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
>> 
>> 
>> 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.
>> 
>> 
>> The use of the word "they" in above sentence can be mistaken to mean either TP systems or the open standards listed.
>> 
>> I suggest
>> 
>>       s/they/these systems
>> 
>> 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.
>> 
>> 
>> I agree this becomes tricky when you get to 3 or more endpoints - but that isn't clear in the above text.
>> 
>> In addition,  there is no standardized way to exchange semantic information about what each media stream represents.
>> 
>> The WG will create specifications for SIP-based conferencing systems 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 entity to another entity:
>> 
>> *Usage of the stream, for example whether the stream is presentation, or document camera output
>> 
>> * 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 SIP and related standards for audio and video is required.  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.
>> 
>> Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints  are important factors 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 2011 Submit standards track specification to IESG  indicating spatial relationships
>> of  screens  cameras (including variable field of view and orientation), speakers and microphones; and the “usage” of a stream as defined in the charter.  Semantics, language and transport mechanism will be specified.
>> 
>> 
>> 
>> List of changes V3 to V4
>> 
>> The WG will create specifications for SIP-based conferencing systems to enable communication..
>> This working group is chartered to specify the information about media streams from one entity to another entity
>> [instead of  This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including:]
>> 
>> 
>> [added] *Usage of the stream, for example whether the stream is presentation, or document camera output
>> 
>> [instead of Interoperation with standards compliant systems is required, such as SIP-based conferencing systems.]
>> 
>> Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints  are important factors for the working group to consider.
>> [instead of Reuse of existing protocols backwards compatibility with existing systems is  an important  factor for the working group to consider.]
>> 
>> Milestones
>> Nov 2011 Submit standards track specification to IESG  indicating spatial relationships of screens, cameras (including variable
>> field of view and orientation), speakers and microphones; and the “usage” of a stream as defined in the charter e Semantics, language and transport will be specified.
>> 
>> [Instead of
>> Nov 2011 Submit standards track specification to IESG  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: Thu, 9 Sep 2010 02:52:55 -0400

It now looks good.

--Alex

On Sep 9, 2010, at 12:10 AM, Allyn Romanow (allyn) wrote:

Folks,

Comments?

------

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.

 Milestones

List of changes V3 to V4

Milestones

[Instead of

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

---

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

Allyn,

Can you explain the following:
"It will consider whether the existing signaling mechanisms (e. g., .... BFCP) can be extended, or another messaging method should be used"

and 

"This working group is not currently chartered to work on 
issues of continuous conference control including: .... floor control..." 

It is unclear to me how BFCP can be within scope yet floor control is out of scope.

John

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 9 Sep 2010 06:33:05 -0400

Hi,

Good catch. That is inconsistent.

I think the reference to BFCP can be removed.

Otherwise I think the charter is good to go.

Peter Musgrave

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 10 Sep 2010 15:42:46 +0200

I agree. BFCP itself needs ways (e.g. RFC4583) to correlate each stream
to the floor handling it, which is similar to what we want to achieve
in this new WG.

About limiting the scope to audio/video, why not rephrase it so that we
limit the scope to whatever can be sent via RTP? That would be less
strict, I guess, and allow for more flexibility.

For what concerns the name, I'm for MAITAI.

L.

On Thu, 9 Sep 2010 06:33:05 -0400

-- 
Lorenzo Miniero
Meetecho s.r.l.
http://www.meetecho.com/

---

From: Roni Even <[email-masked]>
Date: Fri, 10 Sep 2010 17:58:41 +0300

+1
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Musgrave
> Sent: Thursday, September 09, 2010 1:33 PM
> To: Elwell, John
> Cc: DISPATCH list
> Subject: Re: [dispatch] Telepresence charter version 4
> 
> Hi,
> 
> > "It will consider whether the existing signaling mechanisms (e. g.,
> .... BFCP) can be extended, or another messaging method should be used"
> >
> > and
> >

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 15 Sep 2010 10:42:10 -0700

In keeping with John's good catch, the reference to BFCP has been
removed. 
This was the only suggested change to the charter.

Thanks,
Allyn

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) can be
extended, or another messaging method should be used.  

 Milestones  

------------------------------------------------------------------------
--------
-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, September 09, 2010 12:31 AM
To: Allyn Romanow (allyn); DISPATCH list
Subject: RE: Telepresence charter version 4

Allyn,

Can you explain the following:
"It will consider whether the existing signaling mechanisms (e. g., ....
BFCP) can be extended, or another messaging method should be used"

and 

"This working group is not currently chartered to work on 
issues of continuous conference control including: .... floor
control..." 

It is unclear to me how BFCP can be within scope yet floor control is
out of scope.

John

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 16 Sep 2010 13:40:52 +0200

With a reference to a protocol for functionality (floor control) out
of scope removed, this charter looks fine to me :-)

Regarding name. Not that I'm associated with the temperance movement
or something, but instead of all those alcohol related names I think
it's nice for IETF to explicitly have (a) CLUE.

As proposed earlier;   CLUE ControLling mUltiple streams for TElepresence

-- Tom

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 16 Sep 2010 08:36:27 -0400

+1

Ambivalent about the name - but let's pick one and get going!

Peter Musgrave

---

From: [email-masked]
Date: Thu, 16 Sep 2010 11:21:54 -0400

This charter looks good to me, other than some minor editorial nits (details
of punctuation and spacing).  Would it be useful to comment on those, or
does the Secretariat take care of that?

-- 
Jonathan Lennox
[email-masked] / [email-masked]

---

From: Mary Barnes <[email-masked]>
Date: Thu, 16 Sep 2010 11:33:25 -0500

Hi Jonathan,

If you could please just send those offlist, we can get those fixed.

Thanks,
Mary.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 17 Sep 2010 16:16:59 -0400

I am happy with the charter.  I am partial to MAITAI, but all of them are fine.  Pick one and let's move on.

Brian

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Sep 2010 11:18:15 +0200

Hi,

One question for clarification. The text says:

"In addition, there is no standardized way to exchange semantic information about what each media stream represents."

Isn't that something RFC 4574 could be used for?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Allyn Romanow (allyn)
Sent: 15. syyskuuta 2010 20:42
To: Elwell, John; DISPATCH list
Subject: [dispatch] Telepresence charter version 5

In keeping with John's good catch, the reference to BFCP has been removed. 
This was the only suggested change to the charter.

Thanks,
Allyn

MALT - 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

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) can be extended, or another messaging method should be used.  

 Milestones  

Nov 2011 Submit standards track specification to IESG  indicating spatial relationships of  screens  cameras (including variable field of view and orientation), speakers and microphones; and the "usage" of a stream as defined in the charter.  Semantics, language and transport mechanism will be specified.

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, September 09, 2010 12:31 AM
To: Allyn Romanow (allyn); DISPATCH list
Subject: RE: Telepresence charter version 4

Allyn,

and 

John

---

From: Gerard Fernando <[email-masked]>
Date: Mon, 20 Sep 2010 10:05:31 +0000 (GMT)

Dear Allyn, All,
 
I see the statement on interoperability. However, I would guess that the most 
important aspect is  interoperability with H.323. If it's possible to explicitly 
state that in the charter then that could much help with the success of this 
work. I view the following reasons for inclusion of such a statement on H.323 
interoperability:

(a) It ensures that there's no perception of IETF neglecting this aspect of 
interoperability
(b) Bring in companies who have a focus on H.323 into the IETF activity. My 
understanding is that many vendors have products that use the H.323 suite of 
protocols.

Thanks

Gerard
---------

Gerard Fernando
ZTE Corporation

________________________________
From: Allyn Romanow (allyn) <[email-masked]>
To: "Elwell, John" <[email-masked]>; DISPATCH list 
<[email-masked]>
Sent: Wed, 15 September, 2010 10:42:10
Subject: [dispatch] Telepresence charter version 5

Thanks,
Allyn

Milestones  

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, September 09, 2010 12:31 AM
To: Allyn Romanow (allyn); DISPATCH list
Subject: RE: Telepresence charter version 4

Allyn,

and 

John

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 20 Sep 2010 06:37:19 -0400

Hi,

I can understand the motivation for that but I think it greatly
increases the scope - to the point where I think a separate WG is
called for.

I would suggest we get interoperability between systems which at least
have SIP in common and then see if the community has
interest/commitment to extending it to H.323 ina new WG.

Regards

Peter Musgrave

On Mon, Sep 20, 2010 at 6:05 AM, Gerard Fernando <[email-masked]> wrote:
> Dear Allyn, All,
>
> I see the statement on interoperability. However, I would guess that the
> most important aspect is  interoperability with H.323. If it's possible to
> explicitly state that in the charter then that could much help with the
> success of this work. I view the following reasons for inclusion of such a
> statement on H.323 interoperability:
>

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 20 Sep 2010 06:37:54 -0400

Hi Gerard,

IMHO the contributing members in ITU-T Q5/16 and the IETF work are already
well aware of the need to maintain H.323/SIP interoperability.

However, as you know, H.323 has no signaling for telepresence either.  It
seems problematic to create a charter mandate to interoperate with H.323
multistreams, since there is no way to assure this can be done until the
ITU-T consents such signaling.

So while I agree that H.323/SIP telepresence interoperability through
non-transcoding gateways is a desirable outcome, I think it is best to leave
this out of the charter.

Regards,
Stephen Botzko

On Mon, Sep 20, 2010 at 6:05 AM, Gerard Fernando <[email-masked]>wrote:

> ------------------------------
> *From:* Allyn Romanow (allyn) <[email-masked]>
> *To:* "Elwell, John" <[email-masked]>; DISPATCH list <
> [email-masked]>
> *Sent:* Wed, 15 September, 2010 10:42:10
>
> *Subject:* [dispatch] Telepresence charter version 5
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 20 Sep 2010 12:29:33 -0700

Hi Christer,

I think RFC label attribute may be useful; however, we would need to
establish and register set of tokens and the semantics of those tokens.
Once we get to the actual design, that would be worth considering.
Without addition specification, I think you would have proprietary sets
of labels being used at best.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
> Sent: Monday, September 20, 2010 2:18 AM
> To: Allyn Romanow (allyn); Elwell, John; DISPATCH list
> Subject: Re: [dispatch] Telepresence charter version 5
> 
> 
> Hi,
> 
> "In addition, there is no standardized way to exchange semantic
information about what each media
> stream represents."
Behalf Of Allyn Romanow (allyn)
removed.
> MALT - 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
> 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.
> 
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 for SIP-based conferencing systems
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.
> 
streams from one entity to
> another entity:
> * 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).
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) 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.
media types may be considered,
> however development of methodologies for them is not within the scope
of this work.
> Interoperation with SIP and related standards for audio and video is
required.  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
> Reuse of existing protocols and backwards compatibility with
SIP-compliant audio/video endpoints  are
> important factors for the working group to consider. The work will
closely coordinate with the
> Nov 2011 Submit standards track specification to IESG  indicating
spatial relationships of  screens
> cameras (including variable field of view and orientation), speakers
and microphones; and the "usage"
> of a stream as defined in the charter.  Semantics, language and
> "It will consider whether the existing signaling mechanisms (e. g.,
....

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 20 Sep 2010 20:49:36 -0700

Hi Gerard,

I’m in agreement with Peter and Steve’s notes.

As you may know the ITU has recently chartered a group to work on Telepresence. We are hoping that they will reference the work we do for handling multiple streams.

IMTC, the International Multimedia Telecommunications Consortium, an industry group, has been looking at specific aspects of interoperability between SIP and H.323  and made some recommendations. You may want to see what you think of the work they have done. 

As others have said, the charter here is focused specifically on specifying a common approach to handling multiple streams, rather than taking up a wider range of telepresence interoperability issues.

Best regards,

Allyn

From: Gerard Fernando [mailto:[email-masked]] 
Sent: Monday, September 20, 2010 3:06 AM
To: Allyn Romanow (allyn); DISPATCH list
Cc: Gerard Fernando; [email-masked]
Subject: Re: [dispatch] Telepresence charter version 5

Dear Allyn, All,
 
I see the statement on interoperability. However, I would guess that the most important aspect is  interoperability with H.323. If it's possible to explicitly state that in the charter then that could much help with the success of this work. I view the following reasons for inclusion of such a statement on H.323 interoperability:

(a) It ensures that there's no perception of IETF neglecting this aspect of interoperability
(b) Bring in companies who have a focus on H.323 into the IETF activity. My understanding is that many vendors have products that use the H.323 suite of protocols.

Thanks

Gerard
---------

Gerard Fernando
ZTE Corporation

From: Allyn Romanow (allyn) <[email-masked]>
To: "Elwell, John" <[email-masked]>; DISPATCH list <[email-masked]>
Sent: Wed, 15 September, 2010 10:42:10
Subject: [dispatch] Telepresence charter version 5

Thanks,
Allyn

Milestones  

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, September 09, 2010 12:31 AM
To: Allyn Romanow (allyn); DISPATCH list
Subject: RE: Telepresence charter version 4

Allyn,

and 

John

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Sep 2010 07:06:38 +0200

Hi Charles, 

>I think RFC label attribute may be useful; however, we would 
>need to establish and register set of tokens and the 
>semantics of those tokens.
>Without addition specification, I think you would have 
>proprietary sets of labels being used at best.

Yes, I agree that we would need to specify the labels.

My point was that there does exist a mechanism for doing so. So, maybe the text could say something like:

"In addition, standardization work, in order to be able to exchange semantic
information about what each media stream represents, might be needed."

Regards,

Christer

> > *Usage of the stream, for example whether the stream is 
> presentation,
> > "This working group is not currently chartered to work on issues of 
> > continuous conference control including: .... floor control..."
> >

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 20 Sep 2010 22:17:03 -0700

Hi Christer,

Thanks for pointing out that the original sentence is not strictly
accurate, and also not precisely what was meant. I think it is fine to
change the wording along the lines you suggest, can I get back to you
shortly on precise wording?  

Best regards,
Allyn

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, September 20, 2010 10:07 PM
To: Charles Eckel (eckelcu); Allyn Romanow (allyn); Elwell, John;
DISPATCH list
Subject: RE: [dispatch] Telepresence charter version 5

Hi Charles, 

My point was that there does exist a mechanism for doing so. So, maybe
the text could say something like:

"In addition, standardization work, in order to be able to exchange
semantic
information about what each media stream represents, might be needed."

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Sep 2010 07:19:28 +0200

Hi, 

>Thanks for pointing out that the original sentence is not 
>strictly accurate, and also not precisely what was meant. I 
>think it is fine to change the wording along the lines you 
>suggest, can I get back to you shortly on precise wording?  

Sure, no problem.

Regards,

Christer

> To: Charles Eckel (eckelcu); Allyn Romanow (allyn); Elwell, 
> John; DISPATCH list
> COCKTAIL -
> conferencing systems
> issues of

---

From: Roni Even <[email-masked]>
Date: Thu, 23 Sep 2010 02:28:20 +0200

Hi Christer
The label attribute helps with marking the stream but it does not describe
what the stream carries (semantics). RFC 4796 has the content attribute that
defines the semantics of the streams but does not cover the requirements for
the multiple streams case

Roni

> Sent: Monday, September 20, 2010 11:18 AM
> To: 'Allyn Romanow (allyn)'; Elwell, John; DISPATCH list
> information about what each media stream represents."
> 
> Communication and Correlation of Key Telepresence Attributes for
> Interoperable Links MAITAI - Multi-stream Attributes for Improving
> Encoding of QUalifiers for Interoperable Lifelike Applications MOJITO -
> Multi-stream Orientation for Joining of Interoperable Telepresence
> Operations
> 
> 
> reproduction using multiple cameras, encoders, decoders, microphones
> and loudspeakers.
> 
> 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
> there is no standardized way to exchange semantic information about
> what each media stream represents.
> 
> want the source for the left camera, or might want the source chosen by
> VAD (Voice Activity Detection).
> 
> 
> mechanism necessary for communicating the necessary information. It
> will consider whether the existing signaling mechanisms (e. g., SDP)
> Reuse of existing protocols and backwards compatibility with SIP-
> compliant audio/video endpoints  are important factors for the working
> group to consider. The work will closely coordinate with the
> spatial relationships of  screens  cameras (including variable field of
> view and orientation), speakers and microphones; and the "usage" of a
> stream as defined in the charter.  Semantics, language and transport
> mechanism will be specified.
> 
> 
>