<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] 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
- [x] New feature (non-breaking change which adds new functionality)
#### Checklist: - [x] Tested changes locally
#### Description proposal for `xavp_copy()` param1: source xavp name param2: source xavp index param3: destination xavp name
The command will copy only one specific xavp from the stack. If the destination xavp stack exist it will append else it will create a new one, it seems to be more or less compatible to what we do with XAVP in general.
We can not reorder xavp stack like in the following example :
``` route[TEST] { $xavp(a=>x) = "a-0-x"; $xavp(a[0]=>y) = "a-0-y"; $xavp(a=>x) = "a-1-x"; $xavp(a[0]=>y) = "a-1-y"; xinfo("$$xavp(a[0]) = [$xavp(a[0]=>x)][$xavp(a[0]=>y)]\n"); xinfo("$$xavp(a[1]) = [$xavp(a[1]=>x)][$xavp(a[1]=>y)]\n");
$var(src_idx) = 1; $var(v) = "b"; xavp_copy("a", "$var(src_idx)", "$var(v)"); $var(src_idx) = 0; xavp_copy("a", "$var(src_idx)", "$var(v)"); xinfo("$$xavp(b[0]) = [$xavp(b[0]=>x)][$xavp(b[0]=>y)]\n"); xinfo("$$xavp(b[1]) = [$xavp(b[1]=>x)][$xavp(b[1]=>y)]\n"); } ```
``` 2(137) INFO: <script>: $xavp(a[0]) = [a-1-x][a-1-y] 2(137) INFO: <script>: $xavp(a[1]) = [a-0-x][a-0-y] 2(137) INFO: pv [pv.c:827]: w_xavp_copy(): xavp_copy(new): $xavp(a[1]) >> $xavp(b) 2(137) INFO: pv [pv.c:833]: w_xavp_copy(): xavp_copy(append): $xavp(a[0]) >> $xavp(b) 2(137) INFO: <script>: $xavp(b[0]) = [a-0-x][a-0-y] 2(137) INFO: <script>: $xavp(b[1]) = [a-1-x][a-1-y] ``` You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2070
-- Commit Summary --
* core: adding xavp_clone_level_nodata_with_new_name
-- File Changes --
M src/core/xavp.c (126) M src/core/xavp.h (14)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2070.patch https://github.com/kamailio/kamailio/pull/2070.diff
@jchavanton pushed 1 commit.
9acc42389e42cce160605c0312b4598cdb55de9c pv: adding xavp_copy
@jchavanton pushed 1 commit.
69c8e1ccdc478eeb63a47e9fda0fb997c6ca7852 pv: add documentation for xavp_copy
@jchavanton pushed 1 commit.
989fbc5836c8dc79d3827cf3879624aa827cc434 pv: xavp_copy
Thank you. From the code it looks good to me. I think it can be merged when git master is opened again (after 5.3.0 release).
I may find a little bit more time to add another version that will take 4 parameters and would be able to select a destination anywhere in the stack. I believe this should be easy given the set of helper functions available. But this PR seems to be working fine for me.
@jchavanton pushed 1 commit.
f489ab8110f427ed5b44ac1d0cf07bc8f8f4ec8f pv: add missing failure check
I am assuming access to XAVP is synchronized as part of the transaction.
Even if this maybe off topic I am just making sure this assumption is safe. I am looking at the TM module to make sure I understand how the multi replies are synchronized. I can see in the TM module that the post callback is "releasing the transaction" by decrement the ref_count ``` register_script_cb( w_t_unref, POST_SCRIPT_CB|REQUEST_CB, 0)<0 ) ``` I do not yet found the check to lock / delay parallel execution of replies. ``` register_script_cb( script_init, PRE_SCRIPT_CB|REQUEST_CB , 0) ```
I am need a bit more time to make sure everything is safe.
I found the code `reply_received` in tm synchronizing the execution of `onreply_route`.
I think we should merge this first small iteration and I can proceed with another MR to add another xavp_copy function taking 4 params after, in order to proceed with small iterations, let me know if you think otherwise.
I already have the code for `xavc_copy("source_name", "source_index", "destination_name", "destination_index")` This will let the user copy to a specific posistion in the stack (replacing its value). This would bring coherent behaviour compared to assign to a specific index vs appendind.
Example : swapping xavp in and existing stack: (second and third elements) ``` $xavp(a=>x) = "a-0-x"; $xavp(a[0]=>y) = "a-0-y"; $xavp(a=>x) = "a-1-x"; $xavp(a[0]=>y) = "a-1-y"; $xavp(a=>x) = "a-2-x"; $xavp(a[0]=>y) = "a-2-y";
# INFO: <script>: NEW $xavp(a[0]) = [a-2-x][a-2-y] # INFO: <script>: NEW $xavp(a[1]) = [a-1-x][a-1-y] # INFO: <script>: NEW $xavp(a[2]) = [a-0-x][a-0-y]
xavp_copy("a", "1", "c"); xavp_copy("a", "2", "a", "1"); xavp_copy("c", "0", "a", "2");
# INFO: <script>: AFTER $xavp(a[0]) = [a-2-x][a-2-y] # INFO: <script>: AFTER $xavp(a[1]) = [a-0-x][a-0-y] # INFO: <script>: AFTER $xavp(a[2]) = [a-1-x][a-1-y] ```
Just squashed the commits, we needed only 2 in the end.
The master is open for new features, this can be merged.
Merged #2070 into master.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
Julien Chavanton