Subject: [dispatch] Charter for Telepresence multi-streams - third version

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 4 Jul 2010 21:14:38 -0700

Folks,

This makes the change discussed replacing the text in the third paragraph under the Charter section with the text suggested on the list. 

It also changes title from "... Description of Work" to "...Charter"

There weren't any further changes suggested.

Thanks,

Allyn

 

Multi-streams for Telepresence Charter

Background

One branch of video conferencing has evolved that is focused on immersive "being there" experience.  Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments.  In recent years telepresence systems have seen considerable market success.  Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones.  These systems have several important characteristics that are different from more traditional video conferencing systems.  

The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the miking and camera angles at each of the sites . This is distinct from the more traditional approach where the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics.  

A second difference is manipulation of the environment to improve immersion.  With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating and lighting so that when combined with large high quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is created.  Typical video conference systems do not include these considerations.

As telepresence video systems have become successful in the market, manufacturers have started exploring delivery of the nonverbal communication and immersive values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, homes and kiosks. These are also  telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, and large coordinated multi image displays are available for immersive installations.   As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available.

Problem

Although telepresence systems are based on open standards such as RTP, SIP, H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vendor to another. It would be like having to make sure all parties are on the same equipment (and network) when making a telephone call.  A major factor in the inability of Telepresence systems to work with each other is that there is no standard description of the multiple streams that comprise the media flows. 

For example, in a multiple screen conference, the video and audio streams sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability to present the remote participants at their true size for their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously providing a spatial audio sound stage consistent with the video presentation.  The receiving device that decides how to display the incoming information needs to understand a number of variables such as the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media stream is related to each of the displays, etc. 

Charter

The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify for SIP-based systems the content of media multi-stream messages and the way these will be transported. 

This work will provide a standard for the exchange of media semantic information that will foster interoperable end stations and conference bridges. It will specify  variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability.  

This requires considering current widely deployed use cases, as well as cases that are expected to be implemented using the protocol framework produced by this work item.  The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technology and may have use cases that are not currently considered."

The work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required to be implemented to support this functionality.  The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be required.

Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and FECframe.

Scope

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 audio and video multiple 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.

The group will produce

- Requirements and use cases

- Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality required

- Specification of a new protocol to support telepresence multi-streams [if required]

Goals and Milestones

Nov 2010 

Use Cases and Requirements to IESG as Informational RFC 

Nov 2010

March 2011 

Problem Statement to IESG as Informational RFC

Architecture to IESG as Informational RFC 

March 2011

Revise Charter [IF new protocol is not required]

Nov 2011 

Submit protocol draft to IESG as Proposed Standard RFC

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Jul 2010 10:40:40 -0600

I'm wondering if we could get a thread going about what are some of the specific problems we  need to solve  then dispatch theses problems to appropriate WGs. 

For example one problem is when a session involves two video session on multiple screens how does one signal which stream is displayed on the right and left screen. 

I think having a list of specific problems would help get this moving faster. 

Cullen

On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote:

> It also changes title from “… Description of Work” to “…Charter”
>  
> There weren’t any further changes suggested.
>  
> Thanks,
> Allyn
>  
>  
>  
>  
> One branch of video conferencing has evolved that is focused on immersive “being there” experience.  Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments.  In recent years telepresence systems have seen considerable market success.  Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones.  These systems have several important characteristics that are different from more traditional video conferencing systems. 
>  
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

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

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 7 Jul 2010 12:40:52 -0700

Hi Cullen,

We just put out a problem statement draft -
http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat
ement-00. The document is not complete, but we feel it is a solid
beginning.  It does address the example you mention. The use case doc
also describes this case in some detail.
http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases
-00

Do you not feel that the problem statement draft can serve as a good
basis for discussion of problems?

Thanks,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cullen Jennings (fluffy)
Sent: Wednesday, July 07, 2010 9:41 AM
To: DISPATCH list
Subject: Re: [dispatch] Charter for Telepresence multi-streams -
thirdversion

I'm wondering if we could get a thread going about what are some of the
specific problems we  need to solve  then dispatch theses problems to
appropriate WGs. 

For example one problem is when a session involves two video session on
multiple screens how does one signal which stream is displayed on the
right and left screen. 

I think having a list of specific problems would help get this moving
faster. 

Cullen

On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote:

