Pre-Submission Checklist

Commit message has the format required by CONTRIBUTING guide
Commits are split per component (core, individual modules, libs, utils, ...)
Each component has a single commit (if not, squash them into one commit)
No commits to README files for modules (changes must be done to docbook files
in doc/ subfolder, the README file is autogenerated)

Type Of Change

Small bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds new functionality)
Breaking change (fix or feature that would change existing functionality)

Checklist:

PR should be backported to stable branches
Tested changes locally
Related to issue #XXXX (replace XXXX with an open issue number)

Description

Introduce a versatile behavior of the rtpengine module
in terms of ability to parse flags on rtpengine side,
instead of module. Previous behavior is also kept (so backwards compatibility).

General points:

rtpengine daemon supports rtpp flags processing from now on
module still provides in the bencode (when calling daemon):
call-id, to/from tags, viabranch (so identification call data)
even though the module's interface is updated,
a backwards compatibility is given, so no obligatory changes
from kamailio script users required
each rtpengine module's function where it's reasonable to use rtpp flags
as a parameter, now is able to get a third parameter viabranch,
which is used to detect, which approach to use (older/newer):
- without the viabranch - older one used
- with the viabrnach - new one used, so rtpp flags parsing on
  rtpengine side

The reason why the via-branch has been selected as a point of behavior
differentiation is that currently it's only given via option flags list (raw string),
meanwhile with a newer behavior option flags will not be parsed by the module.
Since the module still has to provide all the basic identifiers, such as:
call-id, From/To tags and via-branch, via-branch now is moved to a separate parameter,
and gives to the module a clue a newer behavior is to be applied.

The goal (for the future) is to deprecate processing of option flags
on the module side and only parse them using rtpengine.
This brings a list of benifits, such as:

no need to keep in sync rtpengine and module (for specific flags)
support of different rtpp flag string formats (raw), so that,
for example, kamailio script users can use plain text or
bencode dictionary like format, when providing flags from
the kamailio script

Current change is only applicable with rtpengine versions equal or later than mr12.3
Backwards compatibility provided, so users are not forced to change anything.

You can view, comment on, or merge this pull request online at:

https://github.com/kamailio/kamailio/pull/3788

Commit Summary

67b2e92 rtpengine: add flags processing on the daemon side
e2c1a0f rtpengine: update documentation in regards of flags processing

File Changes

(3 files)

M src/modules/rtpengine/doc/rtpengine.xml (8)
M src/modules/rtpengine/doc/rtpengine_admin.xml (45)
M src/modules/rtpengine/rtpengine.c (847)

Patch Links:

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.