Subject: [dispatch] Version 8 of Telepresence charter

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Tue, 9 Nov 2010 07:07:57 -0800

There is one small change of wording.

Hopefully, this is the draft we will go over during the meeting on
Thursday.

Thanks everyone for good comments-

Allyn

---

Changes from Version 7

change the following:

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.

To:

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

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

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 will be
done in appropriate WGs, for example extensions to SDP in MMUSIC.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 04:45:30 +0800

> protocols will be done in appropriate WGs, for example extensions to SDP

Overall it looks good. The latest modification raises a question for me:
is an extension to SDP really a change to an IETF protocol? If we've
designed our protocols well, an extension is not a change to an existing
protocol, but an optional and backward-compatible feature placed on top
of a more stable core. If we're really going to be *changing* existing
IETF protocols like SIP or SDP or RTP (requiring efforts like 3261bis or
4566bis or 3550bis) then I think we need to be very clear on that up
front. If we're only going to be *extending* or *enhancing* existing
IETF protocols, then I think people (in particular, folks on the IESG)
will be a lot more comfortable with the proposed scope.

Can we move from "any changes to IETF protocols" to "any extensions to
existing IETF protocols"?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/