> Folks,
> This makes the change discussed replacing the text in the third
paragraph under the Charter section with the text suggested on the list.
> One branch of video conferencing has evolved that is focused on
immersive "being there" experience.  Referred to in various ways such as
virtual conferencing, telepresence or media spaces, early systems were
mainly research projects or business systems with limited deployments.
In recent years telepresence systems have seen considerable market
success.  Following the model of early systems, the first wave of
commercial systems have been typically located in specially designed
single-purpose rooms with multiple relatively large displays permitting
life size image reproduction, multiple cameras, encoders, decoders and
microphones.  These systems have several important characteristics that
are different from more traditional video conferencing systems. 
>  
> The first difference concerns controlling the visual viewpoint in
order to improve participant nonverbal communication. These systems
preserve essential group meeting characteristics such as eye contact,
group gestures, seating order and spatial audio by carefully
orchestrating the miking and camera angles at each of the sites . This
is distinct from the more traditional approach where the geometric
relationship between media streams is not used to preserve inter-stream
communication aspects such as eye contact and group dynamics. 
>  
> A second difference is manipulation of the environment to improve
immersion.  With telepresence systems, cinematographic aspects of the
local environment reproduction are carefully planned including color,
table shape, seating and lighting so that when combined with large high
quality displays, a strong sense of a "trompe l'oeil" or "being there"
immersive experience is created.  Typical video conference systems do
not include these considerations.
>  
> As telepresence video systems have become successful in the market,
manufacturers have started exploring delivery of the nonverbal
communication and immersive values of telepresence via smaller, less
expensive and more flexible video conferencing systems for a variety of
venues, such as individual offices, homes and kiosks. These are also
telepresence systems, since the audio and video quality is high enough
to allow clear image reproduction for nonverbal communication, they are
able to send and receive multiple media streams, and large coordinated
multi image displays are available for immersive installations.   As the
industry develops, the line between telepresence and video conferencing
may become blurred as nonverbal communication and immersive
installations become broadly available.
>  
> Problem
> Although telepresence systems are based on open standards such as RTP,
SIP, H.264, H.323 suite, they cannot easily interoperate with each other
without operator assistance and expensive additional equipment that
translates from one vendor to another. It would be like having to make
sure all parties are on the same equipment (and network) when making a
telephone call.  A major factor in the inability of Telepresence systems
to work with each other is that there is no standard description of the
multiple streams that comprise the media flows.
>  
> For example, in a multiple screen conference, the video and audio
streams sent from remote participants must be understood by receivers so
that they can be presented in a coherent and life-like manner. This
includes the ability to present the remote participants at their true
size for their apparent distance, while maintaining correct eye contact,
gesticular cues, and simultaneously providing a spatial audio sound
stage consistent with the video presentation.  The receiving device that
decides how to display the incoming information needs to understand a
number of variables such as the spatial position of the speaker, the
field of view of the cameras, the camera zoom, which media stream is
related to each of the displays, etc.
>  
> Charter
> The Telepresence Multi-Streams work item in DISPATCH is chartered to
define and specify for SIP-based systems the content of media
multi-stream messages and the way these will be transported.
>  
> This work will provide a standard for the exchange of media semantic
information that will foster interoperable end stations and conference
bridges. It will specify  variables that describe the semantics of the
media streams and the recommended behavior to achieve interoperability. 
>  
>  
> This requires considering current widely deployed use cases, as well
as cases that are expected to be implemented using the protocol
framework produced by this work item.  The methodology for describing
the variables must allow extensibility of the variables, since
telepresence is still a young technology and may have use cases that are
not currently considered."
>  
>  
> The work item will identify use cases, define requirements, and define
a method for describing and transporting information about multiple
media streams, including a specification of variables required to
support the use cases. This work item will consider the reuse of
existing IETF protocols and produce an architecture/protocol framework
document describing the protocols required to be implemented to support
this functionality.  The document will identify any enhancements
required to existing protocols as well as describing new protocol(s) for
interoperable multi-streams negotiation that may be required.
> 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 audio and video multiple 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.
> - Architectural Framework describing the protocols required to be
implemented to support this functionality and identifying existing
protocol enhancements and new protocol functionality required

Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jul 2010 00:46:15 -0600

Theses look great - I hope people on the list take some time to read them. 

Cullen Jennings

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 8 Jul 2010 06:45:48 -0400

Hi Allyn/Stephen,

I read through these. I think they do a good job of establishing scope and
raising issues and as a bonus they are very easy to read.

Is there a need to talk about interop with standard video SIP gear? If I use
a TP suite to call a desktop SIP client or a 1080p video conferencing
terminal is there anything about how that should behave that is worth
defining under this work or is that viewed as out of scope?

As for draft-romanow-dispatch-telepresence-use-cases-00.txt

1. (nit)

*"*This draft …" paragraph has a number of A's sprinkled in (typos?)

3. "We describe…display stream" I assume display stream is a stream from a
document camera (as distinct from video stream being from a participant
camera?). This term does not match the words used in the previous paragraph.

