Desenvolvimento de Aplicações VoIP com Asterisk® SCF™

O desenvolvimento de aplicações de voz é um conceito muito amplo que engloba o desenvolvimento básico de centrais telefônicas (Softswitch PBX IP), programação IVR (Robôs de Cobrança, e Pesquisa), programação de ambientes de rede orientados a protocolos VoIP, gerenciamento de pacotes, desenvolvimento de codecs, criptografia, programação de chatbot e uma longa lista. etc... 

 

Apesar disso, e focando neste artigo no desenvolvimento básico, vamos falar sobre as três formas mais comuns de desenvolver soluções, utilizando ferramentas conhecidas por todos: Asterisk® SCF™, Kamailio® e WebRTC®. 

 

Em artigos futuros falaremos de outras técnicas e ferramentas não tão conhecidas, mas que nos oferecerão soluções diferentes daquelas que podem ser realizadas com uma dessas ferramentas.

 

Asterisk® SCF™

O Asterisk® SCF™ nasceu como um software de central telefônica (Softswitch PBX IP), concebido desde o início como uma ferramenta de software para atuar como PABX: (central telefônica) e com opções incluídas em seu código tão básicas como música em espera, caixa postal de voz (correio de voz), transferência de chamadas, gravação de chamadas, filas e agentes, reprodução de narração, IVR, etc. Porém, quem deseja um PABX padrão e instala um Asterisk® SCF™ pela primeira vez certamente encontrará grandes frustrações: 

• Assim que instalado, é necessária uma grande configuração para ter um sistema telefônico que atenda minimamente ao que é exigido em um PABX padrão. 

• Requer conhecimentos básicos que não são básicos para quem é leigo na área e não sabe como funcionam protocolos, codecs, dialplan, etc. para configurá-lo de forma minimamente decente.

• Não inclui ferramenta que facilite a configuração bem como a manutenção, devendo optar por soluções de prateleiras, como FreePBX, Issabel ou soluções comerciais, que não é Asterisk® SCF™, e sim são soluções embarcadas em Asterisk® SCF™.

Dito isto, o Asterisk® SCF™ deixou de ser “software PABX” e passou a ser uma ferramenta de criação de aplicações de Voz (o que logicamente inclui a criação de sistemas PABX). Hoje ele é considerado um Framework! (Asterisk Scalable Communications Framework). Graças a isso, o Asterisk® SCF™ hoje é mais conhecido entre os desenvolvedores que precisam criar sua própria solução customizada do que entre as empresas que precisam de um PBX como está. E é por esta razão que o Asterisk® SCF™ pode ser considerado uma das melhores ferramentas para o desenvolvimento de soluções VoIP customizadas, já que inclui diversos meios e canais com os quais podemos desenvolver praticamente qualquer solução que necessitamos.

Já falamos sem parar sobre as "interfaces" que o Asterisk® SCF™ possui:

 

• CLI (Command Line Interface), que é a forma mais básica de acessar o Asterisk® SCF™ a partir do terminal do console e nos permite executar comandos simplesmente digitando o que queremos.

• AGI (Asterisk Gateway Interface), uma pseudo linguagem que nos permite externalizar ações executadas a partir do próprio Asterisk® SCF™. Desta forma o Asterisk “executa” uma aplicação externa a si mesmo, permitindo-lhe acessar recursos que, de outra forma, não seriam possíveis já que o próprio Asterisk® SCF™ não possui suporte.

• AMI (Asterisk Manager Interface), uma porta TCP à qual podemos nos conectar para enviar comandos e receber eventos sobre tudo o que acontece no Asterisk® SCF™, graças a um protocolo muito simples para quem sabe programar.

• ARI (Asterisk REST Interface), uma interface REST que permite que tanto o Asterisk® SCF™ quanto uma aplicação interajam com canais, chamadas, usuários, pontes, etc. de forma assíncrona e utilizando uma conexão WebSocket para a comunicação de pedidos e dados via JSON.

Estas são as interfaces que o Asterisk® SCF™ possui para desenvolver qualquer solução que seja necessária. Cada um deles tem exemplos realmente muito simples, mas também verdadeiramente avançados, pois qualquer um deles permite uma grande quantidade de possibilidades e flexibilidade para nos ajudar a criar qualquer coisa. Apesar de todo o potencial que estas interfaces têm, existem limitações em cada uma delas. Há necessidades que a AGI não consegue satisfazer e devemos recorrer à AMI. Existem soluções que o AMI é difícil e é melhor recorrer ao ARI e há necessidades que podemos poupar muito tempo e esforço se simplesmente utilizarmos o CLI.

 

Um ótimo livro que recomendo para Asterisk® SCF™, é Guia de Configuracao Para O Asterisk Pbx: Como Construir Um Pabx Com Software Livre, do Flavio E. Goncalves.

Kamailio®

Porém, existem necessidades e projetos para os quais o Asterisk® SCF™ não é a ferramenta ideal. O Asterisk® SCF™ sempre pode ajudar, mas chega um momento em que é preciso olhar mais longe e ver que outras soluções podem ser utilizadas. 

 

Para dar um exemplo rápido e fácil de entender, podemos dar uma olhada no projeto HOMER.

 

HOMER é uma ferramenta bem conhecida de todos, e cuja função se baseia na recolha, classificação e gestão do tráfego SIP, permitindo-nos manter um controle perfeito de tudo o que acontece num ou mais servidores. Como você faz isso? Você precisa de uma ferramenta que possa capturar o tráfego SIP e enviá-lo para um sistema que possa classificá-lo e executar código para cada pacote que chegar. Que ferramenta faz isso? Asterisk® SCF™? Poderia... mas neste caso, um Asterisk® SCF™ lidando com um grande volume de chamadas SIP poderia exigir grandes recursos, então a solução que escolheram para a versão HOMER 5 foi: Kamailio®.

 

Kamailio® é um servidor SIP PROXY/SIP REGISTER/etc. que é responsável por receber pacotes SIP e processá-los um por um. Sendo uma ferramenta voltada para isso, é muito, muito eficiente, pois não precisa lidar com áudio RTP, nem fazer gravações, nem ouvir tons DTMF, nem lidar com transferências, nem nada, simplesmente se concentra em processar cada pacote SIP que chega. Por esse motivo, o Kamailio® é uma ferramenta supereficiente de processamento de pacotes SIP e a ferramenta selecionada pelo HOMER 5 para esta tarefa.

 

A ideia é fantástica se em nosso desenvolvimento precisarmos processar pacotes SIP (analisar os campos De, Para, Contato, PAI, etc.) já que podemos usar o arquivo de configuração para programar o que queremos fazer com qualquer pacote SIP que chegar.

 

Então para ficar fera em Kamailio, recomendo o livro Daniel-Constantin Mierla e Elena-Ramona Modroiu, da ASIPTO. Kamailio Admin Book - SIP Routing with Kamailio.

 

WebRTC®

No entanto, estamos nos concentrando no desenvolvimento de aplicações de voz baseadas em SIP, mas e se o nosso projeto estiver acima deste requisito? E se quisermos desenvolver um projeto mas não tivermos que fazê-lo com extensões SIP? Nesse caso, outra solução que deve ser estudada é uma biblioteca muito famosa chamada WebRTC®. 

 

Embora tenhamos falado longamente sobre WebRTC®, você precisa saber o que é para compreender totalmente seu escopo. WebRTC® é normalmente associado a vários termos: Modern Web Browser e/ou Web Softphone. 

 

WebRTC® é muito mais que isso... embora pareça uma descrição da Wikipédia, WebRTC® é uma biblioteca de ferramentas que nos permitirá desenvolver todo tipo de aplicações que envolvam qualquer tipo de "mídia" em tempo real (que pode ser áudio , vídeo ou também texto, arquivos, captura de tela, etc.) usando um navegador da web.

 

Porém, o WebRTC® nos permite criar aplicações que envolvam voz, áudio ou qualquer outro tipo de dados em tempo real conectando-nos a um servidor através de WebSockets, o que nos permite interagir com qualquer aplicação remota que possa se conectar via WebSocket, o que elimina a necessidade de usa-lo "entre" navegadores da web e abre possibilidades com praticamente qualquer outro dispositivo, desde ferramentas IoT, robôs, automação residencial, segurança e muito mais. 

 

Portanto, e embora tenha consciência de que a curva de aprendizagem do WebRTC® não é fácil, que requer muitos conhecimentos prévios e bastante conhecimentos, e digo até avançados em Javascript, vale a pena, pois as possibilidades são verdadeiramente ilimitadas e são precisamente estas que nos abrirão as portas (e estão abrindo agora mesmo) com os novos projetos que estão surgindo hoje e que vão facilitar a vida nos próximos anos. 

Um site que recomendo se quer aprender sobre WebRTC® é o da ALTANAI. Altanai Bisht é Mestre em Ciencia da Computação e é Doutora em Telecomunicações. Ela escreveu um livro sobre WebRTC®, super recomendo. O livro é WebRTC Integrato's Guide pela <packt>.

 

Fonte:  Sinologic

Adaptação: Angelo Delphini.

AEAP: O protocolo de aplicativos externos do Asterisk® SCF™

 

A equipe de desenvolvimento do Asterisk® SCF™ acaba de anunciar que você está listado no AEAP (Asterisk External Application Protocol), um protocolo que levou mais de um ano sendo desenvolvido e que por fim viu a luz a partir das versões do Asterisk® SCF™ 18.12.0 e Asterisk® SCF™ 19.4.0 e que nos permitirá conectar com aplicativos externos para enviar áudio e dados e obter resultados sobre eles.

 

Um exemplo básico que é usado como demonstração para entender como funciona o AEAP é um módulo para converter VOZ em TEXTO (fala para texto) e que utiliza a API do Google para fazer a conversão, mas podemos usar outros motores e criar nosso próprio conector graças a este protocolo.

 

