SRTP err=7 in Chrome when DTLS-SRTP is used

[RCC]

Hello - 

When using DTLS with Chrome (30m) and our WebRTC Gateway - observing SRTP error (7) from time to time. The behavior is random anyway - but if anything can be interpreted from the Chrome debug logs (attached)? I don't see the errors for SDES. 

I see the DTLS handshake seems to be okay - 

[13940:7048:1022/133207:VERBOSE3:nssstreamadapter.cc(734)] NSSStreamAdapter::OnEvent SE_READ

[13940:7048:1022/133207:VERBOSE3:nssstreamadapter.cc(554)] ContinueSSL

[13940:7048:1022/133207:VERBOSE3:nssstreamadapter.cc(587)] Would have blocked

[13940:7048:1022/133207:VERBOSE3:nssstreamadapter.cc(593)] Timeout is 1000 ms

[13940:7048:1022/133207:VERBOSE3:nssstreamadapter.cc(734)] NSSStreamAdapter::OnEvent SE_READ

[13940:7048:1022/133207:VERBOSE3:nssstreamadapter.cc(554)] ContinueSSL

[13940:7048:1022/133207:VERBOSE3:nssstreamadapter.cc(587)] Would have blocked

[13940:7048:1022/133207:VERBOSE3:nssstreamadapter.cc(593)] Timeout is 1000 ms

[13940:7048:1022/133208:VERBOSE3:nssstreamadapter.cc(734)] NSSStreamAdapter::OnEvent SE_READ

[13940:7048:1022/133208:VERBOSE3:nssstreamadapter.cc(554)] ContinueSSL

[13940:7048:1022/133208:VERBOSE3:nssstreamadapter.cc(782)] NSSStreamAdapter::AuthCertificateHook

[13940:7048:1022/133208:VERBOSE3:nssstreamadapter.cc(800)] Checking against specified digest

[13940:7048:1022/133208:VERBOSE3:nssstreamadapter.cc(812)] Accepted peer certificate

[13940:7048:1022/133208:VERBOSE3:nssstreamadapter.cc(563)] Handshake complete

Then - 

[13940:7048:1022/133208:VERBOSE3:srtpfilter.cc(158)] SRTP activated with negotiated parameters: send cipher_suite AES_CM_128_HMAC_SHA1_80 recv cipher_suite AES_CM_128_HMAC_SHA1_80

The series of error 7 messages for each packet I guess -

[13940:7048:1022/133208:VERBOSE2:srtpfilter.cc(535)] Failed to unprotect SRTP packet, err=7

[13940:7048:1022/133208:VERBOSE1:channel.cc(837)] Failed to unprotect audio RTP packet: size=182, seqnum=20329, SSRC=17792

[13940:7048:1022/133208:VERBOSE2:srtpfilter.cc(535)] Failed to unprotect SRTP packet, err=7

[13940:7048:1022/133208:VERBOSE1:channel.cc(837)] Failed to unprotect video RTP packet: size=850, seqnum=12116, SSRC=18008

[13940:7048:1022/133208:VERBOSE2:srtpfilter.cc(535)] Failed to unprotect SRTP packet, err=7

[13940:7048:1022/133208:VERBOSE1:channel.cc(837)] Failed to unprotect video RTP packet: size=850, seqnum=12117, SSRC=18008

[13940:7048:1022/133208:VERBOSE2:srtpfilter.cc(535)] Failed to unprotect SRTP packet, err=7

Could be something specific to DTLS - any debugging suggestion would be highly appreciated.

Thx

RCC

[RCC]

Just to update further that the DTLS calls work most of the time, and this error happens only sometimes. Also, when this happens, our WebRTC gateway also reports the same decrypt errors.

Is similar issue observed by anyone. Also - we don't see this issue with FireFox - it's rather happening Chrome specific.

Thx

RCC

[ravindra pai]

Hi RCC,

            Did you find the root cause for this problem. Even I am facing same problem randomly.

Thanks,

Ravindra M

[mark...@icewarp.com]

Hello RCC,

The bug is still happening for us. Curious if you were able to find anything new or work around the problem?

Thanks!

IceWarp

[Justin Uberti]

This is typically encountered when a packet is retransmitted, but the original packet eventually reaches the destination and is discarded because it looks like a replay.

We are moving to send RTX packets over a separate SSRC which should resolve this issue.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[xfengtes...@gmail.com]

Is it okey to disable DTLS-SRTP?

在 2014年7月22日星期二UTC+8上午4时40分33秒，Justin Uberti写道：

[Uma Shunmugan]

Justin, is there a bug # for this issue?  

The issue you mentioned - does it really cause error 7 (authenticaion) in SRTP, or else 10 or 9(replay)?  We see error 7 in our gateway once in a while when decrypting packets from Chrome (M37), and once this happens, the session never recovers with a new O/A.

[Iñaki Baz Castillo]

2014-09-22 9:03 GMT+02:00 <xfengtes...@gmail.com>:
> Is it okey to disable DTLS-SRTP?

No.


--
Iñaki Baz Castillo
<i...@aliax.net>

[Justin Uberti]

https://code.google.com/p/webrtc/issues/detail?id=1811 tracked the RTX issue. You should not see err=7 when using RTX.

On Wed, Sep 24, 2014 at 8:55 AM, Uma Shunmugan <ushun...@gmail.com> wrote:

Justin, is there a bug # for this issue?  

The issue you mentioned - does it really cause error 7 (authenticaion) in SRTP, or else 10 or 9(replay)?  We see error 7 in our gateway once in a while when decrypting packets from Chrome (M37), and once this happens, the session never recovers with a new O/A.

[Uma Shunmugan]

FYI, I believe we have found the final/main issue and fixed it in our WebRTC gateway.  After fixing other issues, we were seeing SRTP decrypt errors occasionally with hold/resume.  It turned out the problem was that we were recreating the SRTP contexts for both in and out media streams when outgoing stream (to browser) changed with a new SSRC.  Now, we check if the SSRC from the browser has changed or not, and if it hasn't (it shouldn't unless there is a new gUM or new PeerConnection), we keep using the existing SRTP context for the incoming stream.  I believe the SRTP error was caused due to RTP sequence number roll over.  Happy holidays!