<!-- 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 - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail --> Change parameter one to support pseudo variables ``` if (ds_list_exist("12001") { ... } ``` or ``` $var(id) = 10; if (ds_list_exist($var(id)) { ... } ```
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2099
-- Commit Summary --
* dispatcher: ds_list_exist support pv as param
-- File Changes --
M src/modules/dispatcher/dispatch.c (4) M src/modules/dispatcher/dispatcher.c (11)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2099.patch https://github.com/kamailio/kamailio/pull/2099.diff
@jchavanton this is ok but you could already do ``` if (ds_list_exist("$var(id)") { ```
The current approach is Kamailio specific and I think it is fine to keep it, because it already allows giving the variable as parameter. The fixup proposed to be used in this patch is inherited from SER side.
Thanks for the feedback,
Weird, I decided to change it because it was not accepting the was (complaining at startup). I will dig it further.
We could add deprecated comments here and there to point to the favored alternatives.
``` $var(list) = 10; if (ds_list_exist($var(list))) { ... ```
``` 0(8) CRITICAL: <core> [core/cfg.y:3507]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 200, column 21-44: function ds_list_exist: parameter 1 is not constant ```
I see this is working : ``` $var(list) = 10; if (ds_list_exist("$var(list)")) { ... ```
I guess I have what I need ...
I looked again at the macros, I will always search in `core/mod_fix.h` ``` FIXUP_F2FP(igp_null , 1 , 1 , 1, FPARAM_INT|FPARAM_PVS, 0) #define FIXUP_F2FP(suffix, minp, maxp, no1, type1, type2) \ ```
@jchavanton pushed 1 commit.
65c4ce1169b3a6e0e727fa18ae8a8a2987e06366 dispatcher: ds_list_exist logging adjustments
I converted the PR to a small logging level adjustments.
As I don't know the reasons about this change, why its wrong to inform the user with INFO level about the not found destination sets?
Hi Henning, I run info level logging often and this is the only module logging that level of verbosity. This seems like debug level to me. For me it means info level logging will now be filled with this lines.
The function return the fact that the set exist or not, why would anyone use the logs. The most likely explanation is that the author forgot to lower the log level to debug.
the `INFO` level for this message is actually misleading ops that get into panic saying `something's not working` when is perfectly normal not to have entries in some group. just merge it :)
I consider it should be merged as well: there is no relevant need to have a log message other than debug to confirm one or the other goal of the function -- in this case the function is to detect if a destinations group exists or not, by returning appropriate code in each case, so custom log messages can be printed in config routing blocks.
Anyhow, to differentiate between error and not found, I will change a bit the return codes. So, I am going to close this one and push a slightly different commit soon.
Closed #2099.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
Julien Chavanton
-
lazedo