O protocolo AEAP nos permite criar um “subsistema” para criar aplicações nativas Asterisk® SCF™ que receberão dados de entrada e gerarão dados de resposta. Para fazer esses "subsistemas" você tem que saber como funciona a arquitetura Asterisk® SCF™ e utilizar os módulos res_aeap.h e res_aeap_message.h de onde geraremos um novo "motor" para o qual poderemos enviar os dados e que retornará o resultado que ele retorna para nós.

 

Como exemplo de uso, eles criaram um "subsistema para fazer reconhecimento de fala para texto" e o incorporaram ao Asterisk® SCF™ no módulo res_speech_aeap.c, que irá gerar um novo mecanismo de reconhecimento que podemos usar com o Asterisk® SCF™ SpeechCreate com os comandos, padrão, SpeechStart e SpeechDestroy para enviar o áudio e fazer com que o mecanismo retorne o resultado:

exten => 550,1,NoOp() 

 same => n,Answer() 

 same => n,SpeechCreate(my-speech-to-text) 

 same => n,SpeechStart() 

 same => n,SpeechBackground(hello-world) 

 same => n,Verbose(0,${SPEECH_TEXT(0)}) 

 same => n,SpeechDestroy() 

 same => n,Hangup()

 

Este "my-speech-to-text" é um motor "customizado" que criamos graças a um servidor websocket que recebe o áudio e o envia para a API de reconhecimento do Google para que retorne a variável ${SPEECH_TEXT}. resultado de o reconhecimento, mas com alguma habilidade, pode ser adaptado para que, em vez do Google, utilizemos outros sistemas diferentes, e mesmo que o resultado, em vez de retornar o texto, retorne outras informações (identificação da pessoa que fala, humor, idade aproximada da pessoa, etc. para dar um exemplo).

Esse "my-speech-to-text" está configurado no arquivo de configuração 'aeap.conf' que teria algo assim:

[my-speech-to-text] 

type=client 

codecs=!all,ulaw 

url=ws://127.0.0.1:9099 

protocol=speech_to_text

 

e na porta 9099 teríamos um servidor websocket que receberia o áudio e geraria as variáveis ​​de resultado. 

 

Nesta URL você pode encontrar o servidor websocket que eles usam como exemplo: 

URL: <https://github.com/asterisk/aeap-speech-to-text> 

Este sistema não é algo voltado para o usuário final do Asterisk® SCF™, talvez exija conhecimentos um pouco mais avançados, mas os resultados são verdadeiramente interessantes e promissores. 

 

Mas informações:

URL1: <https://www.asterisk.org/asterisk-external-application-protocol-an-intro/>;

URL2: <https://www.asterisk.org/asterisk-external-application-protocol-speech-to-text-engine/>;

URL3: <https://github.com/asterisk/aeap-speech-to-text>. 

Fonte:

Site Sinologic

 

 

 

 

 

 

 

Mean Opinion Score - MOS (POLQA vs PESQ)

  

O MOS é um teste utilizado há anos para medir a qualidade das redes telefônicas. Este teste foi realizado em determinadas condições ambientais onde as pessoas participantes da “experiência” foram solicitadas a expressar a sua opinião sobre a qualidade do áudio recebido ao longo da chamada.

Dito isso, quando trabalhamos com VoIP, temos consciência de que estamos trabalhando com uma tecnologia digital, composta por um fluxo de dados dedicado à sinalização, e outro fluxo de dados dedicado a mídias, ou seja: áudio, vídeo, arquivos, etc. Tudo é digital, então o ruído eletromagnético que normalmente afeta as informações transmitidas por linhas analógicas não nos afeta neste caso, e também é IP, de forma que em cada dispositivo inteligente, roteadores, switches, etc., existem ferramentas de verificação de dados .que verificam que o que entra por uma porta sai por outra exatamente igual e no menor tempo possível. Porém, há motivos pelos quais, durante uma conversa, temos interesse em conhecer a qualidade do áudio para descobrir erros, problemas e resolvê-los.

80% das vezes, os erros de áudio geralmente são devidos a problemas de qualidade de serviço ou largura de banda insuficiente. Geralmente isso é resolvido configurando QoS no roteador, separando as redes VoIP e de dados para que “as atualizações do Windows não consumam a largura de banda de uma chamada”. 5% das vezes geralmente é devido a problemas com fones de ouvido de baixa qualidade (microfones muito próximos da boca, o que causa volume excessivo e ruídos de movimento da boca que são captados pelo microfone).

Imagine que você está trabalhando, faz uma ligação e o som está entrecortado... por que isso acontece? Como pode ser resolvido? Certamente diremos que é por falta de largura de banda, ou algum gargalo, mas e se não for isso?

Precisamos medir a qualidade de uma chamada para garantir que as conversas tenham a qualidade mínima exigida. Esta medição deve ser objetiva e verificável, por isso temos que nos aprofundar em um novo tema. 

