Summary:	ASTERISK-26637: chan_sip: Video TLS SRTP Broken
Reporter:	Kristopher Kolpin (thehammer86)	Labels:
Date Opened:	2016-12-03 21:07:15.000-0600	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Channels/chan_sip/CodecHandling Channels/chan_sip/SRTP
Versions:	13.12.1 13.12.2 13.14.0 14.3.0	Frequency of Occurrence
Related Issues:
Environment:	Centos 6.6, Centos 7.x	Attachments:	( 0) asterisk_log.txt ( 1) debug_log_123456
Description:	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}
Comments:	By: Asterisk Team (asteriskteam) 2016-12-03 21:07:15.885-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. 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]. By: Joshua C. Colp (jcolp) 2016-12-05 09:45:34.750-0600 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. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. 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 the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Kristopher Kolpin (thehammer86) 2016-12-05 12:26:12.391-0600 1) Disallow invites for both endpoints to force entire duration of call through asterisk pbx. 2) Enable TLS signalling over port 5061 with certificates from a trusted certificate authority. 2) Enable SRTP media encryption. 3) Initiate an audio call between two endpoints with video capability. 4) Shortly after call has been established, enabling video feed on each endpoint issues the error message mentioned above. See detailed debug below: [Edit by Rusty - Removed debug and moving to an attachment (asterisk_log.txt) as per the guidelines] By: Rusty Newton (rnewton) 2016-12-05 17:48:51.477-0600 Looks like you forgot to include all the log channel types. I don't see ERROR messages specifically, but I also don't see DEBUG. Please follow this guide: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Make sure to get "warning,error,notice,verbose,debug" with verbose and debug turned up to level 5 or above. Make sure that the SIP trace is included (as you have with the current log). By: Rusty Newton (rnewton) 2016-12-09 17:21:57.742-0600 Absolutely do not post more than a few lines of debug into a comment field. The last comment you made actually created a situation where we couldn't access this ticket due. To restore access to this ticket we had to delete your comment in a silly way. Now we can't see your debug at all. Please, as I mentioned in an edit of your previous comment, attach your debug to the issue using the menu at the top of the ticket. 1. Click "More" 2. Click "Attach Files" and follow the instructions. By: Kristopher Kolpin (thehammer86) 2016-12-16 08:14:58.663-0600 My apologies. The attachment option wasn't open to me.  I didn't realize I had to sign the license agreement before attaching files. Please find the appropriate log files attached now. By: Kristopher Kolpin (thehammer86) 2016-12-16 08:16:49.253-0600 Requested debug file. By: Kristopher Kolpin (thehammer86) 2016-12-20 16:34:18.954-0600 Is the ASTERISK-20905 issue popping up again here? By: Rusty Newton (rnewton) 2016-12-20 16:46:49.260-0600 You do not have to sign the license agreement before attaching *any* file. You only need to sign the agreement if you are making a code or documentation contribution to the project. The question at the file attachment prompt says: "Is this a code or docs contribution?" Then, the two options are: 1.Yes, this is a code or documentation contribution. 2.No, this is another type of attachment. You should choose option 2 if your attachment is not a code or documentation contribution... Debug files definitely fall under 2. By: Kristopher Kolpin (thehammer86) 2017-01-13 09:47:27.807-0600 Is there any more information I can provide to expedite the resolution of this bug? By: Joshua C. Colp (jcolp) 2017-01-13 09:54:22.347-0600 No, there is no additional information required as of this time. There are no timeframes on issue resolution, and as chan_sip is community supported it may take some time. By: Kristopher Kolpin (thehammer86) 2017-03-09 17:16:36.352-0600 Just did a test with asterisk 14.3.0.  The problem still persists. By: Kristopher Kolpin (thehammer86) 2017-03-09 17:43:30.577-0600 I had another look at this with SRTP disabled.  It seems asterisk is trying to convert audio to video and vice versa. [2017-03-09 18:39:55] WARNING[15741][C-00000026]: channel.c:5630 set_format: Unable to find a codec translation path: (h264) -> (g722) [2017-03-09 18:39:55] WARNING[15741][C-00000026]: channel.c:5630 set_format: Unable to find a codec translation path: (g722) -> (h264) This is really strange as I have used the g722 audio codec with the h264 video codec summer 2016 when I was using an earlier version of Asterisk 13 By: Kristopher Kolpin (thehammer86) 2017-03-09 17:50:44.365-0600 Changed codecs to disallow=all and allow=ulaw&h264.  Still no video but this now appears in my logs: 0x7f894ce02bf0 -- Probation passed - setting RTP source address to 192.168.74.12:8000 0x7f894c24d900 -- Probation passed - setting RTP source address to 192.168.74.13:36528 This messages appear when I press the video button on my endpoints but no video stream actually occurs. By: Alexander Traud (traud) 2020-04-21 11:41:15.778-0500 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?