Subject: [dispatch] Comments on the proposed Telepresence Charter

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Oct 2010 15:47:01 +0200

Hi,

Some colleagues and I have reviewed the two telepresence drafts and
version 5 of the charter and have some comments on the charter.

To make our comments more understandable I think we should explain our
view on telepresence. First we are expecting great variations in the
capabilities of the participating terminals in a session. From personal
terminals for individual users up to multi-display, cameras and
microphone setups. We also expect that more than two end-points being
present in the same session. As we see it it will require good support
for centralized media handling in a mixer (MCU). We also see video
streams not only of high quality to be presented for maximum immersion,
but also lower qualities that can be used to monitor activity in other
rooms that aren't the ones selected for high quality.

Independent if one uses a central mixer or a full mesh there appears to
be a lack in media stream negotiation for how to negotiate what
capabilities the receiving client has in receiving, decoding and
rendering when it comes to number of simultaneous streams. Our
understanding is that RTP mandates any number of streams, while in
reality outside of conferencing that is in fact one single stream.
However with telepresence and conferencing there is a need to negotiate
the actual capability, especially between a mixer and client when it
comes to deliver multiple streams for various usages.

We also think there is missing functionality for expressing who are the
currently active speakers. The RTP CSRC field are not sufficient as they
express which end-points are included in the mix. However, as one likely
include in a mix more rooms than the active speakers to ensure that any
interruption and ambient sound are correctly captured an mechanism for
indicating the currently active speakers are needed. There is also need
to agree on the type of identifier to be used that allow for mapping to
full user names when appropriate.

The charter includes an item to work on control between client and a
mixer what streams should be delivered. We would like to extended this
to allow also the mixer to control the client on when streams are
delivered. In cases where there are more users then available display
area and a particular user is not actually included in any outgoing
mix/selection from the mixer then there is little point in that the
client consumes network resources. Thus we suggest that the stream
selection and control work is extended to allow also the mixer to pause
individual streams from the client to the mixer. Please note that such
control needs to be responsive, thus using the SIP signaling path for
this is to slow, it needs to be on the media path.

Another question to the group is, are there agreement on how streams
should organized into RTP sessions and how they are utilized? If
anything is documented I would appreciate a pointer. The media streams
are for different purposes from different end-points which are then
mixed by a central point and delivered to end-points. My impression for
example is that most proprietary system breaks the RTP semantics and use
individual sessions between the mixer and each end-point, instead of a
joint session. Here also different robustification tools for RTP such as
FEC and Retransmission needs to be considered. This might be work that
belongs in AVT, but are there need for further clarification into this
field?

Comments much appreciated and we can gladly suggest text additions to
the charter proposal.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 12 Oct 2010 11:37:04 -0400

Hi Magnus,

I concur with your viewpoints on highly diverse endpoints, multi-point
(up to and including mesh connections).

I have more specific comments inline.

There is only one point below which I think requires language in the
charter. Please see if you agree.

Regards,

Peter Musgrave

> rooms that aren't the ones selected for high quality.
Agreed.

> comes to deliver multiple streams for various usages.
Agreed. The charter does speak to identifying endpoint capabilities
and I view what you describe here as the kind of meta-information
which needs to fit into that framework.

> full user names when appropriate.
I agree with this. In my opinion this is a separable problem since it
applies to generic audio conferencing as well. There is tangential
work in the conference event package and probably in the XCON stuff -
but I lack detailed background in XCON.

In the context of the TP charter I think the work on indicating which
audio stream is associated with which speaker (or part of the room) is
a slightly different issue - since it's about which stream and not
which speaker within a stream.

> this is to slow, it needs to be on the media path.
I concur.

The charter sentence:
 "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. "

is specific to selection of streams and not to the ability to control
them. I don't see anything here which prevents a source from not
sending selected streams - but I have no objection to making this more
explicit. How about adding:

"Selection choices will be communicated to the sending party to allow
the sender to optionally present information on which streams are in
use and to optionally suspend streams which are not in use." ??

> belongs in AVT, but are there need for further clarification into this
I think this is something which will have to be thought through and
standardized if TP interoperability is to succeed. I would view the
semantics of how the streams are assigned in scope and the "plumbing"
either comes from the AVT/MMUSIC media cap stuff or any additions are
developed in those WGs.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Oct 2010 11:11:11 +0200

Hi Peter,

Good that we are in agreement on a number of things. Response and
clarifications inline.

> which needs to fit into that framework.

Okay, as long as this is included in the thinking about capabilities I
am fine. However, the charter proposal isn't particular detailed in this
regards. But I guess the following charter text is matching this:

