[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=228423#comment-228423 ] 

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

Hi Kirill, this behavior is ICE specific. When media is started and each party has got the SDP of the remote party, they will start procedures called ICE connectivity checks, or ICE negotiation. The ICE connectivity check is done by pairing each candidate in local SDP with the candidates found in remote SDP, and perform connectivity check for each pair by sending STUN Binding request to the remote address in the pair. When this STUN Binding Request yields a successful response, then the party knows that this pair of local and remote candidates may be used for the media transmission. The remote party will do the same pairing and connectivity checks process too. When asterisk receives remote SDP with candidates it creates own response with own candidates in SDP and based on that it can already create pairs of local and remote candidates to check, and that what it is doing right now, stating ICE checks as soon as asterisk have  pairs. But browser is not yet received response from asterisk with asterisks candidates, and just can't create pairs to start negotiation. My patch is fixing that by starting ICE checking only after sending response to remote WebRTC endpoint (browser).

https://tools.ietf.org/html/rfc5245

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