[Home]

Summary:ASTERISK-15954: SDP does not get parsed when in SIP multipart body below line 64
Reporter:khw (khw)Labels:
Date Opened:2010-04-14 03:17:19Date Closed:2010-05-06 10:43:04
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Currently SIP_MAX_LINES ist set to 64. Hence, when the SDP is contained in a SIP multipart body below line 64 it will not get parsed at all, even though there is a valid SDP in the message. When the multipart message is short enough, there is no problem at all. So since Asterisk is able to handle multipart messages (there may be a bunch of other body parts than SDP) I guess it would be also good to handle longer messages.
Is there a reason for this limit?

****** ADDITIONAL INFORMATION ******

channels/sip/include/sip.h

#define SIP_MAX_LINES             64     /*!< Max amount of lines in SIP attachment (like SDP) */
Comments:By: Tilghman Lesher (tilghman) 2010-04-14 09:14:42

No, it's merely an arbitrary limit.  How many lines do you actually have in your longest SIP message?

If you could attach an example of a SIP message with the longer number of headers, that would be helpful in the future, so we could point back to X client which specifies more than 64 lines in the SIP message.


By: khw (khw) 2010-04-14 09:23:46

My sample multipart-message was about 90 lines. Consequently Asterisk didn't find the SDP although a valid SDP was in the body.
By: Leif Madsen (lmadsen) 2010-04-14 10:00:24

As requested, please attach an example of the message, and the client you're using to generate that size of a message.
By: khw (khw) 2010-04-15 08:55:42

I'm using a modified version of the Mozilla SIP Client Zap! (http://ecrit.labs.nic.at) for experimenting with location conveyance in SIP messages (see http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-02). Hence, the SIP body may easily exceed the current limit of 64 lines, as shown below. However, the size of the location information in the body depends on the used Location Information Server, not on the SIP client (as long as the SIP client supports location conveyance, of course). In the future, SIP clients will support location conveyance (and maybe also other data in the body?), hence Asterisk should not be restricted to messages with a limit of 64 lines.

INVITE sip:17476389018@proxy01.sipphone.com SIP/2.0
Via: SIP/2.0/TCP 10.10.0.240:5060;rport;branch=z9hG4bKy69lhu
To: zap voice mail <sip:17476389018@proxy01.sipphone.com>
From: <sip:john.doe@anonymous.invalid>;tag=hvykx4
Call-ID: 69aec6bd-01e3-4f15-b349-4e8fe23ae374@vm-xp
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: zap/0.2.3
Supported: path
Supported: gruu
Contact: <sip:john.doe@1.2.3.4:5060;grid=a50db0b54dce6473068a3e574987f7ef>
Supported: geolocation
Geolocation: <cid:pidflo@zap>;inserted-by=10.10.0.240;recipient=endpoint
Content-Type: multipart/mixed;boundary=boundary1
Content-Length: 3711

--boundary1
Content-Type: application/pidf+xml
Content-ID: <pidflo@zap>

<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative" entity="pres:paul@somecell.example.com">
   <tuple id="relative">
     <status>
       <gp:geopriv>
         <gp:location-info>
           <gml:Polygon srsName="urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d">
             <gml:exterior>
               <gml:LinearRing>
                 <gml:posList>
                   11 34 34 34 34 50 11 50 11 34
                 </gml:posList>
               </gml:LinearRing>
             </gml:exterior>
           </gml:Polygon>
           <rel:reference>
             <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
               <gml:exterior>
                 <gml:LinearRing>
                   <gml:posList> -33.856625 151.215906 -33.856299 151.215343
                     -33.856326 151.214731
                     -33.857533 151.214495
                     -33.857720 151.214613 -33.857369 151.215375
                     -33.856625
                     151.215906