"Information between sources and sinks about media stream capabilities
will be exchanged."

> which speaker within a stream.

I should probably have been clearer. I am concerned that even on media
stream level there is missing functionality to indicate which streams
that contains active speakers and has been included in a mix produced by
the mixer. From our side we see a difference between being included in
the mix and being tagged as currently an active speaker.

I think this is currently missing functionality for which requirements
needs to be agreed on and then a solution developed. However, the
solution might better fit another WG, like AVT. But I think that is for
later determination. I think the requirements phase makes sense to have
in the Telepresence group.

I do agree that such functionality do have a wider usage scope than just
telepresence and can be used in any case of centralized mixers where
special activity needs to be pointed out, with audio being the foremost
example of such media.

> use and to optionally suspend streams which are not in use." ??

When I wrote the above comment I was mostly considering the following
chart text bullet:

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

I think your proposed text combined with the above bullet gives all the
room I see needed for media stream control. However, maybe a
modification of the above to make it clear.

* Which sources a receiver or mixer wants to have transmitted.  For
example, it might want the source for the left camera, or might want the
source chosen by VAD (Voice Activity Detection).

> either comes from the AVT/MMUSIC media cap stuff or any additions are

I agree with that the right place to do specification work is likely
these two groups. However, I think telepresence needs to provide
requirements for such work. Making such requirement development explicit
in the charter would make it clear that we do expect work to happen
somewhere else. At the same time it is after all possible to request
that another WG's charter is updated to cover such work.

The WG may identify interoperability obstacles in existing open
standards. The WG may develop requirements to be communicated to other
IETF WGs or Standards Forums as a kind request to try to meet these
requirements.

Cheers

Magnus Westerlund

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 13 Oct 2010 06:30:01 -0400

HI Magnus,

I have no issues with your proposed changes to the wording.

As for the rest I believe we are in agreement.

Regards,

Peter

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 13 Oct 2010 09:47:38 -0700

Hi Magnus,
I was really glad that you had a chance to carefully consider the proposed work.
Like Peter, I too agree with most of your comments.
Specific points below.

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Tuesday, October 12, 2010 6:47 AM
To: [email-masked]
Subject: [dispatch] Comments on the proposed Telepresence Charter

Hi,

[AR] Yes, absolutely.

[AR] Yes, agree - as you saw, this is covered in the charter.

[AR] Yes.. Both of these points are covered in the charter too, right?

[AR} I agree with your point that it would be good to pause the sender, but I think that falls
 under the category of "continuous conference control" which is out of the scope of this charter.
 Such a feedback mechanism falls probably under AVT.
I think it would be good to add a sentence saying something like, As control issues 
necessary for interoperability arise, they will be directed appropriately.
What do you think?

[AR} Agree this needs to be worked out for Telepresence, and that any activity about it would go to AVT and/or MMUSIC.

Cheers

Magnus Westerlund

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 14 Oct 2010 05:25:28 -0400

HI Allyn/Magnus,

W.R.T

"[AR} I agree with your point that it would be good to pause the
sender, but I think that falls
 under the category of "continuous conference control" which is out of
the scope of this charter.
 Such a feedback mechanism falls probably under AVT.
I think it would be good to add a sentence saying something like, As
control issues
necessary for interoperability arise, they will be directed appropriately.
What do you think?"

I think these words leave room to *not* do what Magnus is suggesting.
e.g. If I have a 1 screen home TP system getting three streams from a
3 camera system and selecting only one it is not really "necessary" to
tell the 3 camera system to pause two streams - but it is a really
good idea to have a way to that! I don't view this is a continuous
conference control issue (since that gets into floor control which I
agree is out of scope) but more like onhold/offhold type negotiation.
I think this is to some extent a plumbing issue (and based on the
desired response time SIP or media path messages will be required).

So I would still like to see a statement which makes it clear that it
not just an issue of receiver selection but there is a need to
communicate that selection back to the sender. The current text does
not say this. Hence my suggestion:

I'm open to other words or some indication of which language in the
current charter ensures this is in scope.

Regards,

Peter Musgrave

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 14 Oct 2010 08:46:08 -0500

Peter,

I have not issue with your proposed words, since they are essentially asking for a "mute" button for all types of communications used by a sender.  This may complicate the algorithm for all the receive systems to know what to display, if for example, you continue to speak, but turn off the video transmission.  A "mute all" option might be more polite.

I did have issue with this comment:  "more like onhold/offhold type negotiation"

I am not sure I would agree with this.  

There needs to be a distinction between when a call starts and when a call stops, the call being *all* communications (sessions) between two points.  Granted putting a call on hold seems like floor control, but the participants of the call on hold are effectively out of the call (left the room) until brought off-hold.  This is SIP level action.

There needs to be a clear distinction between negotiating capabilities, aka knowing what capabilities an endpoint has, and using those capabilities during a call.  That learning process is done via SDP.

The latter part seems to be floor control, continuous conference control, or whatever you want to call it.  There seems to be splitting of hairs over whether the floor control is manual or automatic (determined by the loudest speaker).  This may be AVT.

In summary, you have room access, you define capabilities, you have "speaker" conflict resolution control.  (Note, point-to-point calls are devolution since resolution of conflict is a non-problem with only one opposing party.)

Did I miss some other nuance?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Musgrave
Sent: Thursday, October 14, 2010 5:25 AM
To: Allyn Romanow (allyn)
Cc: [email-masked]
Subject: Re: [dispatch] Comments on the proposed Telepresence Charter

HI Allyn/Magnus,

W.R.T

Regards,

Peter Musgrave

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 14 Oct 2010 16:49:14 +0200

Hi,

let me jump into the "mute" (aka on-hold/off-hold) discussion. I would 
suggest that BFCP can be fruitfully employed here. BFCP can surely 
provide the mixer with a chance to add/remove streams to the mixed flow 
by using a policy-based approach. With respect to the issue raised in 
this thread, which I report here for brevity:

> We would like to extended this

I would say that also here BFCP might play a role. If the mixer, acting 
as a floor control server, removes the floor from a BFCP-aware client, 
such client is expected (even though it is not required) to stop sending 
data to the mixer, since it can be sure that such contribution will not 
be taken into account when building up the mix.

Simon

Il 14/10/2010 15.46, Mike Hammer (hmmr) ha scritto:
> On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn)<[email-masked]>  wrote:
>    
>> Hi Magnus,

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 14 Oct 2010 10:54:30 -0400

Hi Mike,

I agree the onhld/offhold analogy is a poor one. It is a suspension of
a call - which is not intended.

Let me re-phrase and see if we agree:

A sends B three video streams and one audio stream .
B has one display and opts to display one of the three streams.
There is a mechanism for B to tell A that this has happened (and to
say when it wishes to display some other stream from A).

Do we think that the work to do this type of stream-suspension is
floor control? (My opinion is no. I view floor control more as who is
the source for a given stream and not a selection of an agreed upon
stream).

Do we think this work is in scope for Telepresence Interoperability? I
think this is an essential element to deployable TP operation
especially as in expands to "at home" use. If an architecture in which
a room sends all video all the time (even though it's not being used)
is viewed as necessary to avoid complexity/meet responsiveness
requirements is thought to be ok then I'd like to make sure we are
clear that that these limitations exist upfront.

My preference is obviously to permit this feedback and tweak the
proposed charter.

Other opinions?

Regards,

Peter Musgrave

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 14 Oct 2010 10:55:11 -0500

Simon,

Agree that SIP is likely too slow.  Plus my concern that it's connection into other back-end systems (e.g. accounting) might affect those secondary systems.

I agree that BFCP might be able to provide needed capabilities, and thus should not be excluded by the charter.

However, when studying the problem space, I would hope we would not be too constrained by earlier designs, if more recent experience might suggest a different approach.  

For example, we gained advantages by separating the signaling and media planes for VoIP.  Here too, we might find that it is useful to separate out into different protocols the aspects of:
- declaring media control powers (who is capable of MCU mixing)
- selection/assignment of powers to a particular device
- passing of powers (e.g. host or presenter) from one device to another
- execution of powers at a particular point
- response to power assertion by non-power devices.

Note, that some of the above could be done in SDP with Offer/Answer, some could be power agreements in some signaling protocol, and some could be media plane controls.  In essence, the (floor control) policy control and policy execution could be split into two or three planes.

My point here is not to agree to any such thing at this time, only the recognition that the existing protocols may prove deficient, and though overlapping, the WG should be allowed the latitude to do the smart thing and not be overly constrained.  I am sure the AD's can help guide the WG, if they see it getting too far out of bounds.

Thanks,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Pietro Romano
Sent: Thursday, October 14, 2010 10:49 AM
To: [email-masked]
Subject: Re: [dispatch] Comments on the proposed Telepresence Charter

Hi,

Simon

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 14 Oct 2010 17:55:49 +0200

Hi Peter,

I also see it as an important use case to have in the charter. I agree
that floor control (e.g. BFCP) may not be needed in here (not an
authorization scenario) even though it may come in handy and as such
could at least be considered when we'll be talking about solutions.

>From a "technical" point of view, I guess that, if we find a way to
identify streams (what is what) then even just SDP updates may do the
trick then: e.g., video 1 recvonly, video 2 and 3 inactive. But this
would imply implicit feedback (I'm just telling I want one video out
of three, and not why), and so may be restrictive for the use case.

L.

On Thu, 14 Oct 2010 10:54:30 -0400

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

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 14 Oct 2010 11:08:40 -0500

Peter,

I see who is the source of a given stream as something that is a declared capability at the beginning of the call.

Floor control IMHO is the "green light" to transmit content onto the wire (floor).

In the 2-way case you describe, the floor controller is the receiver, in this case the end-consumer versus the MCU.

I don't see these models as being incompatible and do think discussion should be allowed in the charter.

I also agree that it is goodness *not* to waste network bandwidth if no one will render it at a receive point.

So, hope the charter allows that.

Thanks,
Mike

-----Original Message-----
From: Peter Musgrave [mailto:[email-masked]] 
Sent: Thursday, October 14, 2010 10:55 AM
To: Mike Hammer (hmmr)
Cc: Allyn Romanow (allyn); [email-masked]
Subject: Re: [dispatch] Comments on the proposed Telepresence Charter

Hi Mike,

Other opinions?

Regards,

Peter Musgrave

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 14 Oct 2010 16:23:54 -0700

Hi Magnus,
You have made some very helpful points. In particular you've pointed out that the charter talks about the receiver's ability to respond, but not the sender's. Also the charter is not explicit about necessary discussion of Telepresence interoperability issues that are not within the charter of the multi-stream WG to do anything about.   

I'd like to propose some wording in the charter that I think will address your concerns. See what you think- some of the wording is yours :)..

Instead of

	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.
I propose
	The WG will create specifications for SIP-based conferencing systems to enable 	communication of enough information about each media stream so that each sending system, 	receiving system, or bridge system can make reasonable decisions about transmitting, 	selecting, and rendering media streams. This enables systems to make choices that 	optimize the "just like being there" experience.

I would not like to change:
	* 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).
