[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs