SIP Router Project
FS#169 - "Error while parsing Route HF" for some INVITEs
Opened by Jorj Bauer (jorj) - Tuesday, 25 October 2011, 17:29 GMT
Last edited by Daniel-Constantin Mierla (miconda) - Thursday, 11 July 2013, 16:55 GMT
(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:
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:
Route: <sip:188.8.131.52;transport=tcp;r2=on;avp=0VcDBwBhY2NvdW50AwB5ZXMDBgBzdGltZXIEADE4MDA;lr=on>, <sip:184.108.40.206;r2=on;avp=0VcDBwBhY2NvdW50AwB5ZXMDBgBzdGltZXIEADE4MDA;lr=on>
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.
Thursday, 11 July 2013, 16:55 GMT
Reason for closing: Works for me