Closed Bug 915420 Opened 6 years ago Closed 6 years ago

WebRTC Call setup failures under Linux when using TURN

Categories

(Core :: WebRTC: Networking, defect)

All
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla26
Tracking Status
firefox24 --- unaffected
firefox25 + unaffected
firefox26 + verified

People

(Reporter: abr, Assigned: ekr)

References

Details

Attachments

(1 file)

When using Linux to set up a call with a TURN server, the media setup
never actually happens.

EKR tracked this down to an error in the way the interface prioritization
code was being called for relayed candidates.
Assignee: adam → ekr
OS: All → Linux
Blocks: 905150
Attachment #803324 - Flags: review?(docfaraday) → review+
Comment on attachment 803324 [details] [diff] [review]
Use foundation address instead of relay address to determine priority

Review of attachment 803324 [details] [diff] [review]:
-----------------------------------------------------------------

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 904598, 905150, 915420

User impact if declined:
Users will not be able to connect with WebRTC whenever a site
offers TURN service. With 904598 and 905150 but not 915420,
this will only impact Linux users.

Testing completed (on m-c, etc.):
Bugs 904598, 905150 tested by EKR and then EKR and ABR.
Bug 915420 fixed today and tested by EKR and ABR. Recommend
re-testing by QA prior to uplift.

Risk to taking this patch (and alternatives if risky):
This shouldn't make things any worse. The alternative is to
turn TURN off entirely.


String or IDL/UUID changes made by this patch: None.
Attachment #803324 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/28aa5abe0efb
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Comment on attachment 803324 [details] [diff] [review]
Use foundation address instead of relay address to determine priority

https://bugzilla.mozilla.org/show_bug.cgi?id=904598#c57
Attachment #803324 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Uplift turned out not to be needed here. The regression was on m-c and not aurora. My bad.
Verified this on nightly by establishing a connection between a Mac and Linux box where the problem was found, establishing an ordinary call as well as one that used TURN, per instructions Eric had sent me last week.
This is what I tried yesterday and worked for me between two nightly builds, one on OS X and one on Ubuntu:

1. Installed latest nightly on OS X and in Ubuntu.
2. Visited apprtc.webrtc.org on the nightly in OS X, then visited the resulting URL in the nightly in Ubuntu
3. Talked to myself

4. Then I went ahead and forced TURN only on the Mac OS X machine by using the following commands in the terminal (sudo):

ipfw add allow udp from any to any 67 out keep-state
ipfw add allow udp from any 67 to any 68
ipfw add allow udp from any to any dst-port 68 keep-state
ipfw add allow udp from any to any src-port 68 keep-state
ipfw add allow udp from any to any dst-port 53 keep-state
ipfw add allow udp from any to any dst-port 3478 keep-state
ipfw add deny udp from any to any

5. Tried making a call between the two nightlies.

This worked. In addition I tried this on aurora, beta, and release. 26-24.
You need to log in before you can comment on or make changes to this bug.