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

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:

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

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.

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:

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)

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.

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:

Sample DNS entries for SIP and XMPP

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