Summary:ASTERISK-10499: Content-Type: multipart/mixed not recognised correctly (SIP-T on not working)
Reporter:Gaspar Zoltan (gasparz)Labels:
Date Opened:2007-10-11 08:57:50Date Closed:2007-11-15 05:25:09.000-0600
Versions:Frequency of
Environment:Attachments:( 0) chan_sip.diff
Description:In fundtion find_sdp the recognition of the application/sdp is based on a false presummtion: that there is only one header and the content-type header is the first one.

To be able to accept SIP-T messages RFC 3372 defines 2 headers in the SDP body:
Content-type: application/sdp;
Content-disposition: session; handling=required;

some implementations of SIP-T invert the order of the headers (totally acceptable)

Content-Type: multipart/mixed;boundary=sonus-content-delim
MIME-Version: 1.0

Content-Disposition: session; handling=required
Content-Type: application/sdp

My patch does a better parsing based on the following algorithm:
Find delimiter
Search headers until found an empty line
if in these headers we find a Content-Type: application/sdp header we put the start of the sdp to the empty line
The last line of the sdp is either the previous line of the delimiter or the last line in the message (if the SDP part is the last part from the multipart message and there is no delimiter at the end)

How to reproduce:
Send the following invite:
INVITE sip:+number@ip_address:5060 SIP/2.0.
Via: SIP/2.0/UDP ip_address:5060;branch=z9hG4bK02B04622ae828267f1c.
From: <sip:+number@ip:5060;isup-oli=0>;tag=gK0210492c.
To: <sip:+:+number@ip_address:5060>.
Call-ID: 134846_30026@ip.
CSeq: 9886 INVITE.
Max-Forwards: 70.
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,  multipart/mixed.
Contact: <sip:+number@ip:5060>.
P-Asserted-Identity: <sip:+number@ip:5060>.
Supported: 100rel.
Content-Length:  618.
Content-Type: multipart/mixed;boundary=sonus-content-delim.
MIME-Version: 1.0.
Content-Disposition: session; handling=required.
Content-Type: application/sdp.
o=Sonus_UAC 17967 3264 IN IP4 ip.
s=SIP Media Capabilities.
c=IN IP4 media_ip.
t=0 0.
m=audio 14870 RTP/AVP 0 8 18 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
Content-Disposition: signal; handling=optional.
Content-Type: application/isup; version=gr317; base=gr317.
.. .

the path is against 1.4.13 but I can't select it from the list
Comments:By: Terry Wilson (twilson) 2007-11-12 12:42:42.000-0600

You might want to take out all of those ast_log(LOG_WARNING... statements.  :-)  I would test this, but I don't have anything that uses ISUP handy.

By: Olle Johansson (oej) 2007-11-15 05:10:41.000-0600

This patch did not follow our coding guidelines at all... Had to edit quite a lot.

By: Digium Subversion (svnbot) 2007-11-15 05:12:59.000-0600

Repository: asterisk
Revision: 89280

U   branches/1.4/channels/chan_sip.c

r89280 | oej | 2007-11-15 05:12:58 -0600 (Thu, 15 Nov 2007) | 5 lines

Improve support for multipart messages. Code by gasparz, changes
by me (mostly formatting). Thanks, gasparz!

Closes issue ASTERISK-10499


By: Digium Subversion (svnbot) 2007-11-15 05:25:09.000-0600

Repository: asterisk
Revision: 89282

_U  trunk/
U   trunk/channels/chan_sip.c

r89282 | oej | 2007-11-15 05:25:09 -0600 (Thu, 15 Nov 2007) | 13 lines

Merged revisions 89280 via svnmerge from

r89280 | oej | 2007-11-15 12:15:09 +0100 (Tor, 15 Nov 2007) | 5 lines

Improve support for multipart messages. Code by gasparz, changes
by me (mostly formatting). Thanks, gasparz!

Closes issue ASTERISK-10499