If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

TCP gathering can drop candidates

NEW
Assigned to

Status

()

Core
WebRTC: Networking
P3
normal
Rank:
25
2 years ago
11 days ago

People

(Reporter: drno, Assigned: drno)

Tracking

(Blocks: 2 bugs)

43 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox43 affected)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
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)
(Assignee)

Updated

2 years ago
Blocks: 1037618

Updated

2 years ago
backlog: --- → webrtc/webaudio+
Rank: 25
Priority: -- → P2
(Assignee)

Comment 1

2 years ago
Created attachment 8649576 [details]
MozReview Request: Bug 1195396: create ephemeral sockets for TCP active on connect only

Bug 1195396: create ephemeral sockets for TCP active on connect only
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.