[asterisk-bugs] [JIRA] (ASTERISK-24146) No audio on WebRtc caller side when answer waiting time is more than ~7sec

[Dade Brandon (JIRA)]

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

Dade Brandon commented on ASTERISK-24146:
-----------------------------------------

I've confirmed the same persistent problem on 11.16 matching all elements of other contributors to this post.  I was surprised to notice as others do here, that a test extension with a Wait(7) before Answer will never cause this problem (for our testbed, at least),  yet Wait(8) will always cause this error.

- This issue is not present on inbound calls (ie if you wait for 8+ seconds before answering a call inbound to the sip.js phone). 
- This issue is present in both firefox and chrome

I'm going to have to put a workaround of answering before initiating any dial command on webrtc users, since our webrtc based release is due on April 1st, however after that I've locked down time to work on this problem.  If anybody else gathers further information that may assist me in developing a patch for this issue, please share it; I am not at all familiar with Stun, Ice or DTLS, so effectively learning the protocols to fix this will take me some time.  If anybody else wants to take this on, then great, but the issue has been stale for too long for me not to stab at it myself.


Is there a workaround anybody is aware of that is not posted here?

Does anybody have a working configuration that does not exhibit this problem?

Does anybody know why this may happen on outbound, but not inbound calls?  ie which settings / code / protocol behaviors are different between the two, that may be at play?

In case there's some common misconfiguration causing this, here is our relevant template for WebRTC/WSS users:

[wss](!)
avpf=yes
transport=wss
icesupport=yes
encryption=yes
dtlsenable=yes
dtlsverify=no
dtlssetup=actpass
dtlscertfile=<valid; self signed.pem>
dtlsprivatekey=<valid; same file as above.pem>
dtlscafile=<valid; self signed ca.crt>
directmedia=no    ; this was added on as a test yesterday, and had no relevant affect;  I was testing to see if reinvites were causing the issue.
rpid_update=no    ; this was added on as a test yesterday, and had no relevant affect

This gets combined with our nat-user template which adds nat=force_rport,comedia, and other implementation specific details that are unlikely to have any relevant affect

Our rtp.conf and http.conf are correct for webrtc/ssl configuration; We don't have any problem other than this.  

> No audio on WebRtc caller side when answer waiting time is more than ~7sec
> --------------------------------------------------------------------------
>
>                 Key: ASTERISK-24146
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24146
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/WebSocket, Resources/res_rtp_asterisk
>    Affects Versions: 11.11.0, 12.4.0
>         Environment: Ubuntu 14.04
> Asterisk 12.4.0 compiled from tarball
> 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 35.0.1916.153(rev274914) (launch options: --use-fake-ui-for-media-stream --disable-webrtc-encryption)
> SIPml-api.js?svn=224
>            Reporter: Aleksei Kulakov
>         Attachments: badAsterDebug.log, badCall_filtered.pcapng, badChromeConsole.log, badChromeDebug.log, badChromeWebRtc.log, debug.zip, reproduce-confs.zip, sip.conf
>
>
> 1. WebRtc caller(354) dials callee(6001) of any type
> 2. Callee waits 10sec before answering the call.
> 3. No audio on WebRtc caller(354) side, although RTP is flowing in both directions and callee can hear audio from caller mic.
> There is some difference in output of 'rpt set debug on' in *bad* case(+answer wait time > 7sec+):
> {quote}
> Sent RTP P2P packet to 192.168.0.86:43911 (type 08, len 000160)
> Sent RTP P2P packet to 192.168.0.139:23506 (type 08, len 000160)
> Sent RTP P2P packet to 192.168.0.86:43911 (type 08, len 000160)
> Sent RTP P2P packet to 192.168.0.139:23506 (type 08, len 000160)
> {quote}
> and *good* case(+answer wait time <7sec+):
> {quote}
> Sent RTP P2P packet to 192.168.0.86:59092 (type 08, len 000160)
> Sent RTP P2P packet to 192.168.0.86:59092 (via ICE) (type 08, len 000160)
> Sent RTP P2P packet to 192.168.0.86:59092 (type 08, len 000160)
> Sent RTP P2P packet to 192.168.0.86:59092 (via ICE) (type 08, len 000160)
> {quote}
> Issue reproducible only with chan_sip. *Chan_pjsip IS NOT affected*



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