Thanks,

Peter Musgrave

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jul 2010 08:04:08 -0400

On Jul 8, 2010, at 6:45 AM, Peter Musgrave wrote:

> Hi Allyn/Stephen,
>
> I read through these. I think they do a good job of establishing  
> scope and raising issues and as a bonus they are very easy to read.
>
> Is there a need to talk about interop with standard video SIP gear?  
> If I use a TP suite to call a desktop SIP client or a 1080p video  
> conferencing terminal is there anything about how that should behave  
> that is worth defining under this work or is that viewed as out of  
> scope?
>

Read Section 4.2 in Use Cases

http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases-00#section-4.2

which deals with "1 screen units," which is of course what most  
videoconferencing currently is. Is that what you were looking for ?

Regards
Marshall

> "This draft …" paragraph has a number of A's sprinkled in (typos?)
>
> 3. "We describe…display stream" I assume display stream is a stream  
> from a document camera (as distinct from video stream being from a  
> participant camera?). This term does not match the words used in the  
> previous paragraph.
>
> Thanks,
>
> Peter Musgrave
>
>
> >> Relevant work to be drawn upon has been done in XCON, MMUSIC,  
> AVT, and
> > FECframe.
> >>
> >>
> >> Scope

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 8 Jul 2010 08:21:37 -0400

Hi Marshall,

4.2 is part of it - although there may be specific limitations that a VC
unit has that a one screen TP system does not. (Also, ideally there would be
a way to work with such legacy systems without them supporting new TP
features in SIP).

I am also interested in whether heterogenous mixes of TP rooms and legacy
SIP video units in multi-party conferences is something viewed as in charter
- or if it's better to keep things simple and just limit the scope to issues
of TP interop.

Regards,

Peter Musgrave

On Thu, Jul 8, 2010 at 8:04 AM, Marshall Eubanks <[email-masked]> wrote:

>> Is there a need to talk about interop with standard video SIP gear? If I
>> use a TP suite to call a desktop SIP client or a 1080p video conferencing

---

From: Håkon Dahle <[email-masked]>
Date: Thu, 8 Jul 2010 14:48:09 +0200

Peter -

I agree with you in that Section 4.2 only partly addresses the problem. It states: 
 
"The display sizes and camera fields of view at both sites are basically similar, such that each camera view is designed to show two people sitting side by side"

Section 4.2 hence implicitly addresses a single-screen immersive telepresence (TP) system, since it assumes similar camera view and screen size as the multi-screen TP room.

Heterogenous mixing of immersive TP rooms with "legacy" single screen/dual screen SIP and H.323  video units reflects a very typical use case: Most deployments will consist of a small number of immersive TP rooms (could be a mix of single and multi-screen), a larger number of regular meeting room system (single screen/dual screen), and an even larger number of high definition desktop voice & video appliances / video phones. 

In fact, the ability to mix in audio-only calls is also important. This is another very typical use case (whenever a large meeting is called, someone will not be able to attend in person due to travel - telephony is often the only option)

-h

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Musgrave
Sent: 8. juli 2010 13:22
To: Marshall Eubanks
Cc: DISPATCH list; Botzko,Stephen
Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion

Hi Marshall, 

4.2 is part of it - although there may be specific limitations that a VC unit has that a one screen TP system does not. (Also, ideally there would be a way to work with such legacy systems without them supporting new TP features in SIP). 

I am also interested in whether heterogenous mixes of TP rooms and legacy SIP video units in multi-party conferences is something viewed as in charter - or if it's better to keep things simple and just limit the scope to issues of TP interop. 

Regards, 

Peter Musgrave

Hi Allyn/Stephen,

I read through these. I think they do a good job of establishing scope and raising issues and as a bonus they are very easy to read.

Is there a need to talk about interop with standard video SIP gear? If I use a TP suite to call a desktop SIP client or a 1080p video conferencing terminal is there anything about how that should behave that is worth defining under this work or is that viewed as out of scope?

which deals with "1 screen units," which is of course what most videoconferencing currently is. Is that what you were looking for ?

Regards
Marshall

1. (nit)
"This draft ..." paragraph has a number of A's sprinkled in (typos?)

3. "We describe...display stream" I assume display stream is a stream from a document camera (as distinct from video stream being from a participant camera?). This term does not match the words used in the previous paragraph.

Thanks,

Peter Musgrave

Cullen Jennings

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jul 2010 09:17:48 -0400

On Jul 8, 2010, at 8:48 AM, Håkon Dahle wrote:

