rtc-architecture.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="rtc-architecture">
  <title>Architecture overview</title>

  <para>This chapter gives a high-level overview of the RTC architecture.
  Each component is explained in more detail in its own chapter.</para>

  <sect1 xml:id="rtc-architecture-big-picture">
    <title>The big picture</title>
    <figure float="none" xml:id="arch-dia-1">
      <title>Overview</title>
  
      <mediaobject>
        <imageobject role="print">
          <imagedata fileref="figs/svg/arch-overview.svg" width="5in"
            format="SVG" />
        </imageobject>
  
        <imageobject role="web">
          <imagedata fileref="figs/svg/arch-overview.svg"
            format="SVG" />
        </imageobject>
      </mediaobject>
    </figure>

    <para><xref linkend="arch-dia-1"/> demonstrates each of the components
    and how they are interconnected.  The diagram includes an example of
    an external softphone user calling an internal softphone user, the call
    is setup with SIP and the RTP media streams (dotted lines) pass through
    the TURN server.</para>

    <sect2 xml:id="rtc-architecture-use-tls">
      <title>TLS is essential</title>

      <para>SIP, XMPP and WebSockets can be easily configured to run without
      TLS encryption.  Unfortunately, doing so would lead to many of the
      same problems as email, including spam and impersonation.</para>

      <para>Impersonation is even more troublesome in RTC than in an email
      exchange.  If a user replies to an email with a forged
      <literal>From</literal> header, the reply will go to the person
      who was impersonated.  The imposter is unable to receive replies to
      the emails they send.  If a user answers a phone call from a forged SIP
      address, however, they are immediately engaged in two-way communication
      with the imposter.</para>

      <para>Therefore, when RTC protocols are used on the public Internet,
      TLS should always be used.  Additional reasons for using TLS are
      discussed in <xref linkend="optimal-connectivity-tls"/>.</para>

      <para>SMTP is a much older protocol than SIP and XMPP and while it
      does now boast support for STARTTLS,
      <link xlink:href="http://tools.ietf.org/html/rfc6125#appendix-B.4">
      it doesn't clearly specify a mechanism for validation of message
      headers against the certificates</link>.</para>
    </sect2>

    <sect2 xml:id="rtc-architecture-sip-proxy">
      <title>All SIP connectivity through a SIP proxy</title>
      <para>The SIP proxy acts as a router between the external peers,
      internal peers and the soft PBX.  The soft PBX is typically a server
      running Asterisk or FreeSWITCH.  It is important to note that the
      soft PBX does not connect directly to the public Internet and none of
      the internal users connect directly to the soft PBX.</para>

      <para>SIP proxy servers are generally more stable and more secure than
      soft PBXes.  SIP proxy servers typically have more
      connectivity options, including best-of-breed support for IPv6, TLS
      and WebRTC.  In particular, the Asterisk PBX advertises support for TLS
      but it doesn't support mutual TLS certificate verification, something
      that works seamlessly in the SIP proxy <emphasis>repro</emphasis>.
      This means that Asterisk accepts TLS connections from users and other
      servers but is unable to verify local devices with built-in certificates
      such as Polycom phones.  If Asterisk is configured to accept TLS
      connections from the public Internet, Asterisk accepts any call from
      the peer without validating the domain in the <literal>From</literal>
      header.</para>

      <para>Soft PBXes tend to have many more features and vastly
      more configuration options, this also means upgrades to the SIP proxy
      are relatively easy compared to upgrades of the soft PBX.  Finally,
      some people like to be able to make configuration changes to their PBX
      during business hours.  If users are maintaining connections and
      SIP registrations through the SIP proxy, they are much less likely to
      notice if the soft PBX is restarted or crashes.</para>

      <para>One consequence of this design strategy is that it is usually
      best to install, test and configure the SIP proxy before starting
      a soft PBX installation.  In this guide, SIP proxy installation is
      covered in <xref linkend="sip-proxy"/> and soft PBXes are discussed
      in <xref linkend="pbx"/>.</para>
    </sect2>
  </sect1>

  <sect1 xml:id="rtc-architecture-federation-sip">
    <title>SIP federation between two autonomous sites</title>

    <figure float="none" xml:id="arch-dia-fed-sip">
      <title>SIP federation between two sites</title>
  
      <mediaobject>
        <imageobject role="print">
          <imagedata fileref="figs/svg/arch-fed-sip.svg" width="5in"
            format="SVG" />
        </imageobject>
  
        <imageobject role="web">
          <imagedata fileref="figs/svg/arch-fed-sip.svg"
            format="SVG" />
        </imageobject>
      </mediaobject>
    </figure>

    <para><xref linkend="arch-dia-fed-sip"/> emphasizes those components
    that are involved in routing a federated SIP call from one site,
    <emphasis>example.org</emphasis>, to another site,
    <emphasis>example.edu</emphasis>.  For simplicity, this diagram does
    not show the firewalls, soft PBX or other components.  Assuming the
    softphone users are both using NAT addresses, the TURN servers may be
    relaying all the media streams on their behalf.</para>
  </sect1>

  <sect1 xml:id="rtc-architecture-routing">
    <title>Routing calls within a site</title>

    <figure float="none" xml:id="arch-dia-routing">
      <title>Four stages of call routing</title>

      <mediaobject>
        <imageobject role="print">
          <imagedata fileref="figs/svg/arch-routing.svg" width="5in"
            format="SVG" />
        </imageobject>

        <imageobject role="web">
          <imagedata fileref="figs/svg/arch-routing.svg"
            format="SVG" />
        </imageobject>
      </mediaobject>
    </figure>

    <para>If you have just started looking at the configuration
    of a SIP proxy or soft PBX, you have probably observed that the
    scripting languages provide almost infinite flexibility to
    route the calls in different ways.  If you have been working
    with such configurations for a while, you may have seen some that
    have become tremendously convoluted.</para>

    <para><xref linkend="arch-dia-routing"/> demonstrates
    a high-level approach to routing calls within your site, whether
    you are using a single SIP proxy or soft PBX or a combination
    of different components.</para>

    <para>There are four general stages.</para>

    <para>All calls, whether they come from SIP trunking providers, ISDN
    or local users should start in an <emphasis>ingress</emphasis> stage.
    The goal of the <emphasis>ingress</emphasis> stage is simply
    normalizing the numbers into a standard form that will be
    useful in all further stages of call processing.  For example, if
    calls are coming in over an ISDN connection the provider may only
    be sending the last six digits of each destination DDI that
    has been dialed.  The <emphasis>ingress</emphasis> stage handling
    calls from this ISDN circuit adds the country code and other
    leading digits to normalize the numbers in the E.164 format
    (see <xref linkend="pstn"/> for more specific details about
    this type of <emphasis>ingress</emphasis> handling).</para>

    <para>When calls are sent to their final destination, whether it is
    a SIP trunking provider, ISDN circuit or a local user, the
    final stage it should go through is an <emphasis>egress</emphasis>
    stage.  The format of the number/address usually needs to be
    modified again in the <emphasis>egress</emphasis> stage.  For example,
    some providers expect E.164 numbers to have a 00 prefix, as this is
    the dialing prefix many countries use to call international numbers.
    </para>

    <para>Many deployments involve some services where calls are handled by
    an application.  This is the <emphasis>application</emphasis> stage.
    These applications are typically voicemail services, call queues
    and DTMF-driven menus.</para>

    <para>Finally, all these stages are joined together by a
    <emphasis>routing</emphasis> stage.  The routing stage accepts calls
    from the <emphasis>ingress</emphasis> stage, considers both the
    source of the call and the desired destination (both of which
    have been normalized already) and decides where to send them in
    the <emphasis>egress</emphasis> and <emphasis>application</emphasis>
    stages.</para>

    <para>All these stages can be implemented in a single system such
    as an Asterisk PBX.  For ease of administration, it is advisable
    to break the <literal>extensions.conf</literal> file up into
    different files for each stage as demonstrated in
    <xref linkend="arch-routing-asterisk-extensions"/>.</para>

    <para>The more powerful approach is to transpose this paradigm over
    several individual processes and devices.  For example, the
    <emphasis>ingress</emphasis> stage for calls from local users
    may be implemented in the SIP proxy and the <emphasis>ingress</emphasis>
    stage for calls from an ISDN circuit may be implemented using the
    configuration file in a media gateway.</para>

    <example xml:id="arch-routing-asterisk-extensions">
      <title>Splitting Asterisk <literal>extensions.conf</literal></title>
      <programlisting format="linespecific">#include "/etc/asterisk/extensions/ingress/local_users.conf"
