[asterisk-bugs] [JIRA] (ASTERISK-29064) Audio Delay on WebRTC Call

[Oliver Rafael Peña (JIRA)]

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

Oliver Rafael Peña updated ASTERISK-29064:
------------------------------------------

    Attachment: Audio Delay SIP Messages.txt
                Audio Delay Call - udp capture.pcapng

The capture and sip messages were extracted on the WebRTC client's end

> Audio Delay on WebRTC Call
> --------------------------
>
>                 Key: ASTERISK-29064
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29064
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Resources/res_rtp_asterisk
>    Affects Versions: 16.9.0
>         Environment: OS: CentOS Linux release 7.7.1908 (Core)
> CPU Cores: 2
> RAM: 4GB
> Client WebRTC Librery: sip.js 0.15.0
> Chrome version:  85.0.4183.83
> Asterisk Behind NAT: yes
> Client behind NAT: yes
>            Reporter: Oliver Rafael Peña
>              Labels: webrtc
>         Attachments: Audio Delay Call - udp capture.pcapng, Audio Delay SIP Messages.txt
>
>
> Greetings,
> We've deployed asterisk + webrtc in a production enviroment, and since day one we've been having a problem with calls having audio delay  on both ways, this happens on ~10% of the calls, users are more often to identify the problem on outbound calls. The delay goes around 1-10 seconds, it vary. We understand that WebRTC comes with its requirements, and after a few months of research and testing we've done the following trying to solve the problem:
> - Even though we didn't find any fragmentation of DTLS packets on the handshake we decided to activate the pjsip endpoints option "dtls_auto_generate_cert" to discard any problems there.
> - Also we proceed to remove all unnecessary ICE candidates out of the client's end to ease ICE negotiation, along with reducing the ICE timeout to 500ms on the client
> - Also we remove the stunaddr option out of rtp.conf since we know the public IP, therefore removing the stun request out of the process.
> And after all that we still have the issue, hopefully we can clear that out on this thread.
> Based on our most recent testing, we noticed that asterisk is taking a considerable amount of time to initiate the DTLS handshake, roughly 2 seconds after the ICE bindings are done, in the capture file attached you can see that.
> Here are the config files:
> pjsip.endpoint.conf
> {panel}
> [base_webrtc](!)
> type=endpoint
> auth=main_auth
> transport=0.0.0.0-wss
> allow=ulaw,alaw,gsm,g726,g722
> context=from-internal
> dtmf_mode=rfc4733
> mwi_subscribe_replaces_unsolicited=yes
> aggregate_mwi=yes
> use_avpf=yes
> rtcp_mux=yes
> ice_support=yes
> media_use_received_transport=no
> trust_id_inbound=yes
> direct_media=no
> timers=no
> media_encryption_optimistic=yes
> send_pai=yes
> rtp_symmetric=yes
> rewrite_contact=yes
> force_rport=yes
> language=en
> media_encryption=dtls
> dtls_verify=fingerprint
> dtls_auto_generate_cert=yes
> dtls_setup=actpass
> dtls_rekey=0
> webrtc=yes
> rtp_keepalive=2
> [1922285](base_webrtc)
> aors=1922285
> callerid=CallerID <1922285>
> mailboxes=1922285 at device
> {panel}
> rtp.conf
> {panel}
> [general]
> rtpstart=50000
> rtpend=55000
> rtpchecksums=yes
> strictrtp=no
> icesupport=yes
> [ice_host_candidates]
> x.x.x.x => y.y.y.y,include_local_address ; x.x.x.x is the internal IP, y.y.y.y is the external IP
> {panel}
> http.conf
> {panel}
> [general]
> enabled=yes
> enablestatic=no
> bindaddr=::
> bindport=8088
> prefix=
> sessionlimit=1000
> session_inactivity=30000
> session_keep_alive=15000
> tlsenable=yes
> tlsbindaddr=[::]:8089
> tlscertfile=/etc/asterisk/keys/cert.crt
> tlsprivatekey=/etc/asterisk/keys/keyl.key
> {panel}



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