Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
In my opinion, it does not look right. The kamailio.cfg wrapper function should call the kemi function, not the other way around.
If it is not an out put script variable, then the parameter should not be provided as kamailio.cfg pseudo-variable name, but as corresponding value. Practically, the example above with:
KSR.carrierroute.cr_user_carrier("$fU", "$fd", ...
Should be:
KSR.carrierroute.cr_user_carrier(KSR.kx.get_fuser(), KSR.kx.get_fhost(), ...)
Also, looking a bit at the code of the commit, for example:
int ki_cr_user_carrier(struct sip_msg * _msg, str *_user,
str *_domain, str *_dstavp) {
// native api already checks if any of required argument is null
// so this is not strictly necessary.
if (!_msg || !_user || !_domain || !_dstavp) {
LM_ERR("missing a required parameter\n");
return -1;
};
return w_cr_load_user_carrier(_msg, _user->s, _domain->s, _dstavp->s);
}
The content pointed by _user->s is "$fU" (considering the example given in the comment above), and inside w_cr_load_user_carrier():
int w_cr_load_user_carrier(struct sip_msg * _msg, char *_user, char *_domain, char *_dstavp) {
gparam_t *pv_user, *pv_domain, *pv_dstavp;
if (_user == NULL) {
LM_ERR("cannot get the user parameter\n");
return -1;
} else {
pv_user = (gparam_t*)_user;
if (cr_load_user_carrier_fixup((void**)&pv_user, 1) != 0) {
LM_ERR("cannot parse the user parameter\n");
return -1;
}
}
...
It is doing fixup (a little bit odd way), but then no free fixup.
Anyhow, this is not the proper way kemi is supposed to work, from the kemi script it should come direct string (or integer) values, not names of Kamailio-specific pseudo-variables.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.