[Home]

Summary:ASTERISK-29238: chan_sip: SDP: Offers without any enabled stream are accepted.
Reporter:Alexander Traud (traud)Labels:fax patch
Date Opened:2021-01-09 11:16:43.000-0600Date Closed:2021-01-13 07:44:25.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling Channels/chan_sip/Video
Versions:16.15.1 18.1.1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) really_fail_no_acceptable_SDP_offer.patch
Description:When videosupport=no is configured, which is the default, the SIP channel driver chan_sip rejects all incoming video streams (RTP port 0 in SDP). When the SDP offer contains just video, that is rejected, but the overall dialog is accepted (SIP status 200). Asterisk continues in an undefined matter. For example, when the echo test is called, Asterisk still looks for the offered video format.

The same happens for textsupport=no and text-only streams.

{{tests/channels/SIP/codec_negotiation/sipp/decline_crypto.xml}}
In the Asterisk Test Suite, that test fails because it assumes SIP status 488 as a result. videosupport=no is set in that test. The test offers just a single video stream, nothing else. Asterisk rejects all streams but accepts the dialog. Asterisk looks-up its dialplan. In that test, the extension.conf is configured with {{exten => _.,1,NoOp()}}. That triggers a SIP status 603. That was not expected (603 versus 488).

Previously, that test case worked because chan_sip decided on the media profile (RTP/SAVP) of a stream before deciding on the media stream itself (m=video). And in that test, the module res_srtp.so is not loaded. Therefore, Asterisk returned SIP status 488 as expected by the test. The fix for ASTERISK-29222 changed the order, and the media profile is checked only when the media stream is accepted. Because of that, this issue was unveiled: The media stream is not rejected afterward.

Long story short, this was broken for years even without SDES-sRTP:
When an offer included just video, nothing else, and Asterisk was configured with videosupport=no, and Asterisk accepted the dialog although it contained no accepted video stream. Same for text streams.

*Workaround*
videosupport=yes
disallow=h263
in the configuration file sip.conf because, on default, Asterisk allows H.263 (not the [H.263+|https://en.wikipedia.org/wiki/H.263#H.263v2_(H.263+)] variant). With that configuration, Asterisk rejects the dialog because of no matching format. In the case of text, just textsupport=yes is sufficient because Asterisk does not allow any text format on default. see sip_set_default_format_capabilities(.) in channels/chan_sip.c

*Notes*
* The attached patch adds a check for audio streams as well. However, with the current source code, p->rtp is never null. Therefore, this check is just for symmetry reasons.
* The same should be done for image streams based on T.38 FAX (UDPTL). However, code inspection showed that in process_sdp(.), in the part "Setup audio address and port", chan_sip allows no audio but T.38 pass-through without checking p->udptl. It is questionable whether a T.38 session was required before. Nevertheless, because I cannot test this part, the attached patch does not introduce this change for image streams as well.
* The patch was not included in favor of the fix for ASTERISK-29237.
Comments:By: Asterisk Team (asteriskteam) 2021-01-09 11:16:44.666-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].

By: Friendly Automation (friendly-automation) 2021-01-13 07:44:26.001-0600

Change 15271 merged by Friendly Automation:
chan_sip: SDP: Sidestep stream parsing when its media is disabled.

[https://gerrit.asterisk.org/c/asterisk/+/15271|https://gerrit.asterisk.org/c/asterisk/+/15271]

By: Friendly Automation (friendly-automation) 2021-01-13 08:31:31.967-0600

Change 15233 merged by George Joseph:
chan_sip: SDP: Sidestep stream parsing when its media is disabled.

[https://gerrit.asterisk.org/c/asterisk/+/15233|https://gerrit.asterisk.org/c/asterisk/+/15233]

By: Friendly Automation (friendly-automation) 2021-01-13 08:31:43.395-0600

Change 15272 merged by George Joseph:
chan_sip: SDP: Sidestep stream parsing when its media is disabled.

[https://gerrit.asterisk.org/c/asterisk/+/15272|https://gerrit.asterisk.org/c/asterisk/+/15272]