i started to wonder, why my config does not work when there is ';user=phone' param in r-uri. in order to investigate, i added these to the config:
xlog("L_INFO", "r-uri = '$ru'\n"); xlog("L_INFO", "r-uri params = '$(ru{uri.params})'\n"); xlog("L_INFO", "r-uri params = '$sel(ruri.params)'\n");
and made two tests. in the first, r-uri param is ;user=phone:
Dec 19 07:08:10 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri = 'sip:+35862345670@test.tutpro.com;user=phone' Dec 19 07:08:10 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri params = '' Dec 19 07:08:10 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri params = '<null>'
and in the second r-uri param is ;param=value:
Dec 19 07:09:59 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri = 'sip:+35862345670@test.tutpro.com;param=value' Dec 19 07:09:59 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri params = 'param=value' Dec 19 07:09:59 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri params = 'param=value'
note the difference. in the first, neither uri transformation nor ruri select works, but they work in the second.
i checked from rfc3261 and both request uris are syntactically valid and in both cases there is a valid r-uri parameter.
my current hack is to use tobody.params, but would like to get rid of it.
-- juha
Hello,
I expect it has to do with the special requirements on handling uri enforced by 'user=phone'. Something related was on sr-dev few time ago:
- http://lists.sip-router.org/pipermail/sr-dev/2013-December/022267.html - http://lists.sip-router.org/pipermail/sr-dev/2013-December/022269.html
At that time I checked the sources and parameters are linked to another field in uri structure than without it, thus the params field is somehow left empty. I had no time to investigate more the specs, maybe looking at parse_uri() will shed more light.
Cheers, Daniel
On 19/12/13 06:19, Juha Heinanen wrote:
i started to wonder, why my config does not work when there is ';user=phone' param in r-uri. in order to investigate, i added these to the config:
xlog("L_INFO", "r-uri = '$ru'\n"); xlog("L_INFO", "r-uri params = '$(ru{uri.params})'\n"); xlog("L_INFO", "r-uri params = '$sel(ruri.params)'\n");and made two tests. in the first, r-uri param is ;user=phone:
Dec 19 07:08:10 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri = 'sip:+35862345670@test.tutpro.com;user=phone' Dec 19 07:08:10 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri params = '' Dec 19 07:08:10 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri params = '<null>'
and in the second r-uri param is ;param=value:
Dec 19 07:09:59 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri = 'sip:+35862345670@test.tutpro.com;param=value' Dec 19 07:09:59 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri params = 'param=value' Dec 19 07:09:59 rautu /usr/sbin/sip-proxy[5107]: INFO: r-uri params = 'param=value'
note the difference. in the first, neither uri transformation nor ruri select works, but they work in the second.
i checked from rfc3261 and both request uris are syntactically valid and in both cases there is a valid r-uri parameter.
my current hack is to use tobody.params, but would like to get rid of it.
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
I expect it has to do with the special requirements on handling uri enforced by 'user=phone'. Something related was on sr-dev few time ago:
;user=phone may mean something special, but when it comes to request-uri parameter syntax, it is just one parameter among others:
SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ]
uri-parameters = *( ";" uri-parameter)
uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param
other-param = pname [ "=" pvalue ]
things get worse when more params follow user param:
Dec 19 11:07:07 siika /usr/sbin/sip-proxy[8550]: INFO: r-uri = 'sip:+35862345670@test.tutpro.com;user=phone;param=value' Dec 19 11:07:07 siika /usr/sbin/sip-proxy[8550]: INFO: r-uri params = '' Dec 19 11:07:07 siika /usr/sbin/sip-proxy[8550]: INFO: r-uri params = '<null>'
i.e., it is not just user param that is missing from transformation result, but also any param that follows it.
-- juha
Daniel-Constantin Mierla writes:
At that time I checked the sources and parameters are linked to another field in uri structure than without it, thus the params field is somehow left empty. I had no time to investigate more the specs, maybe looking at parse_uri() will shed more light.
looks like uri param transformations need to take params from sip_uri sip_params field:
str params; /*!< Parameters */ str sip_params; /*!< Parameters of the sip: URI. * (If a tel: URI is embedded in a sip: URI, then * params points to the parameters of the tel: URI, * and sip_params to the parameters of the sip: URI. */
perhaps they now take them from params field and that causes the problem?
-- juha
On 19/12/13 15:25, Juha Heinanen wrote:
Juha Heinanen writes:
perhaps they now take them from params field and that causes the problem?
that was it. i just pushed a fix to master and will cherry pick to 4.1. i think that @ruri.params select would need to be fixed too.
Have you checked to see if the sip_params field is also set when 'user=phone' doesn't exist?
Cheers, Daniel
Daniel-Constantin Mierla writes:
Have you checked to see if the sip_params field is also set when 'user=phone' doesn't exist?
yes, my understanding is that it is set as the first thing always:
switch(uri->type){ case SIPS_URI_T: case SIP_URI_T: /* save the original sip: URI parameters in sip_params */ uri->sip_params=uri->params;
but i didn't read the whole code.
-- juha
On 19/12/13 15:42, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Have you checked to see if the sip_params field is also set when 'user=phone' doesn't exist?
yes, my understanding is that it is set as the first thing always:
switch(uri->type){ case SIPS_URI_T: case SIP_URI_T: /* save the original sip: URI parameters in sip_params */ uri->sip_params=uri->params;
but i didn't read the whole code.
OK. I thought you tested with two URI, one with and the other without user=phone. If that is good, then all should be fine.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Juha Heinanen