Support RFC 7635 (TURN OAuth)

NEW
Unassigned

Status

()

Core
WebRTC: Networking
P3
normal
Rank:
25
2 years ago
3 months ago

People

(Reporter: mreavy, Unassigned)

Tracking

38 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: dev-doc-needed)

This is similar to the Chromium issue https://bugs.chromium.org/p/webrtc/issues/detail?id=4907

Initial analysis for prioritization: The key purpose of this is to allow short-lived access to TURN resources without having a tight binding between the web server and the TURN server. The fact that it’s using a different STUN attribute (than password) to communicate the access token is really protocol hygiene. It doesn’t make anything possible that wouldn’t otherwise be possible.  So early implementations can use the technique described in here, but with normal TURN passwords holding the tokens.

For this reason, we are putting this on our longer term roadmap, not our short-term roadmap.  If anyone feels this should be done on the short-term roadmap, please make the argument in this bug.
(Reporter)

Updated

2 years ago
backlog: --- → webrtc/webaudio+
Rank: 35
(Reporter)

Updated

2 years ago
See Also: → bug 1247619

Comment 1

2 years ago
Until support for TURN OAuth is generally available in WebRTC browsers, implementors may wish to look at the technique described in https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 -- it requires no browser support, and only moderate coordination between the application (web) server and the TURN server.
Whiteboard: dev-doc-needed
(Reporter)

Updated

2 years ago
Rank: 35 → 25
Priority: P3 → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.