ICE-lite to RTP Issue with RTPEngine mr13.5.1.3 – No Audio

[xiaofang han (hance)]

Hello everyone,

I’m running a media relay setup with the following flow:

ice-lite endpoint → RTPEngine mr13.5.1.3 → plain RTP endpoint

I’m encountering a complete no-audio issue after routing calls through RTPEngine, and I’m looking for help troubleshooting this.

Relevant Kamailio Configuration

Here is the core RTPEngine routing logic in my kamailio.cfg:

if (has_totag()) {
    rtpengine_manage("SIP-source-address replace-origin replace-session-connection");
} else {
    rtpengine_manage("SIP-source-address replace-origin replace-session-connection ICE=remove ICE-lite=off SDES-off ICE=remove RTP/AVP");
}


Issue Details

Calls establish successfully (SIP signaling works fine), but there is no audio path in either direction.

Full RTPEngine debug logs are available here for reference:

https://pastebin.com/A9tEyrPv

Setup Notes

- RTPEngine version: mr13.5.1.3

- One side is an ICE-lite capable endpoint, the other is a plain RTP endpoint (no ICE support)

- I’m attempting to strip ICE and enforce plain RTP/AVP via the Kamailio flags

- No SRTP/SDES in use (disabled explicitly)

Any advice on misconfigured flags, ICE handling mismatches, or media negotiation issues would be greatly appreciated. Thanks in advance for your help!

[Richard Fuchs]

On 27/03/2026 03.04, xiaofang han (hance) wrote:

ice-lite endpoint → RTPEngine mr13.5.1.3 → plain RTP endpoint

...

Calls establish successfully (SIP signaling works fine), but there is no audio path in either direction. 

...

- One side is an ICE-lite capable endpoint, the other is a plain RTP endpoint (no ICE support)

It looks like your ICE-lite peer has a broken ICE implementation, or something has incorrectly mangled the SDP, or something else is wrong with that peer.

The received offer SDP shows:

a=candidate:5366908390 1 udp 2130706431 172.16.99.205 16912 typ host generation 0
a=candidate:5366908390 2 udp 2130706431 172.16.99.205 16912 typ host generation 0

These two candidates are for components 1 and 2, which are RTP and RTCP. They should have different ports: RTCP would run on 16913, not 16912.

All ICE candidates also must have unique priority numbers, which is mandated by the RFC. These do not.

It's possible to run RTP and RTCP on the same port, but this would need to be advertised explicitly in the SDP (it wasn't), and even if so, then only one candidate should be present.

Rtpengine correctly responds with two distinct candidates for RTP and RTCP:

a=candidate:zL8TuOQMyiInHKIm 1 UDP 2130706431 172.16.99.205 29204 typ host
a=candidate:zL8TuOQMyiInHKIm 2 UDP 2130706430 172.16.99.205 29205 typ host

Ultimately this seems to confuse the peer (if it wasn't already confused) and it ends up delivering RTP to the RTCP port, and so rtpengine forwards this to the remote RTCP port:

port 29205]: [core] Handling packet: remote 172.16.99.205:16912 (expected: 172.16.99.205:16912) -> local 172.16.99.205:29205
port 14095]: [core] Forward to sink endpoint: local 172.16.99.205:14095 -> remote 172.16.99.205:29239

I'm not sure if this sort of misbehaviour could even be identified and remedied for on the rtpengine side, except maybe detecting the obviously wrong ICE offer and just rejecting it.

I don't think we currently have an option to explicitly instruct rtpengine "ignore the ICE offer in this SDP."

Cheers

[xiaofang han (hance)]

A bug was found in the IPPBX system with the following SDP candidate lines:

a=candidate:5366908390 1 udp 2130706431 172.16.99.205 16912 typ host generation 0
a=candidate:5366908390 2 udp 2130706431 172.16.99.205 16912 typ host generation 0

This Kamailio route fixes the candidate line issue :

route[KSR_KEEP_ONLY_FIRST_CAND]{
sdp_get_line_startswith("$avp(candidate)", "a=candidate:");
$avp(candidate) = $(avp(candidate){re.subst,/^(a=candidate:[0-9]+).*/\1/});
$avp(candidate) = $avp(candidate) + " 2 udp";
sdp_remove_line_by_prefix("$avp(candidate)", "audio");
msg_apply_changes();
}

Cheers.