Garbled audio

[David Cunningham]

Hello,

We have a server which had working TLS/SRTP with audio going through rtpengine until we upgraded from Ubuntu 18.04 to 22.04. Calls go from Asterisk to Kamailio, and Kamailio sends the audio to rtpengine for TLS calls.

After the Ubuntu upgrade we recompiled rtpengine but experienced garbled audio in the direction received by the TLS phone. The other direction (from TLS to the plain UDP phone) has working audio. We then upgraded rtpengine from mr11.1.1.2 to mr11.5.1 however the audio is still garbled. Both phones have only the PCMU codec enabled. The rtpengine logging from the end of the call is below.

Does anyone have any suggestions on what the problem could be? Thanks in advance!

Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] Final packet stats:
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] --- Tag 'as29f21306', created 1:14 ago for branch ''
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] ---     subscribed to 'w1XZX1T'
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] ---     subscription for 'w1XZX1T'
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] ------ Media #1 (audio over RTP/AVP) using PCMU/8000
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] --------- Port     XX.XX.1.72:46328 <>     XX.XX.1.72:15166, SSRC 60c7d952, in 431 p, 74132 b, 0 e, 62 ts, out 465 p, 79980 b, 0 e
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] --------- Port     XX.XX.1.72:46329 <>     XX.XX.1.72:15167 (RTCP), SSRC 60c7d952, in 1 p, 64 b, 0 e, 66 ts, out 2 p, 344 b, 0 e
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] --- Tag 'w1XZX1T', created 1:14 ago for branch ''
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] ---     subscribed to 'as29f21306'
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] ---     subscription for 'as29f21306'
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] ------ Media #1 (audio over RTP/SAVP) using PCMU/8000
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] --------- Port     XX.XX.1.72:48482 <>   YY.YY.196.96:59078, SSRC c322896a, in 465 p, 85004 b, 2 e, 60 ts, out 431 p, 77060 b, 0 e
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] --------- Port     XX.XX.1.72:48483 <>   YY.YY.196.96:59088 (RTCP), SSRC c322896a, in 6 p, 748 b, 11 e, 63 ts, out 1 p, 84 b, 0 e
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] --- SSRC c322896a
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] ------ Average MOS 4.3, lowest MOS 4.3 (at 0:09), highest MOS 4.3 (at 0:09) lost:0
Jun  9 18:46:18 caes8 rtpengine[1939]: INFO: [0f4106773ef9fd4e...@XX.XX.1.72:5070]: [core] ------ respective (avg/min/max) jitter 11/11/11 ms, RTT-e2e 1.1/1.1/1.1 ms, RTT-dsct 0.0/0.0/0.0 ms, packet loss 0/0/0%

[Richard Fuchs]

On 09/06/2024 21.55, David Cunningham wrote:
> Hello,
>
> We have a server which had working TLS/SRTP with audio going through
> rtpengine until we upgraded from Ubuntu 18.04 to 22.04. Calls go from
> Asterisk to Kamailio, and Kamailio sends the audio to rtpengine for
> TLS calls.
>
> After the Ubuntu upgrade we recompiled rtpengine but experienced
> garbled audio in the direction received by the TLS phone. The other
> direction (from TLS to the plain UDP phone) has working audio. We then
> upgraded rtpengine from mr11.1.1.2 to mr11.5.1 however the audio is
> still garbled. Both phones have only the PCMU codec enabled. The
> rtpengine logging from the end of the call is below.

Can't really say from just the log, you'd have to look at the actual
media. Cipher suite might be a candidate, perhaps the newer version
negotiates to AEAD while the older one used AES and there's something
broken with AEAD. Search the log for any errors related to SRTP or DTLS.
Use Wireshark to inspect the RTP directly.

Cheers