OK -- thanks for testing, commit backported to 4.4.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/663#issuecomment-230760719___
sr-dev
Closed #663.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/663#event-714269662___
sr-dev mailing list
sr-dev@lists.sip-router.org
Got back to this one and pushed a new commit which does a bit of refactoring
for this function, including the ability to work better with other types of
routing blocks. Can you try again and see if the issue is still there.
---
You are receiving this because you are subscribed to this thread.
OK, useful hints -- I will try to reproduce when I get the first chance.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I am pretty sure it's a request route . It's true I call route[RTPPROXY] from a
reply route too , but when I have the issue is always a request_route . It has
to do with the number of params in Route , it seems the bug becomes visible
only when there's only one param (;lr) and then
But maybe the route(RTPPROXY) is executed from a branch or failure route (or
another route executed from those) ...
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
No and no .
I am using it in my route[RTPPROXY] like this :
if (is_request() && !isflagset(FLT_NAT)) {
if(check_route_param("nat=yes")) {
setflag(FLT_NAT);
}
}
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Are you using it from failure_route or branch failure route?
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/663#issuecomment-225125413___
I applied the patch , but I still have output like this :
rr [loose.c:985]: check_route_param(): current params are (72)
Let me know if I can help further.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I pushed a patch to rr on master, can you give it a try? May or may not be
related, though, ...
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I added that logline . Sometimes it prints strange things like this:
Jun 9 12:10:09 B1-RD-IMS-2 /opt/local/ims/sbin/kamailio[23328]: INFO: rr
[loose.c:980]: check_route_param(): current params are (6f)
Jun 9 12:10:09 B1-RD-IMS-2 /opt/local/ims/sbin/kamailio[23328]: DEBUG: rr
[loose.c:986]:
Can you add a log message before the for block you removed, so the code becomes:
```
LM_INFO("current params are <%.*s> (%x)\n", routed_params.len, routed_params.s,
*(routed_params.s-1));
for( params=routed_params ; params.s[0]!=';' ; params.s--,params.len++ );
```
and then see if the info
Given that there are multiple Route sets , each with one param ,
check_route_param() function fails to search the proper param.s string .
The condition params.s[0]!=';' holds false and it stops the loop only when it
encounters another ";" character which is not part of the Route header .
Eg:
13 matches
Mail list logo
