diff options
author | server-pandora <server-pandora@xencall.com> | 2015-12-14 11:53:20 -0800 |
---|---|---|
committer | Matt Jordan <mjordan@digium.com> | 2015-12-15 07:31:12 -0600 |
commit | 24ae124e4f7310cfa64c187b944b2ffc060da28d (patch) | |
tree | 51813b001eb95dfb948e5c9d48d3fa019bdf16c5 /phoneprov/polycom_line.xml | |
parent | 36097a185db00230a89f019b9b8ee2d478cc6665 (diff) |
res_rtp_asterisk.c: Fix DTLS negotiation delays.
- Trigger pending DTLS packets to send out, once the RTP instance's remote
address is set.
- Avoids locking the DTLS structure unnecessarily by only doing this if
DTLS is passive.
- Add DTLS locks around the structurally sensitive calls in the SSL
portion of __rtp_recvfrom, since dtls_srtp_check_pending does not lock
inside of itself, and we're dealing with the SSL BIO in at least two
threads.
WebRTC channels may receive a DTLS handshake before
ast_rtp_remote_address_set is called, which causes there to be a pending
response to send out. Previous to 1ad827, this was handled by calling
dtls_srtp_check_pending on receipt of any RTP packet - a STUN or RTP
packet could trigger the pending handshake response. Since that was
rightfully removed, whenever the DTLS handshake is received before the
remote address is set, we would have to wait until another SSL packet
arrives.
As of Chrome M47's optimizations to their handshake process, WebRTC
conversations between Chrome M47+ and Asterisk, where Asterisk is passive,
experience a 1 second delay without this patch, because the SSL handshake
is received before ICE negotation stores the remote_address, and the next
SSL packet isn't received until after a 1 second timeout in Chrome, which
causes a new handshake request.
ASTERISK-25614 #close
Change-Id: I547f1be7e302dbf71f6553dd8cbc0657b1d0b908
Diffstat (limited to 'phoneprov/polycom_line.xml')
0 files changed, 0 insertions, 0 deletions