ASTERISK-11219: Asterisk ignores SDP when multiple Content-Type headers are present

[Home]

Summary: ASTERISK-11219: Asterisk ignores SDP when multiple Content-Type headers are present

Reporter: Bluce Ree (tasker) Labels:

Date Opened: 2008-01-12 09:56:49.000-0600 Date Closed: 2008-01-15 14:08:09.000-0600

Priority: Major Regression? No

Status: Closed/Complete Components: Channels/chan_sip/Interoperability

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments:

Description: Asterisk ignores the SDP information when multiple Content-Type headers are defined. Specifically, it seems to happen when SDP is not the first header in a multiple Content-Type situation. The call is still handled and results in one-way audio (inbound RTP only).

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

Below is a SIP INVITE message from a Telica swith:

=======================================
INVITE sip:7023215625@1.1.1.1;user=phone;cic=1234 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2
From: <sip:3197264321@2.2.2.2;user=phone>;tag=10000000-0-963557229
To: <sip:3212022574@1.1.1.1;user=phone>
CSeq: 1 INVITE
MIME-Version: 1.0
Content-Length: 511
Contact: <sip:3197264321@2.2.2.2>
Call-ID: 12720963@2.2.2.2
Remote-Party-ID: <sip:3197264321@2.2.2.2;user=phone>;party=calling;id-type=subscriber;privacy=off;screen=no
Max-Forwards: 70
Content-Type: multipart/mixed; boundary=Telica-boundary

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

v=0
o=- 3162718811 3162718811 IN IP4 2.2.2.2
s=-
c=IN IP4 2.2.2.2
t=0 0
m=audio 22080 RTP/AVP 0 101
a=sendrecv
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

--Telica-boundary
Content-Type: application/ISUP; version=ansi00
Content-Disposition: signal; handling=required

=======================================

Asterisk is not able to see the SDP information located in the second Content-Type. This is confirmed by the fact that we never see the "Found RTP ... Found Description format ... Capabilities: us - ..." messages in the SIP debug at any time during the call setup.

The call proceeds normally, however, with one-way audio as seen below:

=======================================
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008611, ts 044315, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008612, ts 044475, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008613, ts 044635, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008614, ts 044795, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008615, ts 044955, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008616, ts 045115, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008617, ts 045275, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008618, ts 045435, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008619, ts 045595, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008620, ts 045755, len 000160)
Got RTP packet from 2.2.2.2:38852 (type 00, seq 008621, ts 045915, len 000160)

=======================================

Comments: By: Olle Johansson (oej) 2008-01-12 09:57:52.000-0600

Please upload a full SIP debug (according to the bug guidelines). Set debug to 4 and turn on SIP debug. Thanks!
By: Bluce Ree (tasker) 2008-01-12 10:11:57.000-0600

I don't see the point of adding more SIP headers. Multiple content-types are just not supported in Asterisk and the INVITE message is where the offending format exists.

By: Olle Johansson (oej) 2008-01-12 10:14:53.000-0600

It is supported and you have a bug somewhere.
By: Bluce Ree (tasker) 2008-01-12 10:57:08.000-0600

<--- SIP read from 2.2.2.2:5060 --->
INVITE sip:3192908821@1.1.1.1;user=phone;cic=1234 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2
From: <sip:3097182212@2.2.2.2;user=phone>;tag=10000000-0-264876957
To: <sip:3192908821@1.1.1.1;user=phone>
CSeq: 1 INVITE
MIME-Version: 1.0
Content-Length: 510
Contact: <sip:3097182212@2.2.2.2>
Call-ID: 12767973@2.2.2.2
Remote-Party-ID: <sip:3097182212@2.2.2.2;user=phone>;party=calling;id-type=subscriber;privacy=off;screen=no
Max-Forwards: 70
Content-Type: multipart/mixed; boundary=Telica-boundary

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

v=0
o=- 5187263383 5187263383 IN IP4 2.2.2.2
s=-
c=IN IP4 2.2.2.2
t=0 0
m=audio 14442 RTP/AVP 0 101
a=sendrecv
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

--Telica-boundary
Content-Type: application/ISUP; version=ansi00
Content-Disposition: signal; handling=required

¢#! RG#"!C
<------------->
--- (12 headers 22 lines) ---
Sending to 2.2.2.2 : 5060 (no NAT)
Using INVITE request as basis request - 12767973@2.2.2.2
Found no matching peer or user for '2.2.2.2:5060'
Looking for 3192908821 in trisun (domain 1.1.1.1)
list_route: hop: <sip:3097182212@2.2.2.2>

