- 25 Jun, 2020 1 commit
-
-
Nirbheek Chauhan authored
Windows ships with `WinSock2.h` but mingw ships with `winsock2.h`. This is fine on Windows because files are case-insensitive, but on Linux it causes the compiler to not find the header. All other #includes are lowercase, so just use that.
-
- 15 Jun, 2020 2 commits
-
-
Nirbheek Chauhan authored
-
Nirbheek Chauhan authored
We will always have either openssl or gnutls, which are better sources for random nonces. Also, CryptGenRandom is deprecated API that's not available on WinRT/UWP.
-
- 22 May, 2020 16 commits
-
-
Fabrice Bellet authored
This patch tries to move the component state from connected to ready in places where a pair may fail. Consequently, the final check done after the expiration of the idle timeout can be removed, assuming that transitions are done as soon as they occur. The only place where such a situation has been observed in a real world stress test is a 401 unauthorized stun error received in priv_map_reply_to_conn_check_request(), when the conncheck contains a local and a remote candidate, both of type host, with an identical IP address and port number (two boxes with a private network using the same subnet). In such a case, a stun request to the remote candidate will reach the local candidate instead, and will logically fail.
-
Olivier Crête authored
Meson always does out of tree builds
-
Olivier Crête authored
The stream and component pointers are always valid there.
-
Olivier Crête authored
-
Olivier Crête authored
They're always meson now.
-
Tim-Philipp Müller authored
Remove dist check on the CI, since it doesn't really add anything in the Meson case (tarball is based on files checked into git and srcdir != builddir).
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
meson already sets it on warning_level >= 2
-
Olivier Crête authored
The previous patch didn't get triggered
-
Olivier Crête authored
-
Olivier Crête authored
Older gtkdoc versions expect to find a Makefile, so generate a fake one with the information it wants.
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
-
- 19 May, 2020 1 commit
-
-
Fabrice Bellet authored
This patch reenables an interesting side effect that existed before commit 263c0903, when the state of a pair state in the triggered check list was changed to in-progress. Such "triggered" pairs with this state were selectively pruned from the conncheck list according to their priority in priv_prune_pending_checks(), meaning that pairs with a high priority were conserved, and quickly rechecked. Retrospectively, I suspect that this side effect was the initial motivation for changing the state of a "triggered" pair. Commit 263c0903 disabled that behaviour, for the sake of clarity, but it seems important to restore it, because these "triggered" pairs are often retriggered for a good reason, and frequently lead to a nominated pair. And loosing the opportunity to nominate a pair may be critical in controlled role when the peer agent is in aggressive nomination mode.
-
- 18 May, 2020 7 commits
-
-
Olivier Crête authored
The timeout has a weak ref that should be enough.
-
Olivier Crête authored
-
Fabrice Bellet authored
This patch ensures that the retransmit flag is more tightly in sync with the stun transaction list, by now clearing it when the list becomes empty. It makes the code a bit more readable by dropping some cases. In a couple of places, the retransmit flag was also used as a way to compare the priority of a pair and the priority of the selected pair.
-
Fabrice Bellet authored
When reactivating a high priority pair, we have to change back the component state from ready to connected, since there is a new pair to be tested. The case of the succeeded pair is also a bit simplified, the invocation of the function conn_check_update_check_list_state_for_ready() to complete the ready - connected - ready flip-flop transition is not required for the trickle test any longer.
-
Fabrice Bellet authored
This test is redundant with the previous one.
-
Fabrice Bellet authored
We prefer to not change the state of the pair, when it is added to the triggered check queue. Previously its state was changed to in-progress, which was a bit misleading, as it somewhat anticipated a future state.
-
Fabrice Bellet authored
Since commit fcd6bc86 a pair is not always created, when its priority is lower than the selected pair priority. We have to deal with this possibility when calling the function priv_add_new_check_pair(). More precisely, the component state update really requires the addition of a new pair.
-
- 14 May, 2020 3 commits
-
-
Fabrice Bellet authored
With this patch, we merge the two variables stun_sent and keep_timer_going. The three functions that are a possible source of a new stun request returns a boolean value stating if a request has been sent. The semantic of keep_timer_going can now be deduced from stun_sent and from the result of priv_conn_check_stream_nominate(). The trick that makes this merge possible is to repurpose the return value of priv_conn_check_tick_stream(), because keep_timer_going set when the conncheck list contains in-progress pairs in this function is redundant with the same check later in function priv_conn_check_tick_stream_nominate().
-
Fabrice Bellet authored
With this patch, we try to make more explicit the process order between the different types of stun requets, according that only one request is sent per callback timer tick, ie every 20ms, to respect the stun pacing of the spec. We implement the follow priority: * triggered checks * stun retransmissions * ordinary checks In a concrete case, while a stream has stun requests related to triggered checks to be sent, all other stun transactions are delayed to the next timer ticks. The goal of this patch is to make this priority explicit, and more easily swappable if needed. Triggered checks have more probability to succeed than stun retransmissions, this is the reason why they are handled before. Ordinary checks on the contrary can be performed on a lower priority basis, after all other stun requests. The problem that can be sometime observed with a large number of stun transactions is that stun retransmissions may suffer from a delay after they have reached their deadline. This delay should remain small thanks to the design of the initial retransmission timer (RTO), that takes into account the overall number of scheduled stun requests. It allows all stun requests to be sent and resent at a predefined "pacing" frequency without much extra delay. This ordering not perfect, because stun requests of a given type are examinated per-stream, by looking at the first stream before the others, so it introduces a natural priority for the first stream.
-
Olivier Crête authored
-
- 13 May, 2020 1 commit
-
-
Olivier Crête authored
-
- 12 May, 2020 1 commit
-
-
Olivier Crête authored
-
- 08 May, 2020 8 commits
-
-
Olivier Crête authored
Also, update the RFC numbers that are implemented.
-
Fabrice Bellet authored
In OC2007R2 compatibility mode, we observed the behaviour of a skype turn server, when returning code 300 (try-alternate) stun error on its tls connections. This value is returned apparently when the turn server is overloaded already. We noticed that the actual code in priv_handle_turn_alternate_server() cannot handle a non-udp turn server, because a tcp one would require to create a new socket. But, even when creating such a new socket stack (tcp-bsd socket + pseudossl socket), libnice still fails to establish a new connection to the alternate server on port 443, in a very systematic way. I'm not sure whether this problem is specific to this skype server infrastructure (the skype client fails in a similar way). Anyway, this code path works as expected with a non-microsoft turn server (tested with coturn).
-
Fabrice Bellet authored
A previous commit broke the logic used to start a discovery request for tcp turn servers. The ambiguity came from the distinction between the type of the turn server (turn->type), the compatibility of the transport of the local base candidate (turn_tcp), and the reliability of the underlying tcp socket (reliable_tcp). reliable_tcp indicates whether the turn allocate request should be "framed" in a tcp packet, according to RFC 4571. This is required in OC2007R2 only. This commit also puts the setup of the tcp turn socket in a separate function, because such setup is also required when handling try-alternate (code 300) stun errors on these tcp sockets, where we have to setup a new connection to another tcp turn server.
-
Fabrice Bellet authored
Relay candidates obtained from TLS turn server don't have to be refreshed in OC2007R2 compatibility mode.
-
Fabrice Bellet authored
-
Olivier Crête authored
-
Fabrice Bellet authored
This is more friendly with stun pacing.
-
Fabrice Bellet authored
-