Archive for the ‘Telefonia’ Category

JBoss In Bossa – Apresentação Mobicents

maio 8, 2010

Pessoal,

Hoje eu e o Antonio fomos ao JBoss In Bossa 2010 palestrar sobre Mobicents.Estávamos meio ansiosos em relação a palestra porque telefonia não é um assunto que seja do conhecimento e do cotidiano da maioria dos desenvolvedores.

Estavam presentes cerca de 20 pessoas e como a maioria não conhecia de telefonia, que é o esperado neste tipo de evento, fizemos uma apresentação que apresentou mais conceitos nos 45 minutos iniciais e na cerca de 1 hora e 15 minutos restantes mostramos o código necessário para esta implementação.

Espero que as pessoas presentes  gostaram da palestra e fiquem à vontade para entrar em contato. Quem quiser acesso ao código é só ir no Git Hub do Antonio: http://github.com/antonioams .

Segue a apresentação que foi utilizada no evento. Maiores informações podem ser obtidas na página com detalhes da Palestra.

Mobicents: Arquitetura de uma plataforma de comunicações

maio 6, 2010

Como já foi dito no post inicial da série o Mobicents é um servidor de aplicação focado em aplicações de convergentes, entende-se por aplicações de convergentes aquelas que demandam de todos os recursos que um servidor de aplicações padrão (Web Container, Message Driven Beans, Enterprise JavaBeans, ORM, etc.) fornecem, e além disto, demandam de suporte a diversos protocolos de comunicação Real Time (SIP, XMPP/Jabber, MGCP, etc.), possibilitando a implementação de aplicações que integram recursos web com recursos de telecomunicações.

O Mobicents é a primeira implementação Opensource da JSR-240 JAIN SLEE (Service Logic Execution Environment) esta JSR define uma padrão para o desenvolvimento de um container para aplicações de telecomunicações que exigem um ambiente de execução de aplicações de alta capacidade de Throughput, com baixa latência, e alta escalabilidade, mais detalhes sobre o JAIN SLEE pode ser visto em: http://www.jainslee.org

Neste post iremos fornecer uma visão geral sobre a arquitetura do Mobicents, e também sobre os recursos fornecidos pelo mesmo.

O Mobicents foi desenvolvido em cima do JBoss, portanto ele desfruta de todos os recursos que o mais famoso servidor de aplicações open source fornece, tais como: console de gerenciamento Web, interface de gerenciamento JMX, SNMP, Container Web, JMS, EJB, ORM, etc.

A novidade que o Mobicents traz, fica por conta dos Resource Adapters ou simplesmente RA, pois todos os protocolos de comunicações suportados por ele são implementados como um RA, na figura abaixo temos as principais camadas da arquitetura do Mobicents:

Arquitetura Mobicents

JSLEE + J2EE Application Server

Container de aplicações, nesta camada temos o JBoss como um servidor de aplicações JavaEE, e além disto temos a implementação do JAIN SLEE, esta camada é responsável pela hospedagem das aplicações e gerenciamentos dos seus diversos recursos.

Management Interfaces

Nesta camada temos todas as interfaces de gerenciamento fornecidas pelo JBoss, Web Management Console, JMX Console, SNMP, etc. desta forma todos os recursos e aplicações disponíveis no Mobicents podem ser gerenciadas por todas as interfaces fornecidas pelo mesmo.

External Resources

Esta é a camada responsável por trazer todos os protocolos de comunicações, e/ou recursos necessários para o desenvolvimento de aplicações de telecomunicações para dentro do Application Server possibilitando as aplicações se utilizarem deste recursos externos que são chamados de RA ou Resource Adapters.

Cada Resource Adapter é responsável pela implementação de um protocolo de comunicação, ou de controle de um recurso externo, desta forma, temos RA’s para implementar protocolos como: SIP, Jabber, XMPP, MGCP, Diameter, dentre outros, e temos RA’s para controlar o Asterisk, e o próprio Mobicents MediaServer para agregar a capacidade de processamento de media (gravação, reprodução de aúdio e vídeo, reconhecimento de dígitos, transcodificação, etc.) dentro das aplicações.

Abaixo temos um exemplo, de qual componente roda em qual camada, além de exemplificar como as mesma se comunicam:

Funcionalidades fornecidas pelo Mobicents:

Protocolos de comunicações suportados

  • SIP
  • Jabber
  • XMPP/Jingle
  • Parlay
  • Diameter
  • MGCP
  • SMPP
  • SS7
  • Camel
  • XCAP
  • TCAP

Recursos de Media

  • RTP formats: G711, G729, GSM, SPEEX, PCM 16bit 8-44kHz (Mono/Stereo)
  • Audio Codecs: G711,G729,GSM, SPEEX
  • Geração e Detecção de sinais DTMF, BUSY, etc. for inband and outofband (RFC-2833) mode
  • Media files *.wav (G711, GSM, PCM), *.spx(SPEEX), *.gsm

