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

[Eugene Voityuk (JIRA)]

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

Eugene Voityuk commented on ASTERISK-24146:
-------------------------------------------

Well, i just didn't have enough time to fix that... Will try to send clean patch this week. No, there is no other clean way to fix that. Old chan_sip is trying to start ICE negotiation just as it receives an SDP from originator, but browsers will not be ready to do ICE negotiations until they have remote description (SDP from remote). And timeout for ICE negotiation is ~6-7 secs in asterisk. This is that magic time in this issue. After timeout asterisk will never try to start negotiation again, and don't drop the call. So you end up with asterisk already stoped trying to negotiate ICE, and browser which hangs forever in checking state. You might hack this by sending the early media to WebRTC endpoint, just as asterisk receive incoming invite from it (this will force asterisk to send it SDP to WebRTC endpoint and they will be able to negotiate ICE). But i don't believe this is good solution. Other thing is to do invite without SDP, which even worse then previous in my opinion as you will end up with having huge (in my opinion this is huge, sometimes you will need 4-5 secs to gather all needed candidates) delay with no sound after call pickup. 

> [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)