Add support to send a command to an RTPEngine specified by the sock_var - #3617
Merged
Conversation
NormB
marked this pull request as draft
April 1, 2025 20:13
Member
Author
|
I've moved this PR into draft status because it needs more testing against some edge cases. |
NormB
marked this pull request as ready for review
April 3, 2025 19:46
Member
Author
|
@razvancrainea @bogdan-iancu This update offers the possibility of using a script to cause the proxy to direct RTPEngine commands to any RTPEngine that has previously been defined and is operational. This should be used with the same caution as any other function that the proxy provides. If this update is approved, I'll work on some doc to explain how it can be used. Norm |
1. If the set variable is passed in, use it. Otherwise use the existing logic. 2. Move setting of the socket STR outside of the loop.
NormB
marked this pull request as draft
April 10, 2025 11:11
Member
Author
|
Successful testing after requested updates were implemented. |
NormB
marked this pull request as ready for review
April 10, 2025 11:40
liviuchircu
pushed a commit
to liviuchircu/opensips
that referenced
this pull request
May 20, 2025
…ar (OpenSIPS#3617) * Add support to send a command to an RTPEngine specified by the sock_var * Removed some logging problems that the linter complained about. * Updates to support memory corruption edge case * Fixed casting typo * Update some comments * Implement developer suggestions 1. If the set variable is passed in, use it. Otherwise use the existing logic. 2. Move setting of the socket STR outside of the loop. * Update README * Update rtpengine_admin.xml documentation
NormB
added a commit
to NormB/opensips
that referenced
this pull request
May 9, 2026
…ar (OpenSIPS#3617) * Add support to send a command to an RTPEngine specified by the sock_var * Removed some logging problems that the linter complained about. * Updates to support memory corruption edge case * Fixed casting typo * Update some comments * Implement developer suggestions 1. If the set variable is passed in, use it. Otherwise use the existing logic. 2. Move setting of the socket STR outside of the loop. * Update README * Update rtpengine_admin.xml documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Many rtpengine_* functions accept a parameter that will be populated with the socket of the RTPEngine chosen for the particular operation. For example, the rtpengine_offer() function accepts a "sock_var" parameter. The "sock_var" variable is populated correctly. The ability to use the "sock_var" in subsequent rtpengine_* function calls has not been available. This PR adds the ability to have the "sock_var" used to determine the specific RTPEngine that the operation is to be directed towards.
Details
When using a pool of RTPEngines (and/or a pool of OpenSIPS servers) and enabling services such as early media along with bridging multiple call legs it is possible that an OpenSIPS server may not be able to use the call-id to locate which RTPEngine the legs of a call are on. Most of the time, the call-id lookups that rtpengine.c use work well. In some advanced scenarios, the lookup will send the RTPEngine command to an incorrect RTPEngine sever.
This PR provides an ability for the script writer to store the chosen RTPEngine in the "sock_var" variable for an rtpengine_play_media() command and then use the "sock_var" in the rtpengine_stop_media() command.
The format of the data stored in "sock_var" is: proto:ip:port so it is possible for the script writer to create and use a "sock_var" without having it first stored by one of the rtpengine_* functions. Clearly, the script writer needs to have some mechanism to select the correct RTPEngine server.
Solution
The rtpengine.c module is designed in a modular way with subroutines for each rtpengine_* call. All of these subroutines eventually call rtpe_function_call() where the specific RTPEngine node is determined. This PR adds additional logic to rtpe_function_call() to support using the "sock_var" if it has been specified and is non-empty.
In addition, an important improvement has been made to the rtpe_test() subroutine. During the development of this PR a memory corruption / leak was identified. Two different binary encoding (bencode) routines where called, one for requests and the other for replies. Each of these routines allocates space on the bencode_buffer. The problem is that each of these routines stored the resulting allocated memory address in the same variable. Creation of a second variable so that requests and replies are stored separately resolved this issue.
Compatibility
There is no change to any logic when storing the chosen RTPEngine in a specified "sock_var".
If a script specifies a "sock_var" and that variable is non-NULL, then it will be used to determine the RTPEngine server to direct the command to.
If the script writer wants to specify a "sock_var" parameter, but does not want it to be used then the "sock_var" variable should not be populated. In this case, it will be populated when one of the rtpengine_* functions has chosen an RTPEngine server.
Closing issues