Recursos JavaEE

  • JSP Container
  • JMS
  • MDB
  • EJB
  • LDAP
  • HTTP/HTTPS
  • JMX
  • SNMP
  • Etc.

Alta disponibilidade

  • Load Balancer
  • Multi node cluster
  • Session replication

Performance

  • Capacidade de processar até 750 Caps em um único servidor.
  • Possbilidade de montar um cluster com multiplos servidores em Load Balance

Aplicações que podem ser implementadas sob o Mobicents

  • Aplicações IVR
  • Voicemail
  • Unified Messaging
  • Plataforma de Pré pago
  • Plataforma de 0800
  • Softswitch
  • Location Based Services
  • Instant Messaging
  • Presence Server
  • Etc.

Como vocês podem ver quando se trata de aplicações para a Telecom o céu é o limite do Mobicents, pois com todos os recursos que ele já tem embutido mais as possibilidade que o próprio JBoss tem, é uma questão de criatividade, e tempo para implementar uma aplicação.

Abraços,

Antonio Anderson Souza

Colocando o Mobicents com SeamTelcoFramework para rodar

maio 6, 2010

Este post é um tutorial que visa guiar a instalação completa do ambiente de desenvolvimento de aplicações de telecomunicações com foco no protocolo SIP e tratamento de recursos de Media, utilizando o Mobicents e o SeamTelcoFramework o exemplo mais clássico deste tipo de aplicações são as tão famosas URA’s.

Estou utilizando um CentOS 5.4 como base para este tutorial, para quem estiver utilizando este tutorial em outro S.O. só tome cuidado com os caminhos de diretórios, pois podem ser diferentes.

Instalando o Eclipse

Efetue o Download do Eclipse Galileo Eclipse IDE for Java EE Developers para instalar o mesmo basta descompactar na pasta desejada.

Apenas para referencia o meu foi instalado em:

/home/usuario/apps/eclipse

Instalando o Mobicents

Efetue o Download do Mobicents 1.0 com Jboss 4.2.3 (estamos utilizando esta versão pois o SeamTelcoFramework ainda não é compatível com o Mobicents 2 e JBoss 5), para instalar o mesmo basta descompactar na pasta desejada.

Apenas para referencia o meu foi instalado em:

/home/usuario/apps/mss-1.0-jboss-4.2.3.GA

Instalando plugins necessários para o eclipse

  1. Adicione o Jboss tools update site através do menu “Window” > “Preference” > “Install/Update” > “Available Software”
  2. Vá no menu “Help” > “Intall Software”
  3. Selecione o site “Jboss Tools” (site que foi adicionado no passo 1)
  4. Selecione os pulgins listados abaixo que estão dentro de “All JBoss Tools” e prossiga com a instalação dos mesmos:
  • JBoss Tools RichFaces
  • JBossAS Tools
  • JBoss Seam

Instalar o Seam Runtime

Efetue o Download do JBoss Seam 2.1.1GA, para instalar o mesmo basta descompactar na pasta desejada.

Apenas para referencia o meu foi instalado em:

/home/usuario/apps/jboss-seam-2.1.1.GA

Configurando o JBoss Runtime Environment no Eclipse

Vá em “Window”> “Preferences” > “Server” > “Runtime environments” e adicione o Mobicents como um JBoss Community 4.2

Vá em “Window” > “Show view” > “Servers” Adicione um novo servidor baseado no JBoss 4.2 Runtime environment.

Configurando o Seam Runtime no Eclipse

Vá em “Window”> “Preferences” > “JBoss Tools” > “Web” > “Seam” e adicione o JBoss Seam 2.1.1

Pronto neste momento o seu ambiente de desenvolvimento está totalmente instalado, agora é começar a brincar com um projeto.

Criando o primeiro projeto

Crie um novo projeto do tipo “Seam web project”, clique em next até o formulário “Configure Seam Facts Settings”, neste formulário faca as seguintes configurações:

  • Crie um datasource
  • Renomeia os pacotes padrão para um nome apropriado
  • Desative a checkbox “create test project” (Não abordarei sobre os testes neste tutorial).
  • Feito isto clique em “Finish”

Ativar o SeamTelcoFramework em nosso projeto

Adicione os seguintes arquivos a pasta “WEB-INF/lib” do projeto:

Adicione o arquivo sip.xml ao diretório “WEB-INF” do projeto.

Pronto neste momento já temos tudo pronto para começarmos a implementar a lógica da aplicação.

Criando uma Classe para tratar as chamadas SIP

Adicione a classe FirstTelcoClass.java dentro do pacote “<seu pacote>.session”, esta classe implementa uma simples lógica de observar as requisições SIP (INVITE, BYE), quando receber um INVITE atender a chamada e anexar uma sessão de media do Mobicents a mesma, reproduzir um arquivo wav para que você possa ouvir a aplicação funcionando, e depois fazer um eco dos dígitos recebidos (a cada DTMF que você discar a aplicação reproduzirá o mesmo audio).