Para medir a qualidade de uma chamada temos que conhecer alguns conceitos-chave no mundo das comunicações VoIP:

• Latência: É o atraso desde o microssegundo em que o som chega ao microfone do nosso telefone, até sair pelo alto-falante do aparelho do receptor. Esta latência costuma ser inferior a 100ms e quando é superior (<200ms.) percebe-se que há uma certa espera entre um turno de fala e outro, mas ainda assim permite uma conversa mais ou menos fluida. Quando esse tempo aumenta (ao usar redes de alta latência, como links de satélite), é muito mais difícil estabelecer uma conversa normal e você tem que falar em turnos declarados para evitar pisar uns nos outros com respostas a frases antigas.
• jitter: Se a latência for sempre a mesma, você pode manter uma conversa simplesmente esperando um segundo entre o final da frase e o início da próxima. Mas se a latência variar a cada segundo, manter uma conversa será extremamente difícil. Ainda mais quando isso causa perda de pacotes porque há novos pacotes que chegam antes dos mais antigos. É como dizer: - “Vou comprar pão” e esse “pão” chega antes de “comprar”, para que o sistema receptor elimine “comprar” e você ouviria “Vou… pão”.
• Pacotes perdidos: Por vários motivos, um pacote pode desaparecer: muito tempo para ser transmitido (cada pacote tem um TTL -time to live - que se for excedido o pacote é eliminado porque é obsoleto e inútil), ruído no sinal digital que provoca alterações e incentiva o descarte da referida embalagem por ter sofrido alterações durante a viagem, etc. Isto causa problemas de áudio semelhantes ao que foi mencionado anteriormente: micro-cortes de áudio de cerca de 20~30 milissegundos, tempo suficiente para que um corte de áudio seja perceptível se estivermos ouvindo música, mas quase imperceptível se estivermos em uma conversa com paradas, pausas entre palavra e palavra, ou se tivermos consciência de que o nosso interlocutor não tem uma boa ligação. Existem codecs que permitem “completar automaticamente” o áudio que falta, dando aquela sensação de áudio “metálico” ou “robótico” que todos nós certamente já experimentamos. 
• Largura de banda: Se a largura de banda for insuficiente, os pacotes demorarão para chegar ao destinatário, o que implica que há latência, ou que os pacotes são perdidos, então teremos uma conversa com atraso e micro-cortes. Dependendo do codec utilizado, precisaremos de mais ou menos largura de banda, portanto para conexões limitadas é recomendado o uso de codecs especiais como GSM, G729, iLBC, Speex, etc. em vez do G711, G722, G726, etc. 
  

Valores de medição

Os conceitos básicos de qualidade de áudio já foram explicados, mas claro, não é interessante tratar valores específicos para analisar todo o áudio de uma conversa, pois podem ocorrer problemas em 1 segundo da conversa, porem ser perfeito no restante da mesma chamada. Assim, analisando os valores específicos ao longo da conversa, podemos obter medidas mais práticas e interessantes:

• Classe de Serviço (CoS): Mede a porcentagem de pacotes que chegam nas duas extremidades durante toda a conversa. O ideal é que cheguem 100% dos pacotes (CoS = 100%) mas se tivermos valores semelhantes não é drama (>95%). 
• Mean Opinion Score (MOS): É uma das medidas mais utilizadas para saber a qualidade de uma conversa. Ele mede os valores de pacotes perdidos, jitter e latência e gera um valor médio que varia entre 1 e 5. Um valor abaixo de 3,5 é considerado problemático enquanto um valor acima de 4,5 é considerado uma chamada normal e de boa qualidade. 
• Fator R: É uma medida semelhante ao MOS, utilizada como recomendação da UIT e baseada nos mesmos fatores que pontuam a qualidade entre 0 e 100 como pode ser visto na tabela a seguir: 

  

POLQA (Perceptual Objective Listening Quality Analysis) e PESQ (Perceptual Evaluation of Speech Quality) são dois algoritmos de avaliação da qualidade de voz em telecomunicações, que permitem a geração de um escore MOS objetivo, uma métrica típica em chamadas telefônicas.

 

PESQ é um algoritmo que mede a qualidade do sinal de voz após compressão, roteamento e processamento do sinal. Fornece uma pontuação de qualidade de voz em uma escala de 0 a 5, sendo que 5 representa a melhor qualidade possível.

 

Por outro lado, o POLQA é uma evolução do PESQ que utiliza um modelo auditivo mais avançado para avaliar a qualidade da voz. O POLQA é capaz de avaliar a qualidade de voz em uma ampla variedade de codecs e condições de rede e fornece uma pontuação de qualidade de voz em uma escala de 0 a 4,5.

 

