Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

[Bernard Aboba <[e-mail]>]

Peter Thatcher said: 

"It's interesting that most of your list of things that needed to be solved without SDP (simulcast, FEC, correlation of RTP streams with MediaStreamTracks, glare) still haven't been solved for WebRTC even with SDP, despite many months (years?) of effort.  


I don't think anyone is saying "without SDP, there would be issues".  I think they're saying "without SDP, the issues are much easier/faster to solve, and the API would be much more usable and implementable".   And I don't think that's a naive opinion."

[BA] I would even go further - I'd claim that several of these issues are best solved without SDP, either in the API or on the wire.  RTP stacks used in WebRTC need to be able to adapt quickly, which implies that the adaptations cannot be signaled.  Also, if you want to scale, then it's important to strip out unnecessary operations that create performance bottlenecks in media-aware network elements (e.g. decrypt/encrypt operations , parsing of codec-specific parameter sets, transcoding, etc.). All this points to moving functionality out of signaling (and codecs) and into RTP.  If you take this perspective, then removing SDP dependencies isn't just a better plan for getting to "done" - it's an essential part of delivering the next generation realtime architecture.