Product SiteDocumentation Site

11.8. Serviços de Comunicação em Tempo Real

Serviços de Comunicação em Tempo Real (RTC) incluem voz, vídeo/webcam, mensagem instantânea (IM) e compartilhamento de área de trabalho. esse capítulo dá uma breve introdução a três dos serviços necessários para operar um RTC, incluindo os servidores TURN, SIP e XMPP. Compreensíveis detalhes em como planejar, instalar e gerenciar esses serviços estão disponíveis no Guia de Início Rápido para Comunicações em Tempo Real, que inclui exemplos específicos para o Debian.
→ http://rtcquickstart.org
Tanto o SIP quanto o XMPP podem fornecer a mesma funcionalidade. O SIP é sutilmente mais bem conhecido para voz e vídeoo, enquanto que o XMPP é tradicionalmente considerado como um protocolo IM. Na verdade, os dois podem ser usados para qualquer um desses propósitos. Para maximizar as opções de conectividade, é recomendado rodar os dois em paralelo.
Esses serviços fazem uso dos certificados X.509, tanto para propósitos de autenticação quanto para confidencialidade. Veja Seção 10.2.1.1, “Infraestrutura de Chaves Públicas: easy-rsa” para detalhes em como criá-los. Alternativamente o Guia de Início Rápido para Comunicações em Tempo Real também tem algumas explicaçẽos úteis:
→ http://rtcquickstart.org/guide/multi/tls.html

11.8.1. Configurações de DNS para serviços RTC

Serviços RTC requerem registros DNS SRV e NAPTR. Uma configuração exemplo que pode ser colocada no arquivo zona para falcot.com: 
; the server where everything will run
server1            IN     A      198.51.100.19
server1            IN     AAAA   2001:DB8:1000:2000::19

; IPv4 only for TURN for now, some clients are buggy with IPv6
turn-server        IN     A      198.51.100.19

; IPv4 and IPv6 addresses for SIP
sip-proxy          IN     A      198.51.100.19
sip-proxy          IN     AAAA   2001:DB8:1000:2000::19

; IPv4 and IPv6 addresses for XMPP
xmpp-gw            IN     A      198.51.100.19
xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19

; DNS SRV and NAPTR for STUN / TURN
_stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.
_turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.
@           IN NAPTR  10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.

; DNS SRV and NAPTR records for SIP
_sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.
@           IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.

; DNS SRV records for XMPP Server and Client modes:
_xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.
_xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com.

11.8.2. Servidor TURN

TURN é um serviço que ajuda clientes atrás de roteadores NAT e firewalls a descobrir a maneira mais eficiente de comunicar com outros clientes e para retransmitir o fluxo de mídia caso nenhum caminho de mídia direto possa ser encontrado. É altamente recomendado que o servidor TURN seja instalado antes de outros serviços RTC serem oferecidos para os usuários finais.
TURN e o protocolo ICE relacionado são padrões abertos. Para se beneficiar desses protocolos, maximizar a conectividade e minimizar a frustação do usuário, é importante garantir que todos os softwares clientes tenham suporte a ICE e TURN.
Para que o algorítimo ICE funcione efetivamente, o servidor tem que ter dois endereços IPv4 públicos.

11.8.2.1. Instalar o servidor TURN

Instale o pacote resiprocate-turn-server.
Edite o arquivo de configuração /etc/reTurn/reTurnServer.config. A coisa mais importante a fazer é inserir os endereços IP do servidor. 
# your IP addresses go here:
TurnAddress = 198.51.100.19
TurnV6Address = 2001:DB8:1000:2000::19
AltStunAddress = 198.51.100.20
# your domain goes here, it must match the value used
# to hash your passwords if they are already hashed
# using the HA1 algorithm:
AuthenticationRealm = myrealm

UserDatabaseFile = /etc/reTurn/users.txt
UserDatabaseHashedPasswords = true
Reinicie o serviço.

11.8.2.2. Gerenciando os usuário do TURN

Use o utilitário htdigest para gerenciar a lista de usuários do servidor TURN. 
# htdigest /etc/reTurn/users.txt myrealm joe
Use o sinal HUP para fazer com queo servidor recarrege o arquivo /etc/reTurn/users.txt após alterá-lo ou habilite o recurso de recarregamento automático em /etc/reTurn/reTurnServer.config.

11.8.3. Servidor Proxy SIP

Um servidor proxy SIP gerencia entrada e saída de conexões SIP entre outras organizações, provedores de trunking SIP, SIP PBXes tais como Asterisk, telefones SIP, softphones baseados em SIP e aplicações WebRTC.
É altamente recomendado instalar e configurar o proxy SIP antes de tentar uma configuração do PBX SIP. O proxy SIP normaliza muito do tráfego que atinge o PBX e fornece uma melhor conectividade e resiliência.

