[sr-dev] [tracker] Task opened: "Error while parsing Route HF" for some INVITEs (Attachment added)

[sip-router]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Jorj Bauer (jorj) 

Attached to Project - sip-router
Summary - "Error while parsing Route HF" for some INVITEs
Task Type - Bug Report
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
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.


One or more files have been attached.

More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=169

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.