[asterisk-bugs] [Asterisk 0010947]: Content-Type: multipart/mixed not recognised correctly (SIP-T on not working)

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10947 
====================================================================== 
Reported By:                gasparz
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10947
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.12.1  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-11-2007 08:57 CDT
Last Modified:              11-12-2007 12:42 CST
====================================================================== 
Summary:                    Content-Type: multipart/mixed not recognised
correctly (SIP-T on not working)
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

--sonus-content-delim
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 at ip_address:5060 SIP/2.0.
Via: SIP/2.0/UDP ip_address:5060;branch=z9hG4bK02B04622ae828267f1c.
From: <sip:+number at ip:5060;isup-oli=0>;tag=gK0210492c.
To: <sip:+:+number at ip_address:5060>.
Call-ID: 134846_30026 at ip.
CSeq: 9886 INVITE.
Max-Forwards: 70.
Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,OPTIONS.
Accept: application/sdp, application/isup, application/dtmf,
application/dtmf-relay,  multipart/mixed.
Contact: <sip:+number at ip:5060>.
P-Asserted-Identity: <sip:+number at ip:5060>.
Supported: 100rel.
Content-Length:  618.
Content-Type: multipart/mixed;boundary=sonus-content-delim.
MIME-Version: 1.0.
.
--sonus-content-delim.
Content-Disposition: session; handling=required.
Content-Type: application/sdp.
.
v=0.
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.
a=sendrecv.
a=maxptime:20.
.
--sonus-content-delim.
Content-Disposition: signal; handling=optional.
Content-Type: application/isup; version=gr317; base=gr317.
.
.. .
..........hF.R$
...BdVWW.....Cq.6=.....#b.....
--sonus-content-delim--.


the path is against 1.4.13 but I can't select it from the list
====================================================================== 

---------------------------------------------------------------------- 
 twilson - 11-12-07 12:42  
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-12-07 12:42  twilson        Note Added: 0073534                          
======================================================================