Summary:	ASTERISK-27624: WebRTC regression with Asterisk 15 and Chrome 64 to receive calls
Reporter:	Ludovic Gasc (Eyepea) (gmludo)	Labels:	webrtc
Date Opened:	2018-01-25 13:46:38.000-0600	Date Closed:	2018-02-26 09:13:01.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Resources/res_rtp_asterisk
Versions:	15.2.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Debian 9 64 bits, libsrtp 2.0.0	Attachments:	( 0) dtls_error_unexpected_message.pcapng.gz
Description:	Hi, With the new release of Chrome 64 two days ago, we have now a regression with Chrome 64+WebRTC+chan_sip, for the incoming calls on a WebRTC endpoint. When the webphone picks up the incoming call, Asterisk hangs up. We have this log message in Asterisk console: {quote} [Jan 25 20:04:52] ERROR[2431][C-00000006]: res_rtp_asterisk.c:2818 __rtp_recvfrom: DTLS failure occurred on RTP instance '0x7fe6140046b8' due to reason 'unexpected message', terminating [Jan 25 20:04:52] WARNING[2431][C-00000006]: res_rtp_asterisk.c:5802 ast_rtp_read: RTP Read error: Unspecified.  Hanging up. {quote} I have also the DTLS+STUN trace for this incoming call. It works pretty well with Firefox or an older version of Chrome. Do you think it's necessary to open an issue on the bug tracker of Chrome or it's something missing in Asterisk ? Do you need more details ? Thanks for your help.
Comments:	By: Asterisk Team (asteriskteam) 2018-01-25 13:46:39.128-0600 The module you are reporting the issue against is no longer supported as a core module but your issue is in the queue. Your patience is appreciated as a community developer may work the issue when time and resources become available. Asterisk is an open source project and community members work the issues on a voluntary basis. You are welcome to develop your own patches and submit them to the project.[1] If you are not a programmer and you are in a hurry to see a patch provided then you might try rallying support on the Asterisk users mailing list or forums.[2] Another alternative is offering a bug bounty on the asterisk-dev mailing list.[3] Often a little incentive can go a long way. [1]: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process [2]: http://www.asterisk.org/community/discuss [3]: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties By: Asterisk Team (asteriskteam) 2018-01-25 13:46:39.626-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: Ludovic Gasc (Eyepea) (gmludo) 2018-01-25 13:51:03.041-0600 Is it might be related with this issue ? ASTERISK-24205 By: Ludovic Gasc (Eyepea) (gmludo) 2018-01-25 15:20:54.546-0600 I did some tests with Asterisk 13.18 on the same server, no regressions detected, it seems a regression only on Asterisk 15.2. By: Ludovic Gasc (Eyepea) (gmludo) 2018-01-26 04:10:12.975-0600 After more tests, when we have disabled strictrtp in rtp.conf, we don't have the problem for now with incoming calls and Asterisk 15.2. The other difference might be the version libsrtp we use: We use libsrtp2 because it's packaged by Debian distribution, contrary to the recommended version of libsrtp, 1.5.4: https://wiki.asterisk.org/wiki/display/AST/libsrtp On Debian Stretch, we have only libsrtp 1.4.5, that seems dangerous to use, based on the content of the wiki page. By: Joshua C. Colp (jcolp) 2018-01-26 06:52:38.620-0600 Please include a full packet capture (including ICE negotiation) as well as an Asterisk console log with debug enabled (debug in logger.conf and core set debug 9). By: Ludovic Gasc (Eyepea) (gmludo) 2018-01-31 16:00:59.787-0600 Hi Joshua, I have the logs you requested, however, I have two problems to put here: 1. The server has unrelated SIP traffic even outside working hours. 2. We don't really want to publish these information on the Internet. Could I send you that on a private e-mail address ? Thank you. By: Joshua C. Colp (jcolp) 2018-01-31 16:04:56.362-0600 It's unlikely that would be great. The reason being that chan_sip is supported by the community, not by Digium and not by myself. It's unlikely I would be fixing it. By: Ludovic Gasc (Eyepea) (gmludo) 2018-01-31 16:28:51.930-0600 Ok, I fully understand :-) In fact, I already had tried to switch at the same time to Asterisk 15 + pjsip for WebRTC, but I didn't have audio at all, contrary to chan_sip. It's why my plan was to migrate first to Asterisk 15, and after migrate from chan_sip to pjsip for WebRTC. I will do some experimentations with libsrtp, to see what happens, and I will open an issue with WebRTC+pjsip with all debug details you have requested if I still have problems with pjsip. BTW, from our production experience with Asterisk 15 for several weeks, except about WebRTC, it works better compare to Asterisk 13: We still had time to time random Asterisk crashes with 13 release, and only one since our partial switch to Asterisk 15. Have a nice week. By: Ludovic Gasc (Eyepea) (gmludo) 2018-02-26 08:51:00.216-0600 I have tried again to migrate from chan_sip to chan_pjsip for WebRTC with Asterisk 15.3-rc1. We had no audio with Asterisk 15.2+pjsip+Chrome 64, but with Asterisk 15.3-rc1 it's OK now. We still have a delay (5-10 seconds) to pickup calls with incoming calls, we need to investigate more before to open an eventual issue: I don't know yet if it's a problem in the webphone or a real bug in Asterisk. But the situation is clearly better than before ;-) For this bug itself, I will close. By: Ludovic Gasc (Eyepea) (gmludo) 2018-02-26 09:13:01.718-0600 Use chan_pjsip instead of chan_sip By: Ludovic Gasc (Eyepea) (gmludo) 2018-03-15 16:28:33.771-0500 > We still have a delay (5-10 seconds) to pickup calls with incoming calls In case of other people will face to this problem, the solution we have found is to reduce the ICE timeout at Web browser side. With sip.js, it's with the parameter: iceCheckingTimeout. You can keep this issue closed, we confirm it's clearly better to use chan_pjsip instead of chan_sip for WebRTC with Asterisk 15. By: Asterisk Team (asteriskteam) 2018-03-15 16:28:34.179-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.