- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Fri, 15 Jun 2018 09:49:47 +0200
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>, Peter Thatcher <pthatcher@google.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 14/06/2018 21:19, Bernard Aboba wrote: > Sergio said: > > "ORTC is just a bit better, but not much, with the encoding parameters stuff being just a json-version of an m-line, not much improvement there." > > [BA] While SDP has gotten a lot of the shade, it seems to me that RTP/RTCP does not get its fair share of the blame. > > m-lines inherently handle both sending and receiving, which results in considerable complexity and requires a transceiver construct. > > When you separate out the sender and receiver (and the RTCRtpSendParameters and RTCRtpReceiveParameters), things do get simpler, as we have seen when the separation was done within WebRTC 1.0. > > As you've pointed out, considerable complexity remains, which cannot be blamed on SDP. > > That complexity is largely inherent to RTP/RTCP and all the potential levels of multiplexing we have added to it - witness all the effort it took to describe how RTP and RTCP packets are to be routed to senders and receivers (and that doesn't even include things like simulcast and SVC!) > > I'm still not entirely convinced that we will see widespread implementation of the MID and RID header extensions within SFUs. > > So be careful about assuming all that complexity will go away if we separate things out. As long as we're tied to RTP/RTCP, I suspect it will remain - and trying to disentangle RTP from encoding might even make it worse. Indeed, there is a lot of blame to distribute here.. :) If we could remove unused behaviors, like PT multiplexing, things would be much easier to define. IMHO the spec should be API driven, and if there are some edge use cases in RTP that makes the API less clean, we should drop them. Best regards Sergio
Received on Friday, 15 June 2018 07:49:10 UTC