summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* conncheck: rework early stun requests handlingFabrice Bellet2018-03-233-145/+66
| | | | | | | | | | | | | | | | | | | | | | With this patch we simplify the code used to handle the incoming stun request when remote candidates or remote credentials have not been received yet. When the remote credentials is unknown, the stun request is stored in a list of incoming_checks for later processing, and no further processing is done, except responding to the request. When the remote credentials are received, the triggered checks for these incoming checks can now be queued, and the related pairs are created. If the remote candidates have not been received when the stun request on a valid local port arrives, a peer-reflexive remote candidate will be created. This candidate may need to be updated later when remote candidates are finally received, including candidate priority and foundation, and also related pairs. Reviewed-by: Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1889
* agent: Fixes incompatible pointer type warning on OSX.Jozsef Vass2018-03-221-1/+1
| | | | The variable tie is actually never read.
* conncheck: handle alternate-server for turn relays differentlyYouness Alaoui2017-11-281-13/+43
| | | | | | | If a relay gives us an alternate-server, we need to cancel and reset every candidate discovery attempt that uses the same server, to avoid ending up with one component on one server and the other component on another server (causing relay candidates with mismatched foundations).
* discovery: Increase discovery_unsched_items whenever we restart a checkYouness Alaoui2017-11-281-0/+4
| | | | | | The discovery_unsched_items is decremented every time a DiscoveryCandidate goes from non-pending to pending. So if we restart a check by setting pending to FALSE, we should re-increase the discovery_unsched_items.
* turn: Add support for ALTERNATE_SERVER in OC2007 CompatibilityYouness Alaoui2017-11-283-0/+29
| | | | | | | | | The MS Office TURN servers will always return the MS_ALTERNATE_SERVER in allocation responses, and if they are not handled, we end up using the main turn server to send allocation requests that then get sent to the alternate server which will return the XOR_MAPPED_ADDRESS containing the IP address of the turn server that proxied the message instead of our own actual external IP.
* conncheck: do not require that all streams have a connection check listMiguel París2017-11-283-23/+211
| | | | | | One or more streams might not have any connection check list if the number of streams differs from the peer agent. Differential Revision: https://phabricator.freedesktop.org/D1880
* Makefile: really enable debug for testsFabrice Bellet2017-11-271-1/+1
| | | | Differential Revision: https://phabricator.freedesktop.org/D1888
* agent: prevent external role change while conncheck is runningFabrice Bellet2017-11-273-3/+74
| | | | | | | | | With this patch, we stash the controlling mode property change, and apply it safely, when it won't interfere with an ongoing conncheck running. According to RFC5245, sect 5.2. "Determining Role", the role is determined for a session, and persists unless an ICE is restarted. Differential Revision: https://phabricator.freedesktop.org/D1887
* stun: Fix FD leak in test/utility codePhilip Withnall2017-09-121-7/+22
| | | | | | | | https://phabricator.freedesktop.org/T7798 Signed-off-by: Philip Withnall <withnall@endlessm.com> Reviewed-by: Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1819
* tests: Fix agent.h header inclusion in test-gstreamer.cPhilip Withnall2017-09-121-1/+1
| | | | | | Spotted by Lukas Gradl on the mailing list. Signed-off-by: Philip Withnall <withnall@endlessm.com>
* tests: Fix copyright dates in test-gstreamer.cPhilip Withnall2017-09-121-1/+1
| | | | | | This code is not 1000 years old. Signed-off-by: Philip Withnall <withnall@endlessm.com>
* conncheck: change state before updating nominated pairsFabrice Bellet2017-09-051-1/+1
| | | | | | When a pair is nominated while in state failed, we first move back to state connecting, then we update the selected pair, and finally we move to state connected.
* conncheck: forgot to put a pair in triggered check listFabrice Bellet2017-09-051-2/+4
| | | | | | | | | | When a new pair is created from an unknown remote candidate, it should be enqueue for a triggered check, to allow it to be marked as nominated on response arrival in priv_mark_pair_nominated(). Creating it in waiting state is not sufficient since the update in priv_mark_pair_nominated() from previous commits. Differential Revision: https://phabricator.freedesktop.org/D1763
* conncheck: update the state of triggered checks pairsFabrice Bellet2017-09-051-71/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this patch, we fix an ambiguity of some parts of the spec, when the document refers to in-progress pairs, that also concern pairs in the triggered checks list. The first cast is in section 7.1.2.5, "Updating the Nominated Flag", when the in-progress pair will be nominated on response arrival. This is handled in function priv_mark_pair_nominated(), when a pair is put to the triggered check list in reaction to a matching inbound stun request. Such a pair in priv_mark_pair_nominated() will _always_ be in the triggered check list, from the previously called function priv_schedule_triggered_check(). The second case is in section 8.1.2, "Updating State" when an in-progress pair stops its retransmission when another pair of higher priority is already nominated. This is handled by function priv_prune_pending_checks(). Until now, pairs enqueued in the triggered check list move transiently to state waiting, according to 7.2.1.4. But this state causes wrong decisions in the two previous cases, because such pairs should in fact rather be considered "like in-progress", to avoid discarding them inadvertantly. This patch update the state of the triggered check list pairs to in-progress. It allows to remove exception handling cited above: the code is a bit more simple, and allows some refactoring in priv_mark_pair_nominated() between RFC and compatibility modes. Differential Revision: https://phabricator.freedesktop.org/D1762
* conncheck: support several stun requests per pairFabrice Bellet2017-09-052-361/+361
| | | | | | | | | | | | This patch should improve the reliabily of the connection check by keeping the record of several simultaneous ongoing stun requests per pair. A new stun request on an in-progress pair typically is caused by in inbound stun request from the peer on this same pair. This is named "Triggered Checks" in the spec. When this situation arises, it is fair to handle these two stun requests simultaneously, the triggered check, and the initial ordinary check, since both can potentially succeed. Differential Revision: https://phabricator.freedesktop.org/D1761
* conncheck: use stun_timer_remainder less frequentlyFabrice Bellet2017-09-051-29/+48
| | | | | | | | We try to use stun_timer_remainder() less frequently, particularily in the debug messages, and favour of the next_tick value associated to the pair. Differential Revision: https://phabricator.freedesktop.org/D1760
* conncheck: make debug sentences more accurateFabrice Bellet2017-09-051-9/+61
| | | | | | We add a helper function to print the pair state in-extenso. Differential Revision: https://phabricator.freedesktop.org/D1759
* conncheck: reorder some chunks of codeFabrice Bellet2017-09-051-436/+422
| | | | | | With this patch we simplify the levels of code indentation. Differential Revision: https://phabricator.freedesktop.org/D1758
* agent: Set error if it isn't setOlivier Crête2017-09-051-1/+1
|
* conncheck: improve role conflict debugFabrice Bellet2017-06-221-5/+19
| | | | | | | This patch displays explicitely the controlling or controlled role of the agent. Differential Revision: https://phabricator.freedesktop.org/D874
* configure: Remove -Wswitch-enumOlivier Crête2017-06-211-1/+0
| | | | | | Creates useless warnings when other libraries change. https://phabricator.freedesktop.org/T7770
* component: Use non-GClosure dummy callbacksOlivier Crête2017-06-211-3/+15
| | | | GClosures are not that cheap to setup
* agent: Don't crash if recv cancelled without a GErrorOlivier Crête2017-06-211-1/+4
|
* Repleace UNRELEASED with 0.1.15Olivier Crête2017-06-212-7/+7
|
* agent: Adjust the nice_agent_new_full() to use flagsOlivier Crête2017-06-213-13/+31
| | | | This makes it easier to read and more extensible.
* agent: remove spurious newlinesFabrice Bellet2017-06-212-2/+2
| | | | Differential Revision: https://phabricator.freedesktop.org/D1756
* stun: fix gcc7 implicit fallthrough warningFabrice Bellet2017-06-211-0/+1
| | | | Differential Revision: https://phabricator.freedesktop.org/D1754
* agent: add new pairs only for gathering streamsFabrice Bellet2017-06-211-0/+11
| | | | | | | | | | | | | | At the end of the local candidate gathering process, we only create new pairs for streams that are in gathering state. Other stream that may be in ready state for example, due to a previously succeeded conncheck process, may have accumulated some couples (local,remote) candidates that have not resulted in the creation a new pair during this previous conncheck process, and we don't want these new pairs to be added now, because it would generate unneeded transition changes for a stream unconcerned by this gathering. Differential Revision: https://phabricator.freedesktop.org/D1755
* conncheck: fix the component failed transitionFabrice Bellet2017-06-212-14/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the transition of a component from connecting to failed, that previously occured due to the propagation of the keep_timer_going variable, and to the final call to function priv_update_check_list_failed_components(), after the global agent timer was stopped. Previously, the code almost never entered to failed state, because the timer was going one, as long as the number of nominated pair was not enough, and as long as there were valid pairs not yet nominated. Even if all pair timers were over. The definition of the Failed state of a conncheck list is somewhat contradictory in the spec, depending on weather you read : * sect 5.7.4. "Computing States", "Failed: In this state, the ICE checks have not completed successfully for this media stream." or * sect 7.1.3.3. "Check List and Timer State Updates", "If all of the pairs in the check list are now either in the Failed or Succeeded state: If there is not a pair in the valid list for each component of the media stream, the state of the check list is set to Failed." Our understanding of the ICE spec is that, the proper way to enter failed state instead in when all connchecks have no longer in-progress pairs. All pairs are either in state succeeded, discovered, or failed. No timer is still running, and we have no hope that the conncheck list changes again, except if an unexpected STUN packet arrives later. All pairs in frozen state is a special case, that is handled separately (sect 7.1.3.3). A special grace delay is added before declaring a component in state Failed. This delay is not part of the RFC, and it is aimed to limit the cases when a conncheck list is reactivated just after it's been declared failed, causing a user visible transition from connecting to failed, and back from failed to connecting again. This is also required by the test suite, that counts exactly the number of time each state is entered, and doesn't expect these transcient failed states to happen (frequent due to the nature of the testsuite, less frequent in real life). Differential Revision: https://phabricator.freedesktop.org/D1111
* conncheck: remove cancelled pair stateFabrice Bellet2017-06-212-68/+77
| | | | | | | | | | | | | | | | | | | | | | | | Pairs with the state NICE_CHECK_CANCELLED are the pairs targeted for removal after the nomination of a pair with an higher priority, described in Section 8.1.2 "Updating States", item 2 of RFC 5245. They include also pairs that overflow the conncheck list size, but this is a somewhat more marginal situation. So we are mainly interested in the first use case of this state. This state mixes two different situations, that deserve a distinct handling : on one side, there are waiting or frozen pairs that must be removed, this is an immediate action that doesn't need a dedicated state for that. And on the other side, there are in-progress pairs that should no longer be retransmitted, because another pair with a higher priority has already been nominated. This patch removes the cancelled state, and adds a flag retransmit_on_timeout to deal with this last situation. Note that this case should not generate a triggered check, as per described in section 7.2.1.4, when the state of the pair is In-Progress or Failed, since this pair of lower priority has no hope to replace the nominated one. Differential Revision: https://phabricator.freedesktop.org/D1114
* conncheck: adjust recheck on timeout strategyFabrice Bellet2017-06-211-4/+26
| | | | | | | | | | | | | | | | | | The pair recheck on timeout can easily cause repetitive rechecks in a ping-pong effect, if both peers with the same behaviour try to check the same pair almost simultaneously, and if the network rtt is greater than the initial timer rto. The reply to the initial stun request may arrive after the in-progress conncheck cancellation (described in RFC 5245, sect 7.2.1.4). Cancellation creates a new stun request, and forgets the initial one. The conncheck timer is restarted with the same initial value, so the same situation happens again later. We choose to avoid resetting the timer in such situation. After enough retransmissions, the timeout delay, that doubles after each timeout, becomes longer than the rtt, and the stun reply can be handled. Differential Revision: https://phabricator.freedesktop.org/D1115
* conncheck: do not recheck a just succeeded pairFabrice Bellet2017-06-211-0/+12
| | | | | | | | | | We cancel the potential in-progress transaction cancellation, caused by sect 7.2.1.4 "Triggered Checks", when we receive a valid reply before transmission timeout, or just after timeout, when the pair is temporarily put on the triggered check list on the way to be rechecked. This situation is not covered by the RFC 5245. Differential Revision: https://phabricator.freedesktop.org/D1119
* conncheck: fix a state transition caseFabrice Bellet2017-06-211-5/+16
| | | | | | | | | | | | | When a new stun request hits a valid pair, of a failed component, we may have a transition from state failed to connected. In this situation, we do a logical progression failed -> connecting -> connected, like we do in function priv_update_check_list_state_for_ready() Similarily, when a new stun request hits a failed pair, of a failed component, triggering a new conncheck for this pair may also cause the component state to move back from failed to connecting state. Differential Revision: https://phabricator.freedesktop.org/D1118
* conncheck: try to change earlier to state readyFabrice Bellet2017-06-211-0/+11
| | | | | | | | | | | | We check if we can move from state connected to ready just after a pair expired its retransmission count. This pair will be marked failed, and will no longer be in-progress. The number of in-progress dropping down to zero is one of the conditions needed to make the transition to ready, per component (and not globally as it's the case in other locations where this check function is called). Differential Revision: https://phabricator.freedesktop.org/D1117
* conncheck: dont cancel a pair for triggered checkFabrice Bellet2017-06-211-16/+32
| | | | | | | | | | | | This patch adds another supplementary "corner" case, not covered by the ICE spec, sect 8.1.2, "Updating States". A pair in waiting state and in the triggered check list should be considered like an in-progress pair, and cancelled only if its priority is lower than the priority of the nominated pair. This is required in some aggressive nomination situations for both peers to select the same pair, having the highest priority. Differential Revision: https://phabricator.freedesktop.org/D933
* conncheck: remove a useless pair recheckFabrice Bellet2017-06-211-17/+0
| | | | | | | | This exception to the ICE spec is no longer needed: when a pair is in the succeeded state, there is no needed to recheck it again upon reception of an incoming stun request on it. Differential Revision: https://phabricator.freedesktop.org/D884
* conncheck: update the pair state in triggered check listFabrice Bellet2017-06-211-24/+9
| | | | | | | | | | | With this patch, we update the state of the pair to waiting when it is put in the triggered check queue. We also take care to call priv_schedule_triggered_check() before priv_mark_pair_nominated() so a pair to be rechecked and put on the triggered check queue will have a unique state to be tested in the following call to priv_mark_pair_nominated() when evaluating its nomination attributes. Differential Revision: https://phabricator.freedesktop.org/D883
* conncheck: new pairs never have the nominated flag presetFabrice Bellet2017-06-211-10/+11
| | | | | | | | | | | | | This patch disables the possibility to set the nominated flag of a candidate pair at creation time. This possibility was used when a new pair is created from a new peer reflexive remote candidate, when the agent is in controlled mode, and an stun request with USE-CANDIDATE is received. In this case, since previous commit "conncheck: fix a nomination corner case", we set the nominated flag when the stun response of this new pair will arrive, and not before. Consequently, this flag is no longer required when the pair is created. Differential Revision: https://phabricator.freedesktop.org/D881
* conncheck: fix a nomination corner caseFabrice Bellet2017-06-211-2/+33
| | | | | | | | | | | | This patch add two supplementary cases, not covered by the ICE spec, sect 7.2.1.5 "Updating the Nominated Flag" when a controlled agent receives a STUN request with the USE-CANDIDATE flag, for a pair that is in the waiting state. We consider that this case is similar to the in-progress state, and should be handled in the same way. We also accept when the pair is in frozen state. This latter case happens in the new-dribble test, when an agent replays incoming early connchecks. Differential Revision: https://phabricator.freedesktop.org/D880
* conncheck: use the right pair when retriggering a checkFabrice Bellet2017-06-212-3/+19
| | | | | | | | | | | | This patch completes the previous patch by adding a link back from the discovered pair, to the parent pair that generated this check. This link is needed by the ICE spec, to comply with section 8.1.1.1, "Regular nomination", where the check to be retriggered is the initial check that caused the discovery of the valid pair. When the valid pair is a peer-reflexive pair, the retriggered check must target the succeeded pair, and not the valid discovered pair. Differential Revision: https://phabricator.freedesktop.org/D879
* conncheck: link succeeded and discovered pairsFabrice Bellet2017-06-212-0/+8
| | | | | | | | | | | | | | | When the agent has the role of the stun server, is in controlled mode, and receives a pair with the "use-candidate" attribute set, it must find a matching succeded or discovered pair in its conncheck list. This is described in ICE spec 7.2.1.5, "Updating the Nominated Flag", item #1. When a matching pair is in succeeded state, the agent must nominate the valid pair (a discovered pair) constructed from section 7.1.3.2.2, that's been created from this succeeded one. To make this lookup, we introduce a new "discovered_pair" member of the CandidateCheckPair struct, that links the succeeded pair, and its discovered pair if any. Differential Revision: https://phabricator.freedesktop.org/D878
* conncheck: improve triggered check of in-progress pairsFabrice Bellet2017-06-212-16/+74
| | | | | | | | | | | | | This patch update the way triggered checks of in-progress pairs are handled, according to ICE spec, section 7.2.1.4. Previously the same connection check was retransmitted with an updated timeout. This causes problems when a controlling role switch occurs in this time frame. This is the reason why a new connection check must be generated reflecting the updated role. We introduce a new flag "recheck_on_timeout" in the pair indicating that the pair must be rechecked at the next timer expiration. Differential Revision: https://phabricator.freedesktop.org/D875
* conncheck: invoke the debug dump in more placesFabrice Bellet2017-06-121-0/+6
| | | | Differential Revision: https://phabricator.freedesktop.org/D1123
* conncheck: improve the selection of the pairs to be checkedFabrice Bellet2017-06-123-178/+381
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch aims to implement more closely the algorithm described in RFC 5245 indicating how pairs are transitionned from state Frozen to Waiting. This is described in 7.1.3.2 when a check succeeded, and correspond to modifications in function priv_conn_check_unfreeze_related(). This is also described in 5.7.4 when defining the initial state of the pairs in a conncheck, and correspond to modifications in function priv_conn_check_unfreeze_next(). This patch introduces the notion of active and frozen check list. It allows us to define the timer restranmission delay as described in 16.1. Another modification in priv_conn_check_tick_unlocked() is that every stream in handled consecutively, and in an independant way. The pacing was previously of a single STUN request emitted per callback, it is now of a triggered check per callback OR a single STUN per callback AND per stream per callback. The description of ordinary checks per stream in 5.8 is detailled in function priv_conn_check_tick_stream(), and a remaining of the code used to nominate a pair by the controlling agent is put in a dedicated function priv_conn_check_tick_stream_nominate() Differential Revision: https://phabricator.freedesktop.org/D813
* conncheck: update pair valid property selectivelyFabrice Bellet2017-06-121-5/+13
| | | | | | | | | With this patch, we fix a corner case when the succeeded pair is a peer-reflexive candidate pair, that already has been discovered previously, In this case, the current pair -p- should not be marked valid, because the valid flag is already set on the discovered pair. Differential Revision: https://phabricator.freedesktop.org/D1124
* test-nomination: added a new test for the nomination modeFabrice Bellet2017-06-123-1/+268
| | | | Differential Revision: https://phabricator.freedesktop.org/D1107
* conncheck: implement ice regular nomination methodFabrice Bellet2017-06-128-7/+309
| | | | | | | | | | | | | | | | | | | | | | | | | This patch implements Regular Nomation as described in RFC5245 8.1.1.1. The controlling agent lets valid pairs accumulate, and decides which pair to recheck with the use-candidate attribute set. priv_mark_pair_nominated() follows 7.2.1.5, to update the nominated pair when acting as a STUN server, and priv_map_reply_to_conn_check_request() implements 7.1.3.2.4 to update the nominated pair when acting as a STUN client. A new property is also added to the agent to control the nomination mode, which can be regular of aggressive, with default value set to aggressive. Two new flags are introduced in the CandidateCheckPair structure: - use_candidate_on_next_check indicates the STUN client to add the use-candidate attribute when the pair will be checked. At this time, the nominated flag has not been set on this pair yet. - mark_nominated_on_response_arrival indicates the STUN server to nominate the pair when its succesfull response to a previous triggered check will arrive (7.2.1.5, item #2) Differential Revision: https://phabricator.freedesktop.org/D811
* conncheck: fix pair state transition when successful response is receivedFabrice Bellet2017-06-121-4/+13
| | | | | | | | According the ICE RFC 5245, 7.1.3.2.3, the pair that *generated* a successful check should go to state succeeded, not only the valid pair built in section 7.1.3.2.2. Differential Revision: https://phabricator.freedesktop.org/D810
* conncheck: peer reflexive candidates are not pairedFabrice Bellet2017-06-121-0/+21
| | | | | | | | | This patch makes the code compliant with ICE RFC, 7.2.1.3 "Learning Peer Reflexive Candidates" and 7.1.3.2.1 "Discovering Peer Reflexive Candidates", where discovered candidates do not cause the creation of new pairs to be checked. Differential Revision: https://phabricator.freedesktop.org/D805
* conncheck: update selected pair when nominated flag is setFabrice Bellet2017-06-121-1/+3
| | | | | | | | | | | | This modifies commit 8f1f615. It is better focused to update the selected pair just after its nominated flag has been set. We also keep the code homogeneous with other places, where the call to priv_update_selected_pair() immediately follows the setting of pair->nominated. Moreover in priv_update_check_list_state_for_ready(), we would call priv_update_selected_pair() more times that necessary when iterating on all nominated pairs. Differential Revision: https://phabricator.freedesktop.org/D1125