GNOME Bugzilla – Bug 792376
rtspsrc: media stream tagged with 'sendonly' attribute in the SDP are ignored
Last modified: 2018-04-11 08:24:16 UTC
Commit 86a56cc48c521d4fbd4c73c903a58787313458d4 ignores media in the SDP that have the 'sendonly' attribute set. The commit message says: We're never going to receive anything from them, so don't create pads for them. These medias are destinations where *we* could send something. in rfc3264.txt, section 5.1 (Unicast Streams), we see: If the offerer wishes to only send media on a stream to its peer, it MUST mark the stream as sendonly with the "a=sendonly" attribute. Since the RTSP server is offering the SDP, it would mean the exact opposite than the implemented code (sendonly/recvonly). Unfortunately, when inpsecting the ONVIF spec, https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec-v1706.pdf A SDP file is used to describe the session. The server shall include the a=sendonly or the a=recvonly attributes in each media section of the SDP file to indicate the direction the media data will be send. The example elaborates: RTSP/1.0 200 OK Cseq: 1 Content-Type: application/sdp Content-Length: xxx v=0 o= 2890842807 IN IP4 192.168.0.1 s=RTSP Session with audiobackchannel m=video 0 RTP/AVP 26 a=control:rtsp://192.168.0.1/video a=recvonly m=audio 0 RTP/AVP 0 a=control:rtsp://192.168.0.1/audio a=recvonly m=audio 0 RTP/AVP 0 a=control:rtsp://192.168.0.1/audioback a=rtpmap:0 PCMU/8000 a=sendonly This seems to be in complete contradiction of the RFC.
We need to understand if the ONVIF spec is just wrong and can be fixed, and if other implementations are also implementing it like the spec currently says. If the spec can be fixed, then all the logic in rtspsrc can be inverted. Otherwise we have a problem as the same signalling would mean the exact opposite depending on whether the server speaks ONVIF or not.
Link to the RFC for easier discovery: https://tools.ietf.org/html/rfc3264
commit 326e9549e378bcc71587ba569f73755e0abc1794 (HEAD -> 1.12) Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Jan 22 12:24:18 2018 +0200 rtspsrc: Fix up sendonly/recvonly attribute handling We can't handle recvonly streams, sendonly streams are perfectly fine. The direction is the one from the point of view of the SDP offerer (i.e. the RTSP server), and a recvonly stream would be one where the server expects us to send media. RFC 3264, section 5.1: If the offerer wishes to only send media on a stream to its peer, it MUST mark the stream as sendonly with the "a=sendonly" attribute. This is mixed up in the ONVIF streaming specification examples, but actual implementations and conformance tools seem to not care at all about the attributes. https://bugzilla.gnome.org/show_bug.cgi?id=792376
The RTSP RFCs actually define it the other way around, that is how it was before the commit that "fixed" this bug. https://tools.ietf.org/html/rfc2326#page-31 and https://tools.ietf.org/html/rfc7826#appendix-D.1.5 for example say that "recvonly" is for streams that go from the server to the client. This is in direct contradiction to RFC 3264 which says that the offerer (i.e. the server in our case) should use "sendonly" if it only wants to send a stream to its peer (the client). So in summary, the RTSP RFCs clearly say how it should be and that's the other way around than it is defined in the SDP RFC.