| Summary: | ASTERISK-24002: No audio after WebRTC callee resumes call from hold | ||||
| Reporter: | Aleksei Kulakov (Each) | Labels: | |||
| Date Opened: | 2014-07-08 03:13:08 | Date Closed: | 2014-07-14 12:57:59 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_pjsip Channels/chan_sip/SRTP Core/RTP | ||
| Versions: | 12.2.0 12.3.0 12.4.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Ubuntu 14.04 PJProject(https://github.com/asterisk/pjproject 06/JUN/14) --enable-shared --disable-sound --disable-resample --disable-video --disable-opencore-amr --with-external-srtp CFLAGS="-g -DNDEBUG" chromium/chrome M35 (debug launch options: --disable-user-media-security --enable-logging --v=4 --vmodule=*libjingle/source/talk/*=4 --vmodule=*media/audio/*=4) SIPml-api.js?svn=224 with SDES patch from https://code.google.com/p/sipml5/issues/detail?id=183 | Attachments: | ( 0) calleeChromeConsole.txt ( 1) calleeChromeWebrtcDump.txt ( 2) DTLS_calleeHoldBug_chrome_debug.log ( 3) DTLS_calleeHoldBug_chromeConsole.log ( 4) DTLS_calleeHoldBug_ChromeWebRtcDump.txt ( 5) DTLS_calleeHoldBug.log ( 6) DTLS_pjsip.conf ( 7) extensions.conf ( 8) http.conf ( 9) noAudioAfterWebRtcCalleeUnhold.log (10) pjsip.conf (11) sipml_monkeypatch_to_enable_sdes_on_chrome_gte_m35.js | ||
| Description: | # Caller 6001(SIP softphone, but results for WebRTC or 'originate' caller is the same) calls WebRTC endpoint 354(SIPml)
# Callee places call on hold # Callee resumes call from hold After resuming there is no audio on both ends and many of 'SRTP unprotect failed with: authentication failure 110' messages in asterisk log. _NB: When endpoints in pjsip.conf configured to use DTLS, resuming call from hold fails with '488 Not acceptable here'_ Issue reproducible with chan_pjsip(logs for that case) and chan_sip. Can be reproduced even when call is originated by asterisk('originate PJSIP/354 application musiconhold') It is related to [ASTERISK-19609]: When resuming from hold Chrome sends packet with 2 crypto lines: {quote} a=group:BUNDLE audio a=crypto:0 AES_CM_128_HMAC_SHA1_32 a=crypto:1 AES_CM_128_HMAC_SHA1_80 {quote} And asterisk replies with bq. a=crypto:1 AES_CM_128_HMAC_SHA1_80 Then Chrome starts spamming log with mesages like {quote} [24:87:0709/161528:VERBOSE2:srtpfilter.cc(535)] Failed to unprotect SRTP packet, err=7 [24:87:0709/161528:VERBOSE1:channel.cc(575)] Failed to unprotect audio RTP packet: size=176, seqnum=38058, SSRC=699584917 {quote} After adding "srtp_tag_32=yes" option to target endpoint(pjsip.conf), Asterisk wont spam "SRTP Unprotect failed" errors and Chrome logs following: {quote} [24:87:0709/164658:VERBOSE2:srtpfilter.cc(365)] Invalid parameters in SRTP answer ... [24:24:0709/164658:VERBOSE1:webrtcsession.cc(251)] Failed to set remote answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to setup SRTP filter.. {quote} and start spamming log with {quote} [24:87:0709/164658:VERBOSE1:port.cc(296)] Jingle:Port[audio:1:0::Net[eth0:192.168.0.139/32]]: Received non-STUN packet from unknown address (192.168.0.139:10086) {quote} *So it looks like that something went wrong with crypto negotiation procedure.* *Workaround: disable media encryption altogether:* * Remove 'media_encryption' option from endpoint in pjsip.conf * Run chrome with --disable-webrtc-encryption (should work only in dev builds, but chromium M35 on xubuntu 14.04 accepts it too) | ||||
| Comments: | By: Aleksei Kulakov (Each) 2014-07-08 03:21:36.492-0500 sip.conf deleted entirely, rtp.conf unchanged, extensions.conf just added 2 dial rules http.conf - default changes for WebRTC support By: Joshua C. Colp (jcolp) 2014-07-10 05:17:39.572-0500 We don't support external patches to Asterisk on this issue tracker. If you would like help with the DTLS-SRTP part of things that would be fine and could be accomplished by uploading the logs and configuration for that. Additionally the SipML5 folks have admitted that their hold support is currently based around an old approach that may or may not work for people, and they are aiming to rewrite it according to currently available features. It would not surprise me if that was the problem here. By: Joshua C. Colp (jcolp) 2014-07-10 05:20:36.370-0500 Ah, it's a SipML5 patch to force SDES. Even then... going forward DTLS-SRTP is the only way to go. Any time spent on SDES in WebRTC is time wasted as SDES will soon not exist for it. By: Aleksei Kulakov (Each) 2014-07-10 06:39:09.666-0500 Mentioned patch not for asterisk, but for sipml thar allows chrome to use SDES instead of forced DTLS(chrome >m35 forcing it by default). Anyways, if you checking issue with SDES configs via 'originate' this fix isnt need. I added logs and config for DTLS case. Keys generated via _contrib/scripts/ast_tls_cert_ script_, ca.crt added to trusted store. Callee on same machine, call originated with 'originate PJSIP/355 application musiconhold'. Related part of logs can be found by searching for 'crypto:0'. But i suggest you to to look at logs from SDES case, cos they much more informative By: Rusty Newton (rnewton) 2014-07-14 12:57:35.071-0500 Closing this out. As Josh mentioned, SDES won't be supported for WebRTC with browsers for much longer. It is unlikely any work will be done towards that aspect. For the DTLS hold issue, a new, separate issue could be opened after Doubango is able to fix/update the hold/unhold issue on client side. Here is the thread on their forums: https://groups.google.com/forum/#!searchin/doubango/hold/doubango/dycrUePlV8I/CvIa8MwlNNYJ By: Rusty Newton (rnewton) 2014-07-14 12:59:04.919-0500 When the time comes to open a new issue or re-open one, you can always contact a bug marshal in #asterisk-bugs or #asterisk-dev on irc.freenode.net | ||||