29 Aug
2011
29 Aug
'11
1:17 p.m.
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
29 Aug
29 Aug
4:27 p.m.
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
13 Sep
13 Sep
5:06 p.m.
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
14 Sep
14 Sep
2:30 a.m.
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(a)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
3:55 a.m.
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
4:42 a.m.
Hello,
On 9/14/11 9:55 AM, Andreas Granig wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel,
On 09/14/2011 08:30 AM, Daniel-Constantine Mierla wrote:
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
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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:08 a.m.
Hi,
On 09/14/2011 10:42 AM, Daniel-Constantin Mierla wrote:
ok, so then it is found, fix to be done later.
That'd be great!
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. 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
5:27 a.m.
Hello,
On 9/14/11 11:08 AM, Andreas Granig wrote:
Hi,
On 09/14/2011 10:42 AM, Daniel-Constantin Mierla wrote:
ok, so then it is found, fix to be done later.
That'd be great!
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=10eac9b…
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
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. 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..
6:26 a.m.
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=10eac9b…
This has fixed my issue, thanks alot Daniel!
Andreas
4752
days inactive
4768
days old
8 comments
3 participants
participants (3)
-
Andreas Granig -
Daniel-Constantin Mierla -
Daniel-Constantine Mierla