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

Joshua Colp (JIRA) noreply at issues.asterisk.org
Thu Jul 10 05:17:56 CDT 2014


     [ https://issues.asterisk.org/jira/browse/ASTERISK-24002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-24002:
-----------------------------------

    Assignee: Aleksei Kulakov
      Status: Waiting for Feedback  (was: Triage)

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.

> 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
>            Assignee: Aleksei Kulakov
>         Attachments: calleeChromeConsole.txt, calleeChromeWebrtcDump.txt, extensions.conf, http.conf, noAudioAfterWebRtcCalleeUnhold.log, noAudioAfterWebRtcCalleeUnhold.pcapng, pjsip.conf
>
>
> # 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)



More information about the asterisk-bugs mailing list