Open
Bug 1195396
Opened 9 years ago
Updated 2 years ago
TCP gathering can drop candidates
Categories
(Core :: WebRTC: Networking, defect, P3)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox43 | --- | affected |
backlog | webrtc/webaudio+ |
People
(Reporter: drno, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-review-board-request
|
Details |
It looks like the idea of only creating a socket entry in nICEr for TCP active sockets, without a real network socket being created (they get created once a connection attempt from the active socket to a given target is started) is a bad idea as we don't know if the port number is actually available.
Here is how I think we should do it instead:
- at gathering internally allocate TCP active socket with port number 9
- I don't think that multiple sockets on port 9 should be duped, but double check
- at the time of requesting a connection from an active socket to a destination, then allocate a socket with an ephemeral port number (with the n-try loop like we do it at gathering time for passive and so sockets)
Updated•9 years ago
|
backlog: --- → webrtc/webaudio+
Rank: 25
Priority: -- → P2
Reporter | ||
Comment 1•9 years ago
|
||
Bug 1195396: create ephemeral sockets for TCP active on connect only
Comment 2•7 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Reporter | ||
Comment 3•6 years ago
|
||
I don't have the capacity any more to work on this any time soon.
Assignee: drno → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•