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

Dade Brandon (JIRA) noreply at issues.asterisk.org
Tue Jun 30 14:37:33 CDT 2015


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

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

This patch didn't work for me, it broke things that were already working.  We have two possible WebRTC settings in production atm that are affectable via a checkbox for our customers, one of the two breaks.


Case 1:    WebRTC has Early Media turned ON, and invites with SDP

               - this case works as intended with and without the patch (this works around the 7 second answer issue regardless of the patch so long as progress is received within 7 seconds)

Case 2:   WebRTC has Early Media turned OFF, and invites WITHOUT SDP

               - this case works as intended without the patch, however with the patch, this case breaks;  Chrome is permanently stuck connecting (I didn't check the state it was stuck in since I had to rush to revert...)


I suspect most people are using a more standard case where early media is off, and invite happens with SDP.   That case is broken without the patch, however since this patch breaks valid use cases, I request that this patch does not get applied to trunk until the cases it breaks are worked out.  I suggest that anybody waiting for the patch instead uses one of the options I've listed above; we developed both specifically out of a need to work around this problem in production, and it works great.   (Note however there's a delay in source updates when using early media in chrome, ie when it switches from generated ringing to an answer, likely a bug in Chrome with authenticating handling source updates (rtp probation in Chrome, not in asterisk,) so I suggest the invite without SDP.


> [patch]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, bad_call_client_and_server.zip, badCall_filtered.pcapng, badChromeConsole.log, badChromeDebug.log, badChromeWebRtc.log, chan_sip.patch, debug.zip, logs_for_calls.zip, reproduce-confs.zip, res_rtp_asterisk.patch, 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)



More information about the asterisk-bugs mailing list