To the proposed:
	* Which sources a receiver wants transmitted.  For example, it might want the source for 	the left camera, or might want the source chosen by VAD (Voice Activity Detection).

Because there are multiple receivers. A receiver cannot say what should be transmitted, it can only say what itself wants to get, or receive. But I think your concern about sender behavior is covered by the changes to the paragraph above.

I also propose the following addition:
	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. The working group may 	identify interoperability obstacles in existing openstandards. If so, the WG will develp 	requirements to be communicated to other IETF WGs or Standards Forums as a kind request 	to try to meet these requirements.

What do you think?

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Wednesday, October 13, 2010 2:11 AM
To: Peter Musgrave
Cc: [email-masked]
Subject: Re: [dispatch] Comments on the proposed Telepresence Charter

Hi Peter,

Cheers

Magnus Westerlund

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 15 Oct 2010 05:49:58 -0400

Hi Allyn,

This text works for me.

Thanks,

Peter Musgrave

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 13:17:29 -0400

Discussions of putting something "on-hold/off-hold" in the context of 
sip are necessarily imprecise. SIP really has no concept of hold - it is 
an application level issue.

SIP has mechanisms for negotiating how media streams are used, and those 
are often *used* to accomplish a hold feature. But the recipient of an 
offer that manipulates a=sendonly/... does not know if this is because 
of "hold" or something else. And those mechanisms are per-media-stream. 
Most of the examples people are familiar with are on calls that only 
have one media stream, so on can be sloppy and think it is about the 
call as a whole, but that isn't so. As soon as you add a 2nd media 
stream, you have the potential to negotiation the directionality of the 
media independently for each m-line.