Inicie a o Servidor, aguarde até 0 Seam iniciar, pois as vezes ele demora algums segundos para subir, para ter certeza que o Seam iniciou verifique a seguinte mensagem no console “13:39:41,641 INFO  [SipApplicationDispatcherImpl] SipApplicationName : FirstTelcoProject/ServletName : SeamEntryPointServlet

Configurando o Mobicents para rotear as request INVITE para nossa aplicação

Após o servidor ter iniciado abra um browser com o seguinte endereço: http://127.0.0.1:8080/sip-servlets-management na coluna que tem o header INVITE adicione a nossa aplicação, apos adicionar clique em save.

Agora nossa aplicação esta pronta para atender chamadas e falar conosco.

Configurando o Ekiga para fazer chamadas

Adicione uma nova conta no Ekiga “Edit” > “Accounts”  > “New” e configure a mesma igual a imagem ao lado (senha pode colocar qualquer coisa).

Não esqueća de ativar a conta criada, deixando ativo a checkbox da mesma.

Hora de testar se tudo isto que fizemos esta funcionando

Utilizando o Ekiga digite qualquer string na caixa de texto na tela principal do mesmo, e clique no icone localizado a direita desta caixa de texto, neste momento o Ekiga enivará uma request INVITE para a nossa aplicaćão, que da forma que esta programada atendera a chamada e reproduzira um audio.

Bom pessoal é isto, agora já temos uma aplicaćão de telefonia baseada no SeamTelcoFramework rodando dentro do Mobicents, agora é hora de botar a sua cachola para funcionar e modificar esta aplicaćão adicionando novas funcionalidades, se quiser depurar a mesma é só colocar um breakpoint no eclipse e fazer a chamada no Ekiga.

Espero que este conetúdo seja util para vocês, qualquer duvida, sugestão, whatever deixa o seu comentário aqui, pois teremos prazer em responder.

Referencias:

http://groups.google.com/group/mobicents-public/web/seam-telco-framework-for-sip-servlets

http://groups.google.com/group/mobicents-public/web/user-guide

Abraços,

Antonio Anderson Souza

VVoIP (Voice and Video Over IP)

fevereiro 12, 2010

Introdução

Vou tomar a liberdade de me arriscar falando sobre algo que estou aprendendo, portanto caso tenha escrito alguma besteira, por favor deixe um comentário sobre o fato.  Venho trabalhando e um projeto de IVVR e estou estudando a comunicação VOIP com vídeo e videoconferência utilizando Asterisk 1.6 com diversos codecs.
A comunicação por vídeo-chamada está começando a tomar um novo rumo, com a melhoria da infra estrutura e novas tecnologias de compressão de dados, mantendo uma melhor qualidade de som e imagem possível.

Qualidade de imagem

No projeto em que estamos trabalhando esse é um fator muito importante, a compressão não pode prejudicar muito a qualidade da imagem nem o sincronismo dos quadros. Isto pode parecer um obstáculo para a transmissão de mídias pelas redes, mas é possível minimizar os problemas aplicando os estudos de Qualidade de Serviço.

Para que o video seja transmitido é necessário a sua compactação para economia de espaço da banda e o codec realiza a codificação e a decodificação. O aprimoramento dos padrões de compactação nos quais um codec se baseia proporciona maior qualidade de vídeo usando a mesma largura de banda de antes.

Padrões H (codecs)

CoDec é o acrônimo de Codificador/Decodificador, dispositivo de hardware ou software que codifica/decodifica sinais.

A União Internacional de Telecomunicações (ITU) é responsável por coordenar padronizações relacionadas a telecomunicações, os padrões iniciando com a letra H são padrões para codificação de video, sendo  do H.260 até H279 denominados coding of moving video.

H.261 – Video codec for audiovisual services at p x 64 kbit/s

Codec publicado como primeiro esforço para padronização de video digital e focado inicialmente em compressão de video digital priorizando aplicações de telefonia, suportando os tamanhos de video frame : CIF e QCIF

H.263 – Video coding for low bit rate communication

Padrão baseado no H.261, com uma performance de compressão aperfeiçoada permite que o video tenha diversas taxas apenas restrições impostas pela rede. Assim como o H.261 gera dados do tipo CIF e seus derivados sub-QCIF, QCIF, 4CIF e 16CIF

H.264 – Advanced video coding for generic audiovisual services

Este padrão oferece uma tecnologia de compactação avançada com uma experiência de vídeo superior a uma baixa taxa de bits.  Não há uma característica que se destaque isoladamente – todas as novas características trazem pequenas melhorias que, conjuntamente, provêm um grande impacto na taxa-distorção do H.264 relativamente a seus antecessores.

H.265

Já existe previsão, provavelmente para depois de 2010, para a criação de um novo padrão, o H.265, visando reduzir a taxa de bits pela metade (mantendo a mesma qualidade do H.264).

Cronologia do desenvolvimento dos diversos padrões de compressão de vídeo, apresentados isoladamente pelos órgãos ITU-T e MPEG, ou em um esforço conjunto de ambos [5].

