[asterisk-bugs] [JIRA] (ASTERISK-29238) chan_sip: SDP: Offers without any enabled stream are accepted.

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253326#comment-253326 ] 

Asterisk Team commented on ASTERISK-29238:
------------------------------------------

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/].

> chan_sip: SDP: Offers without any enabled stream are accepted.
> --------------------------------------------------------------
>
>                 Key: ASTERISK-29238
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29238
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling, Channels/chan_sip/Video
>    Affects Versions: 16.15.1, 18.1.1
>            Reporter: Alexander Traud
>            Severity: Minor
>              Labels: fax
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)