> Peter –
> “The display sizes and camera fields of view at both sites are  
> basically similar, such that each camera view is designed to show  
> two people sitting side by side”
>
> Section 4.2 hence implicitly addresses a single-screen immersive  
> telepresence (TP) system, since it assumes similar camera view and  
> screen size as the multi-screen TP room.

The attempt in the use cases document was to start with a simple case  
(4.1) and grow in complexity from there. So, 4.2 was deliberately kept  
close in nature to 4.1, which is why this (somewhat artificial)  
restriction. This could, of course, be changed...

Regards
Marshall

>
> Heterogenous mixing of immersive TP rooms with “legacy” single  
> screen/dual screen SIP and H.323  video units reflects a very  
> typical use case: Most deployments will consist of a small number of  
> immersive TP rooms (could be a mix of single and multi-screen), a  
> larger number of regular meeting room system (single screen/dual  
> screen), and an even larger number of high definition desktop voice  
> & video appliances / video phones.
>
> In fact, the ability to mix in audio-only calls is also important.  
> This is another very typical use case (whenever a large meeting is  
> called, someone will not be able to attend in person due to travel –  
> telephony is often the only option)
>
> -h
>
> 4.2 is part of it - although there may be specific limitations that  
> a VC unit has that a one screen TP system does not. (Also, ideally  
> there would be a way to work with such legacy systems without them  
> supporting new TP features in SIP).
>
> I am also interested in whether heterogenous mixes of TP rooms and  
> legacy SIP video units in multi-party conferences is something  
> viewed as in charter - or if it's better to keep things simple and  
> just limit the scope to issues of TP interop.
>
> Regards,
>
> Peter Musgrave
>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jul 2010 09:41:53 -0400

Dear Peter;

On Jul 8, 2010, at 8:21 AM, Peter Musgrave wrote:

> a VC unit has that a one screen TP system does not.

I am not aware of any; if you know of any, please let me know.

I define immersive telepresence as a system to make you feel that you  
and remote participants are in the same room.

Telepresence is a combination of telecommunications technology (high  
quality video, matching of audio and video handedness, etc.) and  
"stagecraft" (the layout and decor of the room, the inconspicuous  
locations of cameras and microphones, etc.). In this work at the IETF  
we will focus on the technology, and the stagecraft is out of scope.  
Most of the technological complications with telepresence occur  
precisely because you have multiple screens and multiple participants,  
so adding in single screen units doesn't IMO add too much complexity.

> (Also, ideally there would be a way to work with such legacy systems  
> without them supporting new TP features in SIP).
>

I feel that "heterogenous mixes" should be in charter.

On the scope of this work : there are vastly more videoconferencing  
units using H.323 than SIP, and whether or not we should worry about H. 
323 interop is something that I think should be decided in this  
charter discussion. (I am neutral about this; bringing in H.323 brings  
in a whole host of complications, but it is definitely the IPv4 of the  
videoconferencing world.)

Regards
Marshall

---

From: stephen botzko <[email-masked]>
Date: Thu, 8 Jul 2010 10:20:41 -0400

Hi Peter

Thanks for the feedback.

I agree that interop with standard video SIP gear will clearly be a
requirement.  Since people are finding the drafts unclear on that point, we
should clarify them.

As far as Marshall's comment on H.323 goes, if the telepresence systems
interoperate with normal SIP video endpoints, then they will also
interoperate with normal SIP<->H.323 gateways.

Stephen Botzko

On Thu, Jul 8, 2010 at 6:45 AM, Peter Musgrave <[email-masked]
> wrote:

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 8 Jul 2010 07:24:01 -0700

Hi Peter,
Thanks for your comments.
 
In answer to your questions - yes, I believe that interop with standard
video SIP is in scope. And yes display stream is from a document camera
- we can change to be consistent.
 
Allyn

________________________________

	From: Peter Musgrave [mailto:[email-masked]] 
	Sent: Thursday, July 08, 2010 3:46 AM
	To: Cullen Jennings (fluffy)
	Cc: Allyn Romanow (allyn); DISPATCH list; Botzko, Stephen
	Subject: Re: [dispatch] Charter for Telepresence multi-streams -
thirdversion

	Hi Allyn/Stephen,

	

	Is there a need to talk about interop with standard video SIP
gear? If I use a TP suite to call a desktop SIP client or a 1080p video
conferencing terminal is there anything about how that should behave
that is worth defining under this work or is that viewed as out of
scope? 

	

	1. (nit)

	"This draft ..." paragraph has a number of A's sprinkled in
(typos?)

	3. "We describe...display stream" I assume display stream is a
stream from a document camera (as distinct from video stream being from
a participant camera?). This term does not match the words used in the
previous paragraph.

	Thanks, 

	Peter Musgrave

	On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings
