Strict Standards: call_user_func() expects parameter 1 to be a valid callback, non-static method dokuwiki_TextFormatter::render() should not be called statically in /var/www/sip-router.kamailio.org/flyspray/includes/class.tpl.php on line 552

Strict Standards: call_user_func() expects parameter 1 to be a valid callback, non-static method dokuwiki_TextFormatter::render() should not be called statically in /var/www/sip-router.kamailio.org/flyspray/includes/class.tpl.php on line 552

Details

(This happens in version 3.0.3 as well as 3.2.0, but flyspray hasn’t been updated to show 3.2.0 yet - so I’m tagging it as “Development.”)

When a call is placed on hold on a shared line, S-R is failing to parse the headers on the way back. It ultimately reports:

find_first_route: Error while parsing Route HF

and the call is dropped. This only happens when we’re signaling using TCP (using UDP, this parse error does not occur, and the call is placed on hold properly).

Attached is the output with debug=6, our (somewhat messy, still under development) configuration script, and a pcap of the entire exchange (starting with the REGISTER).

The INVITE at 21:09:33.670245 (frame 46) is correctly challenged for AuthN. The UA responds (frame 54) with appropriate credentials. S-R responds with a “100 Trying” (frame 56), then internally has an “Error while parsing Route HF”, which returns an error to the script’s proxy_authenticate() call (line 1027 of siprouter.cfg), which (incorrectly) forces a re-send of “407 Proxy AuthN required” (frame 57) as the script can’t differentiate between the internal failure and a failure to authenticate.

The failing call (parse_rr.c, in do_parse_rr_body()) is passed a 0-length buffer; that comes from parse_rr(); that’s called from the parse_rr() call in find_first_route() in modules_s/rr/loose.c.

parse_headers() (just before the parse_rr() call in find_first_route()) doesn’t appear to see the first few headers of the packet - including the Route header. I don’t understand how the header pre-parsing and caching works here, so I don’t know what’s “normal”; but the packet in question does have a valid Route header:

The exact same header was parsed properly in the first INVITE, so I don’t believe the parser itself is at fault. It seems more likely that this is related to some concurrent code path in two forks that’s happening only with TCP flows but I can’t find or prove that.

That’s as far as I can debug this with my limited knowledge of the internals of SIP Router. If I find more I’ll post details to this ticket, but I don’t expect to be able to debug this any deeper without input from someone that knows the internals of SIP Router better than I do.

Strict Standards: call_user_func() expects parameter 1 to be a valid callback, non-static method dokuwiki_TextFormatter::render() should not be called statically in /var/www/sip-router.kamailio.org/flyspray/includes/class.tpl.php on line 552

Not using SER flavour, as it seems in your case (maybe a reason for no reply here so far), but I took the INVITE and injected to the network and it was parsed fine by modules_k/rr module, via loose_route() function. The parser is the same, so it should be like this also for modules_s/rr.

Can you try again with debug=3 in config and paste here the log messages?