Differences between revisions 17 and 18
Revision 17 as of 2014-01-26 19:31:37
Size: 8806
Editor: DanielPocock
Comment:
Revision 18 as of 2014-01-26 19:32:46
Size: 8915
Editor: DanielPocock
Comment:
Deletions are marked like this. Additions are marked like this.
Line 86: Line 86:
||[[http://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT|TURN server]]||2x IPv4 + 1x IPv6 (binding to port 443 on 1 of the IPv4 addresses and IPv6)||Needs a certificate, CN=gr.turn.debian.org (for cilea). Needs a list of H(A1) user passwords in a text file or SQL.||This is a media relay process, so users will notice latency > 100ms. Anticipate minimum 80kbps per concurrent user (including IP overhead).||
||SIP proxy||1x IPv4 + 1x IPv6 (binding to port 443 with both)||Needs a certificate, CN=debian.org or subjectAltName=debian.org. Needs a list of H(A1) user passwords in SQL.||SIP signalling is not excessively demanding on bandwidth or latency requirements. The process will have many concurrently active TCP connections and requires many file descriptors.||
||[[http://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT|TURN server]]||2x IPv4 + 1x IPv6 (binding to port 443 on 1 of the IPv4 addresses and IPv6) (TURN over TLS not live yet, just regular TURN over UDP on 3478)||Needs a certificate, CN=gr.turn.debian.org (for cilea). Needs a list of H(A1) user passwords in a text file or SQL.||This is a media relay process, so users will notice latency > 100ms. Anticipate minimum 80kbps per concurrent user (including IP overhead).||
||SIP proxy||1x IPv4 + 1x IPv6 (binding to port 443 with both) (not yet using 443, just regular port 5061)||Needs a certificate, CN=debian.org or subjectAltName=debian.org. Needs a list of H(A1) user passwords in SQL.||SIP signalling is not excessively demanding on bandwidth or latency requirements. The process will have many concurrently active TCP connections and requires many file descriptors.||

Introduction

These pages are about creating real-time communications services for use by the Debian Developer community. If you are not a Debian Developer and want to understand the packages available to Debian users, please see the main unified real-time communications pages.

Aims

  • to provide convenient solutions for DDs to use on an every day basis
  • to make better use of our communication packages
  • to become more familiar with how to build complete end-to-end solutions using 100% free software
  • to demonstrate Debian's commitment to this area is just as significant as in all our other infrastructure (wiki's, mailing list hosting, etc)

Phase 1: TURN server

The TURN server provides a convenient way to relay media streams when situated in a NAT/firewalled environment, on a mobile network, etc.

The TURN server is the very first step in this project because without it, the SIP and XMPP services will not work for some users, there will be one-way audio problems, etc and people will not have confidence in any of it.

The TURN server can be used with both XMPP (Jabber) and SIP. It can also be used for other things although XMPP and SIP are the most common. TURN has been selected as the mechanism for enabling WebRTC peer-to-peer communications between browsers so it is becoming increasingly prominent.

Action items:

  • choose servers (to minimise latency, probably need at least four: North America, South America, Europe, Asia)
  • assign IPv4 and IPv6 addresses
  • set up DNS entries
    • A, AAAA and/or CNAME records are essential
  • SRV records can be created but they are not widely used by any client yet, creating them is a good idea though
  • decide on a mechanism for exporting DD credentials to the servers (they require H(A1) hashed passwords, similar to Apache digest passwords)
    • it has been suggested that developers should have a secondary password for low-security services such as VoIP, not the same as their main Debian password
  • choose one of the server packages to use

Package

Comment

resiprocate-turn-server

from reSIProcate project, built using boost::asio C++ asynchronous programming style

rfc5766-turn-server

very popular with the WebRTC community now

turnserver

from the Jitsi community

  • configure the package
  • test with something like JsSIP tryit

    • pocock will provide a trivial testcase by putting a preconfigured JsSIP custom.js config file in his web server
    • all TURN activity is logged in the ?JavaScript console and should correspond to debug log output on the server side

Phase 2: SIP or XMPP server (or both)

This phase does not involve a full-featured PBX solution like Asterisk. It is simply about providing a basic SIP proxy or XMPP server to allow users to contact each other and the outside world.

  • choose one or two servers
  • assign IPv4 and IPv6 addresses
  • set up DNS entries (DNS examples)

    • A, AAAA, possibly CNAME
    • SRV and NAPTR records are also essential
  • decide on a mechanism for exporting DD credentials to the servers
    • SIP requires H(A1) hashed passwords, similar to Apache digest passwords
    • X.509 certificates can be used too, all SIP servers listed below support them, but only some client devices support client certs
    • it has been suggested that developers should have a secondary password for low-security services such as VoIP, not the same as their main Debian password
  • choose one of the server packages to use

Package

Technology

Comments

repro

SIP

from the reSIProcate project, supports WebRTC, very easy to configure, uses MySQL or RADIUS for authentication, Python scripting support for routing can be used to lookup forwarding address in LDAP, etc

kamailio

SIP

the most advanced successor of SIP Express Router (SER), wide community support, wide range of user database schemes supported, slightly more complicated configuration syntax (bespoke scripting language) although many working examples available

ejabberd

XMPP

Developed with erlang, very popular, can authenticate against LDAP

prosody

XMPP

Beyond phase 2

There are many possibilities. Phase 1 and 2 are the bare minimum to provide a useful service equivalent to Debian's email services. Anything else is optional and depends on the willingness of volunteers to setup and maintain it. Possible projects:

  • Using Jitsi Video Bridge as a conferencing solution in parallel with IRC

  • Sending SIP or XMPP chat messages when events occur (e.g. build failure, new RC bug in package, ...)
  • Using asterisk or FreeSWITCH to provide PBX services (e.g. voicemail)

  • A WebRTC portal for Debian Developers to make and receive calls with each other and any federated SIP/XMPP user

Specific hardware and IP address requirements

Process

IP addresses

security considerations

bandwidth considerations

TURN server

2x IPv4 + 1x IPv6 (binding to port 443 on 1 of the IPv4 addresses and IPv6) (TURN over TLS not live yet, just regular TURN over UDP on 3478)

Needs a certificate, CN=gr.turn.debian.org (for cilea). Needs a list of H(A1) user passwords in a text file or SQL.

This is a media relay process, so users will notice latency > 100ms. Anticipate minimum 80kbps per concurrent user (including IP overhead).

SIP proxy

1x IPv4 + 1x IPv6 (binding to port 443 with both) (not yet using 443, just regular port 5061)

Needs a certificate, CN=debian.org or subjectAltName=debian.org. Needs a list of H(A1) user passwords in SQL.

SIP signalling is not excessively demanding on bandwidth or latency requirements. The process will have many concurrently active TCP connections and requires many file descriptors.

SIP over ?WebSocket server for WebRTC

1x IPv4 + 1x IPv6 (binding to port 443 with both)

Needs a certificate, CN=sip-ws.debian.org or subjectAltName=sip-ws.debian.org. Needs a list of H(A1) user passwords in SQL.

SIP signalling is not excessively demanding on bandwidth or latency requirements. The process will have many concurrently active TCP connections and requires many file descriptors.

XMPP server

1x IPv4 + 1x IPv6 (binding to port 443 and 5269 with both)

Needs a certificate, CN=debian.org or subjectAltName=debian.org. Can authenticate users against LDAP

XMPP signalling is not excessively demanding on bandwidth or latency requirements. The process will have many concurrently active TCP connections and requires many file descriptors.

Some comments:

  • it may be desirable to have the XMPP and main SIP proxy on the same host to share a single TLS certificate file for the domain debian.org
  • for best performance, multiple TURN servers should be deployed (e.g. US, Europe, Asia, South America) to provide lower latency

Sample DNS entries for SIP and XMPP

See the http://www.rtcquickstart.org/dns-setup][examples on RTCQuickStart.org