3 ms·

Why would any sane person bring SDP into WebRTC? They had a fresh slate to get things right, and instead they end up making it worse than the SIP headache. SDP,

Why would any sane person bring SDP into WebRTC? They had a fresh slate to get things right, and instead they end up making it worse than the SIP headache. SDP, the spec that suggests people might use SDP to setup chess games is a terrible format. In fact, unless they changed the offer answer model, there's actually no way to determine what single codec is in use. It's one of those things where every vendor sorta does something, and relies on tons of interop and guessing to actually come up with an implementation. Plus it's yet another custom parser with a strange format. And deliberately clipped in verbosity (for a text format) because the SIP authors were terrified of IP fragmentation and actually spec'd a hardcoded MTU size. Edit: Frustration aside, this is a really nice explanation, thanks.

wahern 12y ago
Where is the MTU of SDP specified? I can't find it in RFC 4566. Furthermore, the SDP configurations that Windows Media Services emits can include a multi-kilobyte base64-encoded ASF configuration element. So it's not like applications can't choose to ignore such a rule, or agree on a standard that drops such a limitation. If I had to guess why they used SDP it's because 1) it's simple to parse and 2) WebRTC also uses RTP, and RTP libraries already typically include or are accompanied by SDP libraries. I dislike standards that provide so much rope for people to hang themselves. Multimedia standards are horrible rats nests of options, sub-options, and sub-sub-options, the vast majority of which nobody uses or even parse correctly. And while SDP is simple, it aids & abets such behavior by being such a generic format. Still, it's common and there are plenty of standards which define various SDP configurations.
- MichaelGG 12y ago
  The MTU is specified in the SAP protocol. Which is even more strange; a mixed binary and ASCII system, rife with the IETFs poorly conceived SHOULD and MAY clauses, which serve no purpose other than to cause interop issues. Anyways, perhaps networks in 1999 didn't know how to handle IP fragmentation. SIP made the MTU issue worse, requiring switching to TCP on-the-fly when a message exceeded their arbitrary MTU. I'm saying perhaps these considerations are why SDP has such strange choices in formatting. In context of WebRTP, SDP provides no benefits. Might as well used a JSON representation of the media negotiation, requiring no additional parser. Things are already ambiguous and poorly handled when using SDP in the real world. I think it must be something about "simple" permissive protocols that encourage implementation issues.

wahern 12y ago

Where is the MTU of SDP specified? I can't find it in RFC 4566. Furthermore, the SDP configurations that Windows Media Services emits can include a multi-kilobyte base64-encoded ASF configuration element. So it's not like applications can't choose to ignore such a rule, or agree on a standard that drops such a limitation. If I had to guess why they used SDP it's because 1) it's simple to parse and 2) WebRTC also uses RTP, and RTP libraries already typically include or are accompanied by SDP libraries. I dislike standards that provide so much rope for people to hang themselves. Multimedia standards are horrible rats nests of options, sub-options, and sub-sub-options, the vast majority of which nobody uses or even parse correctly. And while SDP is simple, it aids & abets such behavior by being such a generic format. Still, it's common and there are plenty of standards which define various SDP configurations.

MichaelGG 12y ago
The MTU is specified in the SAP protocol. Which is even more strange; a mixed binary and ASCII system, rife with the IETFs poorly conceived SHOULD and MAY clauses, which serve no purpose other than to cause interop issues. Anyways, perhaps networks in 1999 didn't know how to handle IP fragmentation. SIP made the MTU issue worse, requiring switching to TCP on-the-fly when a message exceeded their arbitrary MTU. I'm saying perhaps these considerations are why SDP has such strange choices in formatting. In context of WebRTP, SDP provides no benefits. Might as well used a JSON representation of the media negotiation, requiring no additional parser. Things are already ambiguous and poorly handled when using SDP in the real world. I think it must be something about "simple" permissive protocols that encourage implementation issues.