[Home]

Summary:ASTERISK-20203: Patch to handle complex SDP from TANDBERG/257 - "Unsupported top-level media type in offer"
Reporter:ddkprog (ddkprog)Labels:
Date Opened:2012-08-07 20:57:04Date Closed:2012-09-20 08:03:27
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:SVN Frequency of
Occurrence
Related
Issues:
Environment:linuxAttachments:( 0) chan_sip.c.diff
( 1) complex_invite.txt
Description:i have complicated SDP, with many video+audio codec AND with many unsupported SDP media.
so, asterisk break to parsing SDP attribute and response with "488 Not Accepteble Here"

from log

[2012-08-07 17:02:49] WARNING[13199][C-00000001]: chan_sip.c:9842 process_sdp: Unsupported top-level media type in offer: application 5070 UDP/BFCP *

so, the solutions to "continue" parsion at point "Unsupported top-level media type in offer" not "goto process_sdp_cleanup;"
Comments:By: Rusty Newton (rnewton) 2012-08-09 21:12:34.277-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks!


Can you please provide a packet trace demonstrating the issue ?  Also an Asterisk full debug with VERBOSE and DEBUG messages of level 5. https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: ddkprog (ddkprog) 2012-08-16 05:54:28.286-0500

complex invite and patch files attached
By: Rusty Newton (rnewton) 2012-09-19 20:25:30.727-0500

We didn't see this due to the feedback status not being "sent back".  We'll take a look.
By: Kinsey Moore (kmoore) 2012-09-20 07:54:04.350-0500

This INVITE request is being handled improperly by Asterisk trunk since the 11 branch and trunk should be able to deal with unknown SDP stream types transparently.  I have found the bug and the fix will be committed shortly.
By: Matt Jordan (mjordan) 2012-09-20 10:45:49.250-0500

I'm not sure about that.  I think this change was deliberate.

The idea was that Asterisk should not accept media streams it can't handle.  What change are you proposing for this?
By: Matt Jordan (mjordan) 2012-09-20 11:07:36.552-0500

Disregard - talked with Kinsey about it some more and his patch (r373211) should be appropriate to fix this.
By: ddkprog (ddkprog) 2012-09-20 11:24:34.903-0500

guys how about to commit the patch from this issues
https://issues.asterisk.org/jira/browse/ASTERISK-20201 ?
about unused tos_video field
> chan_sip.c.diff (License #6008)  10/Aug/12 3:14 AM  0.4 kB


By: ddkprog (ddkprog) 2012-09-20 11:27:18.265-0500

about current issues, compelex sdp INVITE attached, and can be included to sipp test into asterisk for testing
By: Matt Jordan (mjordan) 2012-09-20 11:47:51.241-0500

We can reopen ASTERISK-20201, but that would be a separate issue.
By: ddkprog (ddkprog) 2012-09-20 13:19:35.043-0500

patch (r373211) seems will not the fix this issues,
as you can see, we have twice SDP, there the second SDP name by "m=application 5070 UDP/BFCP *" and folow it,
so the second SDP should striped and not used to analize in the chan_sip module

look at the attached patch chan_sip.c.diff


By: Kinsey Moore (kmoore) 2012-09-20 14:28:05.180-0500

Could you be more specific about which parts of the INVITE's SDP you think should be ignored? From what I can tell of your patch, everything down to the first application line should be ignored including session-level parameters and the first audio and video stream offered.
By: ddkprog (ddkprog) 2012-09-20 14:52:39.766-0500

yes! second SDP attribute after "m=application 5070 UDP/BFCP *" should ignogred, becouse it not main SDP. The main SDP already parsed before "m=application 5070 UDP/BFCP *"

the one SDP body, can have many profiles SDP attributes, seperated by "m=application ...." try look at a RFC

at attach "complex_invite.txt" the cisco like example, in the current implementation of the cisco we have the same sdp attributes at main and second profile, but seems a RFC says thats attributes can be a not the same, so we should not to parse the second SDP and need skip it
By: Joshua C. Colp (jcolp) 2012-09-20 14:58:34.773-0500

There is no "main SDP" or "second SDP". This entire SDP contains multiple differing media streams, including multiple differing video and application ones specifically.
By: ddkprog (ddkprog) 2012-09-20 15:01:29.773-0500

Oh, just so it is, I just do not know how better to say
By: Kinsey Moore (kmoore) 2012-09-20 15:22:06.422-0500

As chan_sip currently operates in Asterisk 11 and trunk, it will accept the first m=video offer, the m=first audio offer, the first m=image offer, and the first m=text offer.  All following offers of these four types (audio, video, image, text) will be declined, which sounds like what you want.

Asterisk does not know how to handle m=application offers, so it declines them.

In the case of your example INVITE,
First audio stream: Accepted
First video stream: Accepted
First application stream: Declined (Asterisk can't handle application streams)
Second video stream: Declined (Asterisk can only handle one video stream)
Second application stream: Declined (Asterisk can't handle application streams)

Currently, this behavior is not configurable.
By: ddkprog (ddkprog) 2012-09-20 15:29:06.646-0500

ok, i understand