Open
Bug 1291894
Opened 9 years ago
Updated 2 years ago
Implement ICE pool allocations
Categories
(Core :: WebRTC: Networking, defect, P3)
Core
WebRTC: Networking
Tracking
()
NEW
| Tracking | Status | |
|---|---|---|
| firefox51 | --- | affected |
| backlog | webrtc/webaudio+ |
People
(Reporter: drno, Unassigned)
References
()
Details
Latest JSEP draft suggests (SHOULD) that we implement ICE candidate pools:
https://rtcweb-wg.github.io/jsep/#rfc.section.3.5.4
We can't do it easily on a global (Firefox) level, so before a PeerConnection gets created.
But creating a pool once a nICEr instances gets created, right after a PeerConnection got instantiated should be doable.
|
Reporter | |
Updated•9 years ago
|
backlog: --- → webrtc/webaudio+
Rank: 29
|
||
Comment 1•9 years ago
|
||
I think doing it after the PC was created would be just as good as a global pool and would work out fine. Basic use case is when page is loaded, it creates a PC and a small pool of candidates. Then later when an call is made, it is all ready to go.
|
||
Comment 3•7 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•