sip-router

SIP Router Project

Tasklist

FS#169 - "Error while parsing Route HF" for some INVITEs

Attached to Project: sip-router
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
Task Type Bug Report
Category Core
Status Closed
Assigned To Andrei Pelinescu-Onciul (andrei)
Operating System All
Severity Medium
Priority Normal
Reported Version Development
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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:

Route: <sip:128.91.197.35;transport=tcp;r2=on;avp=0VcDBwBhY2NvdW50AwB5ZXMDBgBzdGltZXIEADE4MDA;lr=on>, <sip:128.91.197.35;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.

This task depends upon

Closed by  Daniel-Constantin Mierla (miconda)
Thursday, 11 July 2013, 16:55 GMT
Reason for closing:  Works for me
Comment by Daniel-Constantin Mierla (miconda) - Thursday, 31 May 2012, 11:00 GMT

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?

Loading...