[asterisk-bugs] [JIRA] (ASTERISK-26637) chan_sip: Video TLS SRTP Broken

[Alexander Traud (JIRA)]

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

Alexander Traud commented on ASTERISK-26637:
--------------------------------------------

Some good news and some bad news. I faced the same symptom. I was able to reproduce your issue in the latest Asterisk 13.32.0. As you commented at the end, the issue is not about SDES-sRTP but about adding video mid-call. This can be seen in your log, with debug level 2:
{code}
chan_sip.c: This call needs video offers, but there's no video support enabled!
chan_sip.c: ** Our capability: (g722|ulaw|g729|h264) Video flag: False Text flag: False
{code}
When you look at source-code file {{channels/chan_sip.c}}, those two debug statements happen because of:
{code}
directmedia=false
videosupport=yes
{code}and because your call did not start with a video stream right-away. You can double-check this by going for {{sip show channel}} on the Asterisk command-line interface (CLI). There, ‘video support’ is ‘no’ because the simple_bridge does not have a video object in each call leg. In other words, the SIP channel driver chan_sip is not able to add video in one call leg and then issue a re-INVITE to the other call leg. All you get is a Status 100 Status 200 video 0 on the originating call leg = adding video gets refused by chan_sip. However in the source code, when you search for {{dialog->vrtp = ast_rtp_instance_new}}, you find a workaround:
{code}
directmedia=false
videosupport=always
{code}If you set video to ‘always’, you are able to attach a video stream even while in the call. This workaround has the drawback that the receiving party always gets a video offer, and some SIP phones show a black video because of that, then. Asterisk allows mid-call re-INVITE just recently, see [this|https://blogs.asterisk.org/2017/09/20/asterisk-15-multi-stream-media-sfu/] and [that|https://blogs.asterisk.org/2020/02/19/adding-and-removing-media-streams/] blog post—you have to migrate to Asterisk 16 LTS _and_ the SIP channel driver chan_pjsip. Another approach is to offer video from the start of the call; some SIP phones like your Zoiper and CounterPath Bria call this feature ‘always offer video,’ and Acrobits Groundwire calls this ‘start video automatically.’ Other SIP phones have a dedicated button to start a call with video.

Consequently, although dealing with media streams is fundamental to SIP, your reported issue is not a software bug, but when it comes to Asterisk, a feature request. Please, someone of the bug marshals, change the component from SRTP to Channels/chan_sip/CodecHandling. Kristopher, I hope you do not mind, but I recommend to close this issue as it cannot be solved (without changing a lot in chan_sip).

Nevertheless, I think about improving the log output. Currently, this limitation can be seen only at debug level 2. And the message is confusing as the user thinks the missing video support is about the endpoint and not the channels. Perhaps I come up with a sensible wording. Perhaps you have an idea?

> chan_sip: Video TLS SRTP Broken
> -------------------------------
>
>                 Key: ASTERISK-26637
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26637
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/SRTP
>    Affects Versions: 13.12.1, 13.12.2, 13.14.0, 14.3.0
>         Environment: Centos 6.6, Centos 7.x
>            Reporter: Kristopher Kolpin
>            Assignee: Unassigned
>         Attachments: asterisk_log.txt, debug_log_123456
>
>
> Seeing the following in my logs when attempting to initiate video during a call.
> {noformat}
> [2016-11-12 20:38:35] VERBOSE[19511][C-00000019] bridge_channel.c: Channel SIP/1001-0000002c joined 'simple_bridge' basic-bridge <93ab1bd6-e342-4c08-a9f5-7074240d318e>
> [2016-11-12 20:38:38] WARNING[19472][C-00000019] chan_sip.c: Rejecting secure video stream without encryption details: video 35906 RTP/SAVP 118
> [2016-11-12 20:38:44] ERROR[18924] tcptls.c: SSL_shutdown() failed: 5
> [2016-11-12 20:38:53] VERBOSE[19511][C-00000019] bridge_channel.c: Channel SIP/1001-0000002c left 'simple_bridge' basic-bridge <93ab1bd6-e342-4c08-a9f5-7074240d318e>
> {noformat}



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