libdatachannel: SRTP protect error, status=10
I’m seeing a fair number of exceptions thrown from rtc::Track->send() with the message “SRTP protect error, status=10”. Does anyone know what those are?
When I get them, I get a lot of them for the same user. So I’m wondering if maybe that indicates a problem with the connection and I should disconnect and reconnect.
Thanks.
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 17 (7 by maintainers)
I don’t know if this will be helpful to anyone, but I also ran into this error message. I was using code based on both the “client” and “media-sender” examples in this repo. In my case it was because I (purposely) kept the webrtc connection up but restarted the gstreamer command which streamed to a port, which is read by the modified example script I’m using. Mr. Ageneau mentions that restarting the RTP stream can lead to this error and that’s exactly my case. I want to be able to restart the stream to the port, without restarting/renegotiating anything else.
Where that error comes from on a lower level: when the stream is restarted, the sequence number is randomized, as it should be, for security reasons according to wikipedia. Sometimes when I restart the stream, the new randomly generated sequence number is greater than the last sequence number I had before I stopped the stream. In that case the stream restarts without error. But more often than not (and eventually guaranteed right?) if I keep restarting the stream I’ll get a case where the randomly generated sequence number is less than the last sequence number I had before I stopped the stream, and that’s an error. As Mr. Ageneau says in this thread, sequence numbers should always increase.
What I did to solve it in my case: it was suggested in this thread that if the stream restarts, a new SSRC number should be used and renegotiated etc. but (and maybe this is conceptually a bad thing to do, but, it works for me) instead of that, I use rtp->setSeqNumber to reset the sequence number before it is sent to the track. So my script defines and updates the sequence number and always resets the sequence number before sending it forward. This allows me to restart the gstreamer command as many times as I want without renegotiating the webrtc connection or anything else.