Closed
Bug 867408
Opened 13 years ago
Closed 11 years ago
Ice candidates given to addIceCandidate should require either a mid or m-line index, but not both
Categories
(Core :: WebRTC: Networking, defect, P3)
Core
WebRTC: Networking
Tracking
()
RESOLVED
DUPLICATE
of bug 823512
| backlog | webrtc/webaudio+ |
People
(Reporter: jsmith, Unassigned)
References
()
Details
Per IRC in addIceCandidate:
if (!cand.candidate || !cand.sdpMLineIndex) {
throw new Components.Exception("Invalid candidate passed to addIceCandidate!");
}
This should be &&, not ||.
| Reporter | ||
Updated•13 years ago
|
Whiteboard: [WebRTC][blocking-webrtc-]
Comment 1•13 years ago
|
||
There's a second assumption here which is that valid sdpMLineIndex > 0, even though the spec says 0 is valid.
This invariant is currently guaranteed by the RTCIceCandidate constructor which adds +1, but while that works, it is wrong, because sdpMLineIndex is a readable, and apps reading it should get the same value they set.
Once we fix that (by pushing the +1 down into the implementation), then we'd want this condition to look more like this I think:
if (!cand.candidate && cand.sdpMLineIndex === undefined) {
throw new Components.Exception("Invalid candidate to addIceCandidate!");
}
Updated•12 years ago
|
Component: WebRTC → WebRTC: Networking
Comment 2•11 years ago
|
||
Is this fixed/irrelevant?
backlog: --- → webRTC+
Rank: 35
Flags: needinfo?(jib)
Priority: -- → P3
QA Contact: jsmith
Whiteboard: [WebRTC][blocking-webrtc-]
Comment 3•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(jib)
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•