Subject: [clue] Full mesh conferneces

From: Roni Even <[email-masked]>
Date: Tue, 23 Aug 2011 21:12:58 +0300

Hi,

During the interim meeting today when we talked about Simultaneous
transmission sets there was a question if the provider may run to conflict
requests for capture sets. There was a question if it is relevant for
centralized multipoint and in my view this is not a problem.

I mentioned that such a problem can occur if we support full mesh
conferences.  For example if a provider can send 3 video captures or by
using one of the camera send a zoom version of the same scene it may cause a
one screen system to ask for the zoom version and a three screen system to
ask for the three streams. This can happen in a full mesh three way call and
will require some way to resolve the conflict.

My personal view is that we are not doing full mesh but just centralized
multipoint conferences.

I am looking for input is this is a problem we need to address

Thanks

Roni Even

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 23 Aug 2011 12:03:25 -0700

I also thought full mesh is not in scope and we don't need to address it.
Mark Duckworth

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Tuesday, August 23, 2011 2:13 PM
To: [email-masked]
Subject: [clue] Full mesh conferneces

Hi,
During the interim meeting today when we talked about Simultaneous transmission sets there was a question if the provider may run to conflict requests for capture sets. There was a question if it is relevant for centralized multipoint and in my view this is not a problem.

I mentioned that such a problem can occur if we support full mesh conferences.  For example if a provider can send 3 video captures or by using one of the camera send a zoom version of the same scene it may cause a one screen system to ask for the zoom version and a three screen system to ask for the three streams. This can happen in a full mesh three way call and will require some way to resolve the conflict.

My personal view is that we are not doing full mesh but just centralized multipoint conferences.

Thanks
Roni Even

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 23 Aug 2011 16:19:56 -0400

Hi,
Roni's problem is not limited to full mesh.  What we are really looking at
is transcoder-less topologies.  The topology for the media distribution can
be anything from  full mesh through multicast to technologies similar to the
one my employer is using.
Let me suggest to think this through a bit more, keeping in mind that the
other videoonferencing related WG in the IETF (webrtc) certainly views full
mesh topologies as an option, and not kill the concept using procedural
arguments.
My current viewpoint is that if it were possible to address capture-type
conflicts as Roni presented (there are many more; think of codec capability
mismatches and similar), we should address those.  Not just expecting that
the magic MCU solves all those mismatches for everyone.  However, I'm not
sure that it is possible at all, at least not without an signaling middlebox
that makes smart decisions (regardless of whether that box performs media
transcoding or not).  At least I have not seen a protocol that would allow
for multiparty feature negotiation without involving a middlebox and with
reasonable delay constraints.  But perhaps others that are closer to
signaling, have?
Stephan

From:  "Duckworth, Mark" <[email-masked]>
Date:  Tue, 23 Aug 2011 12:03:25 -0700
To:  "[email-masked]" <[email-masked]>
Subject:  Re: [clue] Full mesh conferneces

I also thought full mesh is not in scope and we don¹t need to address it.
Mark Duckworth

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Tuesday, August 23, 2011 2:13 PM
To: [email-masked]
Subject: [clue] Full mesh conferneces
 
Hi,

 
 
Thanks
Roni Even

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Aug 2011 17:13:32 -0400

ISTM that the key distinction here is between "configure an endpoint" 
and "configure a session between two endpoints". It feels like these 
have so far been conflated, and should not be.

When viewed that way, it seems obvious to me that a different 
negotiation approach is needed for the two:

- an "O/A-like" approach is fine for
   "configure a session between two endpoints"

- a "voting" or "indication of preference" approach, preceding
   an offer that reflects the current configuration seems more
   appropriate for "configure an endpoint".

	Thanks,
	Paul

On 8/23/11 4:19 PM, Stephan Wenger wrote:
> Hi,
> Roni's problem is not limited to full mesh. What we are really looking
> at is transcoder-less topologies. The topology for the media
> distribution can be anything from full mesh through multicast to
> technologies similar to the one my employer is using.
> Let me suggest to think this through a bit more, keeping in mind that
> the other videoonferencing related WG in the IETF (webrtc) certainly
> views full mesh topologies as an option, and not kill the concept using
> procedural arguments.
> conflicts as Roni presented (there are many more; think of codec
> capability mismatches and similar), we should address those. Not just
> expecting that the magic MCU solves all those mismatches for everyone.
> However, I'm not sure that it is possible at all, at least not without
> an signaling middlebox that makes smart decisions (regardless of whether
> that box performs media transcoding or not). At least I have not seen a
> protocol that would allow for multiparty feature negotiation without
> involving a middlebox and with reasonable delay constraints. But perhaps
> others that are closer to signaling, have?
> Stephan
>
>
> From: "Duckworth, Mark" <[email-masked]
> <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> I also thought full mesh is not in scope and we don’t need to address it.
>
> Mark Duckworth
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Roni Even
> *Sent:* Tuesday, August 23, 2011 2:13 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [clue] Full mesh conferneces
>
> Hi,
>
> transmission sets there was a question if the provider may run to
> conflict requests for capture sets. There was a question if it is
> relevant for centralized multipoint and in my view this is not a problem.
>
> using one of the camera send a zoom version of the same scene it may
> cause a one screen system to ask for the zoom version and a three screen
> system to ask for the three streams. This can happen in a full mesh
> three way call and will require some way to resolve the conflict.
>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/clue
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue