Hello list,
currently I am trying to use the enum_pv_query function of the enum module but I always get an error: the R-Uri-User is not an e164-Number.
That's true, but not important (and must not result in a failed lookup), because the function should use a pv for the lookup, not the R-Uri-User.
In enum.c I discovered in function enum_pv_query_3 :
/* * Get R-URI user to tostring */ if (parse_sip_msg_uri(_msg) < 0) { LM_ERR("R-URI parsing failed\n"); return -1; }
if (is_e164(&(_msg->parsed_uri.user)) == -1) { LM_ERR("R-URI user is not an E164 number\n"); return -1; }
user_s = _msg->parsed_uri.user.s; user_len = _msg->parsed_uri.user.len;
memcpy(&(tostring[0]), user_s, user_len); tostring[user_len] = (char)0;
/* * Get E.164 number from pseudo variable */ if (sp && (pv_get_spec_value(_msg, sp, &pv_val) == 0)) { if (pv_val.flags & PV_VAL_STR) { if (pv_val.rs.len == 0 || pv_val.rs.s == NULL) { LM_DBG("Missing E.164 number\n"); return -1; } } else { LM_DBG("Pseudo variable value is not string\n"); return -1; } } else { LM_DBG("Cannot get pseudo variable value\n"); return -1; } if (is_e164(&(pv_val.rs)) == -1) { LM_ERR("pseudo variable does not contain an E164 number\n"); return -1; }
user_s = pv_val.rs.s; user_len = pv_val.rs.len;
memcpy(&(string[0]), user_s, user_len); string[user_len] = (char)0;
As you can see, the function always tries to read the uri for lookup from the R-Uri, whether "sp" (which is needed to be true for using pv) is defined or not. Why do you need sp? I recognized, that enum_query() (without pv) uses a separate function anyway... I would suggest to remove the lines in this function, which try to use the R-URI for enum lookup...
Thanks Jasmin
Jasmin Schnatterbeck writes:
As you can see, the function always tries to read the uri for lookup from the R-Uri, whether "sp" (which is needed to be true for using pv) is defined or not. Why do you need sp? I recognized, that enum_query() (without pv) uses a separate function anyway... I would suggest to remove the lines in this function, which try to use the R-URI for enum lookup...
jasmin,
from readme:
Most of the time you want to route based on the RURI. On rare occasions you may wish to route based on something else. The function enum_pv_query mimics the behavior of the enum_query function except the E.164 number in its pseudo variable argument is used for the enum lookup instead of the user part of the RURI. Obviously the user part of the RURI is still used in the NAPTR regexp.
-- juha
Le 2 avr. 10 à 17:35, Juha Heinanen a écrit :
Jasmin Schnatterbeck writes:
As you can see, the function always tries to read the uri for lookup from the R-Uri, whether "sp" (which is needed to be true for using pv) is defined or not. Why do you need sp? I recognized, that enum_query() (without pv) uses a separate function anyway... I would suggest to remove the lines in this function, which try to use the R-URI for enum lookup...
jasmin,
from readme:
Most of the time you want to route based on the RURI. On rare occasions you may wish to route based on something else. The function enum_pv_query mimics the behavior of the enum_query function except the E.164 number in its pseudo variable argument is used for the enum lookup instead of the user part of the RURI. Obviously the user part of the RURI is still used in the NAPTR regexp.
Except that before trying to validate the pv as e164 number, the function exit when user part of RURI is not e164-compatible
Thanks Vadim
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Vadim Lebedev writes:
Most of the time you want to route based on the RURI. On rare occasions you may wish to route based on something else. The function enum_pv_query mimics the behavior of the enum_query function except the E.164 number in its pseudo variable argument is used for the enum lookup instead of the user part of the RURI. Obviously the user part of the RURI is still used in the NAPTR regexp.
Except that before trying to validate the pv as e164 number, the function exit when user part of RURI is not e164-compatible
based on the readme, that is what it should do, because "the user part of the RURI is still used in the NAPTR regexp". don't ask me why, because i did not write that function. it was provided by Greg Fausak lgfausak@gmail.com and here is the original description:
Most of the time you want to route based on the RURI. On rare occasions you may wish to route based on the user part of the "From:" tag, analogous to source based policy routing in the ip world. The function enum_fquery mimics the behaviour of the enum_query function except the user part of the "From:" is used for the enum lookup instead of the user part of the RURI. Obviously the user part of the RURI is still used in the naptr regexp.
i don't know if anyone is still using enum_pv_query. if not, then it could be changed to use the number in the pv also where the regex is applied to.
what you can do in the meantime is assign your pv contents to $rU, call normal enum_query and then revert_uri().
-- juha
Am 03.04.2010 08:24, schrieb Juha Heinanen:
based on the readme, that is what it should do, because "the user part of the RURI is still used in the NAPTR regexp". don't ask me why, because i did not write that function. it was provided by Greg Fausak lgfausak@gmail.com and here is the original description:
Most of the time you want to route based on the RURI. On rare occasions you may wish to route based on the user part of the "From:" tag, analogous to source based policy routing in the ip world. The function enum_fquery mimics the behaviour of the enum_query function except the user part of the "From:" is used for the enum lookup instead of the user part of the RURI. Obviously the user part of the RURI is still used in the naptr regexp.
i don't know if anyone is still using enum_pv_query. if not, then it could be changed to use the number in the pv also where the regex is applied to.
True. Using the PV only for the DNS lookup, but using the request URI for the regexp is very strange.
I vote for using the PV for the regexp too.
klaus
Am Dienstag, den 06.04.2010, 11:34 +0200 schrieb Klaus Darilion:
Am 03.04.2010 08:24, schrieb Juha Heinanen:
based on the readme, that is what it should do, because "the user part of the RURI is still used in the NAPTR regexp". don't ask me why, because i did not write that function. it was provided by Greg Fausak lgfausak@gmail.com and here is the original description:
Most of the time you want to route based on the RURI. On rare occasions you may wish to route based on the user part of the "From:" tag, analogous to source based policy routing in the ip world. The function enum_fquery mimics the behaviour of the enum_query function except the user part of the "From:" is used for the enum lookup instead of the user part of the RURI. Obviously the user part of the RURI is still used in the naptr regexp.
i don't know if anyone is still using enum_pv_query. if not, then it could be changed to use the number in the pv also where the regex is applied to.
True. Using the PV only for the DNS lookup, but using the request URI for the regexp is very strange.
I think so as well - it would make much more sense to use the PV value only in this function...
jasmin
I vote for using the PV for the regexp too.
klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Saturday 03 April 2010, Juha Heinanen wrote:
based on the readme, that is what it should do, because "the user part of the RURI is still used in the NAPTR regexp". don't ask me why, because i did not write that function. it was provided by Greg Fausak lgfausak@gmail.com and here is the original description:
Most of the time you want to route based on the RURI. On rare occasions you may wish to route based on the user part of the "From:" tag, analogous to source based policy routing in the ip world. The function enum_fquery mimics the behaviour of the enum_query function except the user part of the "From:" is used for the enum lookup instead of the user part of the RURI. Obviously the user part of the RURI is still used in the naptr regexp.
i don't know if anyone is still using enum_pv_query. if not, then it could be changed to use the number in the pv also where the regex is applied to.
Why have multiple separate functions for the same functionality? These enum functions could from the beginning have been defined as 'enum_query($lookup, $suffix, $service, $regexp_subject)' with all arguments pv's or static strings. The common use case would be enum_query($rU, ...).
Am 06.04.2010 14:09, schrieb Alex Hermann:
On Saturday 03 April 2010, Juha Heinanen wrote:
based on the readme, that is what it should do, because "the user part of the RURI is still used in the NAPTR regexp". don't ask me why, because i did not write that function. it was provided by Greg Fausak lgfausak@gmail.com and here is the original description:
Most of the time you want to route based on the RURI. On rare occasions you may wish to route based on the user part of the "From:" tag, analogous to source based policy routing in the ip world. The function enum_fquery mimics the behaviour of the enum_query function except the user part of the "From:" is used for the enum lookup instead of the user part of the RURI. Obviously the user part of the RURI is still used in the naptr regexp.
i don't know if anyone is still using enum_pv_query. if not, then it could be changed to use the number in the pv also where the regex is applied to.
Why have multiple separate functions for the same functionality? These enum functions could from the beginning have been defined as 'enum_query($lookup, $suffix, $service, $regexp_subject)' with all arguments pv's or static strings. The common use case would be enum_query($rU, ...).
The ENUM module is older than PV support, and also in early days the module functions only supported 2 parameters.
regards klaus
Alex Hermann writes:
Why have multiple separate functions for the same functionality? These enum functions could from the beginning have been defined as 'enum_query($lookup, $suffix, $service, $regexp_subject)' with all arguments pv's or static strings. The common use case would be enum_query($rU, ...).
alex,
"in the beginning" when enum module was written, PVs didn't exist yet. also, functions were restricted to max two arguments.
now we could change that in all modules and in all functions, but it requires work and breaks old scripts.
-- juha
On Tuesday 06 April 2010, Juha Heinanen wrote:
Why have multiple separate functions for the same functionality? These enum functions could from the beginning have been defined as 'enum_query($lookup, $suffix, $service, $regexp_subject)' with all arguments pv's or static strings. The common use case would be enum_query($rU, ...).
"in the beginning" when enum module was written, PVs didn't exist yet. also, functions were restricted to max two arguments.
now we could change that in all modules and in all functions, but it requires work and breaks old scripts.
Hi Juha,
i think its possible to extend already existing config functions, as the parser supports the usage of different fixups and implementation functions depending on the number of parameters in the script. This of course helps probably not in all cases, and its still a bunch of work..
Henning
-
Alex Hermann -
Henning Westerholt -
Jasmin Schnatterbeck -
jh＠tutpro.com -
Klaus Darilion -
Vadim Lebedev