Bottom line - IMO its perfectly fine for telepresence devices to use the 
same mechanism to negotiate the directionality (or inactivity) of 
individual media streams. That mechanism *might* be used as part of 
floor control policy (if done by a focus), or not (if done by a regular 
endpoint that just doesn't want to receive stuff it is ignoring.)

	Thanks,
	Paul

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 15 Oct 2010 15:22:21 -0500

Paul,

I can also drive a screw with a hammer.  That doesn't mean it is the right tool.  :)

In this case, I am not so certain that the use of a 3-way handshake is necessary.

In any case, I think the charter allows us the flexibility to make an informed decision.

Cheers,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
Sent: Friday, October 15, 2010 1:17 PM
To: [email-masked]
Subject: Re: [dispatch] Comments on the proposed Telepresence Charter

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 18:51:42 -0400

> In any case, I think the charter allows us the flexibility to make an informed decision.

I'm not saying its the only way, or the best way for the purpose, but 
its certainly a candidate.

And it can be 2-way rather than 3-way (with UPDATE).

	Thanks,	
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 24 Oct 2010 12:54:46 +0200

Hi Allyn,

That way of getting it into the charter is fine with me.

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 24 Oct 2010 13:03:51 +0200

Hi,

Sorry for the delay in responding.

When it comes to controlling the mix, that is clearly a dynamic control.
A user must be able to basically click or select a particular user as
the one it currently finds most important, and then at some point later
do another selection or go back to letting the mixer do the selection
based on activity.

I don't know the background to the charter paragraph:
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.

But, I guess what I believe is needed will fall under the part of
continuous conference control. I don't see the SIP signalling path work
as this is something that has the potential for being updated often
during a session's duration, and also should be quickly responsive.

If we can't change the charter to perform work on stream selection in
mixers, then can the Telepresence group at least work on requirements
that can be thrown over the wall to some other WG? I also think we need
to have some discussion where this would be appropriate, or if even a
new WG is needed for that topic.

I know that we within Ericsson has been discussing something that is an
extension to BFCP.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 24 Oct 2010 07:31:42 -0400

Hi Magnus/Mike:

Allyn had previously proposed:
" also propose the following addition:
       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. The working group may identify
interoperability obstacles in existing open standards. If so, the WG will
develp        requirements to be communicated to other IETF WGs or Standards
Forums as a kind request to try to meet these requirements.
"

Here the "..will define requirements..." applies to interoperability
obstacles.  I would regard a single panel system having a way of determining
dynamically which video stream it gets from a multi-video source as an
interoperability issue. Hence I would view this as "in scope".

I agree that on-demand media source selection will be a critical
requirement. Personally, I view it as quite different from floor control so
I'm not sure I'd start with BFCP - but I think that discussion makes more
sense when the requirements have been well defined.

Regards,

Peter Musgrave

On Sun, Oct 24, 2010 at 7:03 AM, Magnus Westerlund <
[email-masked]> wrote:

> >> I have not issue with your proposed words, since they are essentially
> asking for a "mute" button for all types of communications used by a sender.
>  This may complicate the algorithm for all the receive systems to know what
> to display, if for example, you continue to speak, but turn off the video
> transmission.  A "mute all" option might be more polite.
> >>
> >> There needs to be a distinction between when a call starts and when a
> call stops, the call being *all* communications (sessions) between two
> points.  Granted putting a call on hold seems like floor control, but the
> participants of the call on hold are effectively out of the call (left the
> room) until brought off-hold.  This is SIP level action.
> >>
> >> There needs to be a clear distinction between negotiating capabilities,
> aka knowing what capabilities an endpoint has, and using those capabilities
> during a call.  That learning process is done via SDP.
> >>
> >> The latter part seems to be floor control, continuous conference
> control, or whatever you want to call it.  There seems to be splitting of
> hairs over whether the floor control is manual or automatic (determined by
> the loudest speaker).  This may be AVT.
> >>
> >> In summary, you have room access, you define capabilities, you have
> "speaker" conflict resolution control.  (Note, point-to-point calls are
> devolution since resolution of conflict is a non-problem with only one
> opposing party.)
> >>
> >>> [AR} Agree this needs to be worked out for Telepresence, and that any
> activity about it would go to AVT and/or MMUSIC.
> >>>

---

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

Hi Magnus - 

I agree with you that the issues you bring up need to be dealt with, and I feel they should potentially result in requirements from this working group.

With respect in particular to your next to last paragraph below, did you not think that my proposed change to the charter (as Peter quoted), covered your concern?

"also propose the following addition:
       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. 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 as a kind request to try to meet these requirements."

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Sunday, October 24, 2010 4:04 AM
To: Peter Musgrave
Cc: [email-masked]
Subject: Re: [dispatch] Comments on the proposed Telepresence Charter

Hi,

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Oct 2010 10:45:57 +0200

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

Ok, I missed that proposal. That seems fine, except that I would
possibly add that a recharter is one possible way of realizing the
requirements?

cheers

Magnus Westerlund

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 25 Oct 2010 12:15:02 -0700

Okay, how about

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

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, October 25, 2010 1:46 AM
To: Allyn Romanow (allyn)
Cc: Peter Musgrave; [email-masked]
Subject: Re: [dispatch] Comments on the proposed Telepresence Charter

cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Oct 2010 16:57:34 +0200

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

Yes, that sounds good.

Cheers

Magnus Westerlund