[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