- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Thu, 14 Jun 2018 19:19:54 +0000
- To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, Peter Thatcher <pthatcher@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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.
Received on Thursday, 14 June 2018 19:20:21 UTC