- 17 May, 2014 29 commits
-
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
The issue here was that there would be a new turn discovery for UDP and for TCP-ACTIVE host candidates and we'd get 2 relayed addresses with the same base_addr causing two relayed candidates to have the same foundation. This causes farstream to duplicate candidates since we only expose the foundation when we signal new-candidate. This will also help later for adding turn-tcp support.
-
Youness Alaoui authored
In the case of OC2007, we must consider that the turn control messages are framed with rfc4571 and udp-turn-over-tcp only adds a single guint16 to represent turn-control or end-to-end indication. Otherwise, we will have issues with double-framing when we do the allocate directly on the udp-turn-over-tcp but we'd have no framing once we add the udp-turn socket layer on top of udp-turn-over-tcp
-
Youness Alaoui authored
-
Youness Alaoui authored
With OC2007 compat, doing a recv on the attached socket (udp-turn-over-tcp) will cause the RFC4571 to be unframed before doing the parse_recv on the udp-turn socket, which will fail. And even if that didn't fail, it would still cause the resulting data to be rfc4571 since the unframing in the agent happens before the parse_recv
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
The UDP-TURN socket layer is only added at the end after we discover the relay candidate with Allocate, but until then, we use the UDP-TURN-OVER-TCP socket layer directly, so we need to do the rfc framing for that as well, otherwise, it won't work.
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
This is a massive commit that can't be split. We add ice-tcp support into the agent by creating local host tcp-active/tcp-passive candidates. We also need to find the local and remote candidates whenever we discover a peer-reflexive because their data is important to setup the peer-reflexive so a few changes were added to look for the local or remote candidate. For TCP-ACTIVE remote peer-reflexive candidates, we can't add conncheck pairs normally because TCP-PASSIVE (local) do not generate candidate pairs, and we also can't have a connection from any local host, so we can only create a single candidatepair with the local/remote that are connected. The pair->socket of a candidate check pair will hold the connected tcp socket (through connect for ACT or accept for PASS) and we will either have a remote or a local peer-reflexive which will create a new candidate pair, we cannot trigger checks on the initial candidate pair, we must only do it on the new check pairs. but in the case of a tcp-passive, we don't get a new local peer-reflexive candidate, so there is no new candidate with a new NiceSocket, so when we get a triggered check, we need to match it to the candidate check pair or when we select a pair, it will still use the original TCP-PASS socket. We must store the new connected tcp socket in the peer reflexive candidates since they represent that unique peer-reflx candidate's connection
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
In the case of TCP-ACTIVE, we don't have a problem, because the new socket will generate a peer-reflexive candidate with the right sockptr, and all sends will go through it, but for TCP-PASSIVE, there is no peer reflexive candidates, so once the pair is selected, the local candidate will point to the TCP-PASSIVE candidate with the TCP_PASSIVE socket type which will cause all sends to fail, so we need to proxy them to the child connections
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
Data and STUN messages sent over TCP MUST follow the framing method specified in [RFC4571] section 2. We will frame every outgoing packet and split it into 62KB frames when sending, and on reception, we will unframe the rfc4571. For now, we only unframe for udp-turn tcp-act/pass candidates, which means only for MS-TURN over TCP. We still need to do the unframing for real ice-tcp candidates, then add support for reading the data in a serialized way.
-
Youness Alaoui authored
Fixes Issue #1
-
Youness Alaoui authored
-
- 15 May, 2014 11 commits
-
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
The add_to_be_sent was duplicated in http/socks5/pseudossl/tcp-bsd and had some small differences. It's better to factor it out so bug fixes get applied to all of them and code is cleaner.
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
The TURN-TCP RFC is very different from TURN-UDP, the current turn and tcp-turn files were only for UDP TURN RFC and UDP TURN using TCP transport. When we implement TCP-TURN, we'll need a different algorithm, so I renamed the files and API to avoid any confusion.
-
Youness Alaoui authored
-
Youness Alaoui authored
test-fullmode: protect against ready->connected->ready state change and accept data reception on connected state
-