Differences between revisions 2 and 3
Revision 2 as of 2014-01-17 08:19:31
Size: 2900
Editor: DanielPocock
Revision 3 as of 2014-01-17 08:27:42
Size: 2525
Editor: DanielPocock
Deletions are marked like this. Additions are marked like this.
Line 33: Line 33:
 * [[http://packages.debian.org/jitsi|Jitsi packages]] are in ''jessie'' and ''sid''
 * Here are screenshots and some tips:
  * Click the advanced button to get the connection parameters screen
   * Fill in the full authentication user field as demonstrated in the screenshot
   * Select the DTMF mode
   * Make sure that only TLS is selected in the general SIP settings, disable the legacy SSL modes as they are less secure and cause the handshake to fail with some proxies
 * See the [[UnifiedCommunications/DebianDevelopers/UserGuide/Jitsi|Jitsi screenshots]] for full details

Key details

  • Debian Developers have access to the following services

    • SIP Proxy
    • TURN server
  • You must create a real-time communications (RTC) password in the LDAP system

    • Do not use the same password that you use for any other Debian service. For example, you may want to cache the RTC password in a mobile device where there is a risk that it will be compromised.
    • Wait 30 minutes for the password to become active.
  • Your debian.org email address is also your SIP address

  • Your SIP software may try to use the user-part of the SIP address for authentication. It will not work.
    • In your SIP settings, look for an authentication username or auth user field. It is often blank by default.

    • Put your full SIP address, e.g. pocock@debian.org in this field

  • The same credentials are used for TURN

NAT traversal

  • NAT and firewalls have traditionally been a problem for free RTC software
  • For SIP itself, we only use TLS
    • This is a stream connection that is more likely to get through NAT than UDP
    • It can also potentially be tunnelled through proxies using the HTTP CONNECT method (port 443)
    • Some routers try to mangle SIP packets to help them through NAT, in practice this sometimes makes the problem worse
    • By using TLS, we ensure that no intermediate device will tamper with the packets, we aim to use industry standard ICE and TURN
  • The modern approach to this problem is the use of Internet Connectivity Establishment (ICE) and, as a last resort, relaying traffic through a TURN server
  • Not all SIP clients support TURN
    • Jitsi only supports TURN with Jabber, the SIP-TURN support is coming
    • Empathy only supports TURN through Google's proprietary TURN servers, but the TURN code could use any TURN server if configuration options were available. There is a bug report for this.
    • Only one end of the connection needs a TURN server for it to work though, as long as both support ICE.
  • The WebRTC demo site based on JSCommunicator does support both ICE and TURN and is pre-configured for Debian's TURN servers. Although the UI is very basic, there is a high probability that it can get through NAT in situations where the other SIP clients currently struggle.

Jitsi configuration