[asterisk-bugs] [JIRA] (ASTERISK-24002) No audio after WebRTC callee resumes call from hold

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-24002:
-----------------------------------------

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



> No audio after WebRTC callee resumes call from hold
> ---------------------------------------------------
>
>                 Key: ASTERISK-24002
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24002
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Channels/chan_sip/SRTP, Core/RTP
>    Affects Versions: 12.2.0, 12.3.0, 12.4.0
>         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
>            Reporter: Aleksei Kulakov
>         Attachments: calleeChromeConsole.txt, calleeChromeWebrtcDump.txt, DTLS_calleeHoldBug_chromeConsole.log, DTLS_calleeHoldBug_chrome_debug.log, DTLS_calleeHoldBug_ChromeWebRtcDump.txt, DTLS_calleeHoldBug.log, DTLS_pjsip.conf, extensions.conf, http.conf, noAudioAfterWebRtcCalleeUnhold.log, noAudioAfterWebRtcCalleeUnhold.pcapng, pjsip.conf, sipml_monkeypatch_to_enable_sdes_on_chrome_gte_m35.js
>
>
> # 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)



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