Support non-canonical SDP for RTSP

[aler9]

Summary

SDP, together with RTSP, is used in most security cameras to serve their live streams, but not all of them fully respect the RFC specification. A versatile SDP library should handle these edge cases too.

Motivation

Hello, first of all thanks for the beautifully-organized WebRTC implementation, that allows developers to pick exactly the components they need (sdp, srtp, rtcp, webrtc) without the effort of downloading the entire framework.

I'm the author of rtsp-simple-server, a RTSP server/proxy that allows to publish, pull and read live streams. RTSP is a RFC specification that, like WebRTC, uses SDP to describe available medias, in order to publish or read them. While WebRTC is mostly used to communicate with browsers, that are limited in quantity and can be upgraded to the last version, RTSP is mostly used to communicate with security cameras, which use embedded hardware and software, that cannot be upgraded, are very different one from another and use different SDP implementations. Therefore, even with recent hardware, i often have to deal with SDPs like this one:

"v=0
m=video 0 RTP/AVP/TCP 96
a=rtpmap:96 H265/90000
a=fmtp:96 sprop-vps=QAEMAf//AWAAAAMAsAAAAwAAAwB4FwJA; sprop-sps=QgEBAWAAAAMAsAAAAwAAAwB4oAKggC8c1YgXuRZFL/y5/E/qbgQEBAE=; sprop-pps=RAHAcvBTJA==;
a=control:streamid=0
m=audio 0 RTP/AVP/TCP 97
a=rtpmap:97 mpeg4-generic/44100/2
a=fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210
a=control:streamid=1

This are the differences i found with respect to the specification:

• origin is missing
• session name is missing
• timing is missing
• there's an additional keyword "TCP" in the media protocol

I think that a unique SDP library would be a great addon for the Go ecosystem, hence my proposal is to support these edge cases, that differs from the specification and require some little changes.

Describe alternatives you've considered

I considered writing a dedicated SDP library, but i prefer contributing to the main one.

Additional context

I already produced a patch that would allow pion/sdp to support non-canonical SDPs, but before opening a PR i want to understand if you're interested in this feature or not.

[at-wat]

Supporting non standard SDP sounds great, but I think it's better to keep them strict by default, and add NonStrict version of functions or non strict mode.

[aler9]

Since there are too many non-standard SDP implementations around, i changed my mind and now i think it's better to work in a separate fork, dedicated to these cases, less efficient but more versatile:
https://github.com/aler9/sdp-dirty