11.8.3.1. Instalar o proxy SIP

Instale o pacote repro. O uso do pacote que está na jessie-backports é altamente recomendado, já que ele tem os últimos melhoramentos para maximizar a conectividade e resiliência.
Edite o arquivo de configuração /etc/repro/repro.config configuration file. A coisa mais importante a fazer é inserir o endereço IP do servidor. O exemplo abaixo demonstra como configurar um SIP regular e um WebSockets/WebRTC, usando TLS, IPv4 e IPv6: 
# Transport1 will be for SIP over TLS connections
# We use port 5061 here but if you have clients connecting from
# locations with firewalls you could change this to listen on port 443
Transport1Interface = 198.51.100.19:5061
Transport1Type = TLS
Transport1TlsDomain = falcot.com
Transport1TlsClientVerification = Optional
Transport1RecordRouteUri = sip:falcot.com;transport=TLS
Transport1TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport1TlsCertificate = /etc/ssl/public/falcot.com.pem

# Transport2 is the IPv6 version of Transport1
Transport2Interface = 2001:DB8:1000:2000::19:5061
Transport2Type = TLS
Transport2TlsDomain = falcot.com
Transport2TlsClientVerification = Optional
Transport2RecordRouteUri = sip:falcot.com;transport=TLS
Transport2TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport2TlsCertificate = /etc/ssl/public/falcot.com.pem

# Transport3 will be for SIP over WebSocket (WebRTC) connections
# We use port 8443 here but you could use 443 instead
Transport3Interface = 198.51.100.19:8443
Transport3Type = WSS
Transport3TlsDomain = falcot.com
# This would require the browser to send a certificate, but browsers
# don't currently appear to be able to, so leave it as None:
Transport3TlsClientVerification = None
Transport3RecordRouteUri = sip:falcot.com;transport=WSS
Transport3TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport3TlsCertificate = /etc/ssl/public/falcot.com.pem

# Transport4 is the IPv6 version of Transport3
Transport4Interface = 2001:DB8:1000:2000::19:8443
Transport4Type = WSS
Transport4TlsDomain = falcot.com
Transport4TlsClientVerification = None
Transport4RecordRouteUri = sip:falcot.com;transport=WSS
Transport4TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport4TlsCertificate = /etc/ssl/public/falcot.com.pem

# Transport5: this could be for TCP connections to an Asterisk server
# in your internal network.  Don't allow port 5060 through the external
# firewall.
Transport5Interface = 198.51.100.19:5060
Transport5Type = TCP
Transport5RecordRouteUri = sip:198.51.100.19:5060;transport=TCP

HttpBindAddress = 198.51.100.19, 2001:DB8:1000:2000::19
HttpAdminUserFile = /etc/repro/users.txt

RecordRouteUri = sip:falcot.com;transport=tls
ForceRecordRouting = true
EnumSuffixes = e164.arpa, sip5060.net, e164.org
DisableOutbound = false
EnableFlowTokens = true
EnableCertificateAuthenticator = True
Use o utilitário htdigest para gerenciar a senha do admin para a interface web. O nome de usuário tem que ser admin e o nome "realm" tem que coincidir com o valor especificado em repro.config. 
# htdigest /etc/repro/users.txt repro admin
Reinicie o serviço para usar a nova configuração.

11.8.3.2. Gerenciando o proxy SIP

Vá para a interface web em http://sip-proxy.falcot.com:5080 para completar a configuraçao fazendo a adição de domínios, usuários locais e rotas estáticas.
O primeiro passo é adicionar um domínio local. O processo tem que ser reiniciado após a adição ou remoção de domínios da lista.
O proxy sabe como rotear chamadas entre usuários locais e endereços SIP completos, a configuração de roteamento só é necessária par sobrescrever o comportamento padrão, por exemplo, para reconhecer números de telefone, adicionar um prefixo e roteá-los para um provedor SIP.

11.8.4. Servidor XMPP

Um servidor XMPP gerencia a conectividade entre usuários XMPP locais e usuários XMPP em outros domínios na internet pública.

VOCABULÁRIO XMPP ou Jabber?

O XMPP é, algumas vezes, referenciado como Jabber. Na verdade, Jabber é uma marca registrada e XMPP é o nome oficial do padrão.
Prosody é um popular servidor XMPP que opera de forma confiável em servidores Debian.

11.8.4.1. Instalar o servidor XMPP

