[asterisk-bugs] [Asterisk 0017179]: SDP does not get parsed when in SIP multipart body below line 64
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Apr 15 08:55:42 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17179
======================================================================
Reported By: khw
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 17179
Category: Channels/chan_sip/General
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
Asterisk Version: SVN
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 257191
Request Review:
======================================================================
Date Submitted: 2010-04-14 03:17 CDT
Last Modified: 2010-04-15 08:55 CDT
======================================================================
Summary: SDP does not get parsed when in SIP multipart body
below line 64
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?
======================================================================
----------------------------------------------------------------------
(0120450) khw (reporter) - 2010-04-15 08:55
https://issues.asterisk.org/view.php?id=17179#c120450
----------------------------------------------------------------------
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 be restricted to messages with a
limit of 64 lines.
INVITE sip:17476389018 at 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 at proxy01.sipphone.com>
From: <sip:john.doe at anonymous.invalid>;tag=hvykx4
Call-ID: 69aec6bd-01e3-4f15-b349-4e8fe23ae374 at vm-xp
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: zap/0.2.3
Supported: path
Supported: gruu
Contact:
<sip:john.doe at 1.2.3.4:5060;grid=a50db0b54dce6473068a3e574987f7ef>
Supported: geolocation
Geolocation: <cid:pidflo at 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 at 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 at 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--
Issue History
Date Modified Username Field Change
======================================================================
2010-04-15 08:55 khw Note Added: 0120450
======================================================================
More information about the asterisk-bugs
mailing list