Summary:	ASTERISK-18919: SIP MESSAGE body is not used verbatim
Reporter:	Walter Doekes (wdoekes)	Labels:
Date Opened:	2011-11-23 15:35:43.000-0600	Date Closed:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Channels/chan_sip/Interoperability
Versions:	1.8.7.1 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	Per the request of Matt Jordan, I'm filing this request for an unmodified SIP request body. http://lists.digium.com/pipermail/asterisk-dev/2011-November/052401.html chan_sip parse_request() does the following: - loop over the entire SIP message (req->data) - replace (CR)LF with NUL - store pointers to the modified buffer, one array of header lines (req->header[] and one array for body lines req->line[]) The header and body lines are then referenced using: REQ_OFFSET_TO_STR(req, header[x]) / REQ_OFFSET_TO_STR(req, line[x]) For SIP parsing, this is fine. In pedantic mode lws2sws() preprocesses the data, so single line headers can be expected. For SDP (SIP body) parsing, having the body split up by line is nice too. For other SIP body uses this may not be nice. One particular instance is the SIP MESSAGE. When fetching the SIP MESSAGE body, we reassemble the body by concatenating it with a single linefeed. This means that: - messages without a line feed can get a trailing newline added (there is a workaround in place) - messages with NULs in them will always be terminated at the NUL (fixing this is probably beyond the scope) - messages with CRs are will have them replaced with LFs or ignored if just before another LF Is the MESSAGE Content-Type is text/plain, this will probably not be a problem, but other message types may require a bit more binary safety. My suggestion would be to have parse_request() stop parsing the body and have someone else continue parsing it only when it is deemed useful (for SDP parsing).
Comments: