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

[Magnus Westerlund <[e-mail]>]

Hi,

So this is my personal opinion and based on my long work with RTP. 

Yes, there are clearly interest in chartering some work in IETF. Howver, I think
there is significant diversity in what people are interested in actually
happening. 

Clearly there is the signalling protocol for seession/call establishment and
control between peering provider nodes. Lets call this the outbound part. The
main issue I see in this area is the quetion of feature creap. It would be good
to figure out what core functionality is really needed and actually get that
described in a charter. A Question is if conference applications impacts this
scope or not. 

The next part is the inbound problem, i.e. having end-user devices/application
being able to register to their provider as being ready to receive/answer calls.
This may actually be sufficient similar to the outbound part that they can be
done in the same WG. 

However, an interesting question for both of the above is if the solution is
required to be able to be implemented in a browser, at least the client part. I
think the signalling is fairly straight forward to be able to implement in JS as
long as we ignore the media. 

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. There are several aspects here.
First of the split in expertise between the media transport and the signalling
folks. The next aspect is the resuability of the media transport, that anyway
need to be define as individual reusable protocol component that is not
dependent on the signalling. I don't see a huge problem with being able to
initiate a media transport channel into the relevant server node using an
initial HTTP request. I am thinking WebSocket like establishment of the media
transport channel here. And possibly there will be need for a fallback to HTTP
only, but also that should be further discussed. 

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. 

We also have use cases that has practical total overlapp, namely real-time
sensor streaming services, where cameras, and other frequently sampling sensors
send data of real-time control loop nature. There is also the media industries
need for content contribution, i.e. how to get camera's media into the
production centers. These are similar enough and need of standardized protocols.
SRT in Dispatch is only one aspect of this. What we don't need to take on for
this is the one-to-many distribution only. So broadcast and multicast can be
declared out of scope. 

I think E2E media secruity need to be defined from day one. It will be a central
part of these systems even if in the legacy interconnect there will be the
termination in gateways. Also media processing nodes can be included but the
inclusion of them in the trust will need to be explicit in this model. 

People have been voicing that we don't need things to work as well as RTP. I
think in fact that a dedicated real-time media over QUIC (with datagram) can
actually achieve better than RTP performance by using a mix of reliable and
semi-reliable transport primitives on applciation data unit level, i.e. audio
and video frames. 

The next media transport issue that was barely discussed in the BOF is the
legacy (RTP) interoperate question. This is going to come back in the scope
discussion and do needs at least a direction. 

Coming back to my initial statement about diversity, I think there at least two
communities that are interested in this. And I think we actually need to attempt
to make relevant protocol work for both these communities. For the moment the
most outspoken people in this effort have been the signalling people. The media
transport crowd have been waiting for their turn until QUIC to matured
sufficiently to be a realistic start. But as people know some discussion have
happened. However we are this point now I think where work can start in ernest
also on this topic. 

So can we seriously consider writing two different charter that together enable
the intended use cases? 

Cheers

Magnus Westerlund 


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