[jitsi-dev] [jitsi/jitsi-videobridge] Mixed audio resulting in "Failed to unprotect SRTP packet" error (#230)


#1

Hi,

I am using JVB with jicofo and mixed audio (see attached crude patch to jicofo just FYI).
I am using audio only (no video).

the good: it seems to be mostly working.

the bad: a percentage of calls (maybe 20%) are failing and the webrtc android client is throwing (lots of) errors as follows:

E/libjingle( 6718): Failed to unprotect audio RTP packet: size=39, seqnum=14646, SSRC=1150943895
W/libjingle( 6718): Failed to unprotect SRTP packet, err=10
E/libjingle( 6718): Failed to unprotect audio RTP packet: size=39, seqnum=14647, SSRC=1150943895
W/libjingle( 6718): Failed to unprotect SRTP packet, err=10
E/libjingle( 6718): Failed to unprotect audio RTP packet: size=39, seqnum=14648, SSRC=1150943895
W/libjingle( 6718): Failed to unprotect SRTP packet, err=10
E/libjingle( 6718): Failed to unprotect audio RTP packet: size=39, seqnum=14649, SSRC=1150943895

I replicated the problematic behavior while tcpdumping on the server.

in my clientside logs I see this error:
W/libjingle(23074): Failed to unprotect SRTP packet, err=10
E/libjingle(23074): Failed to unprotect audio RTP packet: size=109, seqnum=32616, SSRC=2297436400

I then looked through the tcpdump in wireshark for the corresponding info and found this snippet:
http://i.imgur.com/6WFjjPP.png

it looks to me as if the error in the client logs corresponds exactly to this jump from seq 60076 in that SSRC to 32616. i.e. it seems to me that libsrtp on the clientside is unhappy with the backwards jump in sequence numbers.

I have attached the associated jvb.log (redacted ips / hosts). I am also happy to share any other logs or captures with you that might help.

Note: that it is a totally vanilla setup apart from the addition of rtp-level-relay-type="mixer" to some of the XML attributes when creating channels.

is there any extra logging or information that I could enable to pinpoint the issue further?

I am happy to try patches? I would also be grateful for any pointers to places in the code I could dig into as I have no experience with the jvb codebase so rough pointers of where to get started would be help.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/230


#2

I enabled FINER log level and also added some extra logging in SRTPCryptoContext::transformPacket

the following snippet shows the sequence number on SSRC 344202399 jumping from 50315 to
and I can see the sequence number in this example jumping from 47939 back to 50315

I have captured a few examples of this and in all cases it seems to follow the pattern of:
* good sequence number on a given ssrc
* <lots of logging in the ballpark of "Created SendStream">
* bad sequence number on same ssrc

can anyone point me at where or why in the code the sequence number might have been reset here? I think I'm zoning in on the problem here but I'm just not experienced enough with the code to join the dots.

Thanks

[jvb_verbose.txt](https://github.com/jitsi/jitsi-videobridge/files/241602/jvb_verbose.txt)

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/230#issuecomment-215595404


#3

this is pretty interesting. we've seen srtp_unprotect errors in last-n but the cause is a bit more obvious there since there are legitimate gaps in stream forwarding, i wouldn't expect the audio mixing to have that problem. @gardenia was the jump in sequence numbers tied to any event that you were aware of? such as: client muting/unmuting/new client joining/client leaving, anything like that?

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/230#issuecomment-221977042


#4

@brianh5 no we couldn't correlate it to any use ever such as mute/unmute. that was one of the first things we tried as an area of investigation since we had found some webrtc tickets in relation to that.

in all cases I'm aware of it seemed to be preceded with this piece of logging:
org.jitsi.impl.neomedia.device.MediaDeviceSession.trace() Set format of track 0 to opus/rtp, 48000.0 Hz, Stereo

anecdotally it seemed that the above (see jvb.txt in my last comment for larger log snippet) always seemed to precede the problem state. I was not able to establish what it was that was firing the above event (whether it was triggered by some in band media channel event sent from the client or whataver) but that state change seemed to be correlatable to the problem. whether this is actually relevant or not I'm not sure.

I'm pretty sure we did not see the problem until we started using mixed audio streams. but I can't be totally sure about that.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/230#issuecomment-221985015


#5

Hi @brianh5 and @bgrozev, any updates on this isssue?
We experienced the same issue sometimes with mixed audio.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/230#issuecomment-229063384