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

[Joshua C. Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua C. Colp updated ASTERISK-29238:
--------------------------------------

    Status: Open  (was: Triage)

> 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, patch
>         Attachments: really_fail_no_acceptable_SDP_offer.patch
>
>
> 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)