[Home]

Summary:ASTERISK-26069: Asterisk truncates To: header, dropping the closing '>'
Reporter:Vasil Kolev (krokodilerian)Labels:
Date Opened:2016-05-27 08:19:50Date Closed:2016-06-16 19:20:42
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:13.9.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Ubuntu 14.04 ia32Attachments:( 0) asterisk-broken-to-header.pcap
Description:As part of the development of push notifications for Windows phone for the Zoiper softphone, we've discovered that after some version (this AFAIK worked with 1.4), Asterisk starts truncating the To: header if it finds it too large. This leads to nasty issues, for example broken SIP packets in some cases.

Asterisk 11.9 didn't give a very useful message:

failed to extend from 256 to 427

Asterisk 13.9.1 gives the following:

[May 27 16:02:21] ERROR[25411][C-0000001b]: chan_sip.c:14348 initreqprep: The To header was truncated in call '25b40e7f1e385c1e498e17d35ef28515@10.8.1.11:5060'. This call setup will fail.

which is a bit more useful, but doesn't help with the problem itself. I'll attach a packet capture with the problem, where it's visible that asterisk sends an invite with a To: header that looks like this:

To: <sip:push1@10.8.3.92:50068;transport=TCP;rinstance=4015b61ba94093b5;X-PUSH-URI=http://e.notify.live.net/u/1/db5/H2QAAABZevVMbUI_okG-i5MjqfgHM8pKQ4-e3m7bKOGXxA9bBxPEXLj0gYK50BliT1FrnU8xtXJzYYPmTvQ1DIXqNfHK-MtAo3b9ppbBsGz6GjYHA-p-yAZ6R2r2xql6ViL727I/d2luZG9

(e.g. the closing '>' is missing). The contact is also truncated (there are some more bytes to it).

AFAIK in the code there are some static arrays to hold these headers, which creates the issue.

The RFCs don't have any limitation on these headers, and there are also drafts that use these fields extensively (see for example https://datatracker.ietf.org/doc/draft-ivanov-sipcore-pnsip/ ). This also seems to be a regression from previous versions, and not something we've found as an issue with other SIP gateways.
Comments:By: Asterisk Team (asteriskteam) 2016-05-27 08:19:51.192-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Vasil Kolev (krokodilerian) 2016-05-27 08:20:58.391-0500

A packet capture of the issue with the broken header.
By: Olle Johansson (oej) 2016-05-27 10:43:56.208-0500

It's important that this is fixed a.s.a.p. It's a regression that should be simple to fix. We should never shorten a URI - if we can't handle it, then refuse the call.
By: Freddi Hansen (freddi_fonet) 2016-05-29 15:58:24.451-0500

Hi I had the same problem with Zoiper, the quick solution for you until someone fixes this is to chan_sip.c.
search for "static void initreqprep".
change
struct ast_str *invite = ast_str_alloca(256)  to struct ast_str *invite = ast_str_alloca(512)
and
char to[256]; to char to[512];
this change took care of that warning for me.

If you want the Zoiper windows push function to work and you use realtime then you must also expand the 'fullcontact' field in sip_peers to 512.
b.r.
Freddi


By: Vasil Kolev (krokodilerian) 2016-05-30 14:12:39.045-0500

I've written a patch for this to properly reallocate memory (using the ast_str_* stuff), and will upload it as soon as my license agreement is accepted.
By: Vasil Kolev (krokodilerian) 2016-05-31 09:14:02.571-0500

The patch was submitter to gerrit, https://gerrit.asterisk.org/#/c/2923/
By: Corey Farrell (coreyfarrell) 2016-06-07 07:15:23.148-0500

This isn't actually a regression, it's a really old bug.  The from and to variables have been 256 byte buffers since at least 2002 (commit 13f34c3518686a6da8de4f8b185edf44e73dbe66).