Ambos os algoritmos simulam o processo perceptivo humano usando técnicas de processamento de sinal. O POLQA usa uma técnica de processamento de sinal chamada “Análise de Pulso Cepstral de Longo Prazo” (LTPC). Esta técnica utiliza um modelo matemático para simular o processo perceptivo humano, dividindo o sinal de fala em segmentos curtos e analisando cada segmento em busca de distorções e outros artefatos.  

 

Por outro lado, o PESQ utiliza uma técnica de processamento de sinais chamada “Phase and Amplitude Difference Analysis” (Perceptual Evaluation of Speech Quality, em inglês), que também utiliza um modelo matemático para simular o processo perceptivo humano. Esta técnica mede a diferença entre o sinal de voz original e o sinal de voz recebido e utiliza um algoritmo de processamento de sinal para estimar a percepção subjetiva da qualidade de voz pelos ouvintes de teste.  

 

Notavelmente, o PESQ-LQ é uma variante do PESQ que leva em consideração as características específicas dos sistemas VoIP de baixa qualidade, como a presença de ruído de fundo, distorção e perda de pacotes, e fornece medições de qualidade de voz mais precisas nesses sistemas.  

 

Em resumo, POLQA e PESQ são algoritmos de processamento de sinais que simulam o processo perceptual humano para avaliar a qualidade de voz em telecomunicações, e utilizam diferentes técnicas de processamento de sinais para fazê-lo. POLQA é uma evolução do PESQ que utiliza uma técnica mais avançada para avaliar a qualidade de voz sob uma ampla variedade de codecs e condições de rede.  

 

Atualmente apenas as soluções comerciais incluem POLQA (PEXQ, VQuad e OPTICOM), uma vez que o algoritmo POLQA é propriedade da União Internacional de Telecomunicações (UIT) e está protegido por direitos de autor.  

As ferramentas comerciais de medição de qualidade de voz que utilizam POLQA obtiveram licenças para usar o algoritmo e estão sujeitas a restrições de uso e distribuição.  

 

No entanto, existem algumas ferramentas de medição de qualidade de voz de código aberto que utilizam outros algoritmos para medir a qualidade de voz em sistemas de comunicação VoIP, como PESQ e PESQ-LQ (Perceptual Evaluation of Speech Quality). Ferramentas como OpenMOS, VQmon/EP ou implantação de um sistema STOQ (Speech Transmission Quality Overhead), podem ser uma alternativa viável para medição de qualidade de voz em sistemas VoIP se você não tiver acesso a uma ferramenta comercial que utilize POLQA.

Outras ferramentas de análise e medição

Existem ferramentas que analisam o tráfego e mostram, não só o “traço SIP” da conversa, mas também os valores de medição da sua qualidade, dados detalhados da chamada (pacotes perdidos, tempos de resposta, latência, jitter, etc… ) Havia um muito bom, embora comercial, chamado VQManager. Infelizmente, tal como acontece com o software comercial, o software é descontinuado, abandonado e desaparece em vez de ser lançado. Felizmente, existem mais ferramentas que analisam esta informação e oferecem resultados muito interessantes:

• Homer SIP Capture: http://sipcapture.org/ (Opensource)
• VoIPMonitor: http://www.voipmonitor.org/ (Opensource)
• Recqual: https://sourceforge.net/projects/recqual/ (Opensource)
• AQua: http://sevana.biz/products/aqua/
• Niqa: http://sevana.biz/products/niqa/
• VoIPSpear: https://www.voipspear.com/
• CommView: http://www.tamos.com/products/commview/
  

Em resumo: PESQ e POLQA são modelos objetivos de avaliação MOS usados ​​principalmente para avaliar a qualidade de voz em redes de telefonia e voz sobre IP, respectivamente, comparando fisicamente ondas de áudio com versões degradadas do mesmo áudio. É importante ressaltar que PESQ e POLQA também são considerados medidas subjetivas de qualidade de voz, pois dependem das avaliações subjetivas dos usuários, enquanto o Modelo E (Recomendação ITU-T G.107) é um modelo de avaliação objetivo. O MOS usado para prever a qualidade de voz em redes telefônicas é uma medida objetiva baseada em métricas de rede como latência, perda de pacotes e jitter, entre outras.

Fonte: https://www.sinologic.net/blog/2016-06/como-medir-la-calidad-de-una-llamada.html

UPDATE/RE-INVITE e SDP em SIP

 

Normalmente quando uma sessão SIP é estabelecida, alguns "timers" são estabelecidos para saber quem e em que horário irá atualizar a sessão, normalmente o UAS (User Agent Server) ou UAC (User Agent Client) é estabelecido como o atualizador da sessão e este é confirmado na resposta 200 OK do estabelecimento da sessão.

SESSION-EXPIRES: 600;refresher=uac

Neste caso a sessão expira após 600 segundos e o responsável por atualizar a sessão é o UAC (cliente, que inicia a chamada). Esta atualização de sessão geralmente é feita com UPDATE ou RE-INVITE, a diferença entre usar esses 2 métodos é que o UPDATE deve ser respondido imediatamente. No caso do UPDATE podemos identificá-lo facilmente já que o método muda, mas no caso do RE-INVITE, no nível SIP vemos apenas um INVITE e podemos identificá-lo, já que o RE-INVITE tem o mesmo FROM e CALL-ID:

