Este material é uma amostra grátis dos primeiros capítulos do material de treinamento de telefonia IP com SIP.
Datas e disponibilidade do treinamento podem ser verificadas em www.voffice.com.br
Por: Flávio Eduardo de Andrade Gonçalves
flavio.goncalves at voffice.com.br
Este livro foi escrito tendo em vista as pessoas que desejam ter um primeiro contato com um SIP Proxy. O OpenSER é um SIP Proxy licenciado pela licença GNU como software livre. O OpenSER pode ser usado em uma variedade de cenários como solução para criação de um provedor de voz sobre IP, soluções para travessia de NAT e balanceamento de carga.
Ele foi organizado de forma que se possa aprender um pouco da teoria de funcionamento do SIP de forma prática com laboratórios que vão crescendo em complexidade capítulo à capítulo.
No primeiro capítulo falamos sobre a teoria de operação do SIP, detalhando nomenclatura, conceitos e exemplos de comunicação em SIP. Ao final do capítulo existe um exercício usando o Ethereal para analisar uma comunicação SIP.
No segundo capítulo, descrevemos o software OpenSER, seus pontos fortes como desempenho e escalabilidade. São discutidos também a arquitetura do SER e o formato do arquivo de configuração openser.cfg.
No terceiro capítulo abordamos a instalação a partir do zero do Linux e do OpenSER. Usamos o Debian como distribuição pelo bom suporte de hardware e facilidade de instalação de pacotes. Usamos ainda o OpenSER 1.0.0 que é a última versão estável do OpenSER.
No capítulo quatro começamos a analisar o arquivo de configuração padrão do OpenSER e suas funcionalidades.
Na seqüência, no capítulo 5 adicionamos o suporte do banco de dados MySQL para permitir a autenticação dos usuários e transações. Ao final instalamos a interface gráfica SerWEB que vai ajudar a cadastrar os usuários.
Incluímos nesta versão o capítulo 6 específico sobre o portal de usuários SerWEB. Ele trata da configuração e persoanlização da interface SerWEB.
No capítulo 7, incluímos a conexão à um gateway PSTN para encaminhar ligações de um telefone IP para a rede pública de telefonia. Introduzimos o conceito de grupos e autorização de saída para PSTN. Os módulos permissions e group são usados neste capítulo.
No capítulo 8, entramos em encaminhamento de chamados principalmente para mostrar o tratamento de chamadas com blocos “on_reply_route” e “failure_route”.
O capítulo 9, introduzimos um novo módulo chamado mediaproxy usado para permitir a passagem do SIP por NAT.
Incluímos nesta versão o capítulo 10, com mais detalhes sobre a bilhetagem e sobre o utilitátio CDRTool.
No capítulo 11, mostramos algumas ferramentas de depuração como XLOG, LOG, NGREP e append_hf.
É comum que se pergunte qual a diferença entre o OpenSER e o Asterisk. O OpenSER não é exatamente um concorrente do Asterisk. Muito embora você possa criar um provedor de voz sobre IP sobre o Asterisk, quando o volume de usuários cresce muito, os mecanismos de registro do Asterisk não são to robustos quanto os do OpenSER. Outro ponto interessante é a compatibilidade com a RFC3261 (documento que define o protocolo SIP versão 2) que é um ponto alto do Sip Express Router.
SER ou OpenSER ? Eu comecei o trabalho usando o SER da iptel que é bastante robusto. Fiquei um pouco preocupado ao ver que boa parte do trabalho havia parado em 2003 e que a IPTEL em si havia sido vendida para a TEKELEC. Procurando mais encontrei outro grupo de desenvolvedores que me pareceu muito mais ativo, uma ramificação do SER chamada OpenSER. Troquei tudo o que tinha escrito de SER para OpenSER o que não foi difícil, mas foi bem trabalhoso, alguns comandos como o “break” foram substituídos por “exit” no OpenSER.
Eu espero que você goste do livro e estou aberto a opiniões e críticas construtivas. Ninguém gosta de ser criticado, mas é a única forma de evoluir um trabalho.
Flávio Eduardo de A. Gonçalves
flaviogoncalves at msn.com
Este livro é para pessoas com algum conhecimento em telefonia IP e SIP. Conhecimento de Linux é indispensável para realizar os laboratórios deste livro. É recomendável conhecimento em VoIP sem o qual alguns assuntos podem demorar a ser entendidos.
Flávio Eduardo de Andrade Gonçalves,
Me formei em Engenharia em 1989 na Universidade Federal de Santa Catarina. como não queria sair de Florianópolis, uma terra que eu adotei desde os nove anos, fui trabalhar na administração de um sistema DEC VAX em uma empresa local, desde lá nunca mais larguei software e hardware. Em 1991 fiquei envolvido em um processo de migração do VAX para Novell e em 1992 eu já era Certified Novell Engineer. Desde lá a cada ciclo de três ou quatro anos surge a necessidade de renovação.
No final de 1995 o Linux e a Internet surgiram quase ao mesmo tempo. Lembro-me que o Linux naquela época eu recebia em CDRom, era uma versão de Slackware e também tinha o FreeBSD. No final de 1995 montamos, na empresa onde era sócio, um provedor usando NetBSD.
Em 1996 fundei a V.Office empresa que trabalho até hoje. Em 1997 eu comecei a me interessar mais pela estrutura de redes WAN usando Cisco. De roteadores para voz sobre IP, VPNs e gestão de tráfego foi um pulo. Há poucos anos ficou claro para mim que o mercado migraria de voz sobre IP para telefonia IP e que havia um grande mercado a ser explorado em telefonia avançada, URA, DAC, CTI, provedores de voz sobre IP.
Em 2003 tive o primeiro contato com o Asterisk PBX e fiquei muito bem impressionado com a capacidade e facilidade. O produto era excelente, mas a documentação era escassa e distribuída. Achei que escrever um livro sobre o assunto seria uma boa oportunidade, pois o Asterisk não seria largamente adotado se não houvesse uma boa estrutura de documentação e treinamento em língua portuguesa.
Bem depois disto veio o OpenSER e a oportunidade de trabalhar na implantação de alguns provedores de voz sobre IP. Como já havia tido a experiência de ter escrito “Asterisk PBX Guia de Configuração”, escrever sobre o openSER não foi uma decisão difícil.
1.9 Real Time Control Protocol - RTCP
1.10 Session Description Protocol - SDP
1.11 O protocol SIP e o modelo OSI.
1.12 Visão geral de um provedor VoIP
Introdução ao SIP Express Router
2.3 O que é o SIP Express Router
2.4 Lista de recursos e cenários de uso.
2.6 Arquitetura do OpenSER e o arquivo openser.cfg
2.7 Operação em modo “stateful”
2.8 Diferenças entre Strict Routing e Loose Routing
Lab 3.1 - Instalando o Linux para o OpenSER
Lab 3.2 - Baixando e instalando o OpenSER.
Lab 3.3 – Compilando o OpenSER
3.4 Estrutura de arquivos do OpenSer
OpenSER na configuração padrão.
4.3 Listagem e descrição dos comandos
Lab 4.2 – Usando a configuração padrão.
Adicionando autenticação com MySQL
5.4 Seqüência de autenticação para pedidos de registro:
5.5 Seqüência de autenticação do INVITE
5.6 Autenticação do tipo Digest
5.7 Instalando o suporte ao MySQL.
5.8 Análise do arquivo openser.cfg
5.10 Laboratório: Autenticação.
5.12 LAB – Melhorando a segurança
Gerenciando o OpenSER usando SerWEB
6.4 Laboratório - Instalando o SerWEB
6.5 Arquivos de configuração do SERWeb
6.7 Lab – Personalizando o SerWEB
6.8 LAB Fazendo a inscrição de um usuário novo
6.9 Operações simples como administrador
6.10 Operações simples como usuário
6.11 Lab – Altere a senha usando a interface de usuário
6.12 Implementando o suporte a internacionalização.
Conectividade com a rede pública
7.4 Dissecando o arquivo openser.cfg
7.5 LAB – Usando Asterisk como um gateway
7.6 Using LCR (least cost routes)
7.7 Comandos openserctl relacionados
8.4 Visão geral dos pares atributo:valor (AVPairs)
8.5 Implementando siga-me incondicional
8.6 Implementando siga-me (ocupado, não atende)
9.4 Formas de Resolver o problema do NAT
9.5 Solução para a sinalização SIP (RFC3581)
9.6 Recebendo chamadas atrás de NAT.
9.7 Mensagens do tipo INVITE atrás de NAT
9.8 Usando o MediaProxy para a solução de NAT.
9.9 Análise do arquivo openser.cfg para NAT Traversal
9.11 Representação gráfica do script
9.12 LAB – Usando o mediaproxy para travessia de NAT.
9.13 Implementando uma solução no cliente
Bilhetagem usando Radius e CDRTool
10.3 Como é feita a contabilização
10.4 Configurando e Instalando a Bilhetagem (Accounting)
10.5 LAB – Implementando a contabilização com MySQL.
10.7 Contabilização usando um servidor Radius
10.8 Instalação do FreeRadius.
10.10 LAB. Instalação do Cdrtool
10.12 Como o CDRTool tarifa uma chamada
10.13 Lab. Criando e aplicando um plano de tarifação
Visão geral das expressões regulares.
Código de Status das Mensagens
O protocolo SIP, “session initiation protocol” está descrito principalmente em duas RFCs “Request for Comments”, RC2543 e RFC3261 que é também conhecida como SIP versão 2. O SIP é um protocolo da camada de aplicação usado para estabelecer, modificar e terminar sessões ou chamadas multimídia. Essas sessões podem ser conferências, e-learning, telefonia pela Internet e aplicações similares. Ele é um protocolo baseado em texto, similar ao HTTP e SMTP, desenhado para iniciar, manter e terminar sessões de comunicação interativa entre usuários. Tais sessões incluem: voz, vídeo, chat, jogos interativos e realidade virtual. Ele foi definido pela IETF e vem se tornando o padrão de fato em telefonia IP.
O SIP suporta cinco aspectos do estabelecimento e término de sessões multimídia.
· Localização dos usuários: Determina o sistema final a ser usado para a comunicação.
· Recursos disponíveis para o usuário: Determina a mídia e os parâmetros da mídia a serem usados.
· Disponibilidade do usuário: Determina se o usuário está disponível para aceitar uma sessão.
· Estabelecimento da chamada: Estabelecimento dos parâmetros de chamados de ambos quem chamou e de quem foi chamado, além de progresso da chamada como tocando, “ringing”.
· Gerenciamento da chamada: Transferência e término das chamadas.
O SIP foi projetado com parte de arquitetura de dados e controle multimídia, tais como, os protocolos RSVP, RTP, RTSP, SDP, SAP, entretanto não depende de nenhum deles para o seu funcionamento.
O SIP é um protocolo de sinalização de voz sobre IP que possui os seguintes componentes:
· UAC (user agent client) – cliente ou terminal que inicia a sinalização SIP.
· UAS (user agent server) – servidor que responde a sinalização SIP de um UAC.
· UA (user agent) – terminal de rede SIP (telefones SIP, ou gateway para outras redes), contém UAC e UAS.
· Servidor Proxy – Recebe pedidos de conexão de um UA e transfere-o para outro servidor proxy se a estação em particular não está em sua administração.
· Servidor de Redirecionamento – Recebe pedidos de conexão e envia-os de volta ao emissor incluindo os dados de destino ao invés de enviá-los diretamente à parte chamada.
· Servidor de localização – recebe pedidos de registro de um UA e atualiza a base de dados de terminais com eles.
Todas as seções do servidor (Proxy, Redirect e Location) estão tipicamente disponíveis em uma única máquina física chamada proxy server, que é responsável pela manutenção da base de dados de clientes, estabelecimento de conexões, manutenção e término e redirecionamento de chamadas.
O protocolo SIP emprega um componente chamado “Registrar” que é um servidor que aceita pedidos “REGISTER” e coloca a informação que ele recebe nestes pedidos no servidor de localização para o domínio que ele gerência. O SIP oferece a capacidade de descobrimento. Se um usuário inicia uma sessão com outro usuário, o SIP deve descobrir o host atual onde o usuário pode ser alcançado. Este processo de descobrimento é feito pelo Location Server, que recebe o pedido, determina para onde mandá-lo baseado no conhecimento da localização de cada usuário. Isto se baseia numa tabela de localização por domínio.
Antes que um telefone possa receber chamadas, ele precisa se registrar em uma base de localização. É neste local que o nome será associado ao endereço IP onde o telefone se encontra. No nosso caso usamos como nome o ramal 8500. Poderia ser também um endereço no formato sip:flavio@voffice.com.br.
As mensagens básicas enviadas em um ambiente SIP são:
Respostas a mensagens do SIP são em formato texto como no protocolo http. Aqui estão as respostas mais importantes.
Esta seção introduz as operações básicas do SIP usando um exemplo simples. Vamos examinar a seqüência de mensagens entre dois “agentes-usuário” mostrados abaixo.
As mensagens estão rotuladas na seqüência. Neste exemplo o usuário A usa um telefone IP para se comunicar com outro telefone IP pela Internet. Para poder completar esta ligação são usados dois SIP Proxies. O usuário A chama o usuário B usando sua identidade SIP também conhecida como SIP URI. A URI é semelhante a um endereço de e-mail como sip:usuarioA@sip.com.br. O SIP também pode usar uma URI segura como sips:usuarioA@sip.com.br. Uma chamada feita para um URI SIPS garante um transporte de mensagens seguro (TLS) entre o originador e o destino chamado.
A transação começa com o telefone do usuário A enviando um INVITE (Convite) endereçado ao usuário B. O pedido de INVITE (Convite) contém um número de campos de cabeçalho. Campos de cabeçalho são atributos nomeados que provêm informações adicionais sobre a mensagem, eles incluem um identificador único, o destino e informações sobre a sessão.
A primeira linha da mensagem contém o nome do método. As linhas que seguem fazem parte da lista dos campos cabeçalho. Este exemplo contém o conjunto mínimo necessário. Estes campos são rapidamente descritos abaixo:
VIA contém o endereço para o qual o usuárioA está esperando receber respostas a este pedido. Ele também contém um parâmetro “branch” que identifica esta transação.
TO contém um nome (display name) e um SIP ou SIPS URI (sip:usuarioB@sip.com.br) para o qual o pedido foi originalmente direcionado.
FROM também contém um nome (display name) e SIP ou SIPS URI (sip:usuarioA@sip.com.br) que indica o originador da chamada. Este campo cabeçalho tem um parâmetro etiqueta (tag) contendo uma string aleatória (1234567890) que foi adicionada ao URI pelo telefone IP ele é usado para propósitos de identificação.
CALL-ID contém um identificador globalmente único para esta chamada, gerado pela combinação de uma string aleatória e o nome do host ou endereço IP do telefone IP. A combinação da etiqueta TO, FROM e CALL-ID definem completamente uma relação SIP fim-à-fim (“peer-to-peer”) também conhecida como diálogo.
CSEQ ou seqüência de comandos contém um inteiro e um nome de método. O número CSEQ é incrementado para cada novo pedido dentro de um diálogo e é um número de seqüência tradicional.
CONTACT contém um URI SIP ou SIPS que representa uma rota direta para contatar o usuarioA, usualmente composta de um nome de usuário em um domínio totalmente qualificado (FQDN). Como nem sempre alguns sistemas têm um domínio registrado, endereços IP são permitidos. Enquanto o campo VIA diz aos outros elementos para onde enviar uma resposta, o campo CONTACT diz aos outros elementos para onde enviar requisições futuras.
MAX-FORWARDS serve para limitar o número de saltos que um pedido pode dar no caminho ao seu destino. Ele consiste de um inteiro que é decrementado por um à cada salto.
CONTENT-TYPE contém uma descrição do corpo da mensagem.
CONTENT-LENGTH contém uma contagem de bytes do corpo da mensagem.
Os detalhes de uma sessão, tal como o tipo de mídia, codec não são descritos usando o SIP. Ao invés disso o corpo de uma mensagem SIP contém uma descrição da sessão, codificado em outro formato de protocolo. Um destes formatos é o SDP (Session Description Protocol RFC 2327). Esta mensagem SDP é carregada pela mensagem SIP de forma análoga a um anexo de e-mail.
A seqüência da figura fica como acima:
(1) Como o telefone não conhece a localização do usuárioB ou servidor SIP do domínio sipB.com.br ele envia o INVITE para o servidor SIP que serve ao domínio sipA, este endereço é configurado no telefone do usuarioA, ou pode ser descoberto via DHCP. O servidor sipA.com.br é conhecido como proxy.
(2) Neste exemplo o proxy recebe o pedido de INVITE e envia uma mensagem “100 (Trying)” de volta ao usuarioA indicando que o proxy recebeu o INVITE e está trabalhando em encaminhar o pedido. As respostas SIP usam um código de três dígitos seguidos por uma frase descritiva. Esta resposta contém o mesmo To, From, Call-ID, CSeq e o parâmetro “branch” no campo Via como o INVITE, o que permite que o telefone do usuarioA correlacione sua resposta para o INVITE enviado.
(3) O proxyA localiza o proxyB fazendo uma consulta específica ao servidor DNS para encontrar o servidor SIP que serve ao domínio B e encaminhar o INVITE. Antes de encaminhar o pedido o ProxyA adiciona um campo Via adicional que contém seu próprio endereço (O INVITE já contém o endereço de A no primeiro campo Via).
(4) O proxy B recebe o INVITE e responde com um 100 (Trying) “tentando” de volta ao proxy A indicando que ele está processando o pedido.
(5) O servidor Proxy consulta a base de dados, conhecida como serviço de localização, que contém o endereço do usuárioB. O proxyB adiciona um outro campo Via com seu próprio endereço para o INVITE e encaminha para o usuário B.
(6) O telefone do usuário B recebe o INVITE e alerta o usuário para a chamada vinda do usuário A e o telefone desta forma toca. O telefone indica isto com uma resposta 180 (ringing) “tocando”.
(7) que é roteada de volta através dos dois proxys na direção inversa. Cada proxy usa o campo Via para determinar para onde enviar a resposta e remove seu próprio endereço do topo. Como resultado, embora o DNS e a consulta ao serviço de localização sejam necessários para rotear o INVITE inicial, a resposta 180 (ringing) pode retornar ao originador sem lookups e sem que seu estado seja mantido por cada proxy. Isto também faz com que cada proxy que recebeu o INVITE veja todas as respostas do INVITE.
(8) Quando o usuário A recebe o 180 (ringing), ele passa esta informação ao telefoneA que vai soar o áudio de “tocando” (ringback) e/ou mostrar a mensagem na tela do usuarioA.
(9) Neste exemplo, o usuárioB decide atender a chamada. Quando ele pega o handset, este telefone SIP envia uma resposta 200(OK) para indicar que a chamada foi respondida. O 200(OK) contém no corpo da mensagem com a descrição da sessão usando o protocolo SDP. Como resultado, existe uma troca em duas fases das mensagens SDP de A para B e de B para A. Este recurso do SDP possui uma capacidade básica de negociação dos recursos em um modelo simples de oferta/resposta. Se o usuárioB não quiser responder a chamada ou estiver ocupado, um erro será enviado ao invés do 200(OK). A mensagem 200(OK) é algo como aparece abaixo:
A primeira linha de resposta contém o código de resposta e a frase da razão (OK). As linhas restantes contêm campos cabeçalhos. Os campos Via, To, From, Call-ID, e CSeq são copiados do pedido de INVITE. Existem três campos Via, um adicionado pelo telefoneA, outro pelo ProxyA e o último pelo proxyB. O telefone SIP de Bob adicionou em parâmetro tag (etiqueta) em ambos os pontos finais dentro do diálogo e serão incluídos em todos os pedidos futuros e respostas nesta chamada.
O campo Contact contém uma URI com a qual o usuarioB pode ser contatado diretamente no seu telefone IP. Os campos Content-Type e Content-Length se referem ao corpo da mensagem (não mostrado) que contém a informação da sessão SDP (mídia). Além do DNS e do serviço de localização mostrados no exemplo, os servidores proxy podem decidir para onde enviar o pedido. Por exemplo, se o telefone SIP do usuárioB retornar um 486 (Busy here) “Ocupado”, o proxyB poderia fazer um INVITE ao servidor de correio de voz do usuário B. Um servidor proxy pode também enviar um INVITE para vários locais ao mesmo tempo. Este tipo de busca paralela é conhecida como “forking”.
(10) Neste caso, o 200(OK) enviado de volta é roteado de volta pelos dois proxies e recebido pelo usuárioA que então para o tom de retorno e indica que a chamada foi respondida.
(11) Finalmente o usuárioA envia uma mensagem de ACK, para o telefone do usuárioB para confirmar o recebimento da resposta final 200 (OK). Neste exemplo o ACK é enviado diretamente do telefoneA para o telefoneB evitando os dois proxies. Isto ocorre porque os pontos finais aprenderam os endereços uns dos outros a partir dos campos Contact durante o processo de INVITE/200(OK). Isto completa o ciclo INVITE/200/ACK também conhecido como “SIP Three-way-handshake” usado para estabelecer sessões SIP.
(12) Neste momento a sessão entre os usuários começa e eles estão enviam pacotes de media de um para o outro usando formato que eles estabeleceram usando o SDP. Em geral os pacotes fim-à-fim têm um caminho diferente das mensagens de sinalização.Durante a sessão, os usuários A e B podem decidir mudar as características de uma sessão. Isto é feito enviando um novo “convite” (re-INVITE) contendo uma nova descrição de mídia. Este re-INVITE referencia um diálogo existente de forma que a outra parte sabe que ela vai modificar uma sessão existente ao invés de iniciar uma nova sessão. O outro lado envia um 200(OK) com um ACK. Se o outro lado aceitar a mudança ele vai enviar um 200(OK) , o originador responde ao 200(OK) com um ACK. Se o outro lado não aceitar, ele vai enviar uma resposta tal como 488 (não aceitável aqui), que também recebe um ACK. Entretanto a falha no re-INVITE não causa a falha da sessão existente.
(13) No final da sessão, o usuário B desconecta (hang up) e gera a mensagem de BYE. Este BYE é roteado diretamente para o softfone do usuário A “bypassando”os proxies.
(14) O usuário A confirma a recepção do BYE com uma resposta 200 (OK) que termina a sessão e a transação BYE. Nenhum ACK é enviado. Um ACK só é enviado como resposta a um pedido de INVITE.
Em alguns casos pode ser útil para os Proxies ficar no caminho da sinalização para ver todas as mensagens entre os pontos finais pela duração da sessão. Por exemplo, se o servidor proxy B deseja permanecer no caminho da mensagem além do INVITE inicial, ele deve adicionar ao INVITE o campo conhecido como Record-Route que contém a URI do proxy. Esta informação será recebida pelo softfone do usuário B e (devido ao campo Record-Route será passada de volta na mensagem 200 (OK) para o softfone do usuário A e armazenado pela duração do diálogo. Cada Proxy pode de forma independente decidir receber mensagens subseqüentes, e estas mensagens irão passar através dos proxies que elegerem recebê-las. Esta capacidade é frequentemente usada para proxies que estão provendo recursos usados no meio de uma chamada.
O registro é uma forma que o Proxy B pode usar para aprender a localização atual do usuário B. Na inicialização e em intervalos regulares, o softfone B envia mensagens do tipo REGISTER para o servidor no domínio B conhecido como “SIP REGISTRAR”. As mensagens de registro associam o endereço SIP do usuário B (usuarioB@sipB.com.br) com a máquina na qual ele está logado (Que vem como uma URI SIP ou SIPS no campo Contact). O servidor registrar escreve esta associação, também chamada de Binding, para um banco de dados, chamado “location service” onde ela pode ser usada pelo servidor Proxy no domínio sipB. Normalmente o servidor de registro fica junto com o proxy. O usuário pode se registrar de mais de um local e o servidor pode fazer vários tipos de busca para localizar o usuário B. De forma similar, mais de um usuário pode ser registrado em um único dispositivo ao mesmo tempo.
Finalmente, é importante notar que no SIP o processo de registro é usado para rotear as chamadas SIP e não tem papel na autorização dos pedidos de ligação. Autenticação e autorização são gerenciadas pelo SIP em uma base pedido a pedido com um mecanismo de desafio/resposta, ou usando um esquema de nível mais baixo como checagem de endereço IP.
O protocol RTP é reposnável pelo transporte de dados como áudio e vídeo. Ele foi padronizado pela RFC3550. Ele usa UDP como um protocolo de transporte. Para ser transportado, o áudio e vídeo tem de ser empacotados por um codec. Basicamente o protocolo permite a especificação da temporização e do conteúdo da transmissão da mídia.
O RTP tem um protocol auxiliary chamado RTCP (Real Time Control Protocol) usado para monitorar os pacotes de RTP. Ele pode medir o delay e o jitter.
O conteúdo descrito no protocol RTP é normalmente codificado por um Codec. Cada codec tem um uso específico. Alguns tem compressão enquanto outros não. O Codec G.711 que não usa compressão é o mais comum. Usando 64 Kbps de banda para um único canal, ele normalmente precisa de uma rede de alta velocidade, normalmente encontrada em redes locais. Entretanto em redes de longa distância, 64Kbps é muito oneroso. Codecs como o G.729 e o GSM podem compactar os pacotes de voz em até 8 vezes e permitir um melhor uso da banda disponível. Alguns codecs como o iLBC podem sustentar uma boa qualidade de voz mesmo com 7% de perda de pacotes. A correta escolha do codec de voz é fundamental na operação de um provedor VoIP
Algumas vezes os usuários vão precisar usar o teclado do telefone para operar sistemas automáticos como por exemplo telebanco e correio de voz. Para que esta operação se dê sem problemas, é preciso que o DTMF (Dual Tone Multifrequency) seja repassado para a rede pública corretamente. Quando usamos um Codec com compressão como o g.729, os tons enviados pelos dígitos do telefone passam distorcidos e podem ser interpretados de forma incorreta ou simplesmente ignorados. Para resolver isso precisamos de um método especial para a passagem do DTMF. Em alguns casos o protocol RTP é usado para levar informações de sinalização como o DTMF. A RFC2833 especifica os métodos para transmitir O DTMF na forma de eventos nomeados. É importante que vocÊ use o mesmo método para servidores e clientes.
O RTCP pode prover um feedback sobre a qualidade da recepção. Ele fornece controle “fora de banda” de informações como o RTT (Round Trip Time, Latencia e perda de pacotes. É normalmente usado para gerar relatórios da qualidade da ligação.
O protocolo SDP é descrito na RFC4566. Ele é usado para negociar parâmetros de sessão entre os agentes usuário. Detalhes como endereçcos IP e portas para comunicação do RTP e informações relacionadas a Codecs e DTMF-Relay são trocadas no SDP. O SDP funciona no modelo Oferta/Resposta. Normalmente a mensagem de INVITE contém a oferta e a mensagem “200 Ok” contem a resposta. No exemplo abaixo você pode notar que o Codec GSM foi oferecido, mas o outro fone não o suporte, por isto esta conexão deve ser fechada com o Codec G.711 suportado por ambos. A sessão rtpmap:101 é referente ao DTMF-relay descrito na RFC2833.
INVITE (SDP Offer)
200 Ok (SDP Answer)
É sempre importante entender os protocolos de voz a luz do modelo OSI. Com isto situar mais claramente a função de cada protocol.
Antes de começar a se aprofundar no SIP Proxy é importante entender todos os componentes envolvidos na solução. Um provedor VoIP normalmente consiste de vários servidores e serviços. Os serviços descritos aqui poderiam ser instalados em um único servidor ou em múltiplos servidores dependendo do dimensionamento.
Neste material, nós iremos cobrir cada um dos components nos capítulos a frente. Vamos usar esta figura em todos os capítulos para poder situá-lo.
O SIP proxy é o component central de nossa solução. Ele é responsável pelo registro dos usuários e por manter a base de dados de localização (mapeado endereços SIP (uri) para endereços IP). Toda a sinalização e o rotemento são gerenciados pelo SIP Proxy. O SIp Proxy nunca gerencia a media (áudio ou vídeo em RTP). Todos os pacotes RTP são envidos diretamente entre os usuários e os gateways.
Um component importante é o portal de provisionamento e administração. O usuário tem de se inscrever no serviço, ele deveria ser capaz de comprar créditos, mudar senhas, verificar sua conta a assim por diante. Por outro lado, os administradores precisam remover usuários, dar e alterar privilégios, e adicionar créditos. O provisionamento é usado para tornar mais simples a onfiguração dos softphone pelos usuários.
Para que haja comunicação com o service público de telefonia são necessários gateways. Normalmente esta interface de gateway vai usar troncos E1 ou T1 dependendo do país. Os produtos mais comuns para esta tarefa são os gateways da Cisco, AudioCodes e Quintum. O Asterisk vem ganhando mercado nesta área também. Verifique o suporte dos gateway não somente a RFC3261, mas também as RFCs 3515(REFER) e 3891(Replaces) e 3892(Referred By). Este protocolos permite a tranferência de chamadas com consulta. Sem eles pode ser impossível transferir chamadas.
Um SIP proxy nunca gerencia a mídia (RTP). Serviços como URA, correio de voz, conferência ou quaisquer outros relacionados ao uso da mídia, necessitam deste componente. Os dois componentes mais populares para Media Server são o Asterisk e o SEMS desenvolvido pela IPTEL. O SEMS tem recursos interessantes como correio de voz, conferência e anúncios.
Qualquer provedor SIP terá de gerenciar a travessia de NAT para seus clients. O MediaProxy é uma bridge que ajuda os usuários atrás de um NAT simétrico a acessar o provedor. Sem ele não é possível atender a cerca de 35% dos usuários. Você pode implementar técnicas universais de travessia de NAT usando estes componentes. O MediaProxu pode ainda ser usado no auxílio da bilhetagem evitando que pacotes de INVITE sem um BYE deixem de ser contabilizados.
Um servidor com Radius instalado será fundamental para a contabilização das chamadas. Um provedor SIP deverá tomar o máximo cuidado com a contabilização dos registros. O OpenSER pode ser configurado para enviar a contabilidade para um servidor Radius tal como o Freeradius ou o Radiator.
O servidor Radius contem informações sobre a duração da chamada, mas ele não tem informações sobre as tarifas e as regras de tarifação. Aplicar preços as chamadas podem ser bem complicado. Nós vamos usar no capítulo 10 uma ferramenta chamada CDRTool desenvolvida pela AGProjects (cdrtool.agprojects.com). Ela será responsável por aplicar estas taxas as chamadas.
Por fim, nós iremos precisar de ferramentas de monitoramento e testes para nos ajudar a debugar quaisquer problemas ocorrendo no servidor SIP. A primeira destas ferramentas é o analisador de protocolo. Vamos ver também outras ferramentas como o SIP Trace.
A melhor referência para o protocol SIP é a RFC3261. Ler as RFCs é sem dúvida entediante, mas você pode encontra-la em www.ietf.org/rfc3261.
Um bom tutorial sobre SIP pode ser encontrado na Universidade de Columbia. http://www.cs.columbia.edu/~coms6181/slides/11/sip_long.pdf.
No memos lugar você pode encontrar várias informações www.cs.comlumbia.eu/sip.
Outro bom tutorial pode ser encontrado no site da IPTEL. .http://www.iptel.org/files/sip_tutorial.pdf
Existem também listas de e-mail sobre SIP chamada SIP Implementors.
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Este é um portal excepcional a respeito da arquitetura do SIP.
Neste capítulo você aprendeu o que é o SIP seus principais componentes, SIP Proxy, SIP Registrar, User Agent Cliente, User Agent Server, Gateway PSTN. Entendeu como funciona a arquitetura SIP com seus SIP Proxies, entendeu o significado da URI e seus Aliases. Alem disto foi possível entender os principais tipos de mensagem SIP e seu processamento.
Página deixada intencionalmente em branco
O SIP Express Router é um servidor de voz sobre IP gratuito baseado no protocolo SIP (Session Initiated Protocol, RFC3261) voltado a aplicações de grande volume. Ele foi criado para atender infra-estruturas de voz sobre IP de larga escala. O servidor mantém o registro dos usuários, configura as sessões voip, encaminha mensagens instantâneas e cria espaço para novas aplicações. Sua interoperabilidade comprovada garante integração simples com componentes de outros fornecedores. Isto elimina a possibilidade de ficar travado em um único fabricante.
O OpenSER tem um modelo flexível de plug-in para novas aplicações. Terceiros pode facilmente ativar seus plug-ins com o código do servidor e prover deste modo serviços avançados. Desta forma, plug-ins tais como contabilização usando o protocolo RADIUS, gateways de SMS, queries ENUM, ou agente de presença já foram desenvolvidos e são fornecidos como recursos avançados. Outros módulos estão a caminho: controle de firewall, postgres, drivers de LDAP e mais.
Sua performance e robustez permitem a ele servir milhões de usuários e acomodar as necessidades de grandes operadoras. O SIP Express Router é extremamente configurável para permitir a criação de várias políticas de roteamento e admissão bem como serviços novos e personalizados. Sua configuração flexível permite à ele servir muitos papeis como barreira de segurança, servidor de aplicações e proteção à um gateway com a rede pública de telefonia.
O SER é mantido pela IPTEL (www.iptel.org) que saiu da companhia nacional de pesquisa alemã Fhg Focus. O site de iptel é a fonte primária de informações sobre o SER.
Recentemente houve uma ramificação chamada openser (www.openser.org). Começamos este material usando o SER carregado da iptel, mas no meio do caminho decidimos trocar para o OpenSER. O grupo de desenvolvimento do OpenSER se encontra mais ativo e novas versões estão sendo lançadas. Muito da documentação do SER data de 2003 e não tem sido freqüentemente atualizada depois que a empresa foi comprada pela Tekelec. Todas as vezes que nos referirmos ao SER, na verdade estaremos nos referindo a versão 1.0.0 do OpenSER que será usada em todos os labs deste material.
Baseado nos últimos padrões, o OpenSER inclui suporte para o servidor de registro, de proxy e de redirecionamento (Registrar, SIP Proxy e SIP Redirect Mode). Além disso ele atua como um servidor de aplicações com suporte para “instant messaging” e presença incluindo 2G/SMS e Jabber Gateway, uma linguagem de políticas de controle de chamadas, tradução de números de chamada, planos de discagem provados, ENUM, AAA. Ser roda nas principais vertentes do Linux, Solaris e suporta ambos o Ipv6 e Ipv4. É possível manter múltiplos domínios e redundância da base de dados é suportada também.
O OpenSER foi criado com os seguintes objetivos em mente:
Velocidade
Com o OpenSER, milhares de chamadas por segundo podem ser obtidas mesmo em plataformas de baixo custo. Esta velocidade permite que redes sejam configuradas com um custo baixo e de simples gerenciamento. Esta velocidade foi obtida com uso de um código customizado em ANSI C combinado com instruções em Assembler e usando as últimas melhorias do SIP.
Flexibilidade
O OpenSER permite que seus usuários definam o seu comportamento. Administradores podem escrever scripts em texto que determinam as decisões de roteamento SIP, o principal trabalho de um servidor proxy. Eles podem usar o script para configurar numerosos parâmetros e introduzir uma lógica adicional. Por exemplo, os scripts podem determinar para que destinos “record routing” deve ser feito, quem será autenticado, que transações devem ser processadas com estado e que pedidos devem ser processados pelo proxy ou redirecionados.
Possibilidade de crescimento
O OpenSER pode ser estendido linkando novos códigos em C. O novo código pode ser desenvolvido de forma independente do núcleo do OpenSER e ser linkado em tempo de execução. O conceito é similar ao do servidor WEB apache.
Portabilidade
Por ser escrito em ANSI C, ele tem sido testado em PC/LINUX e SOLARIS. Versões para BSD e IPAQ/LINUX existem.
Interoperabilidade
OpenSER é baseado no padrão SIP. Ele passou por testes extensivos com produtos de outros fornecedores ambos nos laboratórios da IPTEL e no SIP Interoperability Tests (SIPIT).
Pequeno tamanho
O núcleo do OpenSER é de 300K, com alguns módulos adicionais chega até 630K.
Nesta seção vamos ver os casos mais comuns de uso do SIP. Em todos estes cenários, o SIP Express Router pode facilmente ser instalado como uma cola entre todos os componentes SIP, sejam ele softfones, hard-phones, gateways PSTN e quaisquer outros dispositivos compatíveis com SIP.
Alguns provedores para atrair clientes vão oferecer serviços de valor agregado. Em alguns casos VoIP poderá ser uma opção. No Brasil, várias empresas já oferecem serviços de VoIP com valores inferiores aos do mercado de telefonia convencional. Outros serviços são instant messaging, e unified messaging. O OpenSER foi criado para atender redes de larga escala, pela sua capacidade de atender um grande número de clientes.
ITSPs (Internet Telephony Service Providers) oferecem um serviço de interconectar usuários de telefonia usando um softfone à rede pública de telefonia. Isto pode reduzir os custos em ligações DDD, DDI e para celulares. O OpenSER pode ser facilmente configurado para esta aplicação.
Diversas universidades vêm usando o OpenSER como um SIP Proxy para telefonia IP e Instant Messaging. Podemos citar a universidade de Columbia e o MIT como usuários destas estruturas que permitem a comunicação de um telefone SIP para outro entre as universidades . Em outubro de 2005 esta rede chegou à cerca de 200000 endereços conectados. Maiores informações podem ser obtidas em: http://www.internet2.edu/sip.edu/. Boa parte destes servidores usam o OpenSER.
É comum que orgãos de governo regulem o uso de VoIP entre suas unidades. Um projeto que tem se tornado comum é o uso do SIP Express Router para controle de numeração e centralização da sinalização SIP, liberando cada órgão para adquirir sua própria solução (PBX) baseada em SIP RFC 3261 e integrando soluções de diferentes fabricantes.
O OpenSER é construído sobre um núcleo que é responsável pela funcionalidade básica e pelo manuseio das mensagens SIP. A maior parte da funcionalidade do OpenSER é executada a partir de seus módulos. Os módulos do OpenSER expõe sua funcionalidade de forma que possam ser usados dentro do arquivo openser.cfg. O arquivo de configuração openser.cfg controla que módulos são carregados e permite configurar parâmetros que regulam o funcionamento dos módulos. O openser.cfg é o principal arquivo de configuração do OpenSER.
O OpenSER tem sete seções:
· Definições globais
o Esta porção do OpenSER contém o endereço IP e a porta no qual ele deve ouvir e nível de debug. São opções do processo do OpenSER.
· Módulos
o Contém a lista de bibliotecas externas que são necessárias para expor funcionalidades que não estão disponíveis no núcleo. Os módulos são carregados com o comando loadmodule.
· Configuração dos módulos
o Vários módulos possuem parâmetros que precisam ser passados adequadamente. Estes parâmetros são configurados com o comando modparam(“nome do módulo”, “parâmetro do módulo”, valor do parâmetro).
· Bloco de roteamento principal
o O bloco de roteamento principal é onde começa o processamento das mensagens em SIP. Ele controla como cada mensagem recebida é processada.
· Bloco de roteamento secundário
o Além do bloco principal, a seqüência de comandos pode ser desviada usando o comando route. Na seção secundária estão estes route() que são como subrotinas.
· Bloco de roteamento de respostas
o Blocos de resposta (Reply) são usados para processar os Reply’s, normalmente as mensagens (200 OK).
· Bloco de roteamento de falhas
o Blocos de roteamento de falhas são usados para processar condições de falha como ocupado ou timeout.
De maneira a entender o OpenSER, é preciso entender três conceitos do mundo SIP.
· Transação SIP
o Uma mensagem SIP (e quaisquer reenvios) e sua resposta direta (Exemplo o usuário envia um REGISTER ao OpenSER e recebe OK);
· Diálogo SIP
o Uma relação entre duas entidades SIP que exista por algum tempo (Exemplo, um diálogo estabelecido desde o INVITE terminando com o BYE).
· Sessão
o Um fluxo de mídia (áudio/vídeo) entre duas entidades SIP
O openser.cfg é um script que é executado para cada mensagem SIP recebida. Por exemplo, o usuário A quer falar com o usuário B e envia uma mensagem do tipo INVITE. Esta mensagem é processada no bloco de roteamento principal (route{}). O processamento continua até encontrar um ponto onde o processamento é encerrado com um t_relay() (encaminhar), um sl_send_reply() (para enviar um erro) ou ainda descartar a mensagem chegando ao fim do bloco ou usando o comando exit().
É importante entender os processo básicos esperados de um proxy segundo à RFC3261. Sem entender estes processos é difícil entender como configurar o Proxy Server.
Cada proxy tomará decisões de roteamento, modificando o pedido antes de encaminhá-lo para o próximo elemento. As respostas serão roteadas através do mesmo conjunto de proxies atravessados pelo pedido na ordem inversa.
Um proxy pode operar em modo “stateless” (sem manutenção de estado) ou “stateful” com manutenção de estado. Quando o proxy atua apenas como um simples encaminhador dos pacotes. Ele encaminha os pacotes para um único elemento determinado apenas pelo pedido. Um proxy atuando como “stateless” descarta quaisquer informações sobre a mensagem uma vez que tenha sido encaminhada. Isto limita o tratamento de falhas e bilhetagem por exemplo.
Quando o OpenSER sabe que mensagem OK pertence a cada INVITE, dizemos que ele está operando no modo Stateful isto significa na prática que você poderá gerenciar a resposta no bloco on_reply_route(). Com o processamento Stateless (ou simplesmente forwarding), cada mensagem no diálogo é gerenciada sem contexto. O encaminhamento sem estado é usado para um processamento simples das mensagens SIP como distribuição da carga.
Quando se quer implementar, recursos mais sofisticados como contabilização das chamadas, siga-me se ocupado, correio de voz você tem de usar o processamento Statefull. Cada transação será mantida na memória de forma que quaisquer falhas, respostas ou retransmissões sejam reconhecidas.
Uma confusão que ocorre com estes conceitos é que o processamento é Statefull por transação e não por diálogo SIP. Então é Statefull o processamento do INVITE e da sua resposta OK e não do INVITE até o BYE.
Quando em modo stateful, um proxy é simplesmente um processador de transações SIP. Quando operando neste modo de acordo com a RFC são necessários pelo menos os seguintes processos:
· Validar o pedido
· Pré-processar as informações de roteamento
· Determinar o alvo do pedido
· Encaminhar o pedido para cada alvo
· Processar todas as respostas
Antes que um proxy possa processar um pedido ele deve verificar a validade de mensagem. As seguintes validações são feitas:
· &nb
