possible regression regarding one-way audio calls in version 13.5.1.25

[henningw]

rtpengine version the issue has been seen with

13.5.1.25-1~bpo12+1

Used distribution and its version

Debian 12

Linux kernel version used

No response

CPU architecture issue was seen on (see uname -m)

x86_64

Expected behaviour you didn't see

The rtpengine should route the calls without one-way audio.

Unexpected behaviour you saw

After an update from 13.5.1.13-1~bpo12+1 to 13.5.1.25-1~bpo12+1 we saw a much higher number of one-way audio calls on the new production rtpengine instance. The instance was removed after one hour, but the number of one-way calls were multiple times higher on the new rtpengine as on the old. The new .25 version rtpengine instance was left running for some time, to eliminate eventual statistical anomalies. The control part (Kamailio 6.0.x) was also rebooted, this did not had any effect regarding this issue. The issue was observed multiple times as well, after removing the rtpengine and adding it back.

Steps to reproduce the problem

So far we only observed it in production on a specific customer system. The control side (Kamailio) was not changed. The same configuration is running on multiple older .13 rtpengine systems without any issues.

No special rtpengine flags were used, also the rtpengine configuration by itself its quite standard. Notable probably that websocket is used as control protocol. The rtpengine instances are managed using the Kamailio RPC command.

[rfuchs]

This isn't really actionable without at least some more detail about what kind of calls are affected, e.g. is ICE or SRTP in use, etc

[henningw]

This isn't really actionable without at least some more detail about what kind of calls are affected, e.g. is ICE or SRTP in use, etc

Thanks, yes. I will add more details tomorrow, also parts of the configuration.

[denyspozniak]

we see 1way audio on 13.5.18 too , maybe related to #2164

[henningw]

This isn't really actionable without at least some more detail about what kind of calls are affected, e.g. is ICE or SRTP in use, etc

Sorry, it took a bit longer due to a change in the remote access from the customer side.

The rtpengine.conf is straightforward

• one listen interface
• kernel mode
• redis for storing session data
• web socket as control channel from kamailio side
• timeout = 60, silent-timeout = 3600, final-timeout = 14400
• homer for getting QoS data

Regarding the kamailio rtpengine configuration is also not special:

• loop-protect replace-origin replace-session-connection ICE=remove RTP AVP (for internal)
• loop-protect replace-origin replace-session-connection ICE=force SRTP AVP (for external)

[rfuchs]

Still not enough information. ICE involvement is a likely culprit as there have been some changes there. Which call scenarios are affected exactly and in which direction?

[henningw]

Still not enough information. ICE involvement is a likely culprit as there have been some changes there. Which call scenarios are affected exactly and in which direction?

Thanks for the ICE related hint. We are trying to reproduce it right now on a test system, then I can forward you a debug log of an affected call. Due to the larger number of calls we can not do that on the production system unfortunately.