1. 21 Jun, 2019 1 commit
  2. 20 Jun, 2019 1 commit
    • Sébastien Blin's avatar
      sip: negotiate both UDP and TCP for the control channel · e83a1006
      Sébastien Blin authored
      NOTE: SIP over TCP is disabled for now on Windows, waiting for
      TLS 1.3 support. To re-enable it, check the #ifdef _WIN32 in
      Our pjsip version supports the RFC6544. With this patch, when
      starting a call, the daemon is using two ICE sessions for the SIP
      channel. One is negotiating a UDP socket, and the other a TCP socket
      and transmits both SDP on the DHT.
      If both negotiations succeed, TCP is prefered and will be used
      to transmit SIP messages and the VCard. This should solve the 30
      seconds timeout on bad networks.
      Note that the media channel is still using UDP to transmit audio
      and video.
      MAJOR CHANGE: the SIP channel use TLS on top of TCP, no DTLS,
      so the transport is considered as reliable.
      Also lot of changes in rfc6544.patch to link to rfc6062. The patch
      needs to be cleaned, cf TODO notes
      Also this seems to fix the ICE shutdown at the end of the call
      (after the IDLE Timeout)
      Change-Id: I55c5f51377fd8787bc951d6d282eec46f8eaf977
      Gitlab: #103
      Gitlab: #108
  3. 18 Jun, 2019 1 commit
  4. 14 Jun, 2019 1 commit
  5. 13 Jun, 2019 1 commit
  6. 12 Jun, 2019 3 commits
  7. 11 Jun, 2019 4 commits
  8. 07 Jun, 2019 5 commits
  9. 05 Jun, 2019 1 commit
  10. 04 Jun, 2019 1 commit
  11. 03 Jun, 2019 1 commit
  12. 01 Jun, 2019 4 commits
  13. 31 May, 2019 5 commits
  14. 30 May, 2019 3 commits
    • Eden Abitbol's avatar
      upnp: Port mappings are not deleted upon IGD discovery anymore. · 852bd075
      Eden Abitbol authored
      Part of the discovery event handling for libupnp was to delete
      all port mappings associated with the local ip address of the
      application. I can only assume this was done to close pre-
      existing ports that were not properly closed when the application
      terminated. The problem with this logic is that since
      advertisements and discovery events are treated with the same
      switch case (fall through), the application was trying to close
      all the ports on the internet gateway everytime it got an
      advertisement. However, the application would then try to reopen
      the ports every time after closing them. And this would happen
      every five to ten seconds (i.e. whenever the application would
      catch and advertisement or discovery event from the internet
      To fix this quickly, I modified the way the event handling treats
      discovery and advertisement events. Instead of having a list based
      on the URL of the internet gateway, I use a list of it's unique
      service ID. That way, as soon as the event occurs, we check if
      we don't already have this service ID in our list. If we don't,
      then we proceed as usual. If we do, we exit the event handling
      since it's already been processed.
      The advertisement bye bye event has also been implemented. When
      this event occurs, the corresponding internet gateway devices are
      deleted from the lists.
      Gitlab: #96
      Change-Id: Idd8023eba319b431b3a9328ebe648e75d61b1dc8
    • Adrien Béraud's avatar
      string utils: cleanup · b7d723ec
      Adrien Béraud authored
      Change-Id: I31f6aa38b7773bc0ecbdeb4ba2ae556f3fd53cc3
    • Sébastien Blin's avatar
      contrib: bump pjproject · ebb5e5c1
      Sébastien Blin authored
      Now that RFC6062 is merged upstream, we can remove the patch from
      our stack. The API changed a bit, so this patch also updates
      turn_transport.cpp to follow changes
      Change-Id: If6e0bae8280d586b2e5fcb0babe83df8127789b6
  15. 27 May, 2019 2 commits
  16. 24 May, 2019 3 commits
  17. 23 May, 2019 1 commit
  18. 22 May, 2019 1 commit
  19. 20 May, 2019 1 commit