<[email-masked]> wrote:

		Theses look great - I hope people on the list take some
time to read them.

		>> Relevant work to be drawn upon has been done in XCON,
MMUSIC, AVT, and
		>> - Specification of a new protocol to support
telepresence
		> multi-streams [if required]
		>>
		>> Goals and Milestones
		>> Nov 2010
		>>

		Cullen Jennings

---

From: "Botzko, Stephen" <[email-masked]>
Date: Thu, 8 Jul 2010 07:27:24 -0700

Though "display stream" can be from a document camera, in general it can also be captured from a PC screen or some other source (such as DVD).  As Allyn indicates, it is not from a participant camera.

Stephen

________________________________
From: Allyn Romanow (allyn) [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 10:24 AM
To: Peter Musgrave; Cullen Jennings (fluffy)
Cc: DISPATCH list; Botzko, Stephen
Subject: RE: [dispatch] Charter for Telepresence multi-streams - thirdversion

Hi Peter,

In answer to your questions - yes, I believe that interop with standard video SIP is in scope. And yes display stream is from a document camera - we can change to be consistent.

Allyn

Hi Allyn/Stephen,

1. (nit)

Thanks,

Peter Musgrave

On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote:

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

Cullen Jennings

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Jul 2010 14:46:25 +0200

I agree it is important to make any enhancements to SIP/SDP backwards compatible with existing SIP/SDP in a way that can achieve meaningful interop with standard video using SIP. This must be within scope.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Allyn Romanow (allyn)
> Sent: 08 July 2010 15:24
> In answer to your questions - yes, I believe that interop 
> with standard video SIP is in scope. And yes display stream 
> is from a document camera - we can change to be consistent.
>  
> Allyn
> 
> 
> 	I read through these. I think they do a good job of 
> establishing scope and raising issues and as a bonus they are 
> very easy to read.
> 
> 	
> 	
> 
> 	Is there a need to talk about interop with standard 
> video SIP gear? If I use a TP suite to call a desktop SIP 
> client or a 1080p video conferencing terminal is there 
> anything about how that should behave that is worth defining 
> under this work or is that viewed as out of scope? 
> 
> 	
> 	
> 
> 	3. "We describe...display stream" I assume display stream 
> is a stream from a document camera (as distinct from video 
> stream being from a participant camera?). This term does not 
> match the words used in the previous paragraph.
> 
> 	
> 	
> 
> 	Thanks, 
> 
> 	
> 	
> 
> 	Peter Musgrave
> 
> 
> 
> 		>> Relevant work to be drawn upon has been done 
> in XCON, MMUSIC, AVT, and
> 		> FECframe.
> 		>>
> 		>>
> 		>> Scope

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 18 Jul 2010 13:57:56 -0400

On Jul 8, 2010, at 10:20 AM, stephen botzko wrote:

> requirement.  Since people are finding the drafts unclear on that  
> point, we should clarify them.
>
> As far as Marshall's comment on H.323 goes, if the telepresence  
> systems interoperate with normal SIP video endpoints, then they will  
> also interoperate with normal SIP<->H.323 gateways.

(From a discussion with Bob Dixon on the Megaco list.)

I must say I am not convinced - if a crucial part of Telepresence  
interoperability is the conveying of meta-data in a recognized fashion  
(i.e., what the room layout is, how people are placed in the room,  
etc., etc.), and that is not part of the current standards, then how  
in the world will that information get across the normal SIP<->H.323  
gateways to a H.323 telepresence unit ?

Regards
Marshall

---

From: stephen botzko <[email-masked]>
Date: Sun, 18 Jul 2010 14:12:00 -0400

Hi Marshall

When the IETF and the ITU-T *both* standardize multistreaming telepresence,
then we can meaningfully talk about how H.323<->SIP gateways perserve the
information. I think the interoperability burden for multiscreen will be on
the SDO that gets there last.

In the meantime, normal SIP<->H.323 gateways (single screen) will have to
do.  And I think it is all one can commit to today.

Stephen Botzko

On Sun, Jul 18, 2010 at 1:57 PM, Marshall Eubanks <[email-masked]>wrote:

> (i.e., what the room layout is, how people are placed in the room, etc.,
> etc.), and that is not part of the current standards, then how in the world
> will that information get across the normal SIP<->H.323 gateways to a H.323
> telepresence unit ?
>
> Regards
> Marshall
>
>
>
>
>
>> Stephen Botzko
>>
>> On Thu, Jul 8, 2010 at 6:45 AM, Peter Musgrave <
>> [email-masked]> wrote:
>> Hi Allyn/Stephen,
>>