failed to decode bencoded reply from proxy

9 views
Skip to first unread message

nz deals

unread,
Jul 13, 2026, 12:03:59 AM (11 days ago) Jul 13
to rtpe...@googlegroups.com

Hi everyone,

Has anyone come across an issue like this before?

I'm sending rtpengine_delete requests from OpenSIPS to rtpengine, and occasionally I receive the following error:

ERROR:rtpengine:rtpe_function_call: failed to decode bencoded reply from proxy

The issue only affects around 2% of calls, while the remaining 98% complete without any problems. When this happens, OpenSIPS retries the rtpengine_delete request several times.

Has anyone seen this before or knows what might cause it? Also, is there a way to safely ignore this error and continue processing if the delete request fails?


Thanks

Regards,
Jason

Alex Balashov

unread,
Jul 13, 2026, 12:22:52 AM (11 days ago) Jul 13
to rtpe...@googlegroups.com
A reasonable guess would be that the OpenSIPS RTPEngine control module doesn't support some rare, newer RTPEngine format or attribute. However, it could be something else.

If you're able to identify the Call-IDs to which this applies, you should capture the NG traffic and see if you can correlate to bencoded messages right off the wire.

-- Alex
> --
> You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/rtpengine/CALOQYiv9jYkc8TG5en7_8PgQ2nZRzWX17G-76EQPpbckvUVNZw%40mail.gmail.com.

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com, https://www.csrpswitch.com
Tel: +1-706-510-6800

Richard Fuchs

unread,
Jul 13, 2026, 7:33:27 AM (10 days ago) Jul 13
to rtpe...@googlegroups.com
Hard to say without seeing the messages in question.

In addition to what Alex suggested, another possible reason could be that "delete" responses can get quite large as they usually contain a bunch of statistics (related discussion here) and perhaps they end up truncated or the decoding process runs into some other kind of limitation. In very recent versions we've therefore added the "fast" flag to suppress these statistics, for people who don't need them, to significantly reduce the size of the messages. It could be worth a shot.

Other than that you'd have to find one of the offending messages to get a definitive answer. Setting the "control" log level to debug should be enough to do that.

Cheers
Reply all
Reply to author
Forward
0 new messages