[tor-bugs] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Sep 4 18:58:39 UTC 2019


#28942: Evaluate pion WebRTC
--------------------------------------------+------------------------------
 Reporter:  backkem                         |          Owner:  cohosh
     Type:  enhancement                     |         Status:  accepted
 Priority:  Medium                          |      Milestone:
Component:  Circumvention/Snowflake         |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:                                  |         Points:  5
 Reviewer:                                  |        Sponsor:
                                            |  Sponsor28-must
--------------------------------------------+------------------------------

Comment (by cohosh):

 Replying to [comment:54 cohosh]:
 > In addition to the issues above, which can be solved with the attached
 patch, the proxy is very slow to generate SDP answers causing the broker
 to timeout. Here are some logs:
 >
 > {{{
 > 2019/09/04 18:01:04 broker returns: 504
 > 2019/09/04 18:01:04 Received offer.
 > 2019/09/04 18:01:24 Setting remote description
 > 2019/09/04 18:01:24 sdp offer successfully received.
 > 2019/09/04 18:01:24 Generating answer...
 > 2019/09/04 18:01:24 error sending answer to client through broker:
 broker returned 410
 > }}}
 >
 > I added the {Received offer} log message
 [https://github.com/cohosh/snowflake/blob/pion/proxy-go/snowflake.go#L349
 here] as a local change.
 >
 > You can see that it takes 20 seconds between receiving the offer and
 generating an answer and after further instrumenting, it appears to be
 caused by the `NewPeerConnection` function
 [https://github.com/cohosh/snowflake/blob/pion/proxy-go/snowflake.go#L280
 here].

 > To be honest, starting ICE gathering in `NewPeerConnection` doesn't make
 sense to me from a design point of view. I would expect it to occur in
 `CreateAnswer` instead (with the trickle method it starts in
 `SetLocalDescription` which I also find unintuitive). The patch above also
 removes a call to `Gather` from `SetRemoteDescription` which also confused
 me.

 This turned out to be a local issue, but I still think it's a weird
 design.

 Now I'm back to the issues found in comment:49. The client successfully
 completes the rendezvous/signaling and then is failing to open the data
 channel (which causes the proxy to eventually time out and keep polling).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28942#comment:55>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list