Alguns protocolos

RTP – Real Time Protocol

É um protocolo utilizado para o transporte de mídias contínuas de tempo real em uma conexão ponto a ponto, como áudio, vídeo ou dados de uma simulação.

Este protocolo não reserva recursos nem garante qualidade de serviço (QoS), porém é freqüentemente utilizado em paralelo com o RTCP (RTP Control Protocol) permitindo que tenha uma certa monitoração da comunicação.

Diferentes tipos de mídia serão enviados em diferentes sessões de RTP mesmo que façam parte da mesma comunicação. Por exemplo, em uma videoconferência são transmitidos dois tipos de mídia (áudio e vídeo), os pacotes de áudio serão transmitidos por uma sessão RTP enquanto os pacotes contendo as imagens serão transmitidas por uma sessão RTP completamente diferente e independente.

RTCP  – Real Time Control Protocol

O protocolo de controle RTP é baseado na transmissão periódica de pacotes de controle para todos os participantes da sessão, usando o mesmo mecanismo de distribuição dos pacotes de dados.

Provê um retorno da qualidade do serviço (QoS) da distribuição de dados, alem de carregar o identificador do nível de transporte chamado CNAME para associar múltiplos fluxos de dados de um determinado participante num conjunto de sessões RTP, para sincronizar audio e video, por exemplo.

RTSP – Real Time Streaming Protocol

Um protocolo de aplicação desenvolvido pela IETF para o controle na transferência de dados com propriedades de tempo real, estabelecer e controlar um único ou vários streams sincronizados de mídias contínuas.

Um servidor streaming é o Darwin Streaming Server (DSS) que é o primeiro open source RTP/RTSP servidor de streaming.

Qualidade de Serviço (QoS)

QoS são mecanismos utilizados na rede para garantir que aplicações criticas como Voip tenham um bom desempenho com banda garantida.

Com uma banda de 128 kbps é possível transmitir vídeo e som de modo que o vídeo tenha 15 quadros por segundo e o áudio tenha qualidade próxima ao da conversa telefônica, mas 15 quadros por segundo está abaixo dos requerimentos humanos e o áudio com qualidade de conversa telefônica não seria aconselhável caso houvesse algo além de fala em seu conteúdo.

Estudos revelam que um vídeo com movimentos naturais e para preencher uma tela inteira, após compactação, ainda necessitaria 384 kbps para ser transmitido.

Uma pequena perda pode ser tolerável se a informação necessária chegar ao destino. No entanto se as perdas prejudicarem a compreensão dos dados estas se tornam inaceitáveis. É preciso estipular-se um limite máximo para estas perdas dependendo da aplicação e assegurar que este não seja ultrapassado.

A implementação de QoS se torna indispensável numa rede voip com video, ainda mais quando o vídeo se torna tão importante quanto a voz na comunicação.

Referencias :

[5] J. Golston and A. Rao, Video Compression: System Trade-Offs with H.264, VC-1 and Other Advanced CODECs, white paper, Texas Instruments, Aug. 2006.

http://www.divx.com/pt-br/technologies/h264

http://www.gta.ufrj.br/grad/01_2/vidconf/rtcp.html

Formspring: Porque mesmo com a banda larga o VoIP não se compara a qualidade da telefonia convencional?

fevereiro 2, 2010

Pensando em qualidade de Voz na internet, largura de banda não é o principal fator, pelo simples motivo de uma chamada sem compactação alguma de voz consome apenas 80kbps, com compactação pode chegar a consumir menos de 30kbps.

O principal fator para ter uma boa qualidade de Audio é a estabilidade da conexão, em termos mais técnicos é o tal do Jitter, a Voz não aceita grandes variações na velocidade de transmissão dos pacotes, não dá para um pacote chegar em 20ms, outro em 100ms, outro em 30ms, outro em 500ms, e assim por diante.

A Internet no Brasil tem melhorado muito mas ainda tem muito a melhorar em termos de estabilidade.

Em resumo para a Voz Sobre IP é melhor ter um link com menos banda estável, do que um bombado instável.

Pergunta feita de forma anônima via Formspring, o que você está esperando  Pergunta aí!

Formspring: Como começar no Mobicents ? Quero fazer uma URA. Vc pode me ajudar ?

fevereiro 2, 2010

Como começar no Mobicents ? Quero fazer uma URA. Vc pode me ajudar ?

Vamos lá, o Mobicents é o que chamo de Telecom Application Server, é um Servidor de aplicações para aplicações de Telecom, ele implementa o padrão JAIN SLEE (padronizado pelo JCP), este padrão determina uma série de regra para tornar rápido, simples, e confiável o desenvolvimento de aplicações para Telecom em ambiente Java, estas aplicações o foco deles são para rodar em Redes Inteligentes (IN), SIP, IMS, etc.

Para começar, como não sei se vocẽ já instalou o mobicents, recomendo a leitura do roteiro de instalação, e depois um tutorial sobre o desenvolvimento de uma aplicação IVR simples.

No google groups do projeto mobicents tem vários tutoriais, todos estão bem atualizados, o pessoal da Redhat estão dando uma garra neste projeto!

Espero que tenha ajudado! Qualquer dúvida pode me enviar email direto antonioams@gmail.com

Pergunta feita de forma anônima via Formspring, o que você está esperando  Pergunta aí!

Ensina aí VoIP

agosto 24, 2009

Dando continuidade a os cursos do Ensina Aí temos grande prazer de divulgar o tão esperado cursos de VoIP, abaixo segue os detalhes do curso:

Inscrição: por e-mail (ensinaai@voicetechnology.com.br).

Valor: gratuito.

Data: 31 de Agosto, 02, e 04 de Setembro das 18:30 às 21:30.

Carga horária: 9 horas.

Local: Voice Technology – Rua Líbero Badaró, 293 – cj. 30 A Centro – São Paulo (Edifício Conde de Prates).

Público Alvo: interessados em VoIP

Total de vagas: 15.

Instrutor: Antonio Anderson Souza

Conteúdo programático:

  • Introdução a voz sobre IP
  • Tendencias no mercado de Voz sobre IP
  • A telefonia convencional PSTN
    • Evolução da telefonia convencional
    • PSTN vs. VoIP
  • Protocolos VoIP
    • H323
    • SIP
    • RTP
    • Codecs
  • Casos de uso
    • Corporativo IP PBX Interno
    • Corporativo Hosted PBX
    • Carrier SIP Softswitch
    • Carrier Media/Application Server
    • Carrie IP Centrex
  • Elementos de uma rede SIP
    • User Agent Client
    • User Agent Server
    • Proxy
    • Registrar
    • Redirect Server
    • Back to Back User Agent
  • Protocolo SIP
    • Estrutura
    • Transações
    • Dialogos
    • User Agents
    • Cenários de sinalização
    • Principais RFC’s

Com que frequência irá ocorrer esse curso?

Irá depender de dois fatores: o feedback recebido nesta primeira realização e a procura pelo curso.

Não poderei participar dessa vez, poderei participar na próxima?

Claro! Aliás, aqueles que não podem participar desta primeira realização, por favor envie o e-mail demonstrando o interesse, pois assim será mais fácil de montar a segunda turma.

O curso será sempre o mesmo, ou haverá cursos mais avançados/específicos?

Novamente dependerá da procura pelo curso. Se você quiser sugerir algum assunto a ser abordado, sinta-se à vontade em comunicar. Assim, se várias pessoas sugerirem o mesmo assunto ou parecido, a probabilidade de ser realizar o curso é maior. Logicamente, que dependendo do conhecimento do ensinador, não vai me pedir um curso de culinária mexicana. (rsrs)

Tenho outras dúvidas, o que faço?

Envie um e-mail para ensinaai@voicetechnology.com.br com a tag [DÚVIDAS].

Faq copiado do QualidadeBR.

Café Com Bits – Portabilidade Numérica

fevereiro 2, 2009
Café Com Bits - 30/01/2009

Café Com Bits - 30/01/2009

São Paulo – No último dia 30 ocorreu mais uma edição do café com bits. O tema desta vez foi portabilidade númerica, assunto de extrema importância para empresas que desenvolvem software para telecomunicações. Ao longo do bate-papo foram apresentados os possíveis modelos de portabilidade existentes no mundo, dando enfase no modelo adotado pelo Brasil: o “All Call Query”.

O modelo “All Call Query” possui uma base de dados central com informações dos usuários que portaram seu números. As operadoras devem manter uma base de dados locais sincronizadas com a base de dados central.

No Brasil esse banco de dados centrais é mantido pela ABR Telecom, uma empresa formada pelas grandes operadoras e que tem por trás uma empresa americana chamada Clear Tech que forneceu a solução técnica.

O banco de dados central é Oracle e possui redundancia física e de redes, o acesso a esse banco de dados se dá através de um link TCP criptografado. Porém acessar esse banco custa caro, e as operadoras de pequeno e médio porte precisarão usar de sua criatividade técnica para conseguir reduzir o número de acessos necessários a essa base de dados central.

Durante o café fez-se uma comparação do sistema de tarifação brasileiro com o americano, destacando-se que nos EUA o custo da chamada telefônica é compartilhado entre quem recebe e quem a faz, além das tarifas tanto da telefonia móvel quanto da fixa serem muito próximas justificando a existência lá de portabilidade tanto entre números fixo e de celular.

O café foi apresentado por Saulo Scarpina e Karen Volcano da equipe de Qualidade e Testes, sob orientação de Elcio Jovelli e contou ainda com importantes participações de Jefferson Zanardi de Freitas, que forneceu  informações sobre o modelo de portabilidade brasileiro, e Rodrigo Zenji, que explanou sobre o funcionamento do sistema de tarifação norte-americano.

A importância dos Codecs

dezembro 21, 2008

Caros colegas,

