Hi,
path module calls register_rrcb when "use_received" is set to 1 to extract the "received=" param and set its content as dst-uri if present.
Now I've noticed that when e.g. a message has a pre-loaded route like "Route: sip:mydomain.com;lr", then kamailio (at least 3.1.3) spits the following error message:
/usr/sbin/kamailio[23953]: ERROR: <core> [parser/parse_param.c:481]: parse_params(): Invalid character, ; expected /usr/sbin/kamailio[23953]: ERROR: path [path.c:213]: failed to parse route parametes
I was trying to reproduce this but without much success, it sometimes happens and sometimes not, but I can't yet put the finger on the reason. Any ideas?
Andreas
Hello,
On 8/29/11 7:17 PM, Andreas Granig wrote:
Hi,
path module calls register_rrcb when "use_received" is set to 1 to extract the "received=" param and set its content as dst-uri if present.
Now I've noticed that when e.g. a message has a pre-loaded route like "Route:sip:mydomain.com;lr", then kamailio (at least 3.1.3) spits the following error message:
/usr/sbin/kamailio[23953]: ERROR:<core> [parser/parse_param.c:481]: parse_params(): Invalid character, ; expected /usr/sbin/kamailio[23953]: ERROR: path [path.c:213]: failed to parse route parametes
can you patch ^here^ and print the value of the parameters that it tries to parse?
I was trying to reproduce this but without much success, it sometimes happens and sometimes not, but I can't yet put the finger on the reason. Any ideas?
No clue yet since I am not calling loose_route() for initial requests, like in the default config, so if there is an issue just with the case of pre-loaded Route, I couldn't spot it so far. Having the value of the parameters it tries to parse (maybe it starts too early/late in the header, or something else) should give some hints...
Cheers, Daniel
Hi,
On 08/29/2011 10:27 PM, Daniel-Constantin Mierla wrote:
No clue yet since I am not calling loose_route() for initial requests, like in the default config, so if there is an issue just with the case of pre-loaded Route, I couldn't spot it so far. Having the value of the parameters it tries to parse (maybe it starts too early/late in the header, or something else) should give some hints...
I was finally able to deploy a version with debug messages, and it looks like this, when it works as expected:
/usr/sbin/kamailio[23936]: INFO: path [path.c:213]: parsing route parameters 'lr;received=sip:1.2.3.4:52091'
And the other cases where it fails, it look like this:
/usr/sbin/kamailio[23927]: INFO: path [path.c:213]: parsing route parameters 'te: sip:my.domain.com;lr#015#012Max-Forwards: 69#015#012F' /usr/sbin/kamailio[23927]: ERROR: path [path.c:215]: failed to parse route parameters 'sip:my.domain.com;lr#015#012Max-Forwards: 69#015#012F'
The content of "str *r_param" differs a lot, e.g. sometimes it's "ntact: <sip:431234566@1.2.3.4:41994;" or any other random part of the SIP message.
No idea how this could happen. The sip message itself looks perfectly fine for cases where this occurs.
Andreas
Hello,
Seems like the rr params value is not set properly. I looked in rr module and such case can happen indeed, but for the case when uri in rr does not match myself. Is this also in your case? I wonder anyhow why the callbacks are executed in route header uri is not local address...
I will make a patch for this case soon.
Btw, were all hops in the signaling performing loose routing or some did strict routing?
Cheers, Daniel
On Sep 13, 2011, at 11:06 PM, Andreas Granig agranig@sipwise.com wrote:
Hi,
On 08/29/2011 10:27 PM, Daniel-Constantin Mierla wrote:
No clue yet since I am not calling loose_route() for initial requests, like in the default config, so if there is an issue just with the case of pre-loaded Route, I couldn't spot it so far. Having the value of the parameters it tries to parse (maybe it starts too early/late in the header, or something else) should give some hints...
I was finally able to deploy a version with debug messages, and it looks like this, when it works as expected:
/usr/sbin/kamailio[23936]: INFO: path [path.c:213]: parsing route parameters 'lr;received=sip:1.2.3.4:52091'
And the other cases where it fails, it look like this:
/usr/sbin/kamailio[23927]: INFO: path [path.c:213]: parsing route parameters 'te: sip:my.domain.com;lr#015#012Max-Forwards: 69#015#012F' /usr/sbin/kamailio[23927]: ERROR: path [path.c:215]: failed to parse route parameters 'sip:my.domain.com;lr#015#012Max-Forwards: 69#015#012F'
The content of "str *r_param" differs a lot, e.g. sometimes it's "ntact: <sip:431234566@1.2.3.4:41994;" or any other random part of the SIP message.
No idea how this could happen. The sip message itself looks perfectly fine for cases where this occurs.
Andreas
Hi Daniel,
On 09/14/2011 08:30 AM, Daniel-Constantine Mierla wrote:
Seems like the rr params value is not set properly. I looked in rr module and such case can happen indeed, but for the case when uri in rr does not match myself. Is this also in your case? I wonder anyhow why the callbacks are executed in route header uri is not local address...
Indeed it happens when it doesn't match itself.
Btw, were all hops in the signaling performing loose routing or some did strict routing?
Well, the use-case is this:
REGISTER sip:mydomain.com:5060 Route: sip:mydomain.com;lr To: sip:myuser@mydomain.com
So it's an initial REGISTER with no to-tag but with a Route header (e.g. pjsip loves to do that for some reason for every initial request). We're using Kamailio as a load-balancer (this is where the error occurs) in the SPCE, and we don't set any "alias" parameter there, so the Route is not considered local.
Instead, we're doing something like this:
if(loose_route()) { if(!has_totag()) { $du = $null; # send off to proxy using dispatcher } else { t_relay(); } }
Then on the proxy we check again after loose_route() using is_domain_local("$dd") to either silently consume routes which are in our domain table or to reject them if not.
Thanks, Andreas
Hello,
On 9/14/11 9:55 AM, Andreas Granig wrote:
Hi Daniel,
On 09/14/2011 08:30 AM, Daniel-Constantine Mierla wrote:
Seems like the rr params value is not set properly. I looked in rr module and such case can happen indeed, but for the case when uri in rr does not match myself. Is this also in your case? I wonder anyhow why the callbacks are executed in route header uri is not local address...
Indeed it happens when it doesn't match itself.
ok, so then it is found, fix to be done later.
However, I wonder if it makes sense to execute the rr calbacks when the uri does not match myself. IIRC, the purpose of rr callbacks was to access parameters added by proxy itself in record-route header which should be mirrored by route headers. Do I misunderstand their goal? Afaik path, dialog and uac modules use them to get parameters for dialog id, from header recovery ... which are added by proxy itself. Not sure for path module, is it about accessing parameters set by same instance in record-route?
Cheers, Daniel
Btw, were all hops in the signaling performing loose routing or some did strict routing?
Well, the use-case is this:
REGISTER sip:mydomain.com:5060 Route:sip:mydomain.com;lr To:sip:myuser@mydomain.com
So it's an initial REGISTER with no to-tag but with a Route header (e.g. pjsip loves to do that for some reason for every initial request). We're using Kamailio as a load-balancer (this is where the error occurs) in the SPCE, and we don't set any "alias" parameter there, so the Route is not considered local.
Instead, we're doing something like this:
if(loose_route()) { if(!has_totag()) { $du = $null; # send off to proxy using dispatcher } else { t_relay(); } }
Then on the proxy we check again after loose_route() using is_domain_local("$dd") to either silently consume routes which are in our domain table or to reject them if not.
Thanks, Andreas
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
Hi,
On 09/14/2011 10:42 AM, Daniel-Constantin Mierla wrote:
Seems like the rr params value is not set properly. I looked in rr module and such case can happen indeed, but for the case when uri in rr does not match myself. Is this also in your case? I wonder anyhow why the callbacks are executed in route header uri is not local address...
Indeed it happens when it doesn't match itself.
ok, so then it is found, fix to be done later.
That'd be great!
However, I wonder if it makes sense to execute the rr calbacks when the uri does not match myself. IIRC, the purpose of rr callbacks was to access parameters added by proxy itself in record-route header which should be mirrored by route headers. Do I misunderstand their goal? Afaik path, dialog and uac modules use them to get parameters for dialog id, from header recovery ... which are added by proxy itself. Not sure for path module, is it about accessing parameters set by same instance in record-route?
At least for path, it's only relevant for extracting information for Routes pointing to itself. E.g. for a REGISTER, the lb puts itself into the Path, like "Path: sip:own-ip:own-port;lr;received=sip:remote-ip:remote-port", and in a subsequent INVITE that would convert into a Route, and the lb can then extract the "received=" information from it in the rr-callback and set it as $du..
Not sure about dialog or uac.
Andreas
Hello,
On 9/14/11 11:08 AM, Andreas Granig wrote:
Hi,
On 09/14/2011 10:42 AM, Daniel-Constantin Mierla wrote:
Seems like the rr params value is not set properly. I looked in rr module and such case can happen indeed, but for the case when uri in rr does not match myself. Is this also in your case? I wonder anyhow why the callbacks are executed in route header uri is not local address...
Indeed it happens when it doesn't match itself.
ok, so then it is found, fix to be done later.
That'd be great!
However, I wonder if it makes sense to execute the rr calbacks when the uri does not match myself. IIRC, the purpose of rr callbacks was to access parameters added by proxy itself in record-route header which should be mirrored by route headers. Do I misunderstand their goal? Afaik path, dialog and uac modules use them to get parameters for dialog id, from header recovery ... which are added by proxy itself. Not sure for path module, is it about accessing parameters set by same instance in record-route?
At least for path, it's only relevant for extracting information for Routes pointing to itself. E.g. for a REGISTER, the lb puts itself into the Path, like "Path: sip:own-ip:own-port;lr;received=sip:remote-ip:remote-port", and in a subsequent INVITE that would convert into a Route, and the lb can then extract the "received=" information from it in the rr-callback and set it as $du..
ok, I committed a fix to master and 3.1 branches:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=10eac9b1...
rr callbacks are executed only when URI is myself (it was the only working case anyhow for loose routing, otherwise params value was bogus) and if there are parameters in Route URI (otherwise further errors were issued inside callback functions, with no option of changing anything, i.e., no return code from callbacks).
It should fix your case, if not, report again.
Cheers, Daniel
Hi,
On 09/14/2011 11:27 AM, Daniel-Constantin Mierla wrote:
ok, I committed a fix to master and 3.1 branches:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=10eac9b1...
This has fixed my issue, thanks alot Daniel!
Andreas
-
Andreas Granig -
Daniel-Constantin Mierla -
Daniel-Constantine Mierla