xmlrpc-callback not triggered when only one side stops sending RTP

[Denys Pozniak]

Hello,
We are testing the no-RTP detection feature using b2b-url + xmlrpc-callback

in rtpengine v11.5.

Setup:
- Kamailio sends xmlrpc-callback=<kamailio-ip> in the ng offer
- rtpengine.conf: timeout=30, b2b-url=http://%%:8080/rpc, xmlrpc-format=2

The problem:
When the SIP client (phone) crashes without sending a BYE, it stops sending
RTP. However, FreeSWITCH (the other leg) is still alive and continues sending
RTP packets towards rtpengine. Since rtpengine's timeout fires only when ALL
media streams are dead (no traffic from either direction), the callback is
never triggered — FS keeps the stream alive indefinitely.

From the man page:
"If all media streams belonging to a particular call go dead, then the call
 is removed from rtpengine's internal state table."

Question:
Is there a way to trigger the xmlrpc-callback when only ONE direction goes
silent (i.e. the client side stops sending), even while the other side
(FS/B2BUA) is still active? Something like a per-direction timeout or a
one-way media detection flag in the ng offer?

If this is not currently supported, is it on the roadmap, or would you
suggest an alternative approach?

Due to technical difficulties, it is not possible to enable rtp-timeout-sec on FS as a workaround.

Thank you!

[Richard Fuchs]

On 17/04/2026 06.22, Denys Pozniak wrote:
> Is there a way to trigger the xmlrpc-callback when only ONE direction goes
> silent (i.e. the client side stops sending), even while the other side
> (FS/B2BUA) is still active? Something like a per-direction timeout or a
> one-way media detection flag in the ng offer?

That's not currently supported (unless there was a contribution that I
missed) and there are no plans to add support for it. But you're welcome
to open a PR if you code it up yourself.

Reason being exactly because:

> Due to technical difficulties, it is not possible to
> enable rtp-timeout-sec on FS as a workaround.

It's supposed to be the responsibility of the remote client to detect
this situation and tear down the call.

There is a `final timeout` option to eventually tear down run-away
calls, but you'd have to set it to a very long timeout so it doesn't
interfere with legitimate long running calls.

Cheers