Novamente tomo a liberdade para escrever no blog do Ensinar. Acredito que este seja um assunto de interesse geral e voltado a todos que trabalham com telefonia IP e VoIP. Este artigo busca fazer entender o que é um codec, quais suas características e critérios para implementação dentro de um servidor Asterisk. Devo frisar que a fonte desse post provém do conteúdo da revista Linux Magazine “Especial 3 – VoIP com Asterisk”, baseado em uma análise escrita por Flávio E. Gonçalves.

Um boa leitura para todos!

 

Introdução

Primeiramente devemos definir o que é um codec. Um codec (coder-decoder) é um codificador-decodificador (traduzindo ao “pé da letra”), de um sinal ou um fluxo de dados digitais. Temos um exemplo abaixo que mostra como funciona a codificação PCM (Pulse Code Modulation):

No caso um sinal analógico de 4000 Hz (faixa da voz humana) é amostrado , quantizado e codificado, gerando um fluxo digital de 8000 amostras, cada uma codificada em 8 bits de dados, consumindo 64kbps de banda, que será transmitido para o sistema. De acordo com a norma da ITU G.711 existem 2 tipos de algoritmos para codificar um sinal PCM: Mu-law e A-law, designados no Asterisk como “ulaw” e “alaw”. O primeiro é usado nos EUA e Japão, enquanto o segundo é usado em quase todos os países. Existem várias características que devem ser entendidas em relação a um codec. Abaixo temos uma tabela com os codecs mais conhecidos e usados no Asterisk e a seguir focaremos em algumas características e pontos importantes a respeito dos codecs.

 

Tabela comparativa dos Codecs
Codecs G.711 G.729 G.723 GSM iLBC
Largura de Banda (Kbps) 64 8 5,3 ou 6,3 13 13,3 ou 15
Complexidade (Mips) 0,35 13 19 5 18
Resistência a perda de pacotes ——- 3% 3% 3% 5% ou 7%
MOS 4,41 4,14 3,79 N/A 4,07

 

  • Qualidade de Voz

A qualidade de voz é medida em MOS (Mean Opinion Score, ou média dos resultados das opiniões). Os testes para MOS seguem a norma P.800 da ITU. O MOS varia em uma escala de um (qualidade ruim) a cinco (qualidade excelente);

  • Compensação (ocultação)

Conhecida como ocultação da perda de pacotes (Packet Loss Concealment). Codecs com essa característica conseguem compensar eventuais perdas de pacotes de voz, “ocultando” isso para o usuário final;

  • Silêncio e ruído

Alguns codecs permitem a detecção de silêncio ou intervalo sem presença de voz, fazendo com que esse “vazio” não seja transmitido, economizando banda. Infelizmente o Asterisk  não suporta (ainda) a inclusão desse recurso;

  • Forma de licenciamento

Nem todos os codecs são gratuitos. Alguns como o G.729 e o G.723 necessitam ser licenciados. O custo não é alto: cerca de 10 dólares por canal simultâneo.

Complexidade

A complexidade de um codec é medida em MIPS (milhões de instruções por segundo). Chega a ser difícil comparar a complexidade em MIPS, pois ela é dependente de um processador. Em muitos casos os codecs são processados em DSP’s (Digital Signal Processor), preparados, construídos e até programados para isso, o que alivia a CPU principal do processo de codificação e decodificação. Logo o processamento de codecs pode ser feito tanto por software como por hardware.

Escolhendo o codec

Cada tipo de codec possui uma aplicação diferente, dependente do sistema, ambiente e solução a que ele for implementado. Por isso, saber escolher pode fazer uma grande diferença. Abaixo temos uma análise para cada tipo de rede:

  • Codecs para redes locais

Em redes locais geralmente temos banda passante em abundância, de forma que o nível de compressão tem um peso pequeno na escolha do codec a ser utilizado. Nesse caso uma escolha natural seria o g.711, que ocuparia cerca de 100kbps (incluindo os cabeçalhos) para cada ligação;

  • Codecs para redes WAN

Em uma rede WAN (Wide Area Network), normalmente temos uma banda passante pequena (64, 128 ou 256 Kbps) onde podemos priorizar o tráfego de voz. Nesse tipo de redes, normalmente, é pouco comum ocorrerem perdas de pacotes. Há três bons codecs para esse tipo de rede: o G.729 provavelmente se destaca, pois provê uma excelente qualidade de voz com uma compressão de 8 para 1; o G.723 permite taxas de compressão ainda maiores, mas com certa perda de qualidade; por fim temos o GSM que é uma alternativa para aqueles que procuram custo/benefício. O ponto negativo do GSM fica para o fato de não ter suporte ao codec na maioria dos telefones IP’s e ATA’s.

  • Codecs para Internet

Em uma rede com Internet há dois desafios: banda passante e falta de controle do meio. Por isso temos uma latência alta e jitter (variação da latência), que culminam com a perda de pacotes. Alguns codecs foram desenvolvidos com esses requisitos em mente. O codec mais indicado para esse tipo de rede é o iLBC, que tem uma boa resistência a perda de pacotes e usa pouca banda passante. Mais informações podem ser encontradas na tabela de codecs desse post.

Consumo

A banda usada em codecs é reservada apenas para o que chamamos de payload, ou “carga”, de voz. Para que um pacote de voz possa trafegar pela rede é preciso que ele seja encapsulado usando cabeçalhos de rede. Uma sessão de voz usando o codec G.729 em uma rede Ethernet , por exemplo, consome cerca de 30 Kbps (quase 4 vezes o tamanho do payload!). Para verificar quanto cada codec consome, em qualquer tipo de rede, podemos usar uma calculadora de banda.

Codec no Asterisk

Esse e os dois tópicos abaixo já são mais técnicos. Para selecionar um codec no Asterisk, é preciso editar o canal relativo ao protocolo desejado (IAX, SIP, H323, etc). Dentro de cada canal é possível escolher os codecs para todos os usuários, presente na seção [general], ou individualmente para cada user em [peer/user].  Por exemplo, para selecionar os codecs para todos os usuários, usamos a seção [general]:

[general]
disallow=all
allow=alaw

E individualmente, por [peer/user]:

[40200]
disallow=all
allow=g729

Transcodificação

Em algumas situações o Asterisk precisa converter os pacotes de voz de um codec para o outro.  Esse processo é conhecido como transcodificação e consome muitos recursos de CPU. Sempre que há conversão de pacotes de voz de um codec para o outro, inclusive em leitura e gravação de gravações de dados, ocorre a transcodificação. Se esse processo puder ser evitado pode-se poupar recursos de CPU e evitar a compra de licenças desnecessárias.

Empacotamento do RTP

Na versão 1.4 do Asterisk também é possível alterar os moldes de empacotamento de cada codec. Pode-se agora aumentar ou diminuir o payload de cada codec, por exemplo, usando 60ms ao invés de 20ms, no caso do codec G.729, impactando no consumo de banda. O empacotamento é definido na instrução Allow:

allow=g729:60

Maiores detalhes podem ser encontrados no site da Digium.

Conclusão

A escolha correta do codec faz toda diferença na implementação de uma solução de telefonia IP ou VoIP. Ela influencia, sobretudo, o consumo de banda, número de canais simultâneos e qualidade de voz para o usuário final. Por isso escolha o codec mais correto para o seu tipo de rede, use técnicas de QoS (qualidade de serviço), priorize o tráfego de pacotes de voz e evite as transcodificações.

O que é o que no mundo voip

dezembro 6, 2008

Estudando voip e sip , vi que muitas vezes somos capazes de entender
contextos e situações porém as vezes falta saber o que é exatamente
cada um dos elementos que fazem parte deste ambiente.
Sendo assim resolvi definir alguns destes elementos

Definiçao Voip –  Voz sobre IP (também conhecido por VoIP, Telefonia IP e Telefonia Internet) se refere à tecnologia que permite a tramsmissão de sinais de voz por uma rede seja ela privada ou uma rede pública como a internet.
É necessário um telefone sip OU um telefone VoIP para que esse tipo de telefonia seja possível. As ligações podem ser feitas para qualquer lugar tanto para números telefônicos VoIP quanto para pessoas com números telefônicos convencionais.

É necessário um telefone sip , mas … o que é um telefone sip ?

Telefone SIP, Telefone VOIP ou soft phones são termos sinônimos entre si e usados par designar telefones que permitem fazer chamadas através da tecnologia VoIP (voz sobre protocolo da internet).

Existem dois tipos de Telefones SIP. O primeiro tipo é o Telefone SIP hardware, que se assemelha a um aparelho de telefone comum, mas pode receber e fazer chamadas usando a internet ao invés do sistema tradicional PSTN.
Os telefones SIP podem também ser com base em software. Estes permitem que qualquer computador seja usado como telefone através de um fone de ouvido com um microfone e/ou placa de som. É necessário também ter uma conexão de banda larga e conexão com um Provedor VOIP ou Servidor SIP.

Entendi tudo, menos o que é um servidor sip ? 

Um servidor SIP é o componente principal de um IP PBX e lida com a organização de todas as chamadas SIP na rede. O servidor SIP também é conhecido por Proxy SIP ou SIP Registrar.
ok , mas e sip e ip pbx ?

SIP é uma sigla para Protocolo de Iniciação de Sessão (Session Initiation Protocol – SIP) é um protocolo de aplicação, que utiliza o modelo “requisição-resposta”, similar ao HTTP, para iniciar sessões de comunicação interativa entre utilizadores

faltou o ip pbx…

IP PBX é um sistema telefônico que gerencia telefones na empresa e atua como o “gateway” para redes externas. Ao contrário de um PABX convencional que exige duas redes separadas, uma para dados e outra para voz , o IP PBX trabalha com ambas (dados e voz) em uma unica rede e pode ser usado com telefones IP, softphones e tradicionais telefones conectados a adaptadores Ethernet (um ATA / “Lingo Box”) ou PCs

O que é um Sistema de Telefonia PBX?

PBX significa Private Branch Exchange (troca automática de ramais privados). É uma rede de telefonia privada usada por uma empresa. Os usuários de um sistema de telefonia PBX compartilham um número de linhas externas para a realização de chamadas externas.

Um PBX conecta os telefones internos de uma empresa e também os conecta à rede pública (PSTN). Uma das tendências mais recentes da telefonia PBX é o VoIP PBX, também conhecido como IP PBX que usa o protocolo de Internet para a transmissão de chamadas.

Atualmente, há quatro opções diferentes de telefonia PBX:

PBX
Hosted/ PBX Virtual
IP PBX
Hosted/ IP PBX Virtual

IP PBX é um sistema de telefonia PBX com base em software que ajuda na realização de certas tarefas e oferece serviços que podem ser difíceis e caros de simplementar usando um sistema PBX tradicional.

E o ATA ?

Adaptador de Telefone Analógico: Um dispositivo que se liga em uma conexão de Internet banda larga em umas das extremidades e em telefones comuns na outra, permitindo a comunicação entre os dois

O que é DID ?

DID – Direct Inward Dialing é um recurso oferecido por companhias telefônicas para serem usadas com o sistema PBX de seus clientes, através do qual a companhia telefônica agrupa um conjunto de números associados com uma ou mais linhas telefônicas.

Tem o propósito de permitir que uma companhia designe um número específico para cada funcionário, sem que cada um precise de uma linha telefônica separada. Desse modo, o tráfico telefônico pode ser dividido e gerenciado mais facilmente.

O que são codecs ?

Codecs são usados para converter um sinal analógico de voz versão codificada digitalmente. Codecs variam na qualidade sonora, largura de banda necessária entre outros requisitos computacionais
Cada serviço, programa, telefone, Gateway, etc suporta vários codecs diferentes, e quando falam entre si negociam qual codec utilizar.

Tipos de codecs mais usados atualmente:

GSM – 13 Kbps (full rate), quadros de 20ms
iLBC – 15Kbps, quadros de 20ms: 13.3 Kbps, quadros de 30ms
ITU G.711 – 64 Kbps, baseado em amostra. Também conhecido por alaw/ulaw
ITU G.722 – 48/56/64 Kbps
ITU G.723.1 – 5.3/6.3 Kbps, quadros de 30ms
ITU G.726 – 16/24/32/40 Kbps
ITU G.728 – 16 Kbps
ITU G.729 – 8 Kbps, quadros de 10ms
Speex – 2.15 to 44.2 Kbps
LPC10 – 2.5 Kbps
DoD CELP – 4.8 Kbps

O que é RTP ?

RTP – significa em inglês Real Time Transport Protocol (Protocolo de Transporte em Tempo Real) e determina um formato de pacote padrão para o envio de áudio e vídeo pela Internet. É definido pela RFC 1889. Foi desenvolvido pelo grupo Audio Video Transport Working e foi primeiramente publicado em 1996.

RTP e RTCP estão intimamente interligados – o RTP entrega os dados e o RTCP é usado como um feedback da qualidade do serviço.
E esse RTCP ?

RTCP significa em inglês Real Time Transport Control Protocol (Protocolo de Controle de Transporte em Tempo Real) definido pela RFC 3550. O RTCP funciona juntamente com o RTP. O RTP realiza a entrega dos dados, enquanto o RTCP envia pacotes de controle aos participantes de uma chamada. Sua função principal é fornecer um feedback da qualidade dos serviços oferecidos pelo RTP.

O que é enum  ?

ENUM significa em inglês Telephone Number Mapping (Mapeamento de Números de Telefone). Esta abreviação esconde em si uma ótima idéia: ser alcançável em qualquer lugar do mundo com o mesmo número de telefone – e com o melhor e mais barato reencaminhamento de chamadas. O ENUM conecta um número de telefone a um endereço da Internet que é publicado no sistema DNS. O proprietário de um número ENUM pode, portanto, publicar para onde uma chamada deve ser reencaminhada através de uma entrada DNS. E mais, diferentes rotas podem ser determinadas para diferentes tipos de chamadas – por exemplo, você pode determinar um reencaminhamento diferente se a chamada vier de um fax. O ENUM necessita do número de onde a chamada se origina para operar.
O número do ENUM é registrado de modo semelhante ao registro de um domínio. No momento, muitos registradores e provedores VoIP estão fornecendo este serviço de graça.
O ENUM é um padrão novo e ainda não muito divulgado. Apesar de parecer estar prontopara causar uma nova revolução nas comunicações e mobilidade pessoal.

O que é  CDR ?

Call Detail Record (Gravador de Detalhes de Chamada)
Um gravador de dados das chamadas em um sistema voip.
Grava informações como origem , destino , hora de inicio , finalização
e duração de uma chamada

fontes:

www.voip-info.org
www.3cx.com.br
http://www.primusvoip.co.uk/jargon_buster.html