- 15 May, 2014 40 commits
-
-
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
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
Now we will always give a handicap to UDP candidates, but still give relays the lower priority. We have the following priorities now : In reliable mode : TCP Host : 120 TCP peer-refl : 110 TCP nat-assist : 105 TCP srv-refl : 100 UDP Host : 60 UDP peer-refl : 55 UDP nat-assist : 52 UDP srv-refl : 50 TCP relay : 10 UDP relay : 5 In unreliable mode : UDP Host : 120 UDP peer-refl : 110 UDP nat-assist : 105 UDP srv-refl : 100 TCP Host : 60 TCP peer-refl : 55 TCP nat-assist : 52 TCP srv-refl : 50 UDP relay : 10 TCP relay : 5
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Jakub Adam authored
-
Jakub Adam authored
STUN_BINDING requests. Candidate check pair foundation was used - a combination of local and remote candidates' foundation, which does not correspond with [MS-ICE2] 2.2.2.1 0x8054 CANDIDATE-IDENTIFIER
-
Jakub Adam authored
At least temporary, maybe it is not used at all. TURN refresh messages were not seen in the packet capture.
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
One issue with tcp-bsd is that it will queue messages when the tcp socket is not writable, but it will also drop messages when the queue is full. If we want to do proper reliable ice-tcp, we need to make sure that messages don't get dropped, also, this would affect http/socks5/pseudossl if their messages get dropped. For ice-tcp, when the socket is not writable we want to return 0, not queue the message. The change here is to allow connchecks and other important protocol messages to be sent as 'reliable' on tcp transports by queuing them and in the various socket layers and to never drop them, but all user messages will be dropped. if the tcp socket is not writable.
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-