[FEATURE] rtpengine selection tags

[john08burke]

Is your feature request related to a problem? Please describe. The current node selection process for rtpengine / rtpproxy modules is based upon the concept of sets. This allows for macro level selection, where nodes are logically grouped into sets and then script level selection is based upon some criteria / settings. This works quite well in most cases, but I often find myself wishing for a more finer level control of node selection in cases where I want to prioritize specific nodes over others.

For example, say I have a global cluster of nodes (i.e. east, central, west) with the goal of keeping RTP as close to the UAC as possible. This is certainly achievable today, where I could represent a set as a geographical grouping of nodes. However, to also allow for site failure I would either need to include in the set some lower weighted off-site nodes... or manually failover between sets at the script level.

To further extend the example. Say I also have nodes with different hardware specs (i.e. kernel-only, transcode, recording). If a call is to be recorded, I might want to send to nodes with some higher end processors / SSDs. However, set management becomes a nightmare if I also want to geographically prioritize node selection.

Describe the solution you'd like One idea would be to implement a tag schema, heavily inspired by MongoDB's read preference tagging schema. The way I would envision it: (1) node definition would include a list of tags, (2) node selection would provide tag(s). This relatively simplistic approach extends the set construct and allows for some pretty complex selection logic. An illustration below:

Node Definitions: Node ID	Set ID	Tags
1	1	west
2	1	east
3	1	transcode
4	1	west,transcode

Node Selection: , - delimiter between tags groups : - delimiter for multiple tags Tags	Result
	any node
east	2
west	random 1,4
west,	random 1,4 else any node
west,east	random 1,4 else 2
transcode	random 3,4
west:transcode,west,	4 else random 1,4 else any node

This idea would also mesh with the current "downed" node mechanism, where we would consider the node state when matching tags. If all nodes are down in the tag group, then we proceed to the next tag group.

Implementation

• Component: rtpengine

To accommodate this logic, the DB schema would need to be modified such as:

CREATE TABLE rtpengine (
    id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
    socket TEXT NOT NULL,
    set_id INT(10) UNSIGNED NOT NULL
    tags TEXT NOT NULL
) ENGINE=InnoDB;

Then the script function(s) would need to accept a tag list argument. Some possibilities would be to extend rtpengine_use_set(), make a new rtpengine_use_tag(), or extend the rtpengine_[offer|answer|delete|manage] methods.

[github-actions[bot]]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.

[github-actions[bot]]

Marking as closed due to lack of progress for more than 30 days. If this issue is still relevant, please re-open it with additional details.

[john08burke]

Hey @razvancrainea, @bogdan-iancu what do you think of this concept? I have some good use cases for it and might have some time in the coming weeks to put a PR together if you're on-board.

[bogdan-iancu]

Hi @john08burke , maybe a miss something here (highly possible, still too morning here :P), but what you are trying to achieve by tags could be also achieved only with groups (and some extended logic on using the groups). More or less I see some overlapping between the 2 concepts (groups and tags). As I see it, you can do the same by making possible to select multiple sets when selecting the rtpproxy. So you can reflect the geo location by groups and simply do invoke with sets 1,2 . In addition the wildcard group selector may be added.

[john08burke]

Hey @bogdan-iancu, I think you're right. The existing group logic could be extended to support the same functionality that tags offer, but would have some limitations. Specifically the logical and case is more difficult to maintain by only extending the group logic. The last scenario from above (west:transcode,west,) demonstrates this. As I see it if only groups are used, you would have to create a group for 1=west, 2=transcode, and 3=west-transcode and then engage rtpengine via 3,1,. It becomes even more complex when you want to implement a n+ functional match scheme (ie west:transcode:epyc:srtp).

I think tags also offer a few auxiliary upsides:

• script/DB management becomes more logical IMO. The script writer accumulates tags based upon some logical decision making (ie location, recording, etc) without the requirement of knowing the tag->group mapping.
• the number of nodes needed to be maintained (probing, connections, etc) can be minimized by using a single group with tags... as opposed to duplicating nodes in multiple groups.
• At a glance, I think it would be easier to implement in the code base.

IMO, a tag scheme would complement the existing grouping scheme. Group gives you macro-level control, while tags give you micro-level control.

Let me know your thoughts!