1. 28 Nov, 2017 4 commits
  2. 27 Nov, 2017 2 commits
  3. 12 Sep, 2017 3 commits
  4. 05 Sep, 2017 8 commits
    • Fabrice Bellet's avatar
      conncheck: change state before updating nominated pairs · 14102d44
      Fabrice Bellet authored
      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.
    • Fabrice Bellet's avatar
      conncheck: forgot to put a pair in triggered check list · 72dd26a3
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: update the state of triggered checks pairs · 6fe64fdb
      Fabrice Bellet authored
      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, "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
      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 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
      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
    • Fabrice Bellet's avatar
      conncheck: support several stun requests per pair · 36f306f4
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: use stun_timer_remainder less frequently · e860948b
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: make debug sentences more accurate · ce33747e
      Fabrice Bellet authored
      We add a helper function to print the pair state in-extenso.
      Differential Revision: https://phabricator.freedesktop.org/D1759
    • Fabrice Bellet's avatar
      conncheck: reorder some chunks of code · 25be0027
      Fabrice Bellet authored
      With this patch we simplify the levels of code indentation.
      Differential Revision: https://phabricator.freedesktop.org/D1758
    • Olivier Crête's avatar
      agent: Set error if it isn't set · 5a42089a
      Olivier Crête authored
  5. 22 Jun, 2017 2 commits
  6. 21 Jun, 2017 21 commits
    • Olivier Crête's avatar
      component: Use non-GClosure dummy callbacks · 63d273ce
      Olivier Crête authored
      GClosures are not that cheap to setup
    • Olivier Crête's avatar
    • Olivier Crête's avatar
      Repleace UNRELEASED with 0.1.15 · dcb0d647
      Olivier Crête authored
    • Olivier Crête's avatar
      agent: Adjust the nice_agent_new_full() to use flags · e3ddaa28
      Olivier Crête authored
      This makes it easier to read and more extensible.
    • Fabrice Bellet's avatar
      agent: remove spurious newlines · c7a5a92b
      Fabrice Bellet authored
      Differential Revision: https://phabricator.freedesktop.org/D1756
    • Fabrice Bellet's avatar
    • Fabrice Bellet's avatar
      agent: add new pairs only for gathering streams · 195db6b3
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: fix the component failed transition · 07366a5b
      Fabrice Bellet authored
      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."
       * sect "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
      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
      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
    • Fabrice Bellet's avatar
      conncheck: remove cancelled pair state · 95f8805e
      Fabrice Bellet authored
      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, 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
    • Fabrice Bellet's avatar
      conncheck: adjust recheck on timeout strategy · d516fca1
      Fabrice Bellet authored
      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 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
    • Fabrice Bellet's avatar
      conncheck: do not recheck a just succeeded pair · f19d209d
      Fabrice Bellet authored
      We cancel the potential in-progress transaction cancellation, caused by
      sect "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
    • Fabrice Bellet's avatar
      conncheck: fix a state transition case · 59fe4851
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: try to change earlier to state ready · 6a512b6e
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: dont cancel a pair for triggered check · 8fa648a1
      Fabrice Bellet authored
      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
      Differential Revision: https://phabricator.freedesktop.org/D933
    • Fabrice Bellet's avatar
      conncheck: remove a useless pair recheck · 11d4e37a
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: update the pair state in triggered check list · 25b3eeec
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: new pairs never have the nominated flag preset · afd8d41b
      Fabrice Bellet authored
      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
    • Fabrice Bellet's avatar
      conncheck: fix a nomination corner case · 3916b8bc
      Fabrice Bellet authored
      This patch add two supplementary cases, not covered by the ICE spec,
      sect "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
    • Fabrice Bellet's avatar
      conncheck: use the right pair when retriggering a check · 9103a5f2
      Fabrice Bellet authored
      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, "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
    • Fabrice Bellet's avatar
      conncheck: link succeeded and discovered pairs · 72ee528f
      Fabrice Bellet authored
      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, "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,
      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
    • Fabrice Bellet's avatar
      conncheck: improve triggered check of in-progress pairs · 2fd78084
      Fabrice Bellet authored
      This patch update the way triggered checks of in-progress pairs are
      handled, according to ICE spec, section 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
      Differential Revision: https://phabricator.freedesktop.org/D875