srtp_unprotect "err_status_replay_fail" when trying to decrypt webrtc stream in custom app

[Dennis]

Hi All,

I've captured a few webrtc streams and I'm trying to decrypt them with a custom app using libsrtp.   I create different SRTP sessions for the audio stream and video stream, but when I go to decrypt them (srtp_unprotect), the very first audio packet and video packet are successful in their sessions, but every subsequent packet I get 'err_status_replay_fail'.  

According to the SRTP docs, this means "the SRTP packet is a replay (e.g. packet has already been processed and accepted)."   I am definitely not decrypting the same packet twice. So I'm at a loss as to why I get this error.  Does anyone with expertise with SRTP have any knowledge as to why I would get this error?  

Some other notes: 

1. I am using libsrtp 1.4.2 downloaded from http://srtp.sourceforge.net/download.html  Is that a problem?  Does WebRTC use a newer version or a custom version that 1.4.2. is incompatible with? 
• ( I suspect WebRTC encrypts with a newer version due to some code I saw in libjingle that is not in my version of libsrtp, namely 'policy.window_size = 1024;' and 'policy.allow_repeat_tx = 1;'  The structure in 1.4.2 does not have window_size and allow_repear_tx.)
  
  
2. which is the correct crypto policy to use?  
• { sec_serv_none = 0, sec_serv_conf = 1, sec_serv_auth = 2, sec_serv_conf_and_auth = 3 } ?  I thought it was 'sec_serv_conf ', ?
  
  
3. which is the correct type to set for decrypting a stream that is received? 
• { ssrc_undefined = 0, ssrc_specific = 1, ssrc_any_inbound = 2, ssrc_any_outbound = 3 } ? I assume 'ssrc_any_inbound'?
  
  
4. should I be passing the RTCP sender reports to the same srtp_session or to a different one?  
• due to my SRTP noobness, I wasn't sure if RTP & RTCP are muxed together if they should be sent to the same srtp_session or different ones.  Right now I am sending to different ones.
• related, I think I saw a few payload types different than audio/video (payload type 228 if I recall correctly? what is that?) , should those also be sent to the same srtp RTP session instance?
  
  
5. I am decrypting in the order that the packet is received which is not exactly in increasing sequence order in the threading model of my test app (i don't buffer/store in reordering queues), so I might not be decrypting in increasing sequence numbers. Just wondering if there is some special case for WebRTC that may require decrypting in increasing sequence number only. 
• In fact I confirmed that I wasn't. I decrypt 1268, then 1267, then 1270, then 1269, etc.  but again, for decryption (not encryption), according to the docs that should be fine "the sequence numbers of the RTP packets presented to this function need not be consecutive, but they must be out of order by less than 2^15 = 32,768 packets."  
  
• another somewhat silly question but I haven't investigated yet, is srtp_unprotect thread safe?  will calling it from multiple threads simultaneously for the same session cause any problems?

I have been using WebRTC for about 1.5 yrs now so very experienced and comfortable with the high layer interfaces and some of the native API interfaces.  I am just new to SRTP and toying around with a custom built app.  I'm sure I will figure it the next time I try in a day or two, but I figured I'd ask here anyway to save me some time if someone's already dealt with this.   but until then any input for you guys will surely help :)  The next logical step for me to try it to find out which libsrtp version Chrome is using and try that using a single thread and reordering buffer just to see if that works.  I'm guess 1.4.2. is too old and incompatible ... that's probably my problem but I figured perhaps there is some other assumption I am making due to my SRTP noobness that may also be incorrect.  

Thanks,

-Dennis

[Dennis]

nevermind, I found the new repo on github https://github.com/cisco/libsrtp so I updated to 1.4.5

I also discovered that srtp_unprotect & srtp_protect are not thread safe within a session.  had to put a lock around the calls.

[Justin Uberti]

Did that fix the problem you were seeing?

--
 
---
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.
 
 

[Dennis E. Dowhy]

Yes that fixed the problem.  I still see error code 9 (replay fail) on srtp_unprotect about once per minute or two for video for some reason (as opposed to every single packet which is what I was seeing with v1.4.2), doesn't seem to affect playback on the receiver side and also not sure if that is actually normal for some reason (maybe a retransmission of a packet possibly that ends up being decrypted twice??)

[Justin Uberti]

Yes, that is normal operation. As you say, sometimes a packet will be retransmitted, but both the original packet and the retransmitted packet will arrive at the receiver. Whichever packet arrives second will be discarded as a replay fail, but since one copy of the packet has already been received, this doesn't cause any serious problems.

There is a open task to improve how we do retransmissions, https://code.google.com/p/webrtc/issues/detail?id=1095, which will resolve this issue.