Instale o pacote prosody. O uso do pacote existente na jessie-backports é altamente recomendado, já que ele tem os últimos melhoramentos para maximizar a conectividade e resiliência.
Reveja o arquivo de configuração /etc/prosody/prosody.cfg.lua. A coisa mais importante a fazer é inserir as JIDs dos usuários que tem permissão para gerenciar o servidor. 
admins = { "joe@falcot.com" }
Um arquivo de configuração individual também é necessário para cada domínio. Copie o exemplo de /etc/prosody/conf.avail/example.com.cfg.lua e use-o como ponto de partida. Aqui está o falcot.com.cfg.lua: 
VirtualHost "falcot.com"
        enabled = true
        ssl = {
                key = "/etc/ssl/private/falcot.com-key.pem";
                certificate = "/etc/ssl/public/falcot.com.pem";
                }
Para habilitar o domínio, tem que existir um symlink de /etc/prosody/conf.d/. Crie-o dessa forma: 
# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/
Reinicie o serviço para usar a nova configuração.

11.8.4.2. Gerenciando o servidor XMPP

Algumas operações de gerenciamento podem ser realizadas usando o utilitário de linha de comando prosodyctl. Por exemplo, para adicionar a conta de administrador especificada em /etc/prosody/prosody.cfg.lua: 
# prosodyctl adduser joe@falcot.com
Veja a documentação online do Prosody para mais detalhes sobre como customizar a configuração.

11.8.5. Rodando serviços na porta 443

Alguns administradores preferem rodar todos os serviços RTC na porta 443. Isso ajuda os usuários a se conectar a partir de localizações remotas, tais como hotéis e aeroportos, onde outras portas podem estar bloqueadas ou o tráfego de Internet é roteado através de servidores proxy HTTP.
Para usar essa estratégia, cada serviço (SIP, XMPP e TURN) precisa de um endereço IP diferente. Todos os serviços ainda podem estar na mesma máquina, já que oLinux tem suporte a multiplos endereços IP em uma única máquina. O número de porta, 443, tem que ser especificado nos arquivos de configuração de cada processo e também nos registros DNS SRV.

11.8.6. Adicionando WebRTC

A Falcot que deixar os clientes fazerem chamadas telefônicas a partir do site web. Os administradores da Falcot também querem usar o WebRTC como parte de seu plano de resgate em um disastre, para que a equipe possa usar navegadores web em casa para iniciar uma sessão no sistema de telefonia da companhia e trabalhar normalmente em uma emergência.

NA PRÁTICA Experimente o WebRTC

Se você nunca experimentou o WebRTC antes, existem vários sites que oferecem uma demonstração online e instalações de teste.
→ http://www.sip5060.net/test-calls
O WebRTC é uma tecnologia de envolvimento rápido e é essencial usar pacotes existentes nas distribuições jessie-backports ou Teste ("Testing").
O JSCommunicator é um telefone WebRTC genérico e sem marca que não requer nenhum script rodando no lado do servidor como o PHP. Ele é construído com HTML, CSS e JavaScript. Ele é a base para muitos outros serviços WebRTC e módulos para mais avançados frameworks de plublicação na web.
→ http://jscommunicator.org
O pacote jscommunicator-web-phone é a maneira mais rápida de instalar um telefone WebRTC em um site web. Ele requer um proxy SIP com transporte de WebSocket. As instruções em Seção 11.8.3.1, “Instalar o proxy SIP” incluem os detalhes necessários para habilitar o transporte de WebSocket no proxy SIP repro.
Após a instalação do jscommunicator-web-phone, existem várias maneira de usá-lo. Uma estratégia simples é incluir ou copiar a configuração de /etc/jscommunicator-web-phone/apache.conf para uma configuração de host virtual do Apache.
Uma vez que os arquivos web-phone estejam disponíveis no servidor web, customize o /etc/jscommunicator-web-phone/config.js para apontar para o servidor TURN server e proxy SIP. Por exemplo: 
JSCommSettings = {

  // Web server environment
  webserver: {
    url_prefix: null            // If set, prefix used to construct sound/ URLs
  },

  // STUN/TURN media relays
  stun_servers: [],
  turn_servers: [
    { server:"turn:turn-server.falcot.com?transport=udp", username:"joe", password:"j0Ep455d" }
  ],

  // WebSocket connection
  websocket: {
      // Notice we use the falcot.com domain certificate and port 8443
      // This matches the Transport3 and Transport4 example in
      // the falcot.com repro.config file
    servers: 'wss://falcot.com:8443',
    connection_recovery_min_interval: 2,
    connection_recovery_max_interval: 30
  },

  ...
Sites web clique-para-chamar mais avançados tipicamente usam scritps do lado do servidor para gerar o arquivo config.js dinamicamente. O código fonte DruCall demonstra como fazer isso com PHP.
Esse capítulo mostrou apenas uma fração dos softwares de servidor disponíveis; contudo, a maioria dos serviços de rede comuns foram descritos. Agora é hora de um capítulo ainda mais técnico: nós iremos entrar mais detalhadamente ainda em alguns conceitos, descrevendo implementações massivas e virtualização.