11.8. Serviços de Comunicação em Tempo Real
Serviços de Comunicação em Tempo Real (Real-Time Communication - RTC) incluem voz, vídeo/webcam, mensagem instantânea (IM) e compartilhamento de área de trabalho. Esse capítulo oferece uma breve introdução a três dos serviços necessários para operar um RTC, incluindo os servidores TURN, SIP e XMPP. Detalhes abrangentes de 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.
Tanto o SIP quanto o XMPP podem fornecer a mesma funcionalidade. O SIP é um pouco mais conhecido para voz e vídeo, 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.
11.8.1. Configurações de DNS para serviços RTC
; 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.
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 frustraçã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.
Instale o pacote coturn e edite o arquivo de configuração /etc/turnserver.conf. Por padrão, um banco de dados SQLite é configurado em /var/db/turndb para definições das contas de usuários(as), mas pode-se configurar PostgreSQL, MySQL ou Redis se preferir. O mais importante a se fazer é inserir o endereço de IP do servidor.
O servidor pode ser iniciando executando turnserver do pacote coturn. Queremos que o servidor seja um serviço do sistema que inicie automaticamente. Esse é o comportamento padrão usando systemd. Somente quando se usa o SysVinit que é necessário editar o arquivo /etc/default/coturn assim:
#
# Uncomment it if you want to have the turnserver running as
# an automatic system service daemon
#
TURNSERVER_ENABLED=1
Por padrão, o servidor TURN usa acesso anônimo. Temos que adicionar os(as) usuários(as) que queremos usar:
# turnadmin -a -u roland -p senha_secreta -r falcot.com
# turnadmin -A -u admin -p senha_secreta
Usamos o argumento -a para adicionar um(a) usuário(a) normal e -A para adicionar um(a) usuário(a) administrador(a).
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, PBXes SIP 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 kamailio e o pacote para o backend de banco de dados. Os administradores da Falcot elegeram o MySQL, assim instalaram o kamailio-mysql-modules e mariadb-server. /etc/kamailio/kamctlrc é o arquivo de configuração para as ferramentas de controle kamctl e kamdbctl. É necessário editar e configurar o SIP_DOMAIN para seu domínio de serviço SIP e configurar DBENGINE para MySQL, ou pode-se usar outro backend de banco de dados.
[...]
## your SIP domain
SIP_DOMAIN=sip.falcot.com
## chrooted directory
# CHROOT_DIR="/path/to/chrooted/directory"
## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE
# by default none is loaded
#
# If you want to setup a database with kamdbctl, you must at least specify
# this parameter.
DBENGINE=MYSQL
[...]
Agora vamos nos concentrar no arquivo de configuração /etc/kamailio/kamailio.cfg. A Falcot precisa de autenticação do usuário e localização persistente do usuário, então eles(elas) adicionaram as seguintes diretivas #!define no topo do arquivo:
#!KAMAILIO
#
# Kamailio (OpenSER) SIP Server v5.2 - default configuration script
# - web: https://www.kamailio.org
# - git: https://github.com/kamailio/kamailio
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
[...]
Kamailio precisa de uma estrutura de banco de dados que podemos criar executando kamdbctl create como root. Finalmente, podemos adicionar alguns usuários com o comando kamctl.
# kamdbctl create
[...]
# kamctl add roland secret_password
Uma vez que tudo está corretamente configurado, você pode iniciar ou reiniciar o serviço com
systemctl restart kamailio e conectar com um cliente SIP fornecendo um endereço IP e a porta (5090 é a porta padrão). Os(As) usuários(as) possuem o seguinte id:
roland@sip.falcot.com, e podem fazer o login com um cliente (veja
Seção 13.9, “Softwares de Comunicação em Tempo Real”).
Um servidor XMPP gerencia a conectividade entre usuários XMPP locais e usuários XMPP em outros domínios na internet pública.
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.
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";
certificate = "/etc/ssl/certs/falcot.com.pem";
}
-- Set up a MUC (multi-user chat) room server on conference.example.com:
Component "conference.falcot.com" "muc"
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
Certas 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
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 o Linux tem suporte a múltiplos 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.
O WebRTC é uma tecnologia de vem se desenvolvendo rapidamente e é essencial usar pacotes da distribuição teste (testing) . Outra opção é compilar o software.
O WebRTC usa uma API simples para fornecer navegadores e aplicativos móveis com RTC, é um software livre e está sendo desenvolvido pelo Google.
Uma abordagem muito flexível é usar a implementação WebRTC do GStreamer. Ela habilita aplicações multimídia baseadas em pipeline, o que permite o desenvolvimento de aplicações muito eficientes e interessantes. Um bom ponto de partida é a seguinte demonstração da Centricular, a principal companhia que a desenvolve:
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
DruCalldemonstra 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.
