dialog: add options_ping_max_retries parameter for OPTIONS ping retries

[digipigeon]

Summary

Add a new options_ping_max_retries module parameter to the dialog module that allows configuring additional OPTIONS ping attempts before declaring a dialog leg dead and terminating the call.

Details

In UDP deployments, a single OPTIONS ping request or its 200 OK response can be lost in transit. With the current behavior, one lost packet immediately terminates an otherwise healthy call, which can be disruptive for end users.

This is particularly problematic in networks with occasional packet loss where calls are functioning normally but a single missed keepalive ping triggers unnecessary call teardown.

Solution

Introduce a new parameter options_ping_max_retries (default: 0) that specifies how many additional OPTIONS pings to send after a timeout before declaring the leg dead:

When an OPTIONS ping times out (408/FAKED_REPLY), the module now checks if retries remain
Retries are sent immediately from the reply callback, not waiting for the next options_ping_interval tick
A per-leg ping_retries counter tracks failed attempts and resets on any successful response
481 responses are treated as definitive failures and not retried
Worst-case detection time: (options_ping_max_retries + 1) * fr_timeout
Changes:

Added options_ping_max_retries parameter in dialog.c
Added ping_retries field to dlg_leg structure
Implemented retry logic in dlg_handle_seq_reply() in dlg_timer.c
Added comprehensive documentation in dialog_admin.xml
Example usage:

Compatibility

Fully backward compatible. The default value of 0 preserves the existing behavior where a single failed OPTIONS ping immediately terminates the dialog.

[bogdan-iancu]

Hi @digipigeon , thanks for the contribution here . I understand that your change introduces a bit of tolerance to the OPTIONS pinging (like 3 pings in a row must fail in order to terminate the call, instead of a single one), but I need to correct you on a statement. You say:

In UDP deployments, a single OPTIONS ping request or its 200 OK response can be lost in transit. With the current behavior, one lost packet immediately terminates an otherwise healthy call, which can be disruptive for end users.

And this is not true at all - one single lost packet does not trigger the call termination - the sending of the OPTIONS is stateful, meaning it is subject to retransmissions (for the request), to it is tolerant to a single packet lost, even on UDP.
Again, I understand the idea behind your PR, but I wanted to clarify this statement, things are not so dramatic as you described :)

Now, to move on with this PR, we need two more things from your side:

• do a rebase as the patch does not apply anymore
• update the docs - drop the changes over the XML file (which does not exist anymore) and update the README.md file. (maybe do this before the above point, at the conflicts may be because of all these doc related changes)