Nesta atualização (ambos os casos), podemos ter alteração de média ou não, caso a média não seja alterada, o mesmo ID de sessão deve ser mantido no SDP, em caso de alteração de média, o ID de sessão deve ser aumentado em 1:

Owner/Creator, Session Id (o): – 4117888791 2277746976 IN IP4 3.3.3.3 

mudar para:

Owner/Creator, Session Id (o): – 4117888791 2277746977 IN IP4 3.3.3.3

Neste caso a média é alterada e, portanto, aumentada em 1.

Fontes:

URL-01: https://datatracker.ietf.org/doc/rfc3725/

URL-02:  https://datatracker.ietf.org/doc/html/rfc6141

 

 

 

 

 

 

 

Configurando o CODEC Opus para Asterisk® SCF™

 

Devido o crescente movimento de uso do WebRTC, a utilização do CODEC Opus para Asterisk® SCF™ se faz necessário e, expõe algumas opções de configuração que permitem manipular o codificador para sua configuração específica. Essas opções podem ser definidas em codecs.conf. Eles são úteis para personalizar um tipo de formato que pode então ser especificado na linha “allow” de um terminal. O codificador usa todas as opções a seguir, direta ou indiretamente. Algumas das opções especificam parâmetros de formato no SDP, mas também influenciam a codificação. Outras opções oferecem dicas ao codificador sobre que tipo de dados processar ou em que tipo de modo operar. A maioria, se não todas as opções, oferece um compromisso entre qualidade e eficiência, por isso é bom saber o que cada uma faz antes de mudar. um valor. As seguintes opções podem ser configuradas no  Asterisk® SCF™:

 

CBR

Quando definido como “yes”, o codificador usa uma taxa de bits constante em oposição a uma taxa de bits variável. Uma taxa de bits variável geralmente é melhor, pois ajusta a taxa automaticamente, permitindo áudio de qualidade potencialmente mais alta em taxas mais baixas. Por causa disso, você normalmente desejará deixar esse valor definido como “no”, que é o padrão. No entanto, alguns dispositivos e configurações podem exigir taxas de bits constantes. 

 

Definir este valor como “yes” também define o parâmetro “cbr” igual a “1” no SDP.

BITRATE

A especificação deste valor define um limite aproximado de taxa de bits no codificador. Os seguintes valores são permitidos: 

• auto – permite que o codificador controle a taxa de bits. Este é o padrão. 
• max – O codificador usa a quantidade máxima que pode. 500 - 512000 – Qualquer valor entre e incluindo esses dois números. Quando designado, este valor também define o parâmetro “maxaveragebitrate” no SDP. 

Embora não seja o único fator, a taxa de bits afeta diretamente a qualidade do áudio. Diminuir a taxa de bits diminui a qualidade do áudio, enquanto aumentá-la aumenta a qualidade. Dito isto, o áudio contendo apenas fala geralmente pode ser codificado em uma taxa de bits muito mais baixa do que o áudio contendo música, sem uma degradação perceptível na qualidade. 

 

Dependendo do(s) tipo(s) de endpoint(s) que você está usando, esta opção pode precisar ser definida para que o codificador codifique o áudio em uma taxa de bits que possa ser manipulada pelo endpoint. Por exemplo, se um endpoint só puder lidar com uma taxa de bits média máxima de 16.000, então isso precisará ser definido como 16.000 ou menos, para atuar com sistema de WebPhones, a taxa de bits média máxima de 8.000 é perfeita.

DTX

Se “yes”, então a transmissão descontínua está habilitada. Isto significa que o codificador tentará reduzir a taxa de bits quando o silêncio for detectado. Quando definido, também define o parâmetro “usedtx” igual a “1” no SDP. O valor padrão para “dtx” é “no”.

MAX_PLAYBACK_RATE

Isso define o parâmetro “maxplaybackrate” do SDP e também limita a largura de banda no codificador. Qualquer valor igual ou entre 8.000 e 48.000 é permitido. O seguinte mostra um mapeamento de larguras de banda com base em um valor especificado: 

 

8000	Banda Estreita
8001 – 16000	Banda Média
16001 – 24000	Banda Larga
24001 – 32000	Banda Super Larga
32001 – 48000	Banda Completa

Está opção tem um valor padrão de 48.000, o que é óbvio não é o recomendado para nossas soluções no Brasil. O recomendado é de 8.000.

PACKET_LOSS

