1. 23 Mar, 2018 1 commit
    • Fabrice Bellet's avatar
      conncheck: rework early stun requests handling · ae3e5acc
      Fabrice Bellet authored
      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's avatarOlivier Crête <olivier.crete@collabora.com>
      Differential Revision: https://phabricator.freedesktop.org/D1889
  2. 05 Sep, 2017 1 commit
    • 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
  3. 21 Jun, 2017 4 commits
    • 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: 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
  4. 12 Jun, 2017 1 commit
    • Fabrice Bellet's avatar
      conncheck: implement ice regular nomination method · 0636f9ad
      Fabrice Bellet authored
      This patch implements Regular Nomation as described in RFC5245 The controlling agent lets valid pairs accumulate, and
      decides which pair to recheck with the use-candidate attribute set.
      priv_mark_pair_nominated() follows, to update the nominated
      pair when acting as a STUN server, and
      priv_map_reply_to_conn_check_request() implements 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 (, item #2)
      Differential Revision: https://phabricator.freedesktop.org/D811
  5. 11 Apr, 2017 1 commit
  6. 04 Apr, 2017 1 commit
  7. 27 May, 2016 3 commits
  8. 26 May, 2016 1 commit
    • Olivier Crête's avatar
      conncheck: Separate valid and succeded states · 1ab9d7c1
      Olivier Crête authored
      RFC 5245 specifies that when a mapped-address differs from the address
      from the request was sent, the mapped-address is used to select the
      valid pair, but the source address of the check is used to select the
      pair that succeeded, so they are not the same.
  9. 04 Apr, 2016 1 commit
  10. 01 Oct, 2015 2 commits
  11. 09 Oct, 2014 1 commit
  12. 22 Sep, 2014 1 commit
    • Philip Withnall's avatar
      agent: Remove dangling pointers on NiceSocket destruction · f6337b53
      Philip Withnall authored
      If a NiceSocket is destroyed, various pointers are currently left
      dangling to it in the conncheck state. These can cause crashes if (for
      example) a CandidateCheckPair with such a dangling pointer is then used;
      the GSocket methods will fail.
      Fix this by explicitly removing the socket and all NiceCandidates which
      wrap it from various areas of the state.
  13. 07 Jul, 2014 1 commit
  14. 15 May, 2014 2 commits
  15. 12 May, 2014 1 commit
    • Olivier Crête's avatar
      agent: Use 1280 instead of 65536 buffer size to send STUN Message · fe762161
      Olivier Crête authored
      RFC 5389 says:
         All STUN messages sent over UDP SHOULD be less than the path MTU, if
         known.  If the path MTU is unknown, messages SHOULD be the smaller of
         576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
         IPv6 [RFC2460].
      So sending 65536 bytes is always wrong
  16. 25 Apr, 2014 2 commits
  17. 30 Apr, 2012 1 commit
  18. 10 Feb, 2011 1 commit
  19. 31 Jan, 2011 1 commit
  20. 16 Feb, 2010 1 commit
  21. 16 Feb, 2009 1 commit
  22. 13 Nov, 2008 1 commit
    • Youness Alaoui's avatar
      remove the traffic_after_tick check because it caused problems with jingle. we... · c8d6d783
      Youness Alaoui authored
      remove the traffic_after_tick check because it caused problems with jingle. we need a tick every 25 seconds, but with that, the conncheck happens at 0s, and when the keepalive gets called @25s, it gets skipped and we only send our first keepalive after 50seconds... which means that jingle which stops processing if it doesn't receive a ping after 30 seconds, will stop playing our audio from 30 seconds to 50 seconds...
  23. 07 Oct, 2008 1 commit
  24. 30 Jul, 2008 1 commit
  25. 20 Jun, 2008 1 commit
  26. 27 May, 2008 1 commit
  27. 22 Apr, 2008 1 commit
  28. 26 Nov, 2007 1 commit
  29. 10 Oct, 2007 2 commits
  30. 11 Sep, 2007 1 commit
  31. 20 Jul, 2007 1 commit