Re: [V3] Centralized conference media

[Cullen Jennings <[e-mail]>]

I’m thinking of this as 100% client / server.  Sure you can build a conferences on top of that but the RIPT layer would not even need to have a clue about the overall conference media topology. The server can do things like pause / resume media FIR etc but it all just two parties involved - the client and the server. Assuming a server that maps media is one of the things that make this so much easier than an RTP multicast conferences. 


> On Mar 27, 2020, at 4:35 PM, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi,
> 
> So yes, I think there are the aspect of the topology as well as how one handle
> the media related controll messages, i.e. the equivalent of RTCP. For example
> things like FIR, PAUSE/Resume. 
> 
> So, if one with RTCP terminating middleboxes means that the ID spaces are soley
> locally that could be a choice. I will note that in some cases one still need to
> have the complete set of media sources from all end-points in a conference be
> identified at a specific point to point leg. Even if only a subset is currently
> transmitted over this leg. There are both benefits and downsides I think of
> using a local namespace and having each node translate these.
> 
> I will note that one may still need to have end-to-end identies on media ADUs if
> one are going to have any end-to-end security. 
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> 
> On Fri, 2020-03-27 at 09:28 -0700, Justin Uberti wrote:
>> I think Magnus is trying to establish the conference topology, which has
>> ramifications on how we want to handle things like RTCP.
>> 
>> One strawman could be to focus on RTCP-terminating SFUs, i.e., cementing the
>> notion that RIPT media flows are indeed point-to-point (i..e., client-to-SFU,
>> as opposed to client-to-client1, client2, client3).
>> 
>> On Fri, Mar 27, 2020 at 9:11 AM Cullen Jennings <[e-mail]> wrote:
>>> 
>>>> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <
>>>> magnus.westerlund=[e-mail]> wrote:
>>>> 
>>>> I am also very worried that if the model for the media transport is only
>>>> point
>>>> to point calls then we get something that will become obsolete or at least
>>>> need
>>>> hacks immediately. This thing need to support centralized conferences with
>>>> cascaded or meshed central media nodes. So I think it is cruical that one
>>>> define
>>>> the usage model with switched central nodes and have that in mind so that
>>>> one
>>>> can actually support the applications needed. I think by defining a strict
>>>> model
>>>> one can actually avoid a lot of feature creep in the media transport. 
>>> 
>>> I think it does make sense to support some meta data on a media flow for
>>> centralized conferencing support. What semantic level information do you
>>> think is needed in the media ?
>>> 
>>> 
>>> 
>>> -- 
>>> V3 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v3
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> 
> -- 
> V3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v3