Isso estipula a porcentagem esperada de perda de pacotes (0 a 100) no codificador. O Opus tem alguns truques na manga quando se trata de perda de pacotes, como correção de erros de encaminhamento em banda (FEC). Falaremos um pouco mais sobre FEC posteriormente, mas para que o codificador inclua os dados FEC, esta opção precisa ser definida com um valor apropriado.

  Aumentar a porcentagem significa melhor proteção contra perdas. No entanto, deve-se ressaltar que o ajuste deste valor pode afetar a qualidade. Para manter a taxa média de bits e ao mesmo tempo incluir informações de perda de pacotes, o Opus pode diminuir a taxa do áudio atual que está sendo codificado. A configuração padrão para isso é ZERO. Se você estiver tendo problemas de áudio devido à perda de pacotes, tente ajustar esse valor para ver se isso ajuda.

APPLICATION

Isso dá uma dica sobre que tipo de dados serão codificados, para que os dados possam ser codificados da maneira mais eficiente possível no que diz respeito ao uso. Os seguintes valores são permitidos:

• voip – O codificador espera voz ou dados de fala. Esta é a configuração padrão. 
• audio – O codificador não faz nenhuma suposição especial sobre os dados.
• low_delay – Os dados são codificados com o menor atraso de codificação possível.

SIGNAL

Semelhante à configuração de “aplicativo”, isso também oferece uma dica ao codificador sobre que tipo de dados está sendo codificado e seleciona o tipo de modo que o codificador prefere. Os seguintes valores são permitidos:

• auto – permite que o codificador escolha. Esta é a configuração padrão. 
• voice – O codificador prefere operar em modos mais propícios aos dados de fala.
• music – O codificador tende a operar em um modo mais aceitável para outro áudio.

COMPLEXITY

A complexidade computacional do Opus pode variar dependendo de vários fatores. Normalmente, quanto maior a qualidade de áudio para a qual o codec está configurado, maior a complexidade e, portanto, potencialmente maior a utilização da CPU. Isto pode ser um pouco mitigado por outras configurações, por exemplo, a codificação de voz é menos complexa que a música. A modificação da configuração de complexidade afeta diretamente a utilização da CPU.  

Os valores permitidos variam de 0 (zero) a 10. Um valor zero representa quantidades menores de tempo de CPU usado, enquanto um valor de dez é o maior tempo concedido.

FEC

Quando definido como “yes”, isso informa ao codificador para adicionar dados de correção de erro direto (Forward Error Correction - FEC) em banda aos quadros Opus codificados. Os quadros contendo informações FEC permitem que os decodificadores reconstruam um quadro anteriormente perdido. Definir este valor não significa que o codificador adiciona FEC automaticamente aos quadros de saída. Outras condições também devem ser atendidas no codificador antes que ele adicione as informações. Por exemplo, deve estar operando no modo correto. Além disso, ajustar a porcentagem de “packet_loss” para um valor esperado apropriado deve acionar a adição de FEC assim que o limite de perda interna for atingido.  

Definir este valor como “yes” também define o parâmetro “useinbandfec” igual a “1” no SDP. Esta opção tem como padrão o valor “no”.

O que mais ?

Atualmente, todas essas opções de configuração são suportadas. Há também uma página wiki que lista todas as opções mais recentes junto com alguns exemplos. Não deixe de conferir! Se ou quando novas configurações forem disponibilizadas, essa página será atualizada.

 

 

Devido, alterações sobre o sistema operacional CentOS, e uma vez que ainda não estamos bem a vontade com o Rock Linux, aqui vai o procedimento para o Debian 10 e 11.

 

E pensando que esteja utilizando o Asterisk 13.35.0:

 

apt-get install -y libopus-dev opus-tools

 

cd /opt/

wget http://downloads.digium.com/pub/telephony/codec_opus/asterisk-13.0/x86-64/codec_opus-13.0_current-x86_64.tar.gz 

