i'm trying to find out why handle_uri_alias() function is not finding any params in ACK request.
i have in script just before handle_uri_alias() call debug statement that prints $rm and $ru and it shows correctly:
Apr 1 17:00:45 lohi /usr/sbin/sip-proxy[22980]: INFO: handling uri alias of ACK sip:+35862345670@192.168.15.100:5060;user=phone;alias=86.133.100.125:5060t1
handle_uri_alias() has in the beginning
if ((msg->parsed_uri_ok == 0) && (parse_sip_msg_uri(msg) < 0)) { LM_ERR("while parsing Request-URI\n"); return -1; } rest = msg->parsed_uri.params.s; rest_len = msg->parsed_uri.params.len; LM_INFO("params are %.*s\n", rest_len, rest); if (rest_len == 0) { LM_INFO("no params\n"); return 2; }
and here is what comes to syslog:
Apr 1 17:00:45 lohi /usr/sbin/sip-proxy[22980]: INFO: nathelper [nathelper.c:1513]: params are Apr 1 17:00:45 lohi /usr/sbin/sip-proxy[22980]: INFO: nathelper [nathelper.c:1515]: no params
why is msg->parsed_uri.params empty str after calling parse_sip_msg_uri()?
-- juha
i think i found the reason. when uri parameters include user=phone param, params are stored in msg->parsed_uri.sip_params instead of msg->parsed_uri.params.
-- juha
On Apr 01, 2010 at 17:32, Juha Heinanen jh@tutpro.com wrote:
i think i found the reason. when uri parameters include user=phone param, params are stored in msg->parsed_uri.sip_params instead of msg->parsed_uri.params.
Yes, if uri->type = TEL_URI_T then the sip uri params are in msg->parsed_uri.sip_params. uris with user=phone are autoconverted to tel uris (if you don't want this, set phone2tel=0 in the .cfg) and in this case uri->params will contain the embedded tel uri params (e.g. 123;foo=bar@test.com;user=phone => uri->params="foo=bar").
Andrei
Andrei Pelinescu-Onciul writes:
Yes, if uri->type = TEL_URI_T then the sip uri params are in msg->parsed_uri.sip_params. uris with user=phone are autoconverted to tel uris (if you don't want this, set phone2tel=0 in the .cfg) and in this case uri->params will contain the embedded tel uri params (e.g. 123;foo=bar@test.com;user=phone => uri->params="foo=bar").
andrei,
thanks for the explanation.
i made a couple of more tests and they showed that when r-uri does NOT contain user=phone, then the parameters are stored in BOTH params and sip_params fields and when user=phone is present, then the parameters are stored ONLY in sip_params field.
based on that, it seems safe to convert handle_ruri_alias() function to always look ;alias parameter in sip_params field.
-- juha