Re: [V3] High level comments on the RIPT charter and scope

[Magnus Westerlund <[e-mail]>]

On Fri, 2020-03-27 at 10:19 -0600, Cullen Jennings wrote:
> 
> 
> > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <
> > magnus.westerlund=[e-mail]> wrote:
> > 
> > The third big part is the media transport. I think we need to strongly
> > consider
> > if this can be broken out in to it seperate WG.
> 
> I think the WG we are talking about here is the WG to do media of H3. So we
> can talk about other things being in or out of it but that is the core thing. 
> 
> I would like to point out that one of the design properties that has been
> making this easier is that media is self describing. What I mean by that is
> that if a device receives media that is one of the supported formats and
> within in the limits of that device supports, the media has all the
> information the device needs to decode it. No out of band information needed.
> That is key to making this easier to deal with HA and scalability on cloud
> side. I think that is a good property for modern designs. We have been going
> that way for a long time with things like opus and it works out well. 

So, let me ask a question here. How important is it be capable to transmitt
individual media ADU or even RTP payloads in a single HTTP request that ripples
through the system independent compared to have a system that can in a 0-rtt
fashion (re-)establish an point to point by initiating an HTTP request? 

Treating each media ADU as its own request potentially being routed in a non-
sticky way will induce significant jitter would it not? The drafts talks about
sticky routing, and I did notice some comments about that assumption already.
Thus, from my perspective it appears that the high-performance target would be
to establish an point to point quic based transport with the relevant server
node that handles media forwarding. If that fails have a mechanism that can
rapidly re-establish that connection with what ever node that is now the
appointed one for the given call/conference. 

Then I do understand the desire to have a fallback, and maybe that is plain HTTP
requests, but let that be the fallback and not the primary mechanism. Becasue I
think that would unnecessary limit the potential of this system. 

> 
> > here are several aspects here.
> > First of the split in expertise between the media transport and the
> > signalling
> > folks. 
> 
> I’m not sure what you mean by signalling but the the singling here was mostly
> start media , stop media. It is not call routing, forking etc that is done by
> SIP. 

Yes, but even session establishment and control is still signalling from my
perspective. 

 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------