tar -zxvf codec_opus-13.0_current-x86_64.tar.gz 
rm -rf codec_opus-13.0_current-x86_64.tar.gz
cp -av codec_opus-13.0_1.3.0-x86_64/*.so /usr/lib/asterisk/modules/
cp -av codec_opus-13.0_1.3.0-x86_64/*.xml /var/lib/asterisk/documentation/thirdparty/ 

 vim /etc/asterisk/modules.conf

load = codec_opus
load = res_format_attr_opus.so
load = res_crypto
load = res_http_websocket
load = res_pjsip_transport_websocket
load = res_srtp
load = format_ogg_opus.so

vim /etc/asterisk/rtp.conf

[general]
rtpstart=10000                      ;; ajuste para sua realidade  
rtpend=10099                        ;; ajuste para sua realidade
rtpchecksums=no
dtmftimeout=3000
rtcpinterval=5000
strictrtp=yes
probation=4
srtpreplayprotection=yes
icesupport=yes                      ;; importante
strictrtp=no                        ;; importante
stunaddr=stun.l.google.com:19302    ;; importante
stun_software_attribute=yes
dtls_mtu=1200

vim codecs.conf

[speex]
quality => 3
complexity => 2
enhancement => true
vad => true
vbr => true
abr => 0
vbr_quality => 4
dtx => false
preprocess => false
pp_vad => false
pp_agc => false
pp_agc_level => 8000
pp_denoise => false
pp_dereverb => false
pp_dereverb_decay => 0.4
pp_dereverb_level => 0.3

[plc]
genericplc => true
genericplc_on_equal_codecs => false

[silk8]
type=silk
samprate=8000
fec=true
packetloss_percentage=10
maxbitrate=10000

[silk12]
type=silk
samprate=12000
maxbitrate=12000
fec=true
packetloss_percentage=10;

[silk16]
type=silk
samprate=16000
maxbitrate=20000
fec=true
packetloss_percentage=10;

[silk24]
type=silk
samprate=24000
maxbitrate=30000
fec=true
packetloss_percentage=10;

[opus]
type=opus
packet_loss=5
complexity=10
max_bandwidth=narrow
signal=auto
application=voip
max_playback_rate=8000
bitrate=auto
cbr=1
fec=1
dtx=0

vim /etc/asterisk/sip.conf

[general]
callcounter=yes ; Habilita estado dos endpoints SIP.
rtcachefriends=yes
udpbindaddr=0.0.0.0:5060
disallow=all
allow=opus
allow=ulaw
allow=alaw
allow=gsm

rasterisk -vvvvgci

*CLI> module show like opus
Module                  Description        Use Count  Status      Support Level
codec_opus.so           OPUS Coder/Decoder 0          Running     extended
format_ogg_opus.so      OGG/Opus audio     0          Running     core
res_format_attr_opus.so Opus Format Attribute Module  1 Running   core
3 modules loaded
*CLI>

*CLI> core show translation paths opus 
--- Translation paths SRC Codec "opus" sample rate 48000 ---
opus:48000 To codec2:8000 : No Translation Path
opus:48000 To g723:8000   : No Translation Path
opus:48000 To ulaw:8000   : (opus@48000)->(slin@48000)->(slin@8000)->(ulaw@8000)
opus:48000 To alaw:8000   : No Translation Path
opus:48000 To gsm:8000    : (opus@48000)->(slin@48000)->(slin@8000)->(gsm@8000)
opus:48000 To g726:8000   : No Translation Path
opus:48000 To g726aal2:8000 : No Translation Path
opus:48000 To adpcm:8000  : No Translation Path
opus:48000 To slin:8000   : (opus@48000)->(slin@48000)->(slin@8000)
opus:48000 To slin:12000  : (opus@48000)->(slin@48000)->(slin@12000)
opus:48000 To slin:16000  : (opus@48000)->(slin@48000)->(slin@16000)
opus:48000 To slin:24000  : (opus@48000)->(slin@48000)->(slin@24000)
opus:48000 To slin:32000  : (opus@48000)->(slin@48000)->(slin@32000)
opus:48000 To slin:44100  : (opus@48000)->(slin@48000)->(slin@44100)
opus:48000 To slin:48000  : (opus@48000)->(slin@48000)
opus:48000 To slin:96000  : (opus@48000)->(slin@48000)->(slin@96000)
opus:48000 To slin:192000 : (opus@48000)->(slin@48000)->(slin@192000)
opus:48000 To lpc10:8000  : No Translation Path
opus:48000 To g729:8000   : No Translation Path
opus:48000 To speex:8000  : No Translation Path
opus:48000 To speex:16000 : No Translation Path
opus:48000 To speex:32000 : No Translation Path
opus:48000 To ilbc:8000   : No Translation Path
opus:48000 To g722:16000 : (opus@48000)->(slin@48000)->(slin@16000)->(g722@16000)
opus:48000 To siren7:16000 : No Translation Path
opus:48000 To siren14:32000 : No Translation Path
opus:48000 To testlaw:8000 : (opus@48000)->(slin@48000)->(slin@8000)->(testlaw@8000)
opus:48000 To g719:48000 : No Translation Path
opus:48000 To none:8000 : No Translation Path
opus:48000 To silk:8000 : No Translation Path
opus:48000 To silk:12000 : No Translation Path
opus:48000 To silk:16000 : No Translation Path
opus:48000 To silk:24000 : No Translation Path                                         
*CLI>  

 

Um ponto muito importante é que você deve utilizar o CODEC Opus de acordo com sua versão, e existe incompatibilidade de versão entre servidores Asterisk, fique atento. 

Qualquer dúvida, estou a disposição no e-mail professor.delphini#outlook.com. Não acredite que vou responder de pronto, mas vou responder, e caso tenha pressa, pode me encontrar na comunidade oficial da Fundação Asterisk Libre no Telegram, segue o convite: https://t.me/asterisk_br 

Uma vez na comunidade, pode questionar, pois tem na mesma uma gama muito grande de profissionais sempre com o espírito de liberdade!

 

Recomendo que veja:

URL: https://jmvalin.ca/opus/opus-1.2/

URL: http://downloads.digium.com/pub/telephony/codec_opus/

 

Fonte:  https://docs.asterisk.org/Configuration/Codec-Opus/