Need clarification on how to enable heuristic end-point learning and strict-source

18 views
Skip to first unread message

Vaibhav Pandey

unread,
Oct 9, 2025, 5:58:54 AMOct 9
to Sipwise rtpengine
Hi,

I am currently running the following versions:
  • OpenSIPS Version: 3.4

  • rtpengine Version: mr13.2.1.1

I am encountering difficulties while attempting to enable the strict-source parameter for media sessions.

As the OpenSIPS rtpengine module documentation for version 3.4 does not list a flag explicitly named strict-source, I would appreciate guidance on the following:

  1. Which specific flag should I use within the rtpengine_offer/answer function in my OpenSIPS configuration to effectively enable the strict-source functionality on the rtpengine?

In addition, once the necessary configuration is implemented, I would like to confirm the expected operational behavior in the rtpengine logs.

  1. What specific log observations (particularly in the rtpengine.log) should I look for after successfully enabling both heuristic mode and the equivalent of the strict-source flag? This information will be crucial for debugging and validation.

BR//
Vaibhav

Richard Fuchs

unread,
Oct 9, 2025, 7:29:07 AMOct 9
to rtpe...@googlegroups.com
On 09/10/2025 05.58, 'Vaibhav Pandey' via Sipwise rtpengine wrote:
  1. Which specific flag should I use within the rtpengine_offer/answer function in my OpenSIPS configuration to effectively enable the strict-source functionality on the rtpengine?

`strict-source`

This is assuming that the OpenSIPS control module supports generic, free-form string flags. The oracle of truth is the rtpengine log file: Enable debug logging and inspect the `flags` list in the offer/answer messages and see if the flag is there.

  1. What specific log observations (particularly in the rtpengine.log) should I look for after successfully enabling both heuristic mode and the equivalent of the strict-source flag? This information will be crucial for debugging and validation.

In addition to checking whether the flag is actually there, the only other relevant log messages are printed only when the respective action is taken, e.g. a packet is dropped because the source address didn't match. As such, the best way to verify the operation is not to look at the log file but rather perform an actual test. Establish a mock call, send mock RTP from different addresses, and see what's coming out the other side.

Cheers

Vaibhav Pandey

unread,
Oct 14, 2025, 2:25:17 AMOct 14
to Sipwise rtpengine
Hi,

Is their setup for establishing a mock call and send mock RTP from different addresses so that i can see the results?

BR//
Vaibhav
Reply all
Reply to author
Forward
0 new messages