Opened 2 years ago

Last modified 3 months ago

#25591 assigned task

Pass STUN information from Broker to WebRTC Client

Reported by: arlolra Owned by: cohosh
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords:
Cc: dcf, arlolra, cohosh, phw Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor28

Description (last modified by cohosh)

The clients may be in filtered regions where common ICE servers may be unavailable.

May need to revise the Configuration interface of go-webrtc while figuring this part out.

Migrated from

We had some discussion in a recent meeting about the original intent of this ticket.

I think to address the need of "default STUN servers are blocked for the client", it would be more interesting to pursue ways in which NAT punching information for the client could be sent over the domain-fronted connection to the broker. Some discussion on #30579 laid out reasons why a more private way of getting ICE candidates is desirable.

Child Tickets

Change History (3)

comment:1 Changed 7 months ago by cohosh

Owner: set to cohosh
Status: newassigned

comment:2 Changed 7 months ago by cohosh

Cc: cohosh phw added
Description: modified (diff)
Sponsor: Sponsor28
Summary: Pass ICE server information from Broker to WebRTC ClientPass STUN information from Broker to WebRTC Client
Type: defecttask

comment:3 Changed 3 months ago by cohosh

In their MassBrowser paper, Nasr et al. claim to be able to determine which peers are behind symmetric NATs by running their own STUN server (Section V.A). I've reached out to ask how they do this. If we can get the broker working as a STUN server, this would be a neat way to help with the incompatible proxy problem (#33666).

Note: See TracTickets for help on using tickets.