intro.xml

<?xml version="1.0" encoding="UTF-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
      xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
      xml:id="intro">
  <title>Introduction</title>

  <para>This quick start guide walks through the essential steps to
  build a working real-time communications platform with full support
  for federation with other autonomous domains over the public
  Internet.</para>

  <para>We show the essential steps first: setting up a TURN server,
  SIP proxy and an XMPP server.  Setting up an Asterisk or FreeSWITCH
  PBX is not essential, these are supplementary services that should
  be added in a later stage of the project.</para>

  <sect1 xml:id="into-federation">
    <title>Federation</title>

    <para>Federation enables direct and efficient communication between
    any two autonomous organizations connected to the public Internet.
    Email is already distributed thanks to SMTP federation.
    The same paradigm has taken hold in the world of voice and video
    communications.  Any two users or organisations can connect to each
    other dynamically without requiring cumbersome, outdated and expensive
    solutions from traditional phone companies.</para>

    <para>A number of technologies help make federation work optimally.
    ENUM helps map traditional phone numbers to Internet domains, it is
    described in <xref linkend="enum"/>.  DNS NAPTR and SRV records make it
    possible to locate servers willing to accept calls any given domain,
    they are described in <xref linkend="dns"/>.  The SIP and XMPP protocols
    allow users to do much more than they can do with traditional phones,
    including cost-effective chat messaging, desktop sharing and
    videoconferencing.</para>
  </sect1>

  <sect1 xml:id="intro-p2p">
    <title>Independent and decentralized alternatives to federation</title>

    <para>Federation takes a lot of power from the telephone industry
    and places more power and control in the hands of organizations and
    individuals who run their own servers.  This is generally a good thing
    for innovation, cost-efficiency, privacy and many other reasons.</para>

    <para>Critics of federation observe that while this model is not
    as tightly centralized as a traditional telephone network, it is built
    around a client-server model, leaving power in the hands of those who are
    able to operate the servers.  Like many Internet-based technologies,
    it also relies heavily on other centralized services:
    the DNS protocol and the certificate authorities.</para>

    <sect2>
      <title>Private networks</title>

      <para>Some operators have created private networks, where users
      can only call other users with the same softphone.  All the users
      communicate through a central server.  The operator chooses to
      locate the server in a location they believe to be secure and
      where they believe the risk of surveillance is low, such as
      Switzerland.</para>

      <para><link xlink:href="https://en.wikipedia.org/wiki/Signal_(software)">Signal</link>,
      the successor to RedPhone and TextSecure from Open Whisper Systems,
      operates through privately run servers.  Administrators of the servers
      are able to observe who is calling who but without knowing what they
      are saying.</para>
    </sect2>

    <sect2>
      <title>Decentralized networks</title>

      <para>Various solutions have begun to emerge in the hope of further
      eliminating these dependencies and offering a genuinely
      decentralized service.  In a truly decentralized service,
      the developer/founder of the service is not even able to see
      which users are calling each other, making it more secure
      than privately run services such as Signal.</para>

      <para>A fundamental issue for these alternatives is the addressing
      scheme.  Some rely on phone numbers and some of these solutions require
      their users to use an identifier other than a phone number, exchanging
      the identifiers in person or though some other communications channel.
      If phone numbers are used, it makes the service more convenient but
      this implies placing some trust in the phone numbering scheme operated
      by the telephone industry.
      </para>

      <para>Another fundamental issue for these services is bootstrapping:
      how the client finds other peer-to-peer participants the first
      time the user runs the software.  The current solution to this
      is usually a central server keeping a list of peers to seed the
      clients.</para>

      <para>Examples of some decentralized and peer-to-peer networks include
      the <link xlink:href="https://ring.cx">Ring softphone from
      Savoir Faire Linux</link>, using the
      <link xlink:href="https://github.com/savoirfairelinux/opendht">OpenDHT</link>
      network, the <link xlink:href="http://tox.chat/">Tox app</link>
      and the <link xlink:href="https://matrix.org/">Matrix.org</link>
      service.</para>
    </sect2>

    <sect2>
      <title>Conclusion</title>

      <para>While some of these alternatives are promising, none of them
      offers a silver bullet.  Private and decentralized services are
      only useful for specific purposes where two people know each other
      personally, such as calling a spouse, a physician calling a patient
      or a lawyer communicating with a client.</para>

      <para>For large organizations that deal with other large organizations
      and with the public in a less personal manner, the decentralized model
      is not universally applicable and a federated model is more likely to
      gain traction and meet operational needs.  That said, it is not
      uncommon for senior executives in some large corporations to seek
      out specialized communications solutions so they can have private
      conversations with each other and their closest advisors.</para>

      <para>Decentralized services are not mutually exclusive with
      federated RTC.  It is quite feasible for an organization to
      operate standard SIP or XMPP internally but setup a gateway at the
      edge of their network to accept calls from customers using
      alternative services.  The external user needs to have some way
      to be certain that their call is connected to an account
      controlled by the organization they want to contact and not
      an imposter or a man-in-the-middle who is relaying the call while
      monitoring it.
      </para>
    </sect2>
      
  </sect1>

  <sect1 xml:id="intro-sip-or-xmpp">
    <title>Choosing between SIP and XMPP</title>

    <para>The IETF has documented two standards for real-time communications
    that are widely implemented: SIP and XMPP.  XMPP is sometimes referred
    to as Jabber.</para>

    <para>This has left many system administrators pondering the question:
    which one do I need?</para>

    <para>Both SIP and XMPP can do all the same things.  SIP can make
    phone calls, video calls and instant messaging (IM) sessions.  XMPP can
    also make phone calls, video calls and IM sessions.  There has been a
    tendency to use SIP more for voice and use XMPP more for IM.</para>

    <para>Both have evolved into different markets.  SIP is particularly
    well supported by telecommunications vendors (for example, companies
    offering trunking to or from the PSTN) and manufacturers of related
    hardware, such as ISDN gateways.  Many larger corporate phone systems also
    have some kind of SIP interface.  XMPP has become very prominent as a
    system for federated IM and many companies have deployed it for this
    purpose without necessarily using it for voice and video.  Just as a
    significant number of voice related products and services use SIP, there
    is a significant quantity of high quality IM client software and
    third-party frameworks for interaction with XMPP and this has helped it
    remain dominant in the IM domain.</para>

    <para>In many cases, a SIP user ID and an XMPP user ID look identical,
    except for the URI prefix and both can be used to reach the same physical
    person.  For example, <literal>sip:alice@example.org</literal> and
    <literal>xmpp:alice@example.org</literal> both provide a means to contact
    the same fictitious Internet user prominent in so many of the IETF's
    publications.</para>

    <para>From the user's perspective, when they see an address without a
    scheme prefix such as <literal>sip:</literal> or <literal>xmpp:</literal>,
    they have no way to know if it is useful for email, SIP or XMPP and may
    have to manually try it in several applications.  Some users may not even
    realize that these different protocols exist for RTC and if the address
    doesn't appear to work in the first application where they try to use it,
    they make come to the conclusion that the address is invalid or the other
    person is unreachable.</para>

    <para>The overwhelming recommendation of the author of this guide and
    the software described here is that to maximise your chance of
    communicating with as many users as possible, <emphasis>you should operate
    both SIP and XMPP servers in parallel</emphasis>.</para>

    <para>Fortunately, some of the infrastructure for these servers (such
    as TURN servers and the X.509 certificates) can be shared by both
    protocols.</para>
  </sect1>

  <sect1 xml:id="intro-os-choice">
    <title>Choice of operating system</title>

    <para>RTC is possible using a range of operating systems, including
    those popular on desktop computers, servers and smartphones.  This guide
    does not recommend a specific operating system.  However, we believe that
    for people who want to mix and match individual packages, the most
    recent stable releases of popular GNU/Linux distributions,
    including Debian, Ubuntu and Fedora, provide a convenient way to get all
    the necessary software in ready-to-run packages.  For people
    who want a turn-key solution, it may be better to choose one of the
    self-installing or ready-to-run RTC or groupware solutions.</para>

    <sect2>
      <title>Using a ready-to-run or turn-key solution</title>
      <para>There are various turn-key solutions for building
      servers for RTC or generic office/groupware purposes.  These
      typically run off a live ISO image, provide a script to pre-install
      and configure packages or they are an image for a platform like
      Docker.</para>

      <para>Examples of these platforms include <link
      xlink:href="http://WikiSuite.org">WikiSuite</link> (based on
      RHEL) and <link xlink:href="https://www.turnkeylinux.org/">
      Turnkey Linux</link> (based on Debian).</para>
    </sect2>

    <sect2>
      <title>Using a generic GNU/Linux distribution</title>
      <para>Users of Red Hat Enterprise Linux, CentOS, openSUSE, SLES and
      other platforms may need to build the packages manually using
      <code>rpmbuild</code> as described in <xref linkend="rpmbuild"/>.</para>

      <para>Several of the components described in this guide have been
      tested on a much wider range of platforms.  The
      <emphasis>reSIProcate</emphasis> products, including the
      <emphasis>repro</emphasis> SIP proxy and <emphasis>reTurn</emphasis> TURN
      server, are extremely versatile and known to run successfully on Microsoft
      Windows, Apple OS, iOS, BSD variants, Android and several Linux based
      routers including OpenWRT, CeroWRT and DD-WRT.</para>
    </sect2>
  </sect1>

  <sect1 xml:id="intro-latest-versions">
    <title>Use latest software versions</title>

    <para>It is recommended that the latest software versions are used,
    especially for components such as the TURN server, SIP proxy and XMPP
    server as these components need to achieve connectivity with a wide range
    of peers on the public Internet.</para>

    <para>This does not imply using an unstable or beta version of your
    preferred Linux distribution, such as Debian <emphasis>sid</emphasis> or
    Fedora <emphasis>rawhide</emphasis>.  Rather, it is recommended that the
    current stable release of the operating system is used and the RTC
    components can then be installed from a source such as Debian's
    <emphasis>stable-backports</emphasis> or Red Hat's
    <emphasis>EPEL</emphasis>.</para>

    <para>Sometimes <emphasis>stable-backports</emphasis> or
    <emphasis>EPEL</emphasis> won't have the latest version of a particular
    package or you want to test some bleeding edge version of the package to
    see if it fixes a particular bug.  Many of the packages can be built
    manually from the source code.  All the leading RTC server projects make
    this very easy as they support tools like <code>debuild</code> for
    Debian/Ubuntu (see <xref linkend="debuild"/>) or <code>rpmbuild</code> for
    RedHat/CentOS/Fedora (see <xref linkend="rpmbuild"/>).</para>
  </sect1>

  <sect1 xml:id="intro-using-ipv6">
    <title>Using IPv6</title>

    <para>Now that IPv4 address space is fully allocated, it is highly
    desirable for organizations to include IPv6 when implementing any new
    network services.</para>

    <para>Therefore, both IPv4 and IPv6 are used in all examples
    throughout this guide.</para>

    <para>All of the recommended software products work on both IP
    versions.</para>

    <para>Everything in this guide will still work even if you only use
    IPv4 or IPv6 alone.</para>

    </sect1>

  <sect1 xml:id="intro-example-network">
    <title>Example network used in the documentation</title>

    <para>For the purposes of this guide, the following conventions are
    used:</para>

    <para>The DNS domain name is <emphasis>example.org</emphasis>.</para>

    <para>All the applications run on a server called
    <emphasis>server1.example.org</emphasis>.  In practice, you could run each
    service on a different server and you may duplicate services across
    multiple servers for <emphasis>N+1</emphasis> redundancy.</para>

    <para>The ICE/STUN process requires two public IPv4 addresses, either
    on the same interface or on different interfaces.  In the examples, the
    server has two IPv4 addresses on the same interface/subnet, they are
    <emphasis>198.51.100.19</emphasis> and <emphasis>198.51.100.20</emphasis>.
    These IP addresses come from the <link
    xlink:href="https://tools.ietf.org/html/rfc5737">RFC 5737 documentation
    subnets</link>.</para>

    <para>For IPv6, RFC 3849 reserves the address prefix
    <emphasis>2001:DB8::/32</emphasis> for documentation.  In the examples,
    <emphasis>server1.example.org</emphasis> uses the address
    <emphasis>2001:DB8:1000:2000::19/64</emphasis>.</para>

    <para>The users have existing email addresses such as
    <emphasis>first.last@example.org</emphasis> and will use the same
    addresses for both SIP and XMPP.</para>

    <para>The internal phone numbers are four digit extensions, such as
    <emphasis>8001</emphasis>, <emphasis>8002</emphasis> and
    <emphasis>8003</emphasis>.</para>
  </sect1>

</chapter>