Subject: Re: [dispatch] Telepresence charter version 5

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 24 Oct 2010 18:14:19 -0700

Hi Christer,

In reviewing this, I think it would be fine to just omit the sentence at
issue-
	In addition,  there is no standardized way to exchange semantic
information about what each 	media stream represents.  

Because I feel that the sentence just prior to it says adequately what
is necessary. It is
	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.

What do you think?

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

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

> -----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, 
> 
> >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.
> 
> 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
> 
> 
> 
> > > -----Original Message-----
> > > 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,
> > > 
> > > 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
> > > 
> > > 
> > > 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) 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.
> > > 
> > > 
> > > 
> > >
> > --------------------------------------------------------------
> > ----------
> > > --------
> > > -----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
> > > _______________________________________________
> > > dispatch mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > > _______________________________________________
> > > dispatch mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > 
>

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 24 Oct 2010 23:46:09 -0400

> comprise the media flows.

That would work for me. This sentence, however, has too many thats.

How about  

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.

Marshall

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 24 Oct 2010 22:40:05 -0700

Much improved. Will incorporate it in next version, which I hope to send
out Monday night.

Thanks,
Allyn 

> From: Marshall Eubanks [mailto:[email-masked]] 
> Sent: Sunday, October 24, 2010 8:46 PM
> To: Allyn Romanow (allyn)
> Cc: Christer Holmberg; Charles Eckel (eckelcu); Elwell, John; 
> DISPATCH list
> > In reviewing this, I think it would be fine to just omit 
> the sentence 
> > at
> > issue-
> 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.
> 
> Marshall
> 
> 
> > 
> > 
> > What do you think?
> > 
> > Best regards,
> > Allyn
> >> 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
> >>> 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.
> >> My point was that there does exist a mechanism for doing so. So, 
> >> maybe the text could say something like:
> >> 
> >> semantic information about what each media stream 
> represents, might 
> >> be needed."
> >> 
> >> Regards,
> >> 
> >> Christer
> >> 
> >> 
> >> 
> >>> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> >>> [mailto:[email-masked]] On Behalf Of Allyn Romanow 
> >>> (allyn)