<--- Transmitting (no NAT) to 2.2.2.2:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 2.2.2.2;received=2.2.2.2
From: <sip:3097182212@2.2.2.2;user=phone>;tag=10000000-0-264876957
To: <sip:3192908821@1.1.1.1;user=phone>
Call-ID: 12767973@2.2.2.2
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:3192908821@1.1.1.1>
Content-Length: 0

<------------>
Audio is at 1.1.1.1 port 18926
Adding codec 0x100 (g729) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
courier*CLI>
<--- Reliably Transmitting (no NAT) to 2.2.2.2:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 2.2.2.2;received=2.2.2.2
From: <sip:3097182212@2.2.2.2;user=phone>;tag=10000000-0-264876957
To: <sip:3192908821@1.1.1.1;user=phone>;tag=as72e07e50
Call-ID: 12767973@2.2.2.2
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:3192908821@1.1.1.1>
Content-Type: application/sdp
Content-Length: 260

v=0
o=root 22521 22521 IN IP4 1.1.1.1
s=session
c=IN IP4 1.1.1.1
t=0 0
m=audio 18926 RTP/AVP 18 0 3
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------>
courier*CLI>
<--- SIP read from 2.2.2.2:5060 --->
ACK sip:3192908821@1.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2
Call-ID: 12767973@2.2.2.2
From: <sip:3097182212@2.2.2.2;user=phone>;tag=10000000-0-264876957
To: <sip:3192908821@1.1.1.1;user=phone>;tag=as72e07e50
CSeq: 1 ACK
Contact: <sip:3097182212@2.2.2.2>
Content-Length: 0
Max-Forwards: 70

<------------->
--- (9 headers 0 lines) ---
courier*CLI>
By: Bluce Ree (tasker) 2008-01-12 11:28:33.000-0600

Here's the debug log (set to 4) for the call:

[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:2676 do_setnat: Setting NAT on RTP to Off
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:4429 sip_alloc: Allocating new SIP dialog for 12767973@2.2.2.2 - INVITE (With RTP)
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:14921 handle_request: **** Received INVITE (5) - Command in SIP INVITE
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:13587 handle_request_invite: No SDP in Invite, third party call control
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:13603 handle_request_invite: Checking SIP call limits for device
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:3110 update_call_counter: Updating call counter for incoming call
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:3921 sip_new: *** Our native formats are 0x100 (g729)
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:3922 sip_new: *** Joint capabilities are 0x106 (gsm|ulaw|g729)
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:3923 sip_new: *** Our capabilities are 0x106 (gsm|ulaw|g729)
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:3924 sip_new: *** AST_CODEC_CHOOSE formats are 0x100 (g729)
[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:3947 sip_new: This channel will not be able to handle video.

By: Bluce Ree (tasker) 2008-01-12 12:02:38.000-0600

Could this be the issue?

----------------------
Content-Type: multipart/mixed; boundary=Telica-boundary

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

The first Content-type defines a section called Telica-boundary. Within that content is where SDP is defined.

Would Asterisk see that as being manufacturer specific data and ignoring everything within Telica-boundary? It would seem to be correct behavior according to the RFC, if I am understaning it correctly, thus it isn't a bug.
By: Olle Johansson (oej) 2008-01-12 12:54:40.000-0600

No, the "Telica-boundary" is just a text string that is used to recognize the boundaries.
By: Olle Johansson (oej) 2008-01-12 12:55:25.000-0600

This is not a full debug - the debug output from asterisk is missing. Check your logging configuration. And please add log output as attachments.

(Read the bug guidelines again!)

Thanks
By: Bluce Ree (tasker) 2008-01-14 16:27:52.000-0600

Well, it seems convenient that everything within the Telica-boundary Content-Type is being ignored:

[Jan 12 12:16:21] DEBUG[25661]: chan_sip.c:13587 handle_request_invite: No SDP in Invite, third party call control

===============================
Content-Type: multipart/mixed; boundary=Telica-boundary

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

v=0
o=- 5187263383 5187263383 IN IP4 2.2.2.2
s=-
c=IN IP4 2.2.2.2
t=0 0
m=audio 14442 RTP/AVP 0 101
a=sendrecv
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

--Telica-boundary
===============================

By: Bluce Ree (tasker) 2008-01-14 16:31:31.000-0600

Whoops ... seems like this is not a new problem and may have been reintroduced:

http://bugs.digium.com/view.php?id=7541
By: Digium Subversion (svnbot) 2008-01-14 16:39:32.000-0600

Repository: asterisk
Revision: 98894

U branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r98894 | file | 2008-01-14 16:39:32 -0600 (Mon, 14 Jan 2008) | 4 lines

Accept "; boundary=" not just ";boundary=" in the multipart mixed content type.
(closes issue ASTERISK-11219)
Reported by: tasker

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

http://svn.digium.com/view/asterisk?view=rev&revision=98894
By: Digium Subversion (svnbot) 2008-01-14 16:41:59.000-0600

Repository: asterisk
Revision: 98895

_U trunk/
U trunk/channels/chan_sip.c

------------------------------------------------------------------------
r98895 | file | 2008-01-14 16:41:58 -0600 (Mon, 14 Jan 2008) | 12 lines

Merged revisions 98894 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r98894 | file | 2008-01-14 18:41:55 -0400 (Mon, 14 Jan 2008) | 4 lines

Accept "; boundary=" not just ";boundary=" in the multipart mixed content type.
(closes issue ASTERISK-11219)
Reported by: tasker

........

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

http://svn.digium.com/view/asterisk?view=rev&revision=98895
By: Bluce Ree (tasker) 2008-01-14 17:22:41.000-0600

Fix did not work.

[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 0: INVITE sip:3094128888@1.1.1.1;user=phone;cic=1234 SIP/2.0 (65)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 1: Via: SIP/2.0/UDP 2.2.2.2 (31)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 2: From: <sip:3198173901@2.2.2.2;user=phone>;tag=10000000-0-408058150 (73)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 3: To: <sip:3094128888@1.1.1.1;user=phone> (47)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 4: CSeq: 1 INVITE (14)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 5: MIME-Version: 1.0 (17)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 6: Content-Length: 504 (19)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 7: Contact: <sip:3198173901@2.2.2.2> (40)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 8: Call-ID: 14452449@2.2.2.2 (32)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 9: Remote-Party-ID: <sip:3198173901@2.2.2.2;user=phone>;party=calling;id-type=subscriber;privacy=off;screen=no (114)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 10: Max-Forwards: 70 (16)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 11: Content-Type: multipart/mixed; boundary=Telica-boundary (55)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4694 parse_request: Header 12: (0)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: --Telica-boundary (17)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: Content-Type: application/sdp (29)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: Content-Disposition: session; handling=required (47)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: (0)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: v=0 (3)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: o=- 3057162828 3057162828 IN IP4 2.2.2.2 (47)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: s=- (3)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: c=IN IP4 2.2.2.2 (22)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: t=0 0 (5)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: m=audio 41444 RTP/AVP 0 101 (27)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: a=sendrecv (10)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: a=ptime:20 (10)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: a=rtpmap:0 PCMU/8000 (20)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: a=rtpmap:101 telephone-event/8000 (33)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: a=fmtp:101 0-15 (15)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: (0)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: --Telica-boundary (17)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: Content-Type: application/ISUP; version=ansi00 (46)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: Content-Disposition: signal; handling=required (46)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: (0)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4726 parse_request: Line: (4)
--- (12 headers 22 lines) ---
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:2676 do_setnat: Setting NAT on RTP to Off
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:4429 sip_alloc: Allocating new SIP dialog for 14452449@2.2.2.2 - INVITE (With RTP)
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:14922 handle_request: **** Received INVITE (5) - Command in SIP INVITE
Sending to 2.2.2.2 : 5060 (no NAT)
Using INVITE request as basis request - 14452449@2.2.2.2
Found no matching peer or user for '2.2.2.2:5060'
[Jan 14 17:59:42] DEBUG[25810]: chan_sip.c:13588 handle_request_invite: No SDP in Invite, third party call control

By: Joshua C. Colp (jcolp) 2008-01-14 17:28:53.000-0600

And svn info confirms you are using the correct revision?
By: Bluce Ree (tasker) 2008-01-14 17:57:19.000-0600

Ok, here's the solution, based on what you linked:

===============

/* if there is no boundary marker, it's invalid */
if (!(search = strcasestr(content_type, ";boundary=")) && !(search = strcasestr(content_type, "; boundary=")) )
return 0;

search += 10;
if((search = strcasestr(content_type, "; boundary="))) // If this version found then search += 11
search += 1;

===============

The 'search' pointer needs to be incremented by 1 more if the second version of "boundary" is found.

By: Bluce Ree (tasker) 2008-01-15 08:43:40.000-0600

The above code solves the issue. It was just a matter of incrementing the 'search' pointer by 1 more when "; boundary" was present, since it contains 11 characters instead of 10 due to the space between the semi-colon and "boundary".
By: Joshua C. Colp (jcolp) 2008-01-15 08:46:31.000-0600

Yes I understand it does and I have a different fix prepared, it's just nobody can commit anything right now so you will have to wait for it to go in.
By: Joshua C. Colp (jcolp) 2008-01-15 14:08:09.000-0600

Fixed in 1.4 as of revision 98934 and trunk as of revision 98935.