Failed to unprotect SRTP packet, err=7

[pablo]

Hi,

I have two clients (Chrome 30) connected to MCU.
Client A has a sendonly PC with audio channel.
Client B has a recvonly PC with audio channel.
The MCU receive RTP packets from client A, decrypt using SDES encrypt with client B crypto key and salt and pass to client B.
On client B log I'm getting for each packet:
[11:15:1013/172301:VERBOSE2:srtpfilter.cc(535)] Failed to unprotect SRTP packet, err=7
[11:15:1013/172301:VERBOSE1:channel.cc(837)] Failed to unprotect audio RTP packet: size=99, seqnum=8143, SSRC=2939086648

What does err 7 means?


Both clients can connect using the apprtc demo.
I'm able to decrypt the audio packets on the MCU, transcode to mp3 and verify that the audio is good.
I've also tried to use client A's crypto key and salt in the SDP response to client B and pass RTP packets from client A to client B without decrypt/encrypt.
In this case I would expect client B to be able to use them but I'm getting the same error.

I also see each RTP packet received twice by the MCU so I only process packets when the sequence number is changing.
Not sure what the cause and if this is related or not.

How can I further debug this issue?

Thanks

[Dmitry Sobinov]

Hi

This is libsrtp error err_status_auth_fail (see crypto/include/err.h, enum err_status_t). It usually means that a wrong key is used to decrypt or a packet is modified after encryption (so computed auth tag doesn't match the one from the packet).

If I understand you right, you try to encrypt MCU->B stream with B's key, but should use MCU's key instead.

Regards,

Dmitry

[pablo platt]

Hi

I've tried two things on the MCU side:

1. Create new SDES key and salt, include them in the crypto line in the SDP answer and use it to encrypt A's packets.

2. Use A's SDES key, salt and SSRC in the SDP answer so I don't need to decrypt/encrypt the rtp packet and can just pass them from A to B.

Both tests fail.

I would expect test 2 to work because I'm just passing the packets and using A's params.

Thanks,

Pablo

--
 
---
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/groups/opt_out.

[Dmitry Sobinov]

Yes, these scenarios should work. You can try to capture packets by Wireshark from A and from MCU and compare. Besides that I can't say what's wrong.

Regards,

Dmitry

[pablo platt]

I was sending the wrong crypto key and salt.
Now passing the RTP packets of client A to client B without decrypt/encrypt works.

I'll check my encryption to see why decrypt/encrypt doesn't work.

Thanks

[Randell Jesup]

On 10/16/2013 9:05 AM, pablo platt wrote:
> I was sending the wrong crypto key and salt.
> Now passing the RTP packets of client A to client B without
> decrypt/encrypt works.
> I'll check my encryption to see why decrypt/encrypt doesn't work.

Before putting too much work into SDES WebRTC MCUs, I'd look at the
results of IETF 87's consensus call on SDES - the overwhelming
consensus (including a plea from an author of SDES) was that SDES "SHALL
NOT" be supported in webrtc. Firefox has never supported SDES, and I
assume Chrome will follow suit at some point in the not-distant future.

You can probably thank Edward Snowden for why the vote was so lopsided.

--
Randell Jesup -- rjesup a t mozilla d o t com
randell-ietf at jesup.org (remove -ietf for personal mail!)

[pablo platt]

I know that I better invest in DTLS but I don't have support for it right now.

Thanks

--

--- 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-webrtc+unsubscribe@googlegroups.com.