You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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
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:
This are the differences i found with respect to the specification:
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.
The text was updated successfully, but these errors were encountered: