DTLS rekeying causes calls to lose audio #1705
Comments
|
For comparison, what does the log show during rekeying in the working version? I guess @Den4t might be interested in this as well |
|
Here's the log of a call lasting about 2 minutes 30 seconds using rtpengine master with a revert commit for 2f4f6d5 on top, no special logging configuration: Same setup, with |
|
So the rekeying is associated with an additional signalling event? An extra answer? Am I seeing this right? (Timestamps are missing from the log) Does the additional answer indicate that DTLS should be re-established? Different fingerprint or |
|
As far as I understand it, there's no additional signaling involved in DTLS rekeying, it is done purely on a DTLS level without any SIP/SDP packets as per RFC5764. This matches the observed SIP traffic: There is no SIP traffic from the participants after the establishing OK/ACK until one party hangs up with a BYE. Only the attached log had timestamps, sorry. Here's a "normal" log with timestamps: |
|
The thing is that in this log I don't see a new DTLS handshake after 2 minutes. And the original code (before 2f4f6d5) would simply ignore and drop DTLS packets after the initial handshake. Which makes me think that it's not a rekeying that's happening here at all. |
|
Or perhaps your PJSIP is trying to rekey, but the old version simply ignores it and the rekey fails, so the previous key continues to be used? Does your PJSIP give any indication as to what it's doing? What do these DTLS packets look like in Wireshark? |
There are some hints as to something related to DTLS in the attached log file above, once while establishing the call: Then again after exactly two minutes: Unfortuately, there's no further information what those DTLS packets contain, as far as I can tell.
I'll convince the Asterisk to log more DTLS details tomorrow morning (UTC+2), and then report back with that data and a PCAP. Thanks for the quick answers and the help so far! |
|
I can find no issues in the Asterisk DTLS debug log, there's just an acknowledgement of the rekeying (I've highlighted the corresponding lines in bold). I've also captured the DTLS traffic – github wont let me attach PCAPs, though. I can see the Asterisk sending an encrypted handshake to rtpengine exactly two minutes after the initial handshake. There's no second handshake between rtpengine and the WebRTC client, though. I think this validates your suspicion that the rekeying just (more or less silently) fails. |
|
Ok that's good information. It will take some trial and error to make this work as I don't have a good way to easily reproduce this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've been using rtpengine 11.2.1.12 with the corresponding kernel module to connect WebRTC calls to Asterisk (16.x and 20.x) via Kamailio (5.7). This setup has been working for quite a while. After an update to basically any newer rtpengine release (we've tried 11.3.1.11 and 11.4.1.3 initially), calls lose audio after exactly 2 minutes, which corresponds to the DTLS rekeying interval specified in our Asterisk PJSIP configuration for those endpoints.
Asterisk logs unprotect errors for both SRTP and SRTCP packets:
rtpengine also logs INFO and WARNING level messages:
With
git bisect, we narrowed down the cause to commit 2f4f6d5. As soon as this commit is reverted, calls no longer lose audio after 2 minutes. Also, disabling DTLS rekeying for the endpoints in Asterisk fixes the issue.We thus suspect the code added in the mentioned commit does not handle DTLS rekeying correctly.
The text was updated successfully, but these errors were encountered: