[Bug 765071] New: SRTP encryption/decryption errors with shared media

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Thu Apr 14 20:23:44 UTC 2016


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

            Bug ID: 765071
           Summary: SRTP encryption/decryption errors with shared media
    Classification: Platform
           Product: GStreamer
           Version: 1.8.0
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-streaming-server
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: jake.foytik at ipconfigure.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: ds at schleef.org
     GNOME version: ---

In our application we are seeing an issue when using rtsp-server in TLS mode
with a media-factory that is set as 'shared'. This issue can be reproduced
using a modified version of the test-video example code. In our test, we enable
the WITH_AUTH and WITH_TLS flags and set the media factory to shared (
gst_rtsp_media_factory_set_shared(factory, TRUE); ).

When streaming multiple rtsp streams from the same factory, occasionally a
stream will connect but not be able to decode the SRTP packets. Steps to
reproduce :
 - Run test-video (with TLS, Auth, and shared factory)
 - Connect a client using gst-launch-1.0 rtspsrc location=.... 
 - Wait around 6 minutes.
 - Connect another client using gst-launch-1.0 --gst-debug=srtpdec:5 rtspsrc
location=... . (Now there will be 2 clients connected to the same session)
 - Observe : The second client will connect with server and will not be able to
decode the SRTP packets. srtpdec (on the client) will post a warnings "Unable
to unprotect buffer (unprotect failed code 7)" and "Error authentication
packet, dropping". The first clients will continue playing as normal. If I
close both connections, then connect another session, the stream plays fine.

It seems as if there is some timeout, or mismanagement of the the key used
between the SRTP elements. This behavior was observed for both gstreamer
version 1.6.3 and 1.8.0.

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


More information about the gstreamer-bugs mailing list