#include "/etc/asterisk/extensions/ingress/trunks.conf"
#include "/etc/asterisk/extensions/routing.conf"
#include "/etc/asterisk/extensions/applications.conf"
#include "/etc/asterisk/extensions/egress/local_users.conf"
#include "/etc/asterisk/extensions/egress/trunks.conf"</programlisting>
    </example>

  </sect1>

  <sect1 xml:id="rtc-architecture-webrtc-peer-to-peer">
    <title>WebRTC peer-to-peer calling</title>

    <figure float="none" xml:id="arch-dia-webrtc-p2p">
      <title>WebRTC basic peer-to-peer</title>

      <mediaobject>
        <imageobject role="print">
          <imagedata fileref="figs/svg/arch-webrtc.svg" width="3in"
            format="SVG" />
        </imageobject>

        <imageobject role="web">
          <imagedata fileref="figs/svg/arch-webrtc.svg"
            format="SVG" />
        </imageobject>
      </mediaobject>
    </figure>

    <para><xref linkend="arch-dia-webrtc-p2p"/> demonstrates how two
    browsers can communicate with each other using WebRTC.  The web
    browsers start by downloading the HTML, CSS and JavaScript from a
    normal web server such as Apache <code>httpd</code>.  The JavaScript
    uses the WebSocket protocol to initiate a connection to the SIP proxy.
    When a call is made, the request is sent over the WebSocket connection
    and the media streams pass through the TURN server.  In this case, the
    browsers are not relaying the media streams through the TURN server,
    possibly because they have discovered they are both on the same
    IP network.</para>
  </sect1>

  <sect1 xml:id="rtc-architecture-webrtc-call-center">
    <title>WebRTC calling to call centers</title>

    <figure float="none" xml:id="arch-dia-webrtc-call-center">
      <title>WebRTC from customer web browser to call center</title>

      <mediaobject>
        <imageobject role="print">
          <imagedata fileref="figs/svg/arch-webrtc-call-center.svg" width="5in"
            format="SVG" />
        </imageobject>

        <imageobject role="web">
          <imagedata fileref="figs/svg/arch-webrtc-call-center.svg"
            format="SVG" />
        </imageobject>
      </mediaobject>
    </figure>

    <para><xref linkend="arch-dia-webrtc-call-center"/> demonstrates a
    more elaborate WebRTC architecture, a customer using a web browser to
    call a corporate call center.  When a call is made, the request is
    sent over the WebSocket connection and the media streams pass through
    the TURN server.  The SIP proxy routes all calls to the corporate PBX
    which routes the calls to an agent.  The media streams must also pass
    through the PBX for transcoding from the Opus codec to one of the
    codecs supported by the desk phones, perhaps G.711 or G.722.</para>
  </sect1>
  
</chapter>