Closed
Bug 1137932
Opened 10 years ago
Closed 10 years ago
DTLS handshake starts before transmitting the STUN response for the nomination
Categories
(Core :: WebRTC: Signaling, defect)
Core
WebRTC: Signaling
Tracking
()
RESOLVED
FIXED
mozilla39
Tracking | Status | |
---|---|---|
firefox39 | --- | fixed |
People
(Reporter: bwc, Assigned: bwc)
References
Details
Attachments
(1 file, 1 obsolete file)
On the answerer side, when the offerer (controlling ICE agent) sends a STUN check that causes ICE to transition to connected, we fire events that cause the DTLS handshake to start, and then send the response. This means that the Client Hello arrives before the STUN response, causing it to be dropped (because ICE isn't connected yet). The retransmission happens a full second later, delaying the flow of media significantly. Fixing this will not only allow our tests to run faster, but will also improve user experience somewhat.
Assignee | ||
Comment 1•10 years ago
|
||
/r/4443 - Bug 1137932: Unwind the stack before starting the DTLS handshake.
Pull down this commit:
hg pull review -r d505249a669520931f59b0f9bcaf772b19fe3b2e
Assignee | ||
Comment 2•10 years ago
|
||
Comment on attachment 8570744 [details]
MozReview Request: bz://1137932/bwc
This is one possible approach for fixing this bug.
The other approach is sending the STUN response before firing the ready callback, which is currently not possible because the ready callback can return an error code that determines whether the STUN response is a 200 or not. In order to do this, we'd either need to do away with this behavior entirely, or we would need to have two ready callbacks, the first of which can fail, and the second of which can not. This would be a bit more invasive.
Attachment #8570744 -
Flags: review?(martin.thomson)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → docfaraday
Updated•10 years ago
|
Attachment #8570744 -
Flags: review?(martin.thomson) → review+
Assignee | ||
Comment 3•10 years ago
|
||
Flags: needinfo?(docfaraday)
Assignee | ||
Comment 4•10 years ago
|
||
Seeing some persistent infra build bustage on that try push. Let's see if a rebase clears that up:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9799aed03755
Assignee | ||
Comment 5•10 years ago
|
||
Flags: needinfo?(docfaraday)
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Assignee | ||
Comment 7•9 years ago
|
||
Attachment #8570744 -
Attachment is obsolete: true
Attachment #8619624 -
Flags: review+
Assignee | ||
Comment 8•9 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•