GNOME Bugzilla – Bug 765071
SRTP encryption/decryption errors with shared media
Last modified: 2016-04-27 13:45:23 UTC
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.
I assume it works correctly if you immediately connect a new client?
Yes it does. There is a window of about 6 minutes where I can successfully connect as many clients as I want to a shared stream, then after that any new connections get the SRTP decode errors.
It's probably re-keying then, and the new client only getting the initial key? Do we implement that? :)
Might also be related to the rollover counter? See https://bugzilla.gnome.org/show_bug.cgi?id=730540
(In reply to Sebastian Dröge (slomo) from comment #4) > Might also be related to the rollover counter? See > https://bugzilla.gnome.org/show_bug.cgi?id=730540 Yes, this is related to the rollover counter. SRTP uses a rollover counter for authentication. When the RTP packet sequence number reaches 65535 and rolls over, the the ROC counter increments. Because the media is shared between the clients, the new clients need to know what's the value of the ROC otherwise they won't be able to authenticate the packets. That's why if you connect the client before the ROC changes (still 0) the client can successfully decode the stream. This is fixed now fixed upstream with bug 730540 (which also needed bug 765082).
The fix will be in release 1.8.1 so updated the milestone.
I'm still seeing this issue with 1.8.1. Do we need to make changes to rtsp-server to support the rollover counter?
(In reply to Jake Foytik from comment #7) > I'm still seeing this issue with 1.8.1. Do we need to make changes to > rtsp-server to support the rollover counter? Yes, see bug 730539 and bug 733265. I have to work on the review of one of them. In the meantime I will upload updated patches so people can use them.
So let's consider this a duplicate of one of those bugs instead. Aleix, only these two patches are needed or would there be more on top? Let me know if/when it's good to review them again :) *** This bug has been marked as a duplicate of bug 730539 ***
(In reply to Sebastian Dröge (slomo) from comment #9) > So let's consider this a duplicate of one of those bugs instead. > > Aleix, only these two patches are needed or would there be more on top? Let > me know if/when it's good to review them again :) > Only these two. Yes, I will let you know.