[dispatch] Version 7 of Telepresence charter

"Allyn Romanow (allyn)" <allyn@cisco.com> Sun, 07 November 2010 00:02 UTC

Return-Path: <allyn@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34783A68E7 for <dispatch@core3.amsl.com>; Sat, 6 Nov 2010 17:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUsGkKx9lRPX for <dispatch@core3.amsl.com>; Sat, 6 Nov 2010 17:02:12 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 645793A68C7 for <dispatch@ietf.org>; Sat, 6 Nov 2010 17:02:12 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAM6J1UyrR7H+/2dsb2JhbACBaKAicaA6mk6CcYJXBIFagn6JDQ
X-IronPort-AV: E=Sophos; i="4.58,308,1286150400"; d="scan'208,217"; a="289478658"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2010 00:02:29 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA702QNk004072 for <dispatch@ietf.org>; Sun, 7 Nov 2010 00:02:29 GMT
Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 6 Nov 2010 17:02:28 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7E0F.10A1365A"
x-cr-puzzleid: {33D9EC89-89B1-4A4C-8A33-CEBAFC5B838B}
x-cr-hashedpuzzle: 27o= AjPV Aska AxOS A1IA CXt9 D76A EWY8 FowK GNkE Gl2u IOeF Iij5 IjLE JACO JGtL; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {33D9EC89-89B1-4A4C-8A33-CEBAFC5B838B}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sun, 07 Nov 2010 00:02:24 GMT; VgBlAHIAcwBpAG8AbgAgADcAIABvAGYAIABUAGUAbABlAHAAcgBlAHMAZQBuAGMAZQAgAGMAaABhAHIAdABlAHIA
Content-class: urn:content-classes:message
Date: Sat, 6 Nov 2010 17:02:24 -0700
Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02D9980A@xmb-sjc-221.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Version 7 of Telepresence charter
Thread-Index: Act+Dw5bRdwWueBFSZaDncTvqn04Jg==
From: "Allyn Romanow (allyn)" <allyn@cisco.com>
To: <dispatch@ietf.org>
X-OriginalArrivalTime: 07 Nov 2010 00:02:28.0421 (UTC) FILETIME=[10F3BF50:01CB7E0F]
Subject: [dispatch] Version 7 of Telepresence charter
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2010 00:02:22 -0000

Folks,

I got some offline comments about the charter.

Here they are with the changes in response to the comments, followed by
version 7.

Please consider them.

 

Regards,

Allyn

 

----------

 

Changes from Version 6

Change "This working group is chartered to specify  information" to
"This working group is chartered to specify the following information"

 

Change 

"Specific characteristics such as viewpoint" to "Specific the following
characteristics: viewpoint"

 

The framework and requirements and much of the protocol work should be
done in this WG but if the something like a new SDP attribute needs to
be defined, I think that work of extending SDP should be taken to
MMUSIC. It needs to be clear if this WG or MMUSIC will be doing changes
to SDP.  Changed text to:

It will consider whether existing protocols for signaling, messaging and
transport are adequate or need to be extended. Any changes to IETF
protocols, or new protocols, will be done in appropriate WGs, such as
MMUSIC for SDP, or AVT for transport.

 

Clarify that providing the location of the current speaker relative to
display microphones needed to be provided dynamically as the speaker
moved. Added : Specifying the location of the current speaker relative
to display microphones needed to be provided dynamically as the speaker
moves.  

 

Following  on Magnus' comments pointing out the importance of feedback
to the sender - The intention seems to be to do Video Pause in the media
path and explicit receiver notification to the sender of desired video
stream. There should be one or two bullet points for these. You probably
need to reconsider the text around "fast frame update" being out of
scope as a pause/unpause is likely exactly that.  Added

As part of the receiver telling the sender what it wants dynamically,
explicit receiver notification to the sender of the desired video stream
and video pause will be considered.

Removed fast frame update from the out of scope list.

 

Magnus - comment Oct 13 - want which speakers included as well as the
"active" speaker - sometimes get seen and get heard alg. Changed to

It also includes handling more dynamic relationships, such as specifying
the audio and video streams for defined speakers. Specifying the
location of the current speakers relative to display microphones needs
to be provided dynamically as speakers move.  

 

change

"multiple audio and video streams"  to "multiple RTP audio and video
streams"

 

============================

 

MAITAI - Multi-stream Attributes for Improving Telepresence Application
Interoperability

CLUE -- ControLling mUltiple streams for 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
limiting the interoperability of telepresence systems  is the lack of a
standardized way to describe and negotiate the use of the multiple
streams of audio and video comprising the media flows.

 

The WG will create specifications for SIP-based conferencing systems to
enable communication of  information about media streams so that a
sending system,  receiving system, or intermediate system can make
reasonable decisions about transmitting, selecting, and rendering media
streams. This enables systems to make choices that optimize user
experience.

 

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

 

* Spatial relationships of cameras, displays, microphones, and
loudspeakers - relative to each other and to likely positions of
participants

 

* Viewpoint, field of view/capture for
camera/microphone/display/loudspeaker - so that senders and intermediate
devices can understand how best to compose streams for receivers, and
the receiver 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 for communicating the necessary information. It will consider
whether existing protocols for signaling, messaging and transport are
adequate or need to be extended.  Any changes to IETF protocols, or new
protocols, will be done in appropriate WGs, such as MMUSIC for SDP, or
AVT for transport.

 

The scope of the work includes describing relatively static relations
between entities (participants and devices). It also includes handling
more dynamic relationships, such as specifying the audio and video
streams for defined speakers. Specifying the location of the current
speakers relative to display microphones needs to be provided
dynamically as speakers move.  

 

As part of the receiver telling the sender what it wants dynamically,
explicit receiver notification to the sender of the desired video stream
and video pause will be considered.

 

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 RTP 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,
floor control, conference roster. The working group may identify
interoperability obstacles in existing open standards. If so, the WG
will develop requirements to be communicated to other IETF WGs or
Standards Forums, or recharter as appropriate.

 

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 (e. g., OPS, SEC), and working groups including  AVT,
MMUSIC, MEDIACTRL, XCON, and SIPCORE.

 

 Milestones  

 

July 2011 Submit informational draft to IESG on use cases 

 

July 2011 Submit informational draft to IESG on framework and
requirements

 

Nov 2011 Submit standards track specification(s) to IESG to support
framework and requirements