</gml:posList>
                 </gml:LinearRing>
               </gml:exterior>
             </gml:Polygon>
             <dyn:Dynamic xmlns:dyn="urn:ietf:params:xml:ns:pidf:dynamic">
               <dyn:orientation>35 12</dyn:orientation>
               <dyn:speed>24</dyn:speed>
               <dyn:heading>278</dyn:heading>
             </dyn:Dynamic>
           </rel:reference>
           <rel:map>
             <rel:url type="image/jpeg">http://data.greatbuildings.com/gbc/drawings/Sydney_Opera_Lower.jpg
             </rel:url>
             <rel:offset>200 210</rel:offset>
             <rel:orientation>68</rel:orientation>
             <rel:scale>2.90</rel:scale>
           </rel:map>
         </gp:location-info>
         <gp:usage-rules/>
         <gp:method>Wiremap</gp:method>
       </gp:geopriv>
     </status>
     <timestamp>2007-06-22T20:57:29Z</timestamp>
   </tuple>

   <tuple id="absolute">
     <status>
       <gp:geopriv>
         <gp:location-info>
           <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
             <gml:exterior>
               <gml:LinearRing>
                 <gml:posList>
                   -33.856625 151.215906 -33.856299 151.215343
                   -33.856326 151.214731
                   -33.857533
                   151.214495
                   -33.857720 151.214613 -33.857369 151.215375
                   -33.856625
                   151.215906
                    </gml:posList>
               </gml:LinearRing>
             </gml:exterior>
           </gml:Polygon>
           <dyn:Dynamic xmlns:dyn="urn:ietf:params:xml:ns:pidf:dynamic">
             <dyn:orientation>35 12</dyn:orientation>
             <dyn:speed>24</dyn:speed>
             <dyn:heading>278</dyn:heading>
           </dyn:Dynamic>
         </gp:location-info>
         <gp:usage-rules/>
         <method>TA-NMR</method>
       </gp:geopriv>
     </status>
     <timestamp>2007-06-22T20:57:29Z</timestamp>
   </tuple>
 </presence>

--boundary1
Content-Type: application/sdp

v=0
o=zap 0 0 IN IP4 1.2.3.4
s=
c=IN IP4 10.10.0.240
t=0 0
a=ice-pwd:12a1jiq1kfqkdglh808p12xqjeo
m=audio 49156 RTP/AVP 0 8 97 101
a=candidate:194w3fn 1 UDP 0.5 10.10.0.240 49156
a=candidate:194w3fn 2 UDP 0.5 10.10.0.240 49157
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 speex/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
--boundary1--


By: Leif Madsen (lmadsen) 2010-04-15 12:53:47

Thanks for the information!
By: Leif Madsen (lmadsen) 2010-04-19 14:01:15

What about making this 128 lines? Unless stack space is a concern?
By: Tilghman Lesher (tilghman) 2010-04-19 15:48:18

The example is already 120 lines, so I'd go with 256, just to be safe.  Stack space is not a concern, as this is allocated on the heap.
By: Digium Subversion (svnbot) 2010-05-06 10:39:10

Repository: asterisk
Revision: 261560

U   trunk/channels/sip/include/sip.h

------------------------------------------------------------------------
r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines

Permit more lines within a SIP body to be parsed.

The example given within the related issue showed 120 lines, which was mostly
a result of the body being XML.

(closes issue ASTERISK-15954)
Reported by: khw

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=261560
By: Digium Subversion (svnbot) 2010-05-06 10:42:47

Repository: asterisk
Revision: 261561

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r261561 | tilghman | 2010-05-06 10:42:47 -0500 (Thu, 06 May 2010) | 15 lines

Merged revisions 261560 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines
 
 Permit more lines within a SIP body to be parsed.
 
 The example given within the related issue showed 120 lines, which was mostly
 a result of the body being XML.
 
 (closes issue ASTERISK-15954)
  Reported by: khw
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=261561
By: Digium Subversion (svnbot) 2010-05-06 10:42:56

Repository: asterisk
Revision: 261562

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r261562 | tilghman | 2010-05-06 10:42:56 -0500 (Thu, 06 May 2010) | 15 lines

Merged revisions 261560 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines
 
 Permit more lines within a SIP body to be parsed.
 
 The example given within the related issue showed 120 lines, which was mostly
 a result of the body being XML.
 
 (closes issue ASTERISK-15954)
  Reported by: khw
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=261562
By: Digium Subversion (svnbot) 2010-05-06 10:43:04

Repository: asterisk
Revision: 261563

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r261563 | tilghman | 2010-05-06 10:43:04 -0500 (Thu, 06 May 2010) | 15 lines

Merged revisions 261560 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines
 
 Permit more lines within a SIP body to be parsed.
 
 The example given within the related issue showed 120 lines, which was mostly
 a result of the body being XML.
 
 (closes issue ASTERISK-15954)
  Reported by: khw
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=261563