[Bug 792376] New: rtspsrc: media stream tagged with 'sendonly' attribute in the SDP are ignored

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=792376

            Bug ID: 792376
           Summary: rtspsrc: media stream tagged with 'sendonly' attribute
                    in the SDP are ignored
    Classification: Platform
           Product: GStreamer
           Version: 1.12.4
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: marc.leeman at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.