A.B.Delphini™

Módulo DISPATCHER Kamailio vs Módulo DISPATCHER OpenSIPS

2026-02-03T08:22:00.002-10:00

Kamailio Dispatcher

Pontos Fortes

Algoritmos de Balanceamento Avançados

Oferece múltiplos algoritmos de distribuição: hash, round-robin, baseado em peso (weight-based) e menor uso (least-used/call load).
Suporte para distribuição baseada em chaves do SIP: Call-ID, From URI, To URI e Request URI (garantindo persistência de sessão para o mesmo destino).
Algoritmo de peso dinâmico que permite ajustar a carga distribuída conforme a capacidade de processamento do servidor de destino.

Detecção Proativa de Falhas (Health Check)

Monitoramento contínuo (Heartbeat) via SIP OPTIONS com intervalos e limites configuráveis.
Detecção rápida de servidores indisponíveis (down) e recuperação automática (probing mode).
Suporte flexível para definição de códigos de resposta aceitáveis (ex: considerar 404 como ativo, mas 503 como falha).

Flexibilidade na Configuração

Configuração dinâmica de destinos sem necessidade de reiniciar o servidor (via comando kamcmd ou reload).
Suporte a múltiplos grupos de destinos (sets), permitindo segregar rotas (ex: PSTN, Interno, Failover).
Possibilidade de configurar destinos de prioridade e backup dentro do mesmo grupo.

Escalabilidade e Performance

Otimizado para alto rendimento (milhares de CPS) e baixíssima latência.
Suporte nativo para IPv6 e transporte dual-stack.
Gerenciamento eficiente de memória compartilhada (shm) para lidar com grandes volumes de tráfego.

Integração com Banco de Dados e Cluster

Capacidade de carregar destinos diretamente de tabelas de banco de dados (MySQL/PostgreSQL), ideal para integração com painéis web.
Integração com o módulo DMQ (Distributed Message Queue) para sincronizar o estado dos gateways (up/down) entre múltiplos servidores Kamailio em tempo real (Cluster Ativo-Ativo).

Controle via Event Routes

Execução de scripts personalizados quando um destino cai ou volta (event_route[dispatcher:dst-down]), permitindo notificações externas, logs personalizados ou alertas via API.

Pontos Fracos

Complexidade de Configuração

Curva de aprendizado íngreme para configurações avançadas; não é plug-and-play.
Documentação oficial extensa, porém extremamente técnica e por vezes fragmentada.
Exige conhecimento profundo do fluxo SIP (Transaction, Dialog) para otimizações específicas.

Limitações no Failover Automático

O módulo apenas seleciona o destino. O failover (tentativa de nova rota) não é automático; deve ser programado manualmente dentro do bloco failure_route do script.
Certas situações de rede (como timeouts silenciosos) exigem configuração manual adicional de timers (fr_timer) para evitar travamento da chamada.

Visibilidade Limitada da Camada de Aplicação

O Health Check via SIP OPTIONS verifica se a pilha SIP responde, mas não garante que a aplicação atrás dela (ex: banco de dados do Asterisk ou serviço de mídia) esteja funcional. O servidor pode responder "200 OK" no OPTIONS mas falhar ao processar uma chamada real se não houver verificações de nível de aplicação.

OpenSIPS Dispatcher

Pontos Fortes

Simplicidade e Facilidade de Uso

Configuração mais intuitiva e direta (menos "verbosa" que o Kamailio).
Documentação oficial clara, bem estruturada e rica em exemplos práticos.
Curva de aprendizado mais suave para iniciantes em Proxy SIP.

Integração com Ecossistema OpenSIPS

Integração nativa e fluida com a ferramenta de linha de comando (opensips-cli), facilitando a gestão operacional.
Interface gráfica (Control Panel) intuitiva disponível para gestão de destinos sem tocar em código.
Excelente interação com módulos de cache NoSQL (Redis/Cassandra) para estratégias de roteamento.

Estabilidade Comprovada

Implementação madura e extremamente estável em ambientes de produção (foco em versões LTS).
Menos mudanças disruptivas de sintaxe entre versões principais (backward compatibility).
Comportamento previsível em diferentes cenários de falha.

Gerenciamento de Estado e Clustering

Gerenciamento eficiente do estado dos destinos (Active/Probing/Inactive).
Integração com Módulo Clusterer: Diferente do Kamailio (que usa DMQ), o OpenSIPS utiliza uma camada de clustering binária nativa para replicar o estado do dispatcher entre nós. É robusto e fácil de configurar para manter a consistência em topologias Anycast.
Sincronização eficaz entre processos worker (filhos) para evitar condições de corrida.

Interface de Eventos

Event Interface (EVI): Capacidade robusta de disparar eventos (via RabbitMQ, HTTP, Datagram) quando o estado de um destino muda. Isso facilita muito a criação de dashboards de monitoramento externos em tempo real.

Pontos Fracos

Algoritmos de Balanceamento Mais Limitados

Menos opções de algoritmos de distribuição se comparado ao Kamailio (que possui variações de hash mais granulares).
Algoritmos de peso (weight-based) menos sofisticados para cenários de cargas extremamente assimétricas.
Limitações em balanceamento baseado em métricas dinâmicas de carga do servidor remoto (CPU/Memória do destino).

Capacidades de Monitoramento (Health Check)

Opções de health checking menos flexíveis em termos de personalização de pacotes SIP (embora cumpra bem o papel com OPTIONS).
Intervalos de monitoramento e lógicas de "recovery" (histerese) menos granulares que o concorrente.
Menor variedade nativa de métodos de detecção de falhas fora do protocolo SIP (ex: checagem pura de porta TCP/ICMP integrada na lógica de decisão).

Escalabilidade em Cenários Extremos

Embora extremamente performático, pode apresentar limitações de throughput em cenários de altíssimo tráfego (milhares de CPS concentrados) devido a diferenças na gestão de locks de memória compartilhada em comparação ao Kamailio.
Menos otimizações de baixo nível para casos de uso muito específicos de alta carga de sinalização.

Dependência de Scripting para Failover

Assim como no Kamailio, o failover não é "automático" no sentido de "configurar e esquecer". Requer implementação lógica no script de roteamento (failure_route) para decidir o que fazer quando o Dispatcher retorna um destino falho.

Comparação Técnica Direta: Kamailio vs OpenSIPS

Característica	Kamailio	OpenSIPS
Algoritmos de Balanceamento	Extenso (8+): Hash granular, Load-balancing real, Peso dinâmico, Latência e Custo.	Essencial (4-5): Focados em Round-Robin, Peso e Hashing básico. Eficientes, mas com menos opções nativas.
Health Checking (Monitoramento)	Altamente Configurável: SIP OPTIONS, HTTP (via curl), Scripting personalizado e integração com Keepalived.	Focado em SIP: Principalmente SIP OPTIONS. Forte integração com o módulo Clusterer para compartilhar estado.
Configuração Dinâmica	Excelente: Recarregamento quase total sem restart (hot-reload), forte uso de Database (MySQL/PostgreSQL) e KEMI.	Muito Boa: Ferramentas de CLI robustas e Painel de Controle (CP) nativo para gestão de dados em tempo real.
Performance e Scalabilidade	Superior em Throughput Bruto: Otimizado para volumes massivos de pacotes e gestão de memória compartilhada em cenários extremos.	Alto Desempenho: Excelente para a maioria dos cenários de operadoras (Carrier Grade), com foco em lógica de roteamento complexa.
Facilidade de Uso	Complexa: Curva de aprendizado íngreme. Arquitetura modular que exige entender "como as peças se encaixam".	Moderada/Simples: Sintaxe de script mais intuitiva ("human-readable"), documentação mais didática e ferramentas de gestão mais amigáveis.
Linguagens de Script (Adicionado)	KEMI (Poderoso): Permite escrever a lógica de roteamento em Python, Lua, Go, Ruby ou JavaScript.	Script Nativo: Foco na linguagem nativa do OpenSIPS. Suporte a Python/Perl existe, mas é menos central que no Kamailio.
Clustering/Alta Disponibilidade (Adicionado)	DMQ (Distributed Message Queue): Baseado em troca de mensagens SIP para replicar estado (leve e desacoplado).	Clusterer (Binário): Protocolo binário próprio para sincronização de estado. Muito robusto para topologias complexas.
Documentação	Extensa (Wiki): Muita informação, mas muitas vezes fragmentada, desatualizada ou espalhada em módulos diferentes.	Organizada (Manual): Bem estruturada, centralizada e geralmente atualizada com a versão do software.
Comunidade e Ciclo de Vida	Muito Ativa / Ciclo Rápido: Muitas atualizações, recursos novos constantes. Ótimo para quem quer "bleeding edge".	Estável / Ciclo LTS: Foco maior em versões de Longo Suporte (LTS) e estabilidade para ambientes corporativos (Enterprise).

Casos de Uso Recomendados

Use o Kamailio Dispatcher quando:

Necessitar de algoritmos de balanceamento sofisticados e lógica complexa de roteamento.
Lidar com volume de tráfego extremamente alto (> 1.000 CPS) e picos agressivos.
Exigir máxima flexibilidade e controle granular sobre a memória e o fluxo da transação.
Tiver uma equipe com experiência avançada em Engenharia SIP e desenvolvimento.
A otimização de performance bruta e a latência mínima forem requisitos críticos.

Use o OpenSIPS Dispatcher quando:

Priorizar a simplicidade de configuração, legibilidade do script e facilidade de manutenção.
Tiver uma equipe com foco maior em Operação e menos experiência profunda em "escovação de bits" SIP.
Precisar de uma solução estável, previsível e focada em versões LTS (Long Term Support).
O volume de tráfego for de nível corporativo ou médio (foco em lógica de negócio e não apenas em rendimento bruto).
Valorizar a integração nativa com ferramentas de gerenciamento visual (Control Panel) e linha de comando (CLI).

Nota Técnica da Engenharia: Embora o texto original sugira o OpenSIPS para tráfego "< 500 CPS", é importante ressaltar que em hardware moderno (como os servidores que usamos na Saper), o OpenSIPS lida tranquilamente com volumes muito superiores a isso. A distinção real é: Kamailio para força bruta e escalabilidade extrema; OpenSIPS para estabilidade empresarial e facilidade de gestão.

Conclusão e Recomendação

Para a maioria das implementações empresariais (Enterprise), recomendo o OpenSIPS Dispatcher pelas seguintes razões:

Curva de aprendizado mais suave: Permite implementações mais rápidas (Time-to-market) e reduz a chance de erros humanos na configuração.
Manutenção simplificada: Menor complexidade operacional a longo prazo, facilitando a vida da equipe de sustentação.
Estabilidade comprovada: Comportamento mais previsível e robusto em ambientes de produção.
Ecossistema integrado: Melhor integração nativa com ferramentas de gerenciamento (GUI e CLI).

No entanto, escolha o Kamailio Dispatcher se:

Sua organização gerencia tráfego de volume muito alto (cenários de Carrier ou Atacado).
Você precisa de algoritmos de balanceamento muito específicos ou customizados.
Você possui uma equipe técnica altamente experiente em engenharia SIP (C/Linux).
Você requer a máxima otimização de performance e controle de memória.

Consideração Híbrida (Arquitetura Mista): Em ambientes complexos, você pode utilizar o OpenSIPS como Proxy de Borda/Entrada (pela simplicidade e segurança) e o Kamailio para funções de Core com alta carga (pela performance bruta), obtendo assim o melhor dos dois mundos.

A decisão final deve basear-se no seu contexto específico: volume de tráfego, nível de experiência da equipe, requisitos de SLA e a complexidade do seu ambiente de rede.

Delphini, Dell Senior C/C++/Python Developer & VoIP Specialist

🎓 Instrutor na Academia Saper Domine a engenharia por trás do Asterisk, OpenSIPS e Kamailio.

📞 (48) 3121-0110 🌐 Blog: www.delphini.tel | Saper: www.saperx.com.br

Kamailio - Entendendo a lógica de roteamento.

2025-07-14T06:10:00.001-10:00

O mercado de VoIP (principalmente VoIP Peering) exige profissionais com expertise em desenvolvimento ToIP. O crescimento contínuo das ITSPs (Internet Telephony Service Provider) no Brasil tem impulsionado uma demanda urgente por desenvolvedores especializados em soluções de Telefonia IP (ToIP), com ênfase em tecnologias robustas e escaláveis como o Kamailio.

Kamailio é hoje uma das ferramentas mais poderosas para desenvolvimento de servidores SIP de alta performance, capazes de gerenciar milhares de chamadas por segundo, com alta confiabilidade, performance e escalabilidade - requisitos essenciais em ambientes de VoIP Peering e Operadoras VoIP (ITSP).

O que o mercado espera desses profissionais ?

Domínio no desenvolvimento e customização de soluções com Kamailio.
Conhecimento de protocolos SIP, UDP, TCP, SCTP, TLS.
SIP-I (SIP for ISUP) e SIP-T (SIP for Telephones).
Suporte a NAT Traversal, IPv4/IPv6, failover e load balancing.
Implementação de "Kamailio Multi-SIP Interop com Dialplan Database Control - DDC". Que é a ideia de suportar chan_sip, chan_pjsip, SIP-I e SIP-T, e ainda controlar tudo via Banco de Dados.
Implementação de interfaces com Banco de Dados (DDC) e RADIUS.
Desenvolvimento de soluções com suporte apresença (SIMPLE), dialogue info e CDRs.
Capacidade de integrar e desenvolver com Asterisk, FreeSWITCH e WebRTC.
Desenvolvimento completo: Backend e Interface Grafica (GUI) para gestão das soluções.

São poucos os profissionais e empresas no mundo com domínio avançado em Kamailio e outras tecnologias VoIP combinadas. Essa é uma oportunidade de ouro para quem busca se posicionar como especialista em uma área estratégica e carente de talentos.

Se você atua com desenvolvimento VoIP, ou pretende entrar nesse nicho promissor, o momento é agora. O mercado está aquecido e exige profissionais prontos para entregar soluções robustas, escaláveis e personalizadas.

Dito isso, um dos aspectos mais importantes e, ao mesmo tempo difíceis de entender no Kamailio é a lógica de roteamento, pois ela tem muito a ver com o comportamento do protocolo SIP.

Após alguns estudos mais detalhados, resolvi passar aqui a minha visão de entendimento sobre o comportamento do Kamailio, principalmente no kamailio.cfg. E esse vai ser o objetivo deste post, e vou tentar adentrar com mais detalhes no mesmo.

Primeiro vamos dar uma olhada geral no que o arquivo de configuração contém:

Agora, vamos analisar cada ponto:

1. Definições Globais

Variáveis que usaremos em toda a Lógica de Roteamento, que podem se referir a parâmetros de LOG, Endereços IP e Portas nas quais o servidor esturatá (LISTEN) entre outros. Tem o seguinte formato:

2. Seção de Módulos

É aqui que definimos ou carregamos os módulos que estamos usando, por exemplo, o módulo MySQL para salvar registros no Banco De Dados ou o módulo TLS para criptografia de sinais.

Eles têm o seguinte formato:

3. Seção de Configuração de Módulos

Nesta seção, parametrizamos ou configuramos os módulos que carregamos na seção anterior. É muito importante configurá-los adequadamente, pois, em alguns casos, eles são ativados com configurações padrão, o que pode produzir efeitos estranhos no comportamento ao longo da vida útill do servidor SIP.

Eles têm o seguinte formato:

4. Blocos de Rota ou Lógica de Roteamento

Está é a seção chave do arquivo de configuração, pois estabelece todo o caminho que as solicitações SIP que recebemos seguirão. Vale ressaltar que não existe um padrão único aqui, pois você pode tornar sua lógica tão simples ou complexa quanto desejar, ou seja, com mais ou menos blocos de rota. No entanto, existem certos padrões que você sempre respeitará ou encontrará em outros arquivos. Estes são os blocos de rota que você normalmente encontrará:

Principal (Main ou request_route).
Secundários (REQINIT, WITHINDLG, REGISTER).
Falhas/Failure (failure_route).
Ramificação/Branch (branch_route).

Este é um diagrama que tenho como padrão para meus projetos, é um esquema de roteamento, pouco complexo, objetivo e prático:

Como você pode ver, tudo começa no bloco PRINCIPAL ou REQUEST_ROUTE e flui para os outros blocos, cada um com uma finalidade específica para a solicitação SIP recebida.

O bloco REQINIT desempenha um papel muito importante, pois realiza a maioria das verificações de PRÉ-REQUISITOS, como avaliações de segurança, entre outras necessidades de cada cenário.

Em seguida, os métodos secundários registram, localizam e encaminham as solicitações SIP para outro servidor, como o Asteirsk conforme apropriado.

Fontes:

URL: https://kamailio.org/docs/modules/6.0.x/

URL: https://www.kamailio.org/wiki/tutorials/getting-started/main

Bom, espero que este post amplie sua compreensão de como o Kamailio funciona. Conforme vou conseguindo tempo (para escrever, rsrsr), iremos nos aprofundar em outros aspectos deste software formidável.

Por hoje é só pessoal!

Peering: Interconectando a Indústria de VoIP

2025-06-09T05:01:00.005-10:00

"Imagem gerada por IA usando Microsoft Copilot"

À medida que o setor de VoIP continua a evoluir e amadurecer, começamos a ver um grande número de provedores ITSP (Internet Telephony Service Provider) fazendo peering entre si. Neste post, falaremos um pouco sobre o que é peering e por que estamos vendo um movimento em direção ao peering. Vamos começar fornecendo um pouco de contexto sobre o que é peering. O peering é um acordo entre duas ou mais redes (ITSP) para peering ou interconexão física com o objetivo de trocar tráfego entre os usuários de cada rede. O peering envolve a união de duas redes para um benefício mútuo, que normalmente é a redução ou eliminação dos custos dos serviços. Existem duas interconexões físicas para peering: peering público e peering privado (com objetivo de dar mais segurança entre Matriz e Filiais). Uma interconexão de peering público utiliza uma rede compartilhada multipartidária, como um switch Ethernet. Já uma interconexão de peering privado utiliza um link ponto a ponto ou direto entre duas partes.

Então, por que o setor de VoIP, mais especificamente as ITSPs no atacado e grandes provedores de serviços de varejo, está fazendo peering com mais frequência? Há alguns motivos: melhor qualidade e economia de custos.

Vamos analisar como as chamadas são tratadas. Uma ITSP atacadista compra serviços de uma ULC (under lying carrier) ou de uma rede terceirizada para que possam ser revendidos. O peering entre operadoras no Brasil geralmente ocorre por meio de IXPs (Internet Exchange Points) ou acordos diretos entre as partes, sem nenhum registro obrigatório. Para garantir a interoperabilidade e aqualidade do serviço, as operadoras podem estabelecer acordos bilaterais ou multilaterais, mas isso não parece ser rugulado pela ABR Telecom da mesma forma que o NPAC nos EUA.

Uma ULC (Underlying Carrier) é uma operadora de telecomunicações que fornece infraestrutura e serviços de rede para outras empresas, sem necessariamente atender diretamente os consumidores finais. Essas operadoras atuam nos bastidores, oferecendo conectividade, terminação de chamadas e outros serviços essenciais para provedores de VoIP e Telecomunicações.

No Brasil, um equivalente funcional às ULCs seria as operadoras de backbone e carrier globais, como Telekom Global Carrier, que oferecem infraestrutura de conectividade para outras empresas de telecomunicações. Além disso, grandes operadoras como Embratel, TIM, VIVO e Claro também desempenham papéis semelhantes ao fornecer serviços de interconexão e transporte de tráfego para provedores menores (ITSPs).

Nota Importante: A ABR Telecom é a entidade responsável pela administração da portabilidade numérica no país, garantindo que os usuários possam trocar de operadora sem perder seus números de telefone. Ela opera como uma entidade neutra, gerenciando o bando de dados central que coordena as solicitações de portabilidade entre as oeperadoras de telefonia fixa e móvel. Desde a implementação da portabilidade numérica no Brasil, a ABR Telecom tem desempenhado um papel fundamental na modernização do setor de telecomunicações.

O principal objetivo da ULC para a ITSP (aqui no Brasil, tamém chamado de Provedor de VoIP) é fazer a transição de chamadas IP mutuamente para a PSTN (rede telefônica pública comutada), bem como passar chamadas IP para IP.

Bem, e quanto às chamadas que não precisam ser enviadas para a PSTN? Elas precisam ser enviadas para a ULC? A resposta é não, não com uma estrutura de peering em vigor. Essas chamadas podem ser passadas diretamente entre as ITSPs (os Provedores de VoIP), eliminando a necessidade de passar chamadas para a ULC. Sem peering, as ITSPs dependem das ULCs para atuar como um hub central para passar o tráfego de um provedor para outro. À medida que o peering aumenta, estamos vendo cada vez mais interconexões diretas entre as ITSPs e, em última análise, menos necessidade de intermediários.

"Imagem gerada por IA usando Microsoft Copilot"

Isso significa que ITSP com grandes redes de usuários que fazem peering com outras grandes redes podem transferir chamadas diretamente entre si, reduzindo custos e aumentando a qualidade para o usuário final. Isso pode ser uma tremenda vantagem competitiva para ITSP que optam pela interconexão!

Os benefícios do peering vão muito além da simples redução de custos. Os usuários finais se beneficiarão das interconexões formadas durante o processo de peering. Como resultado do peering, os usuários finais verão uma mudança perceptível na qualidade de seus serviços. Como o intermediário é eliminado, há menos saltos de switch, redução do PDD (atraso pós-discagem), redução da degradação do serviço e menor chance de falha do equipamento.

Não é de se admirar que o peering esteja crescendo em popularidade; os clientes estão obtendo uma melhor qualidade de serviço e é isso que qualquer bom ITSP se esforça para fazer. À medida que mais ITSPs interconectam suas infraestruturas por meio de parcerias de peering e mais usuários adotam o serviço de Telefonia sobre IP (ToIP) e Voz sobre IP (VoIP), a necessidade de depender de ULCs diminuirá. Isso deixará uma rede VoIP interconectada de propriedade e operada por um grande número de ITSPs menores, em vez de algumas entidades governamentais e grandes empresas.

Mas por onde começar? Eu recomendo iniciar pela RFC6405.

Que plataforma utilizar? Eu recomendo iniciar pelo projeto 100% Open Source I::VOZ PROVIDER da Irontec. Inclusive tem um grupo de estudos com varios profissionais de ITSPs do Brasil no Telegram dedicado ao I::VOZ PROVIDER.

Recomendo, ler o artigo do Sr. Álvaro Marques: "VoIP Peering: O próximo Passo da Interconexão" disponivel no site da Teleco.

"Nada nos para, o que é que há velhinho?!" (Pernalonga - Bugs Bunny, 85 anos, criado por Tex Avery).

Evitando Spoofing no Asterisk® SCF™

2025-04-09T06:14:00.003-10:00

Imagen extraita do site: https://www.tripwire.com/state-of-security/caller-id-spoofing

O uso malicioso do CALLERID(name)<number> pode ser uma forma de spoofing, onde o atacante tenta enganar o sistema ou usuários ao passar um número falso — como delphini<1234>. Isso pode ser usado para:

Burlar regras de acesso;
Fazer chamadas fraudulentas;
Injetar comandos em logs, bancos de dados ou URAs, se não houver tratamento adequado.

Como evitar ataques via CALLERID(number) no Asterisk

1. Sanitizar o CALLERID no dialplan

Você pode limpar o número, mantendo apenas dígitos:

exten => _X.,1,Set(CALLERID(num)=${FILTER(0-9,${CALLERID(num)})})

Ou, para armazenar em variável segura:

exten => _X.,1,Set(SAFE_CALLERID=${FILTER(0-9,${CALLERID(num)})})

Assim, qualquer caractere estranho (letras, símbolos, espaços, etc) será removido.

2. Verificar padrões válidos antes de usar

exten => _X.,n,GotoIf($["${CALLERID(num)}" :!^ [0-9]+$] ?hangup,s,1)

Isso envia para um contexto de hangup se o número tiver algo além de dígitos.

3. Bloquear chamadas com CALLERID suspeito

Você pode negar chamadas que tenham nomes/números suspeitos:

exten => _X.,1,ExecIf($["${CALLERID(name)}" = "delphini"]?Hangup())

exten => _X.,n,ExecIf($["${CALLERID(num)}" = "1234"]?Hangup())

Ou usar expressões mais robustas com ${REGEX(...)}.

4. Forçar um novo CALLERID confiável

Se você sabe que as chamadas vêm de uma operadora confiável, pode substituir o CallerID:

exten => _X.,1,Set(CALLERID(num)=0123456789)

exten => _X.,n,Set(CALLERID(name)=EmpresaX)

5. No sip.conf ou pjsip.conf: Controlar permissões

SIP (chan_sip):

[ataque]

callerid=unknown

trustrpid=no

sendrpid=no

PJSIP (chan_pjsip):

[ataque]

trust_id_inbound=no

send_pai=no

send_rpid=no

Esses parâmetros evitam que o Asterisk confie no CALLERID vindo do peer.

6. Logs e proteção contra injeções

Nunca jogue o CALLERID(num) diretamente em banco de dados, logs ou AGI sem limpar. Exemplo:

exten => _X.,n,Set(SAFE_CID=${FILTER(0-9,${CALLERID(num)})})

7. iptables / fail2ban para SIP

Monitore tentativas suspeitas com fail2ban (regex em /var/log/asterisk/messages).

Pode criar regras para bloquear IPs que tentam registrar ou enviar chamadas com CALLERID inválido.

Segue um Validador de Chamadas Suspeitas por CallerID (Python)

Bloquear IPs no IPTABLES (associados ao CallerID suspeito).
Gravar os eventos em um banco de dados MariaDB.

Pré-requisitos

Python:
- pyodbc (ou mysql-connector-python)
- Acesso sudo (para executar iptables)
Banco de dados MariaDB com tabela:

CREATE TABLE chamadas_suspeitas (

id INT AUTO_INCREMENT PRIMARY KEY,

callerid VARCHAR(50),

ip VARCHAR(50),

datahora DATETIME,

motivo VARCHAR(255)

);

Código Python

import re

import logging

import subprocess

import mysql.connector

from datetime import datetime

# Configurações

DB_CONFIG = {

'host': 'localhost',

'user': 'usuario',

'password': 'senha',

'database': 'seu_banco'

}

PATTERNS_SUSPEITOS = [

r'^00\d{6,}', r'^1\d{2,}$', r'^\d{10,}$', r'^[*#]\d+',

r'^(.)\1{5,}$', r'^(1234|1111|0000)$', r'^anonymous$', r'^restricted$', r'^$',

]

def eh_callerid_suspeito(callerid):

callerid = callerid.strip().lower()

for padrao in PATTERNS_SUSPEITOS:

if re.match(padrao, callerid):

return padrao

return None

def bloquear_ip(ip):

try:

subprocess.run(['sudo', 'iptables', '-A', 'INPUT', '-s', ip, '-j', 'DROP'], check=True)

logging.warning(f"IP bloqueado via iptables: {ip}")

except subprocess.CalledProcessError as e:

logging.error(f"Erro ao bloquear IP: {ip} - {e}")

def registrar_no_banco(callerid, ip, motivo):

try:

conn = mysql.connector.connect(**DB_CONFIG)

cursor = conn.cursor()

query = """

INSERT INTO chamadas_suspeitas (callerid, ip, datahora, motivo)

VALUES (%s, %s, %s, %s)

"""

valores = (callerid, ip, datetime.now(), motivo)

cursor.execute(query, valores)

conn.commit()

cursor.close()

conn.close()

logging.info(f"Registro salvo no banco: {callerid}, {ip}, motivo: {motivo}")

except Exception as e:

logging.error(f"Erro ao salvar no banco: {e}")

def processar_chamada(callerid, ip):

motivo = eh_callerid_suspeito(callerid)

if motivo:

bloquear_ip(ip)

registrar_no_banco(callerid, ip, motivo)

# Exemplo de chamadas

chamadas = [

{"callerid": "anonymous", "ip": "192.168.1.100"},

{"callerid": "5511999999999", "ip": "192.168.1.101"},

{"callerid": "999999", "ip": "192.168.1.102"},

{"callerid": "normaluser", "ip": "192.168.1.103"}

]

if __name__ == "__main__":

logging.basicConfig(level=logging.INFO)

for chamada in chamadas:

processar_chamada(chamada["callerid"], chamada["ip"])

Dicas finais:

⚙️ Para o sudo funcionar sem senha com iptables, edite /etc/sudoers com:

youruser ALL=NOPASSWD: /sbin/iptables.

Problema de SIP e NAT em Intranet.

2024-05-22T08:35:00.002-10:00

Resumo:

Session Initiation Protocol (SIP) é o protocolo necessário para iniciar uma sessão de comunicação entre dois terminais. É um protocolo de SOLICITAÇÃO/RESPOSTA escalável e leve e é amplamente utilizado em serviços VoIP. No entento, a questão da passagem no NAT (Network Address Translator) para suportar o SIP em um ambiente de rede privada (Intranet) tem sido um debate contínuo e depende do tipo de NAT. Consequentemente, este post propôs e implementou um Proxy SIP simplificado e um módulo de retransmissão UDP para resolver o problema de passagem NAT para o SIP, especialmente em um ambiente NAT simétrico.

Para este fim, definimos e implementamos um pacote de biblioteca SIP no topo do Gateway baseado em OSGi e implementamos o módulo de Servidor SIP assim como o modulo de retransmissão UDP na forma de pagote OSGi. O método proposto neste post não requer nenhuma configuração adicional do Agente Usuário (UAS/UAC) SIP.

1. Introdução:

No futuro, as redes evoluirão para um ambiente de rede doméstica devido ao rápido desenvolvimento da Internet e dos dispositivos de informação e ao desejo de conveniência dos clientes . Neste ambiente de rede doméstica, espera-se que uma rede privada utilizando NAT seja estabelecida para cada residência, em vez de atribuir um IP público (Protocolo de Internet) a todos os terminais da residência.

Enquanto isso, a Internet atual está evoluindo gradualmente do tráfego de dados centrado na Web para serviços que exigem tráfego em tempo real, como reuniões remotas e VoIP (voz sobre IP) . Portanto, as futuras redes também deverão ser capazes de fornecer serviços baseados em UDP (User Datagram Protocol), onde o tempo de chegada é mais importante do que a transmissão precisa de dados dependendo do serviço. Atualmente, os protocolos de configuração de chamadas mais comumente usados para serviços de transmissão em tempo real incluem H.323 apresentado pela ITU-T e SIP da Internet Engineering Task Force (IETF).

Atualmente, a maioria dos fabricantes de equipamentos e empresas de serviços suportam o protocolo H.323, mas espera-se que o protocolo SIP do IETF, que possui muitas funções e escalabilidade, se torne popular no futuro. Em geral, SIP é um padrão definido no documento IETF RFC3261 e é um protocolo de controle de camada de aplicação para estabelecer, modificar e encerrar sessões ou chamadas para comunicação multimídia, como vídeo e voz.

SIP é um protocolo baseado em cliente-servidor implantado na forma de um originador de chamada chamando a outra parte para participar da sessão. Adicionalmente, a informação de sessão a ser expressa numa sessão para comunicação de serviço multimédia é descrita utilizando SDP (Session Description Protocol). No entanto, num ambiente de rede doméstica com uma rede privada que utiliza NAT, existem restrições à prestação de tais serviços SIP.

Em outras palavras, o processamento de fluxos de mídia RTP utilizando SIP entre UAC (User Agent Client) e UAS (User Agent Server) localizados em uma rede privada varia dependendo do tipo de NAT.

No caso do Full Cone NAT, ele existe em uma rede pública, pode ser processado configurando Through NAT, mas se for NAT simétrico, não é possível mesmo que exista STUN. Se o NAT da rede doméstica for NAT simétrico, você poderá configurar um servidor TURN (Traversal Using Relay NAT) na rede pública para ativar o processamento RTP. No entanto, neste momento, o TURN tem problemas como desperdício de largura de banda e atraso devido a solicitações de media relay de um grande número de clientes.

Para resolver esse problema, projetamos e implementamos um Proxy SIP simples, voltado para uso doméstico e um pacote de retransmissão UDP. Esses pacotes são montados na estrutura OSGi do gateway doméstico e interagem entre si, ajudando a enviar e receber fluxos de mídia em tempo real com êxito, mesmo no ambiente NAT simétrico, que deverá se tornar o mais comum no futuro.

2. Problema de passagem de NAT do SIP:

O NAT converte endereços IP privados e endereços IP públicos. É um dispositivo que permite que vários terminais em uma rede privada salvem endereços IP públicos compartilhando um IP público.

Esses NATs são amplamente classificados em NAT de cone completo, NAT de cone restrito, NAT de cone restrito de porta e NAT simétrico. Do ponto de vista de uma sessão SIP, é importante saber se a sinalização para configuração de chamada e subsequente transmissão de mídia pode passar pelo NAT.

Dependendo do tipo de NAT. Até agora, existem vários métodos para resolver este problema de travessia SIP NAT. Neste momento apresentaremos os principais métodos existentes para resolver este problema, e no próximo bloco do post mostraremos que um dos métodos foi implementado baseado em OSGi.

2.1. UPnP:

UPnP, proposto pela Microsoft, tem como objetivo conectar PCs, dispositivos periféricos, dispositivos AV, etc. em casa através de uma rede e funcionar sem operações ou configurações complicadas . UPnP permite que aplicativos clientes descubram e configurem automaticamente componentes de rede, como NAT e firewalls. Para fazer isso, cada dispositivo deve estar equipado com software UPnP. Muitos pequenos fornecedores de NAT estão comprometidos em oferecer suporte à funcionalidade UPnP para aplicativos SIP, mas ainda existem poucos clientes UPnP úteis. O UPnP tem a desvantagem de ser vulnerável à segurança porque depende apenas do pinhole de abertura do NAT para se conectar a uma rede pública externa sob o controle dinâmico do programa cliente.

Portanto, o escopo deste método parece estar limitado a aplicações de pequena escala.

2.2. STUN (Simple Traversal of UDP through NAT):

STUN é um método que usa uma sonda NAT chamada servidor STUN. Para estabelecer uma sessão, um cliente equipado com a função STUN envia uma mensagem de consulta ao servidor STUN externo para determinar a porta para receber o fluxo de mídia . O servidor STUN lê esta mensagem e informa ao cliente qual endereço IP público e porta foi utilizado pelo NAT no envio da mensagem, bem como o tipo de NAT.

O endereço IP público e a porta fornecidos pelo servidor STUN são usados na fase de configuração da chamada. No entanto, o servidor STUN não existe no caminho de sinalização e transmissão do fluxo de mídia real.

Portanto, este método não funciona em um ambiente NAT simétrico onde o mapeamento de endereços é formado com base não apenas no endereço de origem e na porta, mas também no endereço e na porta de destino . Em outras palavras, como o endereço do cliente SIP de destino é diferente do endereço do servidor STUN, o NAT formará um novo mapeamento para o cliente SIP, o que novamente significa que as informações incluídas na fase de configuração da chamada perdem o sentido.

Portanto, a tentativa de estabelecer a chamada falha. A desvantagem deste método é que ele requer funcionalidade adicional do cliente SIP para suportar a função STUN. Além disso, o NAT no qual este método opera é vulnerável a ataques de varredura de porta, levantando preocupações de segurança.

2.3. TURN (Traversal Using Relay NAT):

O TURN foi proposto pela IETF para resolver problemas de travessia de mídia em um ambiente NAT simétrico. Ao contrário do método STUN, o TURN coloca uma sonda NAT chamada servidor TURN no caminho de sinalização e transmissão do fluxo de mídia . Um cliente SIP equipado com a função TURN envia uma mensagem de consulta ao servidor TURN localizado na rede pública. O servidor TURN então responde ao cliente SIP com o endereço IP público e as informações da porta usadas pelo NAT para a mensagem.

Esta informação é útil para configuração de chamadas e transmissão do fluxo de mídia real. Isso ocorre porque o servidor TURN está localizado ao longo do caminho de sinalização e transmissão de mídia.

No entanto, este método coloca uma grande carga no servidor TURN à medida que o número de clientes SIP aumenta e pode causar atrasos na transmissão devido a solicitações de corretagem de mídia por clientes SIP. Há uma desvantagem.

2.4. Media Relay:

Este método é semelhante ao TURN no sentido de que ele medeia pacotes de mídia. Entretanto, diferentemente do TURN, os Media Relays têm acesso às mensagens SIP. Normalmente, há um servidor chamado Proxy NAT no caminho da sessão SIP, que modifica a mensagem SDP para permitir que ela passe pelo NAT. Além disso, ele modifica a mensagem SDP para instruir o Proxy NAT a enviar pacotes de mídia através de uma porta específica, em vez de enviar o fluxo de mídia diretamente entre os dois clientes SIP.

Você pode iniciar seus estudos sobre OSGi nesse link: (https://pt.wikipedia.org/wiki/OSGi);

Sobre Media Relay, este é um ótimo artigo para iniciar: (Innovaphone WiKi);

Em relação ao TURN, existe uma excelente explanação no projeto (Debian Handbook);

Já sobre o STUN, eu recomendo o Estudo de Caso do Fabricio José Costa e Luis Augusto Mattos Mendes, para o Departamento de Ciência da Computação da Universidade Presidente Antônio Carlos - UNIPAC, Campus Magnus - Barbacena/MG. (Estudo de Caso);

Então, temos o UPnP, que podemos ter uma boa visão no proprio site da Microsoft, (Visão Geral da Arquitetura UPnP).

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

2023-12-20T05:30:00.002-10:00

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™

2023-12-18T04:43:00.002-10:00

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)

2023-10-30T05:39:00.004-10:00

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

2023-10-30T04:51:00.004-10:00

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™

2023-09-15T07:02:00.004-10:00

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/

Asterisk® SCF™, qualidade de chamadas e MES (Media Experience Score)

2023-08-10T09:09:00.002-10:00

Medir a qualidade da chamada sempre foi bastante complicado e talvez o método mais conhecido/utilizado seja o MOS (Mean Opinion Score). Embora algoritmos sejam usados para calcular o MOS, esse sistema nasceu com base na percepção do áudio que os usuários de um determinado sistema de VoIP, ou algum circuito de áudio têm e seu julgamento expresso sobre a experiência usando esse mesmo sistema.

Para fugir desse conceito e considerando que o novo índice é baseado em cálculos puramente matemáticos, nasceu recentemente o MES (Media Experience Score), sistema que permite medir a qualidade de áudio do canal PJSIP (chan_pjsip.so). O cálculo é baseado em três valores que podem ser extrapolados a partir da vazão média:

RTT (tempo de ida e volta de um pacote de áudio);
Jitter, que é um indicador de como o fluxo médio se comporta;
A perda de pacotes que afeta a qualidade do fluxo médio.

Usando esses três valores, é obtido um Fator de Qualificação que vai de 0 a 100, onde 0 equivale a qualidade de áudio ruim e 100 a qualidade de áudio ideal.

O valor inicial desse Fator R foi definido em 93,2 e uma fórmula é aplicada a esse valor para obter um valor final. Contribui para a formação desse valor final:

RTT médio;
Jitter médio;
Atraso do codec de áudio (pacotes perdidos).

O valor obtido, como já foi dito, pode estar entre 0 e 100 e a partir deste valor pode-se obter um índice entre 1 e 4,5, se necessário, tipo MOS, utilizando a seguinte fórmula:

No Asterisk® SCF™ podemos obter toda uma série de valores relacionados ao MES através da função CHANNEL ${CHANNEL(rtcp,<stat>)}, onde ao invés de stat você pode colocar:

all_month;
txmes;
rxmeses;
remote_maxmonth;
remote_minmes;
remote_normdevmes;
remote_stdevmes;
local_maxmonth;
local_minmeses;
local_normdevmes;
local_stdevmes.

Com LOCAL entendemos o fluxo de mídia que chega ao Asterisk® SCF™ e com REMOTO o fluxo de mídia que sai do Asterisk® SCF™. Eu testei em duas chamadas:

uma entre ramais;
e uma saída usando um tronco SIP.

Em ambos os casos, a qualidade era muito boa. Se quiséssemos expressar o valor com o índice de 1 a 4,5, tomando, por exemplo, o valor do MESlocalMAX da primeira chamada, que seria (arredondamento):

Opinião = 1 + (0,035 x 85,4) + (85,4 x (85,4 – 60) x (100 – 85,4) * 0,0000007) = 4,01

Por Andrea Sannucci

Fonte: Planet SIP

Yeti Switch - SOFTSWITCH PARA HUMANOS!!

2023-07-24T08:44:00.005-10:00

Versão 1.12

O sistema operacional suportado é Debian GNU/Linux 11, a única arquitetura suportada é amd64.

Configuração de repositórios

A maioria dos servidores pode usar o mesmo conjunto de repositórios:

deb http://ftp.debian.org/debian/ bullseye main contrib non-free
deb http://ftp.debian.org/debian/ bullseye-updates main
deb http://security.debian.org/debian-security bullseye-security main

deb http://pkg.yeti-switch.org/debian/bullseye 1.12 main
deb http://apt.postgresql.org/pub/repos/apt/ bullseye-pgdg main

Os repositórios do sistema podem ser alterados editando o arquivo: /etc/apt/sources.list. Como usamos nosso próprio repositório de pacotes, você deve adicionar nossa chave a um arquivo confiável.

# apt install -y vim wget gnupg net-tools

# wget http://pkg.yeti-switch.org/key.gpg -O - | apt-key add -

A chave do repositório PGDG também deve ser adicionada à lista confiável:

# wget https://www.postgresql.org/media/keys/ACCC4CF8.asc -O - | apt-key add -

Roteando a instalação do banco de dados

NOTA: Recomendamos colocar o banco de dados de roteamento no mesmo host com interface WEB de gerenciamento para melhor desempenho e capacidade de resposta da interface web.

Versões suportadas

A única versão do PostgreSQL suportada é a 13.

Instalação de pacotes

# apt update

# apt install postgresql-13 postgresql-contrib-13 postgresql-13-prefix postgresql-13-pgq3

# apt install postgresql-13-pgq-ext postgresql-13-yeti postgresql-13-pllua pgqd

Criação dos bancos de dados

Criar banco de dados de roteamento

# su - postgres
$ psql

postgres=# create user yeti encrypted password 'algumasenha' superuser;
CREATE ROLE
postgres=# create database yeti owner yeti;
CREATE DATABASE
postgres=# \q

postgres@yeti:~$ exit

NOTA: Recomenda-se escolher nomes de bancos de dados, nomes de usuários e senhas diferentes dos especificados neste manual por motivos de segurança.

Para grandes instalações, é recomendável colocar o banco de dados CDR em um servidor dedicado.

Verificações

Verifique se os bancos de dados foram criados com sucesso e estão acessíveis:

root@yeti:/# psql -h 127.0.0.1 -U yeti -d yeti
Password for user yeti:  psql (9.4.5) SSL connection
(cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256)
Type "help" for help.

yeti=# \q
root@yeti:/#

Não se esqueça de fazer alterações em /etc/postgresql/13/main/pg_hba.conf e aplicá-las se você planeja acessar esses bancos de dados de outros hosts e/ou configurar a replicação do banco de dados.

Instalação de bancos de dados CDR

O sistema requer dois bancos de dados: um para roteamento e outro para CDRs. A configuração de diferentes instâncias do PostgreSQL é altamente recomendada para possibilitar a replicação.

Instalação de pacotes

Bancos de dados CDRs requerem um conjunto de pacotes semelhante ao banco de dados de roteamento.

# apt update

# apt install postgresql-13 postgresql-contrib-13 postgresql-13-prefix postgresql-13-pgq3

# apt install postgresql-13-pgq-ext postgresql-13-yeti postgresql-13-pllua pgqd

NOTA: É importante instalar o Postgresql do repositório PGDG. Consulte a configuração dos repositórios para obter detalhes.

Criação dos bancos de dados

Criar banco de dados cdr (Call Detail Record).

# su - postgres
$ psql

postgres=# create user cdr encrypted password 'algumasenha' superuser;
CREATE ROLE
postgres=# create database cdr owner cdr;
CREATE DATABASE
postgres=# \q

postgres@yeti:~$ exit

NOTA: Recomenda-se escolher nomes de bancos de dados, nomes de usuários e senhas diferentes dos especificados neste manual por motivos de segurança.

Para grandes instalações, é recomendável colocar o banco de dados CDR em um servidor dedicado.

Código PGQd

Após a inicialização do banco de dados CDR, você deve executar pgq ticker daemon (pgqd) no servidor com banco de dados CDR. Edite o arquivo de configuração /etc/pgqd.ini e realize as modificações a seguir:

[pgqd]
base_connstr = host=127.0.0.1 port=5432 dbname=cdr user=cdr password=algumasenha
initial_database = cdr
database_list = cdr
pidfile = /var/run/postgresql/pgqd.pid

Então você deve iniciar o ticker:

# service pgqd start

# servide pgqd status

● pgqd.service - PgQ maintenance daemon
     Loaded: loaded (/lib/systemd/system/pgqd.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-07-24 14:07:52 -03; 47min ago
   Main PID: 6949 (pgqd)
      Tasks: 1 (limit: 2323)
     Memory: 1.1M
        CPU: 46ms
     CGroup: /system.slice/pgqd.service
             └─6949 /usr/bin/pgqd /etc/pgqd.ini

Verificações

Verifique se os bancos de dados foram criados com sucesso e estão acessíveis:

root@yeti-cdr:/# psql -h 127.0.0.1 -U cdr -d cdr
Password for user cdr:  psql (9.4.5) SSL connection
(cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256)
Type "help" for help.

cdr=# \q
root@yeti-cdr:/#

instalação da interface WEB

Requisitos do servidor:

Arquitetura amd64;
Distribuição Debian 11 Bullseye;
Pelo menos 4 GB de RAM.

Instalação de pacotes

# apt update && apt install yeti-web nginx

Configuração de conexão de bancos de dados

Para configurar os parâmetros de conexão de bancos de dados, crie o arquivo /opt/yeti-web/config/database.yml com o seguinte conteúdo:

production:
  primary:
    adapter: postgresql
    encoding: unicode
    database: yeti
    username: yeti
    password: algumasenha
    host: 127.0.0.1
    port: 5432
    schema_search_path: 'gui, public, switch, billing, class4, runtime_stats, sys, logs, data_import'
    min_messages: notice
    pool: 5

  cdr:
    adapter: postgresql
    encoding: unicode
    database: cdr
    username: yeti
    password: algumasenha
    host: 127.0.0.1
    port: 5432
    schema_search_path: 'cdr, reports, billing'
    min_messages: notice
    pool: 5
    migrations_paths: db/cdr_migrate

Você deve especificar endereços e credenciais corretos que foram usados na seção anterior.

Configuração Yeti-web

Copie o exemplo do arquivo de configuração /opt/yeti-web/config/yeti_web.yml.distr para /opt/yeti-web/config/yeti_web.yml

# cp -av /opt/yeti-web/config/yeti_web.yml.distr /opt/yeti-web/config/yeti_web.yml

Inicialização da comunicação com os bancos de dados

Para inicializar bancos de dados vazios durante a instalação inicial:

# cd /opt/yeti-web
# su -s /bin/bash yeti-web
$ RAILS_ENV=production ./bin/bundle.sh exec rake db:schema:load db:migrate
$ RAILS_ENV=production ./bin/bundle.sh exec rake db:seed

yeti-web@yeti:~$ exit

root@yeti:/opt/yeti-web# cd /

Para atualizar os bancos de dados para a versão mais recente:

# cd /opt/yeti-web
# su -s /bin/bash yeti-web
$ RAILS_ENV=production ./bin/bundle.sh exec rake db:migrate

yeti-web@yeti:~$ exit

root@yeti:/opt/yeti-web# cd /

Configuração do Nginx

Para configuração básica, remova a configuração padrão e copie yeti-web.dist.nginx:

# rm /etc/nginx/sites-enabled/default
# cp /opt/yeti-web/config/yeti-web.dist.nginx /etc/nginx/sites-enabled/yeti
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# service nginx restart

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-07-24 15:22:34 -03; 4s ago
       Docs: man:nginx(8)
    Process: 16821 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 16822 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 16823 (nginx)
      Tasks: 2 (limit: 2323)
     Memory: 2.6M
        CPU: 15ms
     CGroup: /system.slice/nginx.service
             ├─16823 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             └─16824 nginx: worker process

Lançar

Após a configuração bem-sucedida dos bancos de dados, você finalmente pode executar o software usando os seguintes comandos:

# service yeti-web start
# service yeti-cdr-billing@cdr_billing start
# service yeti-cdr-billing@cdr_stats start
# service yeti-delayed-job start
# service yeti-scheduler start

Isso executará a interface da WEB, as agendas de processos, processos de tarefas agendadas em segundo plano e os serviços de processamento do CDR.

Verificações

Verifique se o puma escuta no soquete local:

# netstat -lpn | grep puma
unix 2 [ACC] STREAM OUVINDO 41901 16860/puma 6.2.1 (u /run/yeti/yeti-unicorn.sock)

verifique se o nginx escuta em endereços e portas TCP/IP corretos:

# netstat -lpn | grep nginx
tcp 0 0 127.0.0.1:6666 0.0.0.0:* OUÇA 16823/nginx: master
tcp 0 0   0.0.0.0:80   0.0.0.0:* OUÇA 16823/nginx: master

Arquivos de log para verificar possíveis avisos/erros:

/var/log/yeti/yeti-web.log
/var/log/yeti/yeti-cdr-billing.log
/opt/yeti-web/log/puma.stdout.log
/opt/yeti-web/log/puma.stderr.log

Tente abrir a interface de gerenciamento em seu navegador favorito e faça o login com as credenciais padrão:

User: admin

Pass: 111111

E por hoje é só, pessoal!

Fonte: https://yeti-switch.org/

Asterisk® SCF™ - PJSIP Negociação Avançada de CODEC

2023-07-03T10:29:00.003-10:00

Prefácio

Este post não está completo e nem o software em 15 de julho de 2020. Ainda há muitas coisas para imprementar e/ou testar.

Direct Media (Mídia Direta);
100rel/early media;
re-INVITES;
Fax;
Multi-Stream (Transmissão Múltipla);
Deferred SDP (Deferimento do SDP);
ARI Channel Operations (Operações do Canal ARI);
Interoperabilidade com outros drivers de canal;
Função do Dialplan;
etc.

Bem, ainda estamos trabalhando nisso.

Introdução

Com o lançamento do Asterisk® SCF™ versão 18, vem um novo processo de Negociação Avançada de CODEC. Isso não apenas cria novas oportunidades de configuração, mas também refatora completamente o próprio processo de negociação. O resultado é um processo de negociação mais fácil de entender, imprementado em muito menos código. O driver do canal PJSIP é atualmente o único a adotar o novo processo, mas seus outros drivers podem ser alterados para usá-lo no futuro. No entanto, eles teriam que adotar a interface do STREAMS.

Arquitetura

Ao pensar no processo de negociação, estamos realmente falando sobre a negociação de topologias de fluxo entre duas entidades. Para cada canal, existe uma topologia que contém um ou mais fluxos que descrevem a mídia. Na verdade, o processo de negociação acontece stream a stream, mas vamos usar a " chamada de áudio simples " como exemplo. A topologia conteria apenas um fluxo de " áudio ", mas esse fluxo poderia, é claro, permitir vários codecs.

Uma vez que o Asterisk® SCF™ é um Agente de Usuário Back-2-Back, não há praticamente nenhum cenário (mesmo com Mídia Direta) onde as partes chamadoras e chamadas negociam diretamente umas com as outras. Temos 2 canais e o CORE do Asterisk® SCF™ envolvido. Com isso em mente, se Alice chama Bob, Alice negocia com o driver de canal de Alice, o driver de canal de Alice negocia com o driver de canal de Bob via CORE do Asterisk® SCF™, então o driver de canal de Bob negocia com Bob. Diante disso, existem 4 pontos de controle onde podemos alterar o comportamento do processo de negociação...

Depois de recebermos a oferta de SDP de Alice, mas antes de o driver enviar a oferta ao CORE do Asterisk® SCF™. (incoming_offer);
Depois que o CORE do Asterisk® SCF™ enviou a oferta para o canal de Bob, mas antes de enviarmos uma oferta SDP para Bob. (outgoind_offer);
Depois de recebermos a resposta SDP de Bob, mas antes de enviá-la ao CORE do Asterisk® SCF™. (incoming_answer);
Após o CORE do Asterisk® SCF™ ter enviado a resposta para o canal de Alice, mas antes de enviarmos uma resposta SDP para Alice. (outgoing_answer).

Em todos esses casos, temos duas topologias que podemos alternar, uma " pendente "(pending) e uma " configurada " (configured), e várias operações de seleção e filtragem que podemos realizar nelas. O resultado é uma topologia " resolvida " (resolved). O processo de resolução é controlado por quatro parâmetros...

prefer: Qual da lista de CODECs no stream nós preferimos? O pendente ou o configurado?

incoming_offer: Este é bastante óbvio. Pendente é a topologia criada analisando a oferta do SDP de Alice e Configurada é aquela criada a partir da lista de CODECs permitidos no terminal de Alice.
output_offer: Este é um tanto óbvio. Pendente é o resultado da resolução incoming_offer de Alice que foi recebida do CORE do Asterisk® SCF™ e Configurado é aquele criado a partir da lista de CODECs permitidos no terminal de Bob.
incoming_answer: Este é menos óbvio. Pendente é o resultado da análise da resposta SDP de Bob e Configurado é o que enviamos a Bob na oferta.
outgoing_answer: Este também é menos óbvio. Pendente é o resultado da resolução incoming_answer de Bob e Configurado é o resultado da resolução incoming_offer de Alice.

Então, o que prefer realmente significa? Leia...

operation: Agora que sabemos qual topologia preferimos, que operação queremos realizar nelas?

union: Combinamos os codecs de ambas as topologias começando com a lista preferencial e adicionando ao final os codecs da lista não preferencial que ainda não estavam na lista preferencial. Basicamente, estamos preservando a ordem da topologia preferida.
intersect: Começamos com a lista preferida novamente, mas descartamos quaisquer CODECs que não estejam em ambas as listas. Isso mantém apenas os CODECs comuns enquanto preserva a ordem da lista preferencial.
only_preferred: Apenas usamos a lista de preferidos e descartamos completamente a lista de não preferidos.
only_nonpreferred: Apenas usamos a lista de não preferidos e descartamos completamente a lista de preferidos.

keep: Agora que temos uma lista filtrada e ordenada, o que guardamos dela?

all: Mantenha-os todos;
first: Passe apenas pelo primeiro CODEC na lista resultante.

Transcode: Finalmente, permitimos a transcodificação ou não?

allow: Permite que a chamada prossiga mesmo se a lista resultante não tiver CODECs nela.
prevent: NÃO permite que a chamada prossiga se a lista resultante não tiver CODECs nela.

Configuração

Os quatros pontos de controle e seus parâmetros são todos configurados nos terminais PJSIP. Os parâmetros do ponto de controle são nomeados...

codec_prefs_incoming_offer;
codec_prefs_outgoing_offer;
codec_prefs_incoming_answer;
codec_prefs_outgoing_answer.

Os parâmetros são especificados como pares <nome>:<valor> separados por vírgulas (o espaço em branco é ignorado). Aqui está um exemplo, incluindo uma declaração de permissão, mostrando os padrões para cada ponto de controle...

Padrões de preferência de negociação de CODEC

allow = !all,g722,ulaw
codec_prefs_incoming_offer = prefer: pending, operation: union, keep: all, transcode: allow
codec_prefs_outgoing_offer = prefer: pending, operation: intersect, keep: all, transcode: allow
codec_prefs_outgoing_offer = prefer: pending, operation: union, keep: all, transcode: allow
codec_prefs_outgoing_offer = prefer: pending, operation: union, keep: all, transcode: allow

Você notará que os padrões sempre preferem a topologia "pendente", portanto, em nosso exemplo, o que Alice envia em sua oferta SDP define o cenário.

Realmente Simples

Vamos começar com uma chamada básica em que Alice e Bob são configurados com suas configurações padrão e ambos com um parâmetro "allow" definido como "!all,ulaw,g722".

Alice faz uma oferta => Asterisk® SCF™ => Bob:

Alice envia um INVITE com uma oferta SDP contendo ulaw e g722 nessa ordem.
O canal de Alice resolve essa topologia com os codecs configurados de seu endpoint e as preferências de incoming_offer. Como preferimos Pendentes e a operação é union (união), o resultado do primeiro estágio não surpreende: ulaw,g722. Vamos manter ambos os CODECs e a transcodificação realmente não importa neste momento.
O canal de Alice então envia a chamada para o CORE do Asterisk® SCF™ junto com a topologia resolvida.
O CORE do Asterisk® SCF™ invoca o dialplan que cria o canal de saída de Bob e encaminha a topologia resolvida para ele.
O canal de Bob agora resolve a topologia que veio do CORE do Asterisk® SCF™ (pendente) com os CODECs configurados de seu próprio terminal e as preferências de output_offer. A única diferença entre suas preferências e as de Alice é a operação. Como ambas as topologias já são iguais, o resultado ainda é ulaw,g722.
Com base nisso, o canal de Bob cria um INVITE de saída com uma oferta SDP contendo ulaw,g722 nessa ordem.

Bob aceita a oferta => Asterisk® SCF™ => Alice.

Bob responde a oferta com uma resposta do tipo SDP contendo apenas ulaw.
O canal de Bob resolve a topologia de resposta recebida (pendente) com a topologia enviada para Bob (configurada) que tem ulaw,g722 e as preferências de resposta recebida de Bob. Como a operação é union (união), a topologia resolvida contém apenas ulaw.
O driver de canal de Bob passa a topologia resolvida de volta ao CORE do Asterisk® SCF™, pois indica que a chamada está sendo atendida (answered).
O CORE do Asterisk® SCF™ passa a topologia resolvida de volta para o canal de Alice, uma vez que informa que Bob respondeu (answered).
O canal de Alice resolve a topologia do CORE do Asterisk® SCF™ (pendente), com a topologia que originalmente enviou para o CORE do Asterisk® SCF™ (configurado) que tinha ulaw,g722 e as preferências de outgoing_answer de Alice. Novamente, como a operação é union (união), a topologia resolvida contém apenas ulaw.
O canal de Alice então envia a resposta SDP de volta para Alice com apenas ulaw.

Nesta chamada, Alice deu o tom para a chamada.

Uma mudança na ordem

Sabemos que os telefones de Alice e Bob podem suportar g722, mas seus telefones sempre listam ulaw primeiro. Então, como podemos fazê-los usar o g722? Vamos fazer algumas alterações de configuração...

Começamos alterando as preferências de oferta de entrada de Alice para preferir a topologia configurada em vez da pendente.

codec_prefs_incoming_offer = prefer: configured, operation: union, keep: all, transcode: allow

Em seguida, configuramos os CODECs de Alice para g722,ulaw.

allow = !all,g722,ulaw

Agora vamos ligar...

Alice faz uma oferta => Asterisk® SCF™ => Bob:

Alice envia um INVITE com uma oferta SDP contendo ulaw e g722 nessa ordem.
O canal de Alice resolve essa topologia (pendente) com os CODECs configurados de seu terminal (g722,ulaw) e as preferências de incoming_offer. Como preferimos configurado e a operação é union (união), o resultado do primeiro estágio agora é g722,ulaw.

O restante da chamada flui como antes, exceto que g722,ulaw é a topologia pendente. Pode haver um " gotcha " (te peguei). A RFC3264 afirma que um agente de usuário que recebe uma oferta NÃO DEVE alterar a ordem dos codecs ao criar sua resposta. Não diz que NÃO DEVE alterar o pedido. Portanto, é possível, embora altamente improvável, que Bob possa responder a g722,ulaw com ulaw,g722. Se for esse o caso, você pode forçar Bob a usar g722 definindo seu parâmetro de manutenção de outgoing_offer como primeiro. Desta forma, enviaremos apenas g722. Claro, se ele não suporta g722, você não deveria tê-lo configurado em seu terminal em primeiro lugar. 😂

Transcodificação

Isso é onde fica complicado...

Digamos que o terminal de Alice esteja configurado apenas com alaw como CODEC, mas ela envia apenas ulaw,g722. Se a topologia resolvida estiver vazia, como seria se a operação fosse union (união), a chamada é encerrada imediatamente com um 488 Not Acceptable Here. Não importa qual é o parâmetro de transcodificação definido porque, neste ponto, nem sabemos qual é o canal de saída.
Agora vamos supor que o endpoint de Alice tenha ulaw,g722. Como o terminal dela também tinha ulaw,g722, nós o enviamos para o CORE do Asterisk® SCF™. O endpoint de Bob, no entanto, tinha apenas um CODEC, alaw! E sua operação era union (união). Isso resultaria em uma topologia resolvida vazia. Para que a transcodificação seja considerada, o parâmetro de transcodificação de incoming_offer de Alice e o parâmetro de transcodificação de outgoing_offer de Bob DEVEM ser configurados para permitir. Se um deles for "impedir", a chamada será encerrada. Se ambos forem permitidos, enviaremos uma oferta a Bob com alaw como CODEC.
Se Bob responder sem CODECs, a chamada será encerrada. Novamente, porém, você provavelmente não deveria ter configurado o endpoint de Bob com um CODEC não suportado. Caso contrário, a topologia resolvida (alaw) é passada de volta para o CORE do Asterisk® SCF™.
O canal de Alice obtém a topologia do núcleo (pendente) e a resolve em relação ao que foi enviado ao CORE do Asterisk® SCF™ (configurado) e às preferências de outgoing_answer de seu terminal. Se a topologia resultante estiver vazia, como seria neste caso, o parâmetro de transcodificação output_answer será verificado. Se for permitido, o canal usará a topologia originalmente enviada ao CORE do Asterisk® SCF™ para construir a resposta de saída e simplesmente ignorará a topologia resolvida. Se o parâmetro transcode for prevent (o que provavelmente foi uma configuração incorreta), a chamada será encerrada.

Implementação nos bastidores

A implementação antiga tinha negociação de CODEC espalhada por chan_pjsip, res_pjsip_session e res_pjsip_sdp_rtp. A ACN tenta consolidar toda a negociação de CODECs em chan_pjsip, mas ainda há resquícios nos outros módulos que precisarão ser refatorados. Um bom exemplo é a função "set_caps" em res_pjsip_sdp_rtp. Ele é chamado tanto nas respostas recebidas quanto nas respostas enviadas, mas na verdade não queremos que ele seja executado para respostas enviadas, pois ele tenta definir os limites para o que estava na oferta recebida original. Isso não é bom. Tudo funciona como pretendido, mas é um código inútil. Outro problema é que muitas das funções nos módulos res_pjsip são reutilizadas e não têm ideia do contexto em que são executadas. Por exemplo, apply_negotiated_sdp é executado para respostas recebidas e enviadas (é assim que set_caps é executado duas vezes). De qualquer forma...

Alice faz uma oferta => Asterisk® SCF™ => Bob:

incoming_offer: Isso é tratado em chan_pjsip:chan_pjsip_incoming_request( ) antes que o canal seja realmente criado. Essa função é chamada por sessão por meio do suplemento handle_incoming_request. A função resolve a topologia criada a partir da oferta de Alice com os parâmetros e CODECs do endpoint e do endpoint de Alice. Supondo que haja fluxos ativos deixados na topologia resolvida, a função redefine a topologia pendente na sessão para ser a topologia resolvida e chama chan_pjsip_new, que define a topologia no canal junto com os limites de formato nativo e os formatos de leitura e gravação. NOTA: Não definimos os CODECs de instância RTP aqui, mas deveríamos. Se a resolução falhar, terminamos com um 488.
Eventualmente, trabalhamos até app_dial:dial_exec_full, que cria o canal de saída de Bob com ast_request_with_stream_topology( ) passando na topologia do canal de Alice.
outgoing_offer: ast_request_with_stream_topology( ) chama chan_pjsip_request_with_stream_topology( ). Em seguida, isso resolve a topologia de solicitação (pendente) com os parâmetros output_offer do endpoint de Bob e os CODECs de endpoint do endpoint de Bob. Supondo que existam fluxos ativos deixados na topologia, a função chama chan_pjsip_new( ) que define a topologia do canal de Bob, limites de formato nativo e formatos de leitura/gravação. Mesma observação acima, devemos definir os CODECs de instância RTP aqui, mas ainda não. Se a topologia resolvida, incluindo a aplicação de opções de transcodificação, não tiver mais fluxos ativos, retornamos uma causa de AST_CAUSE_FAILURE para app_dial e bail, o que faz com que um 503 seja enviado para Alice.
dial_exec_full finalmente chama chan_pjsip_call( ) cuja tarefa call( ) chama ast_sip_session_create_invite( ) então ast_sip_session_send)request( ).

Bob aceita a oferta => Asterisk® SCF™ => Alice.

incoming_answer: Quando Bob envia um 200OK, pjproject chama nosso callback session_inv_on_media_update( ) que então chama res_pjsip_session:handle_negotiated_sdp( ). Isso define a topologia ativa para aquela recebida de Bob. Eventualmente, pjproject sinaliza uma mudança de estado de transação com base no recebimento de 200OK, que aciona os suplementos handle_incoming_response da sessão, um dos quais é chan_pjsip_incoming_response_after_media( ). Isso resolve a topologia ativa que veio de Bob, com a topologia que enviamos a Bob usando as preferências de resposta recebida do endpoint de Bob. A função então chama ast_queue_control_data com um tipo de quadro AST_CONTROL_ANSWER e a topologia resolvida como os dados.
app_dial:wait_for_answer( ) recebe o quadro ANSWER e coloca a topologia na estrutura de configuração da ponte. Isso é passado para features:ast_bridge_call( ) e para baixo para pre_bridge_setup( ) que chama ast_raw_answer_with_stream_topology( ). Isso, por sua vez, chama chan_pjsip_answer_with_stream_topology no canal de Alice.
output_answer: a tarefa de resposta de chan_pjsip_answer_with_stream_topology faz a resolução final usando a topologia ativa de Bob, a topologia pendente de Alice que foi originalmente enviada para o CORE do Asterisk® SCF™ e os parâmetros de output_answer do terminal de Alice.

Fonte: https://wiki.asterisk.org/

Por: George Joseph.

Asterisk® SCF™ - Utilizando PJSIP como Proxy

2023-07-03T05:53:00.003-10:00

Existe muitos cenários de proxy diferentes nos quais o Asterisk® SCF™ pode estar envolvido. Nem todos podem ser explicados aqui, mas alguns exemplos podem ajudá-lo a se adaptar à sua situação específica. O primeiro e mais simples cenário é onde o Asterisk® SCF™ está funcionando como um PBX na mesma rede privada em que os telefones estão, mas precisa de conectividade com um Provedor de Serviços de Telefonia pela Internet (ITSP - Internet Telephony Service Provider).

Outbound Proxy (Proxy de Saída)

Assumiremos que o ITSP exige que o Asterisk® SCF™ se registre para receber chamadas. Claro, mesmo com o Asterisk® SCF™ atrás de um firewall ou roteador NAT, um proxy não é realmente necessário, mas a configuração é boa para começar. Embora a configuração de um proxy como o Kamailio® esteja além do escopo deste post, este cenário requer apenas as configurações de proxy mais simples e provavelmente funcionaria com os exemplos fornecidors pelo Kamailio®. Vamos assumir que o proxy é DUAL HOMED com uma interface na rede privada e uma inteface na rede pública. Também assumiremos que o proxy está retransmitindo mídia e sinalização. Usaremos 192.168.15.1 como endereço privado do proxy e 192.168.15.2 como endereço do Asterisk® SCF™ (atuando como um Softswitch PBX IP).

Configuração do Asterisk® SCF™

Existem vários objetos PJSIP que precisam ser configurados para esta situação.

transport: Na verdade, esta é uma ação de desconfiguração 😂. Se o Asterisk® SCF™ não estiver usando um proxy, você pode ter parâmetros no transporte como external_signalling_address, external_media_address, local_net, etc. Estes NÃO deve ser configurados quando o Asterisk® SCF™ e o PROXY estiverm na mesma rede. O Asterisk® SCF™ não deve saber nada sobre o que está do outro lado do proxy, pois o trabalho do proxy é tornar isso invisível.

Examplo:
[ipv4-udp]
type = transport
protocol = udp
bind = 0.0.0.0:5060

endpoint: Configure o endpoint do ITSP como faria normalmente, mas adicione um parâmetro outbound_proxy com um URI que aponta para o endereço interno do proxy. Isso direcionará (quase) todas as solicitações de saída desse endpoint para o proxy. Você também não deve ativar nenhum parâmetro reladionado ao NAT, como force_rport, ice_support, etc.

Examplo:
[myitsp]
type = aor
contact = sip:my.itsp.com:5060
outbound_proxy = sip:192.168.0.1\;lr
qualify_frequency = 60

registration: O mesmo que aor. Os URIs do clinte e do servidor devem permanecer como estavam para a situação sem proxy e o parâmetro outbound_proxy deve ser incluído.

Examplo:
[myitsp]
type = registration
client_uri = sip:my_account@my.itsp.com
server_uri = sip:my.itsp.com
outbound_proxy = sip:192.168.0.1\;lr

identify: agora as coisas ficam um pouco complicadas. A mairoria dos ITSPs não autentica de volta para seus clientes ao enviar as chamadas e eles podem estar enviando o CallerID do originador/chamador como o usuário do cabeçalho FROM: (DE), portanto, a (quase) única maneira de identificar as chamdas da ITSP é pelo endereço IP. Se não houvesse proxy no circuito, você provavelmente configuraria um objeto de identificação com um parãmetro match = my.itsp.com. No caso do proxy, porém, a correspondência precisa ser com o endereço privado do proxy, pois esse é o endereço IP de onde os pacotes virão.

Examplo:

[myitsp]
type = identify
match = 192.168.0.1
endpoint = myitsp

Você deve ter notado que os URIs do proxy têm o parâmetro " lr " adicionado. Isso ocorre porque a maioria dos proxies hoje em dia segue o RFC 3261 e, portanto, tem " loose-routing " (roteamento flexível). Se você não o tiver definido, provavelmente receberá uma reposta 404 do proxy. O objeto " \ " antes do ponto e vírgula é importante para evitar que o ponto e vírgula seja tratado como um caractere inicial de comentário no arquivo de configuração.

Bom, nesse ponto, você deve ter um tronco com sua ITSP funcionando para chamadas de Inbound (entradas) e Outbound (saídas).

Direct Media

Se o seu proxy for compatível, você poderá ativar a mídia direta entre os telefones e o proxy definindo direct_media = yes no telefone (device) e nos terminais (endpoint) da ITSP. O proxy deve cuiadar do resto. Tentar fazer mídia direta, diretamente entre os telefones (devices) e o terminais (endpoints) da ITSP provavelmente não funcionará.

Multiplas ITSPs

Há um pequeno problema com a configuração acima se você tiver mais de 1 tronco ITSP por meio do proxy. Na configuração acima, o objeto de identificação é usado para direcionar solicitações recebidas do proxy para um único endpoint e você não pode direcionar o mesmo endereço IP para vários endpoints por motivos óbvios. Você pode definir 1 endpoint e 1 identificador para o proxy atuar como o receptor de chamadas de todos os provedores de serviços, mas isso nem sempre é conveniente ou possível com algumas GUIs front-end.

Nesse caso, e se o seu ITSP suportar, você pode usar o parâmetro de linha do objeto de registro como o mecanismo para corresponder as solicitações recebidas a um terminal e eliminar completamente o uso de identificar.

Veja como funciona: Quando você especifica line = true e endpoint = <endpoint> em um registro, o Asterisk® SCF™ acrescenta um parâmetro " line " ao URI de contato do REGISTER de saída que contém uma string exclusiva. Ficará assim: " Contact: <sip:s@192.168.0.2.245:5060;line=eylpkkv> ". Se a sua ITSP suportar, quando enviar uma solicitação INVITE para o Asterisk® SCF™, ele incluirá o parâmetro " line " no Request URI ou no cabeçalho To da seguinte forma: " INVITE sip:8005551212@192.168.0.2:5060;line=eylpkkv SIP/2.0 " . O Asterisk® SCF™ então usará essa string única para corresponder a solicitação ao endpoint especificado no registro.

Examplo:
[myitsp]
type = registration
client_uri = sip:my_account@my.itsp.com
server_uri = sip:my.itsp.com
outbound_proxy = sip:192.168.0.1
line = yes
endpoint = myitsp

Header Matching (Correspondência de Cabeçalho)

Algumas ITSPs incluem cabeçalhos " X- " em suas solicitações que contêm números de contas ou outras informações de identificação. O Asterisk® SCF™, em suas versões 13.15 e 14.5 têm um novo recurso de identificação que permite combinar as solicitações recebidas com os endpoints por meio desses cabeçalhos.

Examplo:
[myitsp]
type = identify
match_header = X-My-Account-Number: 12345678
endpoint = myitsp

Inbound Proxy (Proxy de Entrada)

Em um cenário de provedor de serviços (ITSP), o Asterisk® SCF™ provavelmente estará atrás de um proxy separado da internet pública e dos clientes, sejam eles telefones ou PBXes ou o que quer que seja. Nesse caso, a carga de configuração muda do Asterisk® SCF™ para o proxy. Você provavelmente desejará configurar o proxy para lidar com autenticação, qualificação, direção de mídia para gateways de mídia, servidores de correio de voz etc., e tudo isso está além do escopo deste documento. Contribuições que contenham instruções para proxies populares serão muito bem-vindas.

Fonte: https://wiki.asterisk.org/

Por George Joseph.

Asterisk® SCF™ Aplicativo: sendDTMF( )

2022-12-13T04:30:00.001-10:00

O Aplicativo de Dialplan do Asterisk® SCF™: sendDTMF( ), envia uma sequencia especificada de tons DTMF em um canal.

Descrição

Envia a sequencia especificada de dígitos para o canal.

Sintaxe

sendDTMF(dígitos[,timeout_ms[,duration-ms[,canal]]])

Argumentos

dígitos - números ou símbolos suportados

0 - 9 - números

* # - os caracteres especiais * e #

a - d - letras latinas minúsculas de a a d

A - D - letras latinas maiusculas de A a D

w - pausa (wait) de 0,5 segundos

W - pausa (wait) de 1 segundo

F - flash gancho se suportado pelo canal

timeout_ms - intervalo entre os sinais DTMF - por padrão são de 0,25 segundos.

duration_ms - duração de cada dígito.

canal - o canal para onde os dígitos devem ser enviados.

Observação: O Aplicativo de Dialplan do Asterisk® SCF™ Dial( ), com o parâmetro D também pode enviar sequencias DTMF.

Exemplo

Nesse exemplo temos um Dial sendo executado sobre um sistema POTS (Sistema de Cartão), e estamos substituindo o número do sistema e o pincode.

O assinante faz a marcação do prefixo 001 e o número chamado.

O sistema liga para o número da operadora (cardnum) e envia a sequencia de DTMF: o codigo pin e o numero de destino da chamada (PIN e NUM).

[from-internal]
exten => _001X.,1,noop
   same => n,answer
   same => n,mset(num=${EXTEN:3},pin=1234567,cardnum=6666666)
   same => n,Dial(PJSIP/${cardnum}@pjsip_trunk,,U(sub-card^${pin}^${num}))
[sub-card]
exten =>  s,1,senddtmf(W${ARG1}w${ARG2}#,,,)
   same => n,return

Fonte: Asterisk® Documentation

Asterisk Module and Build Option Selection - XXX cel_pgsql

2022-09-15T07:37:00.001-10:00

Olá a todos, depois de muito tempo, venho trazer uma treta bacana que peguei no Asterisk® SCF™, por algum motivo no método normal de instalação das dependências do Asterisk® SCF™ não ocorreu o atendimento da dependência para que o Asterisk Module and Build Option Selection identifica-se o PGSQL(E) para o modulo cdr_pgsql e cel_pgsql. Observe a imagem a seguir:

Para entender o que está ocorrendo, entre no fonte do Asterisk® SCF™ e execute o teste pelo script install_prereq:

# cd /usr/local/src/asterisk-13.35.0/

# contrib/scripts/install_prereq test

Neste caso, que estamos expondo, a resposta foi essa:

yum install --skip-broken --assumeyes speexdsp-devel postgresql-devel mysql-devel iksemel-devel hoard gmime.x86_64 gmime-devel.x86_64

Observe que entre a resposta do teste, esta sendo informado que postgresql-devel não foi encontrado para atender os módulos do Asterisk® SCF™.

Executando o comando do RPM para validar os pacotes instalados obtemos a seguinte resposta:

# rpm -qa | grep postgres

postgresql11-libs-11.13-1PGDG.rhel7.x86_64
postgresql11-server-11.13-1PGDG.rhel7.x86_64
postgresql11-devel-11.13-1PGDG.rhel7.x86_64
postgresql11-11.13-1PGDG.rhel7.x86_64
postgresql11-contrib-11.13-1PGDG.rhel7.x86_64

Ou seja, temos o PostgreSQL 11 instalado, e logo sabemos que o PostgreSQL11-Devel se encontra instalado, mas o Asterisk® SCF™ não sabe. Então para ter certeza que ter certeza de qual versão se encontra ativo e funcional no Sistema Operacional use esse comando:

# psql --version | awk '{print $3}' | awk -F '.' '{print $1}'
11

Obtivemos o resultado sendo 11, então execute o configure para essa versão do postgresql-devel, deste modo:

# ./configure --prefix=/usr --with-postgres=/usr/pgsql-11/.

Entre novamente no Menu Select do Asterisk Module and Build Option Selection:

# make menuselect

E observe que agora temos os modulos ativos para serem copilados, veja as figuras a seguir:

Agora para compilar este Build com segurança, devemos parar o Asterisk® SCF™, para isso execute os próximos passos:

# systemctl stop asterisk.service

# make -j4

# make install

# ldconfig

# systemctl start asterisk.service

# rasterisk -vvvvgci

Na console do Asterisk® SCF™ valide se os módulos já estão ativos, caso não estejam suba eles. Lembrando que para que os módulos sejam carregados automaticamente é necessário em modulos.conf a opção autoload do modules estar ativa para yes:

[modules]

autoload=yes

*CLI> module show like cel_pgsql.so
Module Description Use Count Status Support Level
cel_pgsql.so PostgreSQL CEL Backend 0 Running extended
1 modules loaded

*CLI> module show like cdr_pgsql.so
Module Description Use Count Status Support Level
cdr_pgsql.so PostgreSQL CDR Backend 0 Running extended
1 modules loaded

Pronto, a partir deste ponto, a sua comunicação com o banco de dados PostgreSQL via conector nativo do Asterisk® SCF™ funcionando.Tire a prova de conexão com o CORE/PBX:

*CLI> cel show status
CEL Logging: Enabled
CEL Tracking Event: HANGUP
CEL Tracking Event: ANSWER
CEL Tracking Event: BRIDGE_ENTER
CEL Tracking Event: ATTENDEDTRANSFER
CEL Tracking Event: USER_DEFINED
CEL Tracking Event: LINKEDID_END
CEL Event Subscriber: CEL Custom CSV Logging
CEL Event Subscriber: ODBC CEL backend
CEL Event Subscriber: CEL PGSQL backend

Se executar o comando cdr show status, vais ver que também está tudo funcional entre o modulo e CORE/PBX.

Lembrando que não é mais recomendado usar o modulo nativo para MySQL e PostgreSQL. É altamente recomendado usar a conexão com Banco de Dados via UnixODBC.

Thats All FOLKS! (Isso é tudo, pessoal!)

Asterisk® SCF™ Remoção total para reinstalação - Metodo Recomendado.

2022-08-03T06:04:00.004-10:00

Imagine a seguinte situação, você por algum motivo necessita de fazer um reinstalação do Asterisk® SCF™ em seu servidor, muitas vezes vejo as pessoas apenas indo na pasta do source, e executando todos os procedimentos de instalação novamente, as vezes nem se preocupam em parar o Asterisk® SCF™.

Bem isso é totalmente errado, e pode trazer consequências prejudiciais a sua produção, aqui vou demonstrar como fazer isso de maneira segura e correta.

E porque eu necessito de reinstalar o Asterisk® SCF™? Bom no meu caso isso ocorre quando tenho que desenvolver algo que tenho que utilizar uma versão antiga do Asterisk® SCF™, tipo um downgrade...

Nesse exemplo, estou removendo um Asterisk® SCF™ versão 16.28.0-rc1, e instalando uma versão 13.35.0 para um projeto especifico.

Claro que os procedimentos a seguir, também pode ser utilizado para quando quiser remover por completo o Asterisk® SCF™, a ponto de não querer mais usar ele em um servidor especifico.

Eu necessito lhe informar que você deve fazer backup do seu projeto atual? Ok! Então faça um backup da pasta /etc/asteirsk/ em algum lugar, assim como /var/lib/asterisk/.

E vamos nessa!

killall -9 safe_asterisk
killall -9 asterisk
systemctl disable asterisk.service
rm -rf /etc/asterisk
rm -rf /var/log/asterisk
rm -rf /var/lib/asterisk
rm -rf /var/lib64/asterisk
rm -rf /var/spool/asterisk
rm -rf /usr/lib/asterisk
rm -rf /usr/lib64/asterisk
reboot

OBS: Dependendo da instalação, systemctl disable asterisk.service, pode não estar habilitado ou foi configurado para ser executado via @reboot cron, e não por daemon service.

Agora pode baixar o pacote do Asterisk® SCF™, e refazer a instalação, estou usando o Rock Linux™ e confesso que estou muito feliz com essa distribuição baseada no Sistema Operacional GNU/Linux.

cd /usr/local/src/
wget https://downloads.asterisk.org/pub/telephony/asterisk/old-releases/asterisk-13.35.0.tar.gz
tar -xvf asterisk-13.35.0.tar.gz
cd asterisk-13.35.0/
./contrib/scripts/install_prereq install
./configure --libdir=/usr/lib64 --with-jansson-bundled=yes --with-pjproject-bundled=yes
make menuselect
make -j4
make install
make basic-pbx
make config

Pronto, agora você está com uma nova versão totalmente limpa em seu servidor. Em make menuselect, corrija todos os pontos que sejam importantes para sua solução.

Um outro ponto que deve ser tomado em conta, é que para Asterisk® SCF™ até a versão 14, devemos usar o comando:

./configure --libdir=/usr/lib64 --with-jansson-bundled=yes --with-pjproject-bundled=yes

Para versões superiores a versão 15, deve ser assim:

./configure --libdir=/usr/lib64 --with-jansson-bundled=yes

Thats All FOLKS! (Isso é tudo, pessoal!)

Capítulo 22. Agrupamento (Clustering).

2022-06-04T15:30:00.015-10:00

Você pode não conseguir comer um cacho de uva de uma única vez, mas é muito fácil comer uma a uma.

- Jacques Roumain - Escritor, Político e Defensor do Marxismo Haitiano. 1907 ~ 1944, Porto Príncipe/Haiti.

A palavra agrupamento (Clustering) pode significar coisas diferentes para pessoas diferentes. Algumas pessoas diriam que o clustering é simplesmente ter um sistema replicado em espera disponível para ser ativado quando o sistema primário falhar. Para outros, clustering é ter vários sistemas trabalhando em conjunto, com dados replicados, totalmente redundantes e infinitamente expansíveis. Para a maioria das pessoas, provavelmente está em algum lugar entre esses dois extremos.

Este capítulo do livro Asterisk: The Definitive Guide (3nd Edition for Asterisk 1.8), escrito por Leif Madsen, Jim Van Meggelen, e Russell Bryant. é explorado as possibilidades de clustering que existem com Asterisk® SCF™ em alto nível, dando a você o conhecimento e direção para começar a planejar seu sistema no futuro. Como exemplos, discutiremos algumas das ferramentas que usamos em nossa próprias grandes implantações; embora não haja uma única maneira de construir um Cluster de Asterisk® SCF™, as topologias que abordamos provaram ser confiáveis ao longo dos anos.

Nossos exemplos se aprofundarão na construção de um call center distribuído, uma das razões mais populares para construir um sistema distribuído. Em alguns casos, isso é necessário simplesmente porque uma empresa possui escritórios satélites que deseja vincular ao sistema primário. Para outros, o objetivo é integrar funcionários remotos ou poder lidar com um grande número de extensões. Começaremos analisando um sistema Softswitch PBX IP simples e tradicional e veremos como esse sistema pode eventualmente se transformar em algo muito maior.

Call Centers Tradicionais

A maioria dos sistemas implantados antes do ano 2000 será bastante semelhante. Eles envolverão um conjunto de linhas telefônicas entregues por meio de uma PRI (PSTN) ou por meio de um conjunto de linhas analógicas (POTS), que se conectam a um sistema de PABX (Central de Comutação, Hardware) que entrega chamadas para aparelhos que provavelmente são proprietários (Cisco, Avaya, Intelbras, etc.) dos sistemas implantados. Esses sistemas provavelmente fornecerão um conjunto básico de funções, com funções extras, como correio de voz e conferência, sendo fornecidas por meio de módulos externos que pode custar milhares de dólares. Essa topologia é ilustrada na Figura 22.1, "Central de Atendimento Tradicional".

Figura 22.1. Central de Atendimento Tradicional

Esses sistemas utilizarão um conjunto de regras para entregar chamadas aos agentes por meio das regras padrão de distribuição automática de chamadas (DAC/ACD) e terão pouca flexibilidade. Provavelmente será impossível ou caro adicionar agentes remotos, pois as chamadas precisariam ser entregues pela PSTN, que utiliza duas linhas telefônicas: um apara o chamador de entrada da fila e outra para ser entregue ao agente remoto (na maioria dos casos, os agentes precisam apenas residir no mesmo local físico que o próprio PABX).

No entanto, esses sistemas telefônicos tradicionais estão sendo gradualmente eliminados, à medida que mais pessoas começam a clamar pelos recursos que o VoIP traz para a mesa. E mesmo para sistema que não usarão VoIP, soluções como o Asterisk® SCF™ trazem recursos que antes custavam milhares de dólares como parte incluída do software.

É claro que, com o dinheiro investido em hardware caro em sistemas tradicionais, é natural que as organizações com esses sistemas queiram obter o máximo de uso possível deles. Além disso, simplesmente trocar um sistema existente não é apenas caro (custos de fiação para telefones SIP, custos de substituição de aparelhos proprietários, etc.), mas pode ser invasivo para o Call Center, especialmente se ele operar continuamente.

Talvez, no entanto, tenha chegado a hora de expandir e o sistema existente não consiga mais acompanhar o número de linhas necessárias e o número de extensões necessários para acompanhar a demanda. Nesse caso, pode ser vantajoso olhar para um sistema híbrido, onde hardware existente continua a ser usado, mas novas extensões e recursos são adicionados ao sistema usando o Asterisk® SCF™.

Sistemas Híbridos

Um sistema de telefonia híbrido (figura 22.2, "Sistema Híbrido Remoto) contém a mesma funcionalidade e hardware de um sistema de telefonia tradicional, com exceção de outro sistema, como o Asterisk® SCF™, que está conectado a ele, fornecendo capacidade e funcionalidade adicionais. Adicionar o Asterisk® SCF™ a um sistema tradicional normalmente é feito através de uma conexão PRI (PSTN). Do ponto de vista do sistema tradicional, o Asterisk® SCF™ se parecerá com outra companhia telefônica (Escritório Central ou Operadora VoIP - ITSP, Internet Telephony Service Provider). Dependendo da forma como o sistema tradicional opera e dos serviços disponíveis para ou da ITSP, o Asterisk® SCF™ entregará chamadas do PRI (PSTN) através dele mesmo e para o PABX existente, ou o PABX existente enviará chamada pela conexão PRI para o Asterisk® SCF™, que em seguida, direciona as chamadas para os novos terminais (Telefones IPs) e para a própria ITSP, criando ai, uma Rota de Menor Custo (Least Cost Routing).

Figura 22.2. Sistema Híbrido Remoto

Com o Asterisk® SCF™ no cenário (circuito), a funcionalidade pode ser movida aos poucos do sistema PABX existente para o Asterisk® SCF™, que pode assumir um papel maior e comandar mais do sistema ao longo do tempo. Eventualmente, o sistema de PABX existente pode simplesmente ser usado como um método para enviar chamadas para os aparelhos existentes (analógicos, POTS), nas estações dos agentes, com aqueles sendo eliminados ao longo do tempo e substituídos por telefones baseados em SIP, à medida que a fiação é instalada e os telefones IPs são comprados.

Ao adicionar o Asterisk® SCF™ ao circuito existente, ganhamos um novo conjunto de funcionalidades e vantagens, como:

Suporte para funcionários remotos: as chamadas são entregues pela conexão de Internet Existentes, para Gateways IPs, Telefones IPs, Softphones em Desktops, Tablets e até mesmo em Smartphones;
Funcionalidades como conferencia e correio de voz (com a possibilidade de os usuários serem notificados por e-mail de novas mensagens);
Linhas telefônicas expandidas usando VoIP e redução de custos de longa distancia (DDD e DDI)

Tal sistema ainda sofre de algumas desvantagens, pois todo o hardware precisa residir na instalação do Call Center, e ainda estamos restritos a usar hardware (relativamente) caro no sistema Asterisk® SCF™ para conexão ao PABX tradicional. No entanto, estamos indo na direção certa e, com o sistema Asterisk® SCF™ no circuito, podemos iniciar a migração ao longo do tempo, limitando as interrupções nos negócios e adotado uma abordagem mais gradual para treinar os usuários.

Asterisk® SCF™ Puro, Não Distribuído (Nondistributed)

O próximo passo em nossa jornada é o sistema Asterisk® SCF™ Puro (Puro que dizer, somente a linha de comando, se nenhuma interface gráfica, lembrando que a interface gráfica oficial do projeto Sangoma Digium é o FreePBX e não mais o AsteriskNow). Neste sistema, migramos com sucesso do sistema PBX existente e agora estamos lidando com todas as funcionalidades através do Asterisk® SCF™. Nosso PRI (PSTN) existente foi anexado ao Asterisk® SCF™ e expandimos nossa capacidade integrando um Provedor de Telefonia Pela Internet (ITSP) em nosso sistema. Todos os agentes/usuários agora estão usando telefones SIP (Telefones IP, e Softphones) e até adicionam0os vários funcionários remotos. Está topologia é ilustrada na Figura 22.3, "Asterisk® SCF™ Puro, Não Distribuído (Nondistributed)".

Figura 22.3. Asterisk® SCF™ Puro, Não Distribuído (Nondistributed)

Funcionários remotos podem ser uma grande vantagem para uma empresa. Permitir que seu trabalho em locais remotos (Home Office, P. Ex.) não apenas aumenta o moral dos funcionários, aliviando o fardo de uma viagem potencialmente longa, mas também permite que os funcionários trabalhem em um ambiente em que se sintam confortáveis, o que pode torná-los mais produtivos. Além disso, o gerente do Call Center não tem menos controle sobre as estatísticas dos funcionários; suas chamadas ainda podem ser monitoradas para fins de treinamento, e os dados estatísticos coletados não parecem diferentes para o gerente do que para os funcionários que residem na instalação.

Uma vantagem mensurável para a empresa é a redução na quantidade de hardware necessária a ser comprada para cada funcionário. Se os agentes puderem utilizar seus sistema de computador, redes elétricas e conexões de Internet existentes, a empresa poderá economizar uma quantia significativa de dinheiro apoiando funcionários remotos. Além disso, esses funcionários podem estar localizados em todo o mundo, para expandir o número de horas que seus agentes estão disponíveis, permitindo que você atenda a mais fusos horários.

A utilização deste sistema é simples e eficiente, mas à medida que a empresa cresce, o sistema pode chagar a um problema de capacidade.

Integração do Asterisk® SCF™ Puro ao Banco de dados.

Integrar o Asterisk® SCF™ com um banco de dados pode adicionar muitas funcionalidades ao seu sistema. Além disso, ele fornece uma maneira de construir utilitários de configuração baseados na WEB para facilitar a manutenção de um sistema Asterisk® SCF™. Além disso, permite acesso instantâneo a informações do Dialplan e outras partes do sistema do Asterisk® SCF™.

Banco de Dados Único

Adicionar integração de banco de dados ao Asterisk® SCF™ (Figura 22.4 "Integração de Banco de Dados ao Asterisk® SCF™, Banco de Dados Único") é uma maneira poderosa de obter acesso a informações que podem ser manipuladas por outros meios. Por exemplo, podemos ler informações sobre as extensões e dispositivos no sistema de um banco de dados usando a Arquitetura Realtime Asterisk - ARA, e podemos modificar as informações armazenadas no banco de dados por meio de um sistema externo, como uma pagina da Web (GUI Interface).

A integração com o banco de dados adiciona uma camada entre o Asterisk® SCF™ e a Interface Web com a qual o Web Designer está familiarizado e permite a manipulação de dados de uma forma que não requer nenhum conjunto de habilidades adicionais. O conhecimento do próprio Asterisk® SCF™ é deixado para o administrador do Asterisk® SCF™, e o desenvolvedor Web pode trabalhar alegremente com ferramentas com as quais está familiarizado.

Figura 22.4. Integração de Banco de Dados ao Asterisk® SCF™, Banco de Dados Único

Claro, isso torna o sistema Asterisk® SCF™ um pouco mais complexo de construir, mas a integração com um banco de dados via ODBC adiciona todos os tipos de possibilidades (como o hot-desking). O FUNC_ODBC é uma ferramenta poderosa para o administrador do Asterisk® SCF™, fornecendo a habilidade de construir um Dialplan estático usando dados de natureza dinâmica.

Também gostamos muito do módulo FUNC_CURL, que fornece integração com serviços da Web sobre HTTP diretamente do Dialplan.

Com os dados abstraídos diretamente do Asterisk® SCF™ agora teremos mais facilidade para avançar em direção a um sistema que está se preparando para ser agrupado (Clustered). Podemos usar algo como Linux-HA (http://www.linux-ha.org/wiki/Main_Page) para fornecer failover automático entre os sistemas. Embora, no caso de uma falha as chamadas no sistema com falha sejam perdidas, o failover levará apenas alguns instantes (menos de um segundo) para ser detectado e o sistema aparecerá para seus usuários como imediatamente disponível novamente. Nesta configuração, como nossos dados são abstraídos fora do Asterisk® SCF™ podemos usar aplicativos como UNISON (https://www.cis.upenn.edu/~bcpierce/unison/) ou até mesmo o RSYNC para manter os arquivos de configuração sincronizados entre os Sistemas Operacionais e o Backup do Sistema. Também podemos usar o SubVersion ou o Git para rastrear alterações nos arquivos de configuração, facilitando a reversão de alterações que não funcionam.

É claro que se nosso banco de dados desaparecer devido a uma falha do hardware ou do software, nosso sistema ficará indisponível a menos que seja programado de forma a poder funcionar sem a conexão com o banco de dados. Isso pode ser feito por meio do uso de um banco de dados local que simplesmente se atualiza periodicamente a partir do banco de dados primário, ou por meio de informações programadas diretamente no Dialplan. Na maioria dos casos, a funcionalidade do sistema neste modo será mais simples do que quando o banco de dados estava disponível, mas pelo menos o sistema não ficará totalmente inutilizável.

Uma solução melhor seria usar um banco de dados replicado, que permite que os dados gravados em um servidor de banco de dados sejam gravados em outro servidor ao mesmo tempo. O Asterisk® SCF™ pode então fazer o failover para o outro banco de dados automaticamente se o servidor primário ficar indisponível.

Banco de Dados Replicados

O uso de um banco de dados replicado fornece alguma redundância no back-end para ajudar a limitar a quantidade de tempo de inatividade que os chamadores e os agentes experimentam se ocorrer uma falha no banco de dados. Uma configuração de banco de dados Mestre-Mestre é necessária para que os dados possam ser gravados em qualquer banco de dados e replicados automaticamente para o outro sistema, garantindo que tenhamos uma cópia exata dos dados em duas máquinas físicas. Outra vantagem dessa abordagem é que um único sistema não precisa mais lidar com todas as transações do bando de dados; a carga pode ser dividida entre os servidores. A Figura 22.5 "Integração de Banco de Dados do Asterisk® SCF™ com Banco de Dados Distribuído" ilustra esse cenário recomendado.

Figura 22.5 Integração de Banco de Dados do Asterisk® SCF™ com Banco de Dados Distribuído

Já utilizamos em nossos cenários a replicação Mestre-Mestre do MySQL antes (agora usamos o PostgreSQL) e funciona muito bem. Não realizamos o mesmo cenário com MariaDB, logo não temos como assegurar o comportamento. Também quero dizer que não é difícil de configurar, e existem vários tutoriais na Internet. Outros sistemas de banco de dados provavelmente também conterão essa funcionalidade, especialmente se você estiver usando um sistema comercial com o Oracle ou MS SQL.

Failover pode ser feito nativamente no Asterisk® SCF™, pois res_odbc.so e func_odbc.so contêm opções de configuração que permitem especificar vários bancos de dados. Em res_odbc.so, você pode especificar a ordem preferencial para conexões de banco de dados em caso de falha. Em fun_odbc.so, você pode até especificar servidores diferentes para ler e gravar dados por meio de funções no Dialplan que você cria. Toda essa flexibilidade permite que você forneça um sistema que funcione bem para o seu negócio.

Programas externos também podem ser usados para controlar o Failover entre sistemas. O aplicativo PEN (http://siag.nu/pen/) é um balanceador de carga para aplicativos TCP simples, como HTTP ou SMTP, que permite que vários servidores apareçam como um. Isso significa que o Asterisk® SCF™ só precisa ser configurado para se conectar a um único endereço IP (ou hostname); o aplicativo PEN cuidará de controlar qual servidor será uasdo para cada solicitação.

Asterisk® SCF™ Puro e Estados de Dispositivos Distribuído

Os estados do dispositivo no Asterisk® SCF™ são importantes tanto do ponto de vista do software (o Asterisk® SCF™ pode precisar saber o estado de um dispositivo ou da linha em um dispositivo para saber se uma chamada pode ser feita para ele) quanto do ponto de vista do usuário (P. Ex., uma luz (BFL/HINT) pode ser ligada ou desligada para indicar se uma determinada linha esta em uso ou se um agente está disponível para mais chamadas). Do ponto de vista de uma fila, é extremamente importante saber o status do dispositivo que um agente está usando para determinar se o próximo chamador da fila pode ser distribuído para esse agente. Sem o conhec9imento do estado do dispositivo, a fila simplesmente faria varias chamadas para o mesmo endpoint.

Depois de começar a expandir seu sistema único em vários servidores (potencialmente em vários locais físicos, como escritórios remotos ou satélites), você precisará distribuir o estado do dispositivo dos terminais entre os sistemas. O tipo de implementação necessária dependerá se você os está distribuindo entre sistema na mesma LAN (links de baixa latência) ou em uma WAN (links de alta latência).

Bem, vamos discutir os dois métodos de distribuição de estado dos dispositivos na sequencia: OpenAIS para links de baixa latência e XMPP para links de alta latência.

Distribuindo Estados de Dispositivos em uma LAN

A implementação do OpenAIS (Using OpenAIS) foi adicionada pela primeira vez ao Asterisk na branch 1.6.1, para permitir a distribuição de informações de estado do dispositivo entre servidores. A adição do OpenAIS forneceu grandes possibilidades para sistemas distribuídos, pois a consciência do estado do dispositivo é um aspecto importante de tais sistemas. Os métodos anteriores exigiram o uso de GROUP( ) e GROUP_CONT( ) para cada canal, com essa informação consultada por DUNDi®. Embora essa abordagem seja útil em alguns cenários (podemos usar essa funcionalidade para pesquisar o número de chamadas que nossos sistemas estão processando e direcionar chamadas de forma inteligente para sistemas que lidam com menos chamadas), como um mecanismo para determinar as informações de estado do dispositivo, se está presente ou não.

Figura 22.6. Distribuição de Estado do Dispositivo com OpenAIS

O OpenAIS nos deu a primeira implementação de um sistema que permite que o estado dos dispositivos e as indicações de mensagens em espera sejam distribuídos entre vários sistemas Asterisk® SCF™ (veja a Figura 22.6, "Distribuição de Estado de Dispositivo com OpenAIS"). A desvantagem da implementação do OpenAIS é que ela exige que todos os sistemas residam em links de baixa latência, o que normalmente significa que todos precisam residir no mesmo local físico, conectados ao mesmo switch. Dito isso, embora a biblioteca OpenAIS não funcione em redes fisicamente separadas, ela permite que um Queue( ) resida em um Servidor Asterisk® SCF™ e seus membros da fila residam em outro Servidor Asterisk® SCF™ (ou vários Servidores Asterisk® SCF™). Ele faz isso sem exigir que usemos canais locais e testemos sua disponibilidade por meio de outros métodos, limitando (ou eliminando) o número de tentativas de conexão feitas na rede e o toque de vários dispositivos.

O uso do OpenAIS tem uma vantagem, pois é relativamente fácil de configurar e começar a trabalhar. A desvantagem é que não é distribuível em locais físicos. A partir da branch 1.8, porém, podemos usar o XMPP para Distribuição de Estado do Dispositivo em uma rede de longa distância, como você verá na próxima seção.

Distribuindo Estados de Dispositivos em uma WAN

Desde a branch 1.8 do Asterisk® SCF™, foi adicionado uma implementação que usa XMPP para distribuição de estado do dispositivo. Como o protocolo XMPP é projetado para (ou pelo menos permite) uso em redes de longa distância, agora podemos ter sistemas Asterisk® SCF™ em diferentes locais físicos, distribuindo informações de estado do dispositivo entre si (veja a Figura 22.7, "Distribuindo Estados de Dispositivos com XMPP"). Com a implementação do OpenAIS, a biblioteca seria usada em cada sistema, permitindo que eles distribuíssem informações de estado do dispositivo. No cenário XMPP, um servidor central (ou cluster de servidores) é usado para distribuir o estado entre todas os Servidores Asterisk® SCF™ no cluster. Atualmente, a melhor aplicação para fazer isso é o Servidor Tigase XMPP (https://tigase.net/), devido ao suporte a eventos PubSub. Embora outros servidores XMPP possam ser suportados no futuro, apenas o Tigase é conhecido por funcionar no momento.

Figura 22.7, Distribuindo Estados de Dispositivos com XMPP

Com o XMPP, as filas podem ser localizadas em diferentes locais físicos e os escritórios satélites podem receber chamadas do escritório principal ou vice-versa. Isso fornece outra camada de redundância, porque se o site principal ficar offline e o ITSP for configurado de forma a fazer failover para outro escritório, as chamadas poderão ser distribuídas entre esses escritórios satélites até que o site principal volte a ficar online. Isso é bastante empolgante para muitas pessoas, pois adiciona uma camada de funcionalidade que não estava disponível anteriormente e a maior parte pode ser feita com uma configuração relativamente mínima.

A vantagem da distribuição de estado do dispositivo com XMPP (Using XMPP), é que, é possível distribuir o estado para vários locais físicos, o que não é possível com o OpenAIS. A desvantagem é que é mais complexo de configurar (já que você precisa de um serviço externo rodando o servidor Tigase XMPP ou alternativo) do que a implementação do OpenAIS.

Múltiplas Filas, Múltiplos Sites

Agora, vamos ser criativos e usar as várias ferramentas que discutimos nas seções anteriores para criar uma infraestrutura de fila distribuída. A Figura 22.8, " Infraestrutura de Filas Distribuídas" ilustra um exemplo de configuração onde temos cinco servidores Asterisk® SCF™ sendo liderados por outro cluster usado para distribuir/rotear as chamadas para as várias filas que configuramos. Nosso ITSP envia chamadas para o clouster de roteamento (que pode ser algo como Kamailio®, ou mesmo vários servidores Asterisk® SCF™ implementando DUNDi® ou algum outro método para rotear e distribuir chamadas, P. Ex. FreeSWITCH®), que então envia as chamadas conforme apropriado para um dos três Servidores Asterisk® SCF™ nos quais temos nossas filas configuradas. Cada servidor lida com uma fila diferente, como vendas, suporte, técnico e devoluções (apenas exemplos). Esses servidores, por sua vez, usam os agentes localizados em dois locais físicos separados. os dispositivos dos agentes são registrados em seus próprios servidores de registro local (que também podem realizar outras funcionalidades).

Veja, estamos mostrando todos os aspectos do sistema para manter o diagrama simples, mas neste caso usaríamos o sistema de estado de dispositivo distribuído XMPP, pois estamos sugerindo que os agentes são distribuídos em vários sites físicos.

Figura 22.8, Infraestrutura de Filas Distribuídas

Todos os agentes nos diferentes locais podem ser carregados em uma ou mais filas e, como estamos distribuindo informações de estado do dispositivo, cada fila saberá o estado atual dos agentes na fila e distribuirá apenas os chamadores aos agentes conforme apropriado. Além disso, podemos configurar penalidades para filas e/ou para os agentes para que os chamadores cheguem aos melhores agentes se estiverem disponíveis, e só usar os outros agentes quando todos os melhores agentes estiverem em uso.

Podemos adicionar mais agentes ao sistema adicionando mais servidores ao cluster no mesmo local ou em locais físico adicionais. Também podemos expandir o número de filas que suportamos adicionando mais servidores, cada um lidando com uma fila ou filas diferentes.

Uma desvantagem de usar este sistema é a forma como o aplicativo Queue( ) foi desenvolvido. Queue( ) é uma das aplicações mais antigas do Asterisk® SCF™, e infelizmente não acompanhou o ritmo de desenvolvimento no domínio da distribuição de estado do dispositivo, então não há como distribuir o mesmo Queue( ) em vários servidores. P. Ex. suponha que você tenha filas de vendas em dois servidores. Se um chamador entra na fila de vendas do primeiro servidor Asterisk® SCF™ , e então outro chamador entra na fila de vendas do segundo servidor Asterisk® SCF™, nenhuma informação será distribuída entre essas filas para indicar quem é o primeiro e quem é o segundo na fila de vendas. As duas filas são efetivamente separadas e não se conhecem a nível de sistemas. Talvez versões futuras do Asterisk® SCF™ tenham a capacidade de fazer isso, mas no momento não há suporte. Mencionamos isso para que você possa planejar seu sistema de acordo com essas limitações.

Como as filas em algumas implementações (como em Call Centers) podem ser necessárias para lidar com muitas chamadas de uma só vez, os requisitos de processamento e carga para um único servidor podem ser bastante altos. Ter a capacidade de acessar os mesmo recursos de agentes em vários servidores significa que podemos distribuir nossos chamadores entre vários servidores, reduzindo significativamente os requisitos de processamento colocados em um único sistema. Um sistema não precisa mais fazer tudo - podemos dividir vários componentes do sistema em diferentes servidores.

Um ótimo recurso para ser utilizado entre os vários servidores Asterisk® SCF™ é um Peering IAX2 mantendo assim a qualidade da chamada, bem como a distribuição das mesmas sem o uso de muito recursos. E deixando assim SIP somente para os usuários/devices/endpoint e ITSP.

Conclusão

Neste capitulo, foi explorado como você pode fazer a transição de um sistema de telefonia tradicional (não Asterisk® SCF™, ou não Softswitch PBX IP) para um Call Center distribuído. Ao logo do caminho, vimos como um Call Center com apenas algumas posições pode ser transformar em um sistema com centenas de posições em diferente locais físicos.

Embora a capacidade de expandir seus negócios e planejar o futuro seja crucial, também é importante não criar um sistema mais complexo do que o necessário. Quanto maior você for e quanto mais distribuído for um sistema que você construir, mais tempo levara para decolar e mais difícil será fazer todas as coisas que são importantes quando ocorrerem mudanças, como testar implementar as mudanças, e manter as coisas sincronizadas. Se o seu sistema nunca vai crescer além de um Call Center de 40 posições, não construa um para 500 posições. Tudo o que vc está fazendo é adicionar custos e complexidade adicionais para acomodar um sistema em uma escala que pode nunca ser totalmente realizada.

Construir um sistema simples agora e planejar para o futuro e como você vai chegar lá (especialmente se você puder fazer isso em iterações, sem ter que destruir toda a sua infraestrutura ou começar do zero) vai te colocar em funcionamento tanto mais rápido. À medida que você cresce, você pode adicionar mais peças, determinar se a abordagem que vc está adotando está correta e, se não , voltar e retrabalhar essa peça em particular. Esse tipo de abordagem pode poupar muitas dores de cabeça no futuro, quando vc percebe que não precisa refazer todo o seu sistema complexo por causa de algum novo requisito que você não previu no inicio.

Também mencionamos algumas vantagens de ter um sistema distribuído com funcionários remotos, como melhorar a moral dos funcionários e redução de custos. Você pode usar as conexões de Internet, hardware e eletricidade existentes de seus funcionários, o que pode economizar dinheiro para a empresa, e seus funcionários se beneficiarão evitando o agravamento e os custos de se deslocar para um escritório todos os dias. Embora nem todas as situações permitam esse tipo de cenário, vale a pena explorar se adicionar suporte para funcionários remotos será útil para o seu negocio.

Finalmente, o estado do dispositivo distribuído pode abrir um mundo de possibilidades para sua empresa, permitindo que ela cresça além do único sistema Asterisk que faz tudo. A divisão da funcionalidade em vários servidores agora é uma realidade e pode ser abordada com uma medida de confiança nunca vista anteriormente.

Fonte: Asterisk: The Definitive Guide (3nd Edition for Asterisk 1.8), escrito por Leif Madsen, Jim Van Meggelen, e Russell Bryant. (Capitulo 22).

Channel PJSIP < == > Channel SIP (Configurando um Tronco IP)

2022-02-01T06:05:00.002-10:00

Fonte: https://iplinktelecom.com/

Este guia irá ajuda-lo a realizar a configuração de um Tronco IP entre dois servidores Asterisk® SCF™, utilizando canais diferentes em relação ao protocolo SIP, afinal não importa se é CHANNEL SIP (modulo chan_sip.so) ou CHANNEL PJSIP (modulo chan_pjsip.so), o protocolo é único, SIP 2.0, ainda com a RFC 3261.

E claro que unificar ambas tecnologias não é uma tarefa facil, o recomendado é que você ABANDONE o modulo chan_sip.so. E passe a usar unicamente o modulo chan_pjsip.so. Mas como existes ainda muitas empresas que fazem uso do modulo chan_sip.so, vamos encontrar na planta de Telefonia IP (ToIP) a necessidade de criar um trunk entre as duas tecnologias (tecnologias não protocolo!).

Asterisk® SCF™ é uma estrutura de código aberto para a construção de aplicativos de comunicação. O Asterisk® SCF™ transforma um computador comum em um servidor de comunicação. O Asterisk® SCF™ lhe permite implementar sistemas em telecomunicações, como Softswitch PBX IP, Gateways POTS, ISDN, GSM, Servidores de Conferência e outras soluções personalizadas que depende exclusivamente do seu conhecimento sobre o Asterisk® SCF™. É usado por pequenas empresas e grande empresas, Call Centers, Operadoras e Agências Governamentais, em todo o mundo.

Existem dois métodos padrão para conectar um Softswitch PBX IP, baseado em Asterisk® SCF™ entre si:

CHANNEL SIP, para usar o mesmo PROTOCOLO de Iniciação de Sessão (SIP) padrão usado para conectar telefones que fazem uso do PROTOCOLO SIP.
CHANNEL PJSIP, para usar a pilha de PROTOCOLOS Open Source Embedded SIP, que passou a ser padrão, usado para conectar telefones que fazem uso do PROTOCOLO SIP.

Muito importante lembrar que o correto para fazer um tronco entre dois servidores Asterisk® SCF™ é fazendo uso do PROTOLOCO IAX que se encontra também na versão 2.0. Aqui tem um post sobre isso

Para mais documentação do Asterisk® SCF™, veja:

http://www.asteriskdocs.org é um livro HTML gratuito (o livro impresso correspondente é publicado convencionalmente pela O'Reilly em Inglês e pela Novatec em Português).
http://www.asterisk.org é o site do Asterisk® SCF™, operado pela Digium® uma empresa do grupo Sangoma®.

.Instruções para configurar um tronco entre dois servidores Asterisk® SCF™, a seguir vamos ver:

Configurar um tronco SIP utilizando PJSIP_WIZARD;
Configurar o servidor para fazer e receber chamadas entre eles;
Concluindo a configuração básica do PJSIP;
Configurar o Dialplan.

Pré-requisitos:

Um servidor com Asterisk fazendo uso do modulo chan_sip.so;
Um servidor com Asterisk fazendo uso do modulo chan_pjsip.so;
Rede totalmente funcional entre os servidores.

1 - Segue as configurações para o servidor fazendo uso do modulo chan_sip.so:

OBS: Algumas configurações são recomendadas, ou seja não são obrigatórias.

Edite o arquivo sip.conf:

[general]

dtmfmode=rfc2833

notifyringing=yes

context=from-pstn

srvlookup=yes

disallow=all

rtptimeout=60

useragent=PBX IP

qualify=100000

nat=yes

maxexpirey=1800

defaultexpirey=1800

tcpenable=yes

#include "sip_custom.conf"

[94455]

type=friend

allow=ulaw
allow=alaw
allow=g729

allow=gsm
dtmfmode=rfc2833
call-limit=60
defaultuser=srvchansip
fromuser=srvchansip
fromdomain=172.31.31.1
qualify=yes
port=5060
secret=srv12345
insecure=port,invite
host=172.31.31.1
context=from-itx-srvchanpjsip
transport=udp

2 - Segue as configurações para o servidor fazendo uso do modulo chan_sip.so:

Edite o arquivo pjsip_wizard.conf:

[trunk_defaults]

type = wizard

[srvchansip]

endpoint/transport = 0.0.0.0-udp

endpoint/allow = !all,ulaw,alaw,G729,G722

endpoint/rewrite_contact = yes

endpoint/dtmf_mode = rfc4733

endpoint/context = from-pstn

endpoint/force_rport = yes

aor/qualify_frequency = 60

sends_auth = no

sends_registrations = no

remote_hosts = 172.31.31.1:5060

OBS: para que esta configuração funcione, o modulo res_pjsip_config_wizard.so deve estar instalado e carregado. Este modulo está disponível desde o Asterisk® SCF™ 13.2.

3 - Configurando o Asterisk® SCF™ para fazer e receber chamadas:

Você precisará modificar o arquivo /etc/asterisk/pjsip_wizard.conf para adicionar as configurações globais para as extensões que utilizaremos em nossa POC (Proof Of Concept).

Neste exemplo, estamos configurando uma extensão 95566 para fazer e aceitar chamadas. Os parâmetros que fazem referência a 95566 e senha podem ser personalizados para seus requisitos e mapeados para os seguintes campos:

[defaults_user](!)

type = wizard

accepts_registrations = yes

sends_registrations = no

accepts_auth = yes

sends_auth = no

endpoint/context = from-internal

endpoint/allow = !all,ulaw,alaw,G729,G722

endpoint/dtmf_mode = rfc4733

endpoint/rewrite_contact = yes

endpoint/force_rport = yes

aor/max_contacts = 1

aor/remove_existing = yes

aor/minimum_expiration = 30

95566

endpoint/callerid = Peter Parker <95566>

inbound_auth/username = P3t35P4k35$

inbound_auth/password = P3t35P4k35$

Depois que temos o modelo "(!)", configurar um novo endpoint geralmente é tão simples quanto configurar um nome de usuário/senha, pois o objeto endpoint herda do modelo "(!)" criado em pjsip_wizard. Você nem precisará especificar um tipo. Veja os seguintes exemplos:

[Parker](user_defaults)

hint_exten = 95566

endpoint/callerid = Peter Parker <95566>

inbound_auth/username = P3t35P4k35$

inbound_auth/password = P3t35P4k35$

[Diana](user_defaults)

hint_exten = 95567

endpoint/callerid = Diana de Themyscira <95567>

endpoint/allow = !all,ulaw

inbound_auth/username = D14N4

inbound_auth/password = D14N4

;has_phoneprov = yes ;--> Padrão é não

;phoneprov/MAC = 00:1B:C9:4B:E3:57 ;--> deve especificar se has_phoneprov=yes;

;phoneprov/PROFILE = profile1 ;--> deve especificar se has_phoneprov=yes

4 - Concluindo a configuração básica do PJSIP:

Embora o pjsip_wizard.conf seja um grande facilitador na configuração endpoints PJSIP, configurações globais ou qualquer outra coisa que possa ser necessaria, ainda deve ser realizado e mesmo adicionado (muitas vezes necessario) em /etc/asterisk/pjsip.conf. No escopo de nossa configuração básica, adicione as linhas abaixo ao pjsip.conf para endpoints que estejam atras de NAT.

[global]

type = global

user_agent = PBX IP

[transport-udp-nat]

type = transport

protocol = udp

bind = 0.0.0.0:5060

local_net = X.X.X.X/24

external_media_address = X.X.X.X

external_signaling_address = X.X.X.X

allow_reload = no

Caso o Softswitch PBX IP não esteja em uma rede NAT, você pode remover com segurança (ou comentar) os seguintes parâmetros: external_media_address e external_signaling_address.
Com as configurações acima adicionadas aos respectivos arquivos, seu Softswitch PBX IP fazendo uso do modulo chan_pjsip.so, agora deve estar registrado no outro Softswitch PBX IP fazendo uso do modulo chan_sip.so, e o endpoint 94455 em seu telefone IP/Softphone deve estar registrado no seu Softswitch PBX IP que faz uso do modulo chan_pjsip.so.

5 - Configurar o Dialplan:

O Asterisk® SCF™ faz uso dos Dialplans desenvolvidos em /etc/asterisk/extensions.conf, ou extensions.ael, e extensions.lua, para rotear chamadas entre endpoints, e realizar outras tarefas. Para permitir que nosso endpoint 994455 chame os usuários do outro Softswitch PBX IP que usa o modulo chan_sip.so, bem como para enviar quaisquer chamada que chegue ao DID atribuído ao respectivo troco, você precisa abrir extension.conf e adicionar as seguintes linhas de código:

[from-pstn]

exten => _+55XXXXXXXXXXX,1,Dial(PJSIP/94455)

exten => _XX9XXXXXXXX,1,Dial(PJSIP/94455)

[from-internal]

exten = _119XXXXXXXX,1,Dial(PJSIP/${EXTEN}@srvchansip)

same = n,Hangup()

exten = _X.,1,Dial(PJSIP/${EXTEN}@srvchansip)

same = n,Hangup()

[from-pstn] - serve para encaminhar chamadas para a Rede Pública de Telefonia Comutada - RPTC (do inglês - Public Switched Telephone Network ou PSTN), proveniente do Softswitch PBX IP (modulo chan_sip.so) e as envia para o endpoint 94455. O bloco de código [from-pstn] capturará todas as chamadas para CLDs nacional padrão telefonia móvel (11 9 44 55 66 77) e enviara para o endpoint 94455.
[from-internal] - serve para encaminhar chamadas para a RPTC/PSTN através do Softswitch PBX IP (modulo chan_pjsip.so). O bloco [from-internal] capturará chamadas para números nacional padrão telefonia móvel e encaminhara para o Softswitch PBX IP (modulo chan_sip.so).

IMPORTANTE! Se você quiser fazer seu tronco baseado em TECH PREFIX para autenticar, isso deve ser implementado no Dialplan.

Por exemplo, se você configurou o TEC PREFIX para "9999" no Softswitch PBX IP (modulo chan_sip.so), seu bloco [from-internal] deve ficar assim:

[from-internal]

exten = _119XXXXXXXX,1,Dial(PJSIP/9999${EXTEN}@srvchansip)

same = n,Hangup()

exten = _X.,1,Dial(PJSIP/9999${EXTEN}@srvchansip)

same = n,Hangup()

É isso! Você concluiu a configuração dos servidores baseados em Asterisk® SCF™ e agora pode fazer e receber chamadas entre eles.

Asterisk Extension Language - AEL (Parte 01)

2021-04-20T14:30:00.002-10:00

A Sangoma Digium, por meio da sua equipe de desenvolvimento do Asterisk® SCF™, vem recebendo fortes pressões para adicionar recursos ao extensions.conf de modo a torná-lo mais parecido com uma linguagem de programação. O fato é que o AEL tem como objetivo fornecer uma linguagem de programação real que pode ser usada para escrever um Dialplan (Plano de Marcação, como não se faz mais uso de aparelhos de pulso com discos, não faz sentido traduzir para Plano de Discagem. Até porque em Telefones IP, e destinado a POTS temos teclas, e as marcamos ao invés de discar.).

Começando:

O analisador AEL (pbx_ael.so) é completamente separado do módulo que analisa o extensions.conf (pbx_config.so). Para suar o AEL, a única coisa que deve ser feita é que o módulo pbx_ael.so deve ser carregado pelo Asterisk® SCF™. Isso será feito automaticamente se usar "autoload=yes" (que não é recomendado) em /etc/asterisk/modules.conf. Quando o módulo for carregado, ele procurará por extensions.ael em /etc/asterisk/. Ambos extensions.conf e extensions.ael pode ser usados em conjunto um com o outro, se isso for desejado. Alguns Engenheiros de Sistemas em Telecomunicações NGN, podem querer manter extensions.conf para usar os recursos que são configurados na seção "[GENERAL]".

Recarregando extensions.ael:

Para recarregar o extensions.ael, o seguinte comando pode ser emitido no *CLI>.

*CLI> ael reload

Depurando:

Habilitar depuração de contextos do AEL;

*CLI> ael debug contexts

Habilitar depuração de macros do AEL;

*CLI> ael debug macros

Habilitar depuração de leitura do AEL;

*CLI> ael debug read

Habilitar depuração de tokens do AEL;

*CLI> ael debug tokens

Desativar mensagens de depuração do AEL;

*CLI> ael no debug

Comentários:

As linhas que começam com barra dupla (//) são comentários.

Exemplo: // Este é um comentário.

Contexto:

Os contextos em AEL representam um conjunto de extensões da mesma forma que o fazem em extensions.conf (CONF).

context internal_pbx_extensions {

};

OBS: A chave de abertura deve aparecer como acima. Movê-la para a linha seguinte pode ter consequências desastrosas.

Extensões:

Para especificar uma extensão em um contexto, a seguinte sintaxe é usada. Se mais de um aplicativo for chamado em uma extensão, eles podem ser listados em ordem dentro de um bloco.

context internal_pbx_extensions {
  _10XX => {
           Verbose(Comutação Interna entre Extensions);
           Wait(0.2);
           Dial(PJSIP/${EXTEN},45,rTtHhKkwo);

if("${DIALSTATUS}"=="BUSY") {

                Playback(call-sorry&is-in-use&call-goodbye);
           };
           HangUp();
   };

   _80XX => {
           Dial(PJSIP/${EXTEN},45,rTtHhKkwo);
           Verbose(Comutação entre servidores);
           Dial(PJSIP/TRUNK-SRV-SP/${EXTEN},45,rTtHhKkwo);
           if("${DIALSTATUS}"=="BUSY") {
               Verbose(Encaminhamento Incondicional);
               Playback(one-moment-please);
               goto internal_pbx_extensions|5099|1;
           };
           HangUp();
   };

   _5XXX => {
           Verbose(Comutação para a Telefonista);
           Dial(IAX2/TRUNK-SRV-SP/${EXTEN},45,rTtHhKkwo);
           if("${DIALSTATUS}"=="BUSY") {
               Playback(call-sorry&is-in-use&call-goodbye);
             HangUp();
           };
           HangUp();
   };

   h => {
           Verbose(//----> Chamada encerrada...: ORIG-${CALLERID(num)});
   };
};

Inclui:

Os contextos podem ser incluídos em outros contextos. Todos os contextos incluídos são listados em um único bloco.

context internal_pbx_extensions {
includes {

               chamadas_local;
               chamadas_ddd;
               chamadas_ddi;
       };
};

Dialplan Switches:

Os switches são listados em seu próprio bloco dentro de um contexto.

context internal_pbx_extensions {

switches {

DUNDi/e164;

IAX2/TRUNK-SRV-SP;

};

eswitches {

IAX2/context@${CURSERVER};

};

Ignore Padrão (ignorepat):

ignorepat pode ser usado para instruir os drivers de canal a não cancelar o tom de marcação ao receber um determinado padrão (pattern). O exemplo mais comumente usado é '9'.

context chamadas_local {

ignorepat=> 9;

};

OBS: A chave de abertura deve aparecer como acima. Movê-la para a linha seguinte pode ter consequências desastrosas.

Variáveis:

As variáveis no Asterisk® SCF™ não têm um tipo, então para definir uma variável, ela só precisa ser especificada com um valor.

As variáveis podem ser definidas nas extensões.

context chamadas_local {

_92929XXXX => {

Set(ignore_pattern=9); // definindo uma variável.

ignorepat=> ${ignore_pattern}; // usando a variável.

}

};

Variáveis globais são definidas em seu próprio bloco.

globals {

CONSOLE=Console/dsp;

TRUNK-GOIP=DAHDI/g2;

};

OBS: A chave de abertura deve aparecer como acima. Movê-la para a linha seguinte pode ter consequências desastrosas.

Protocolo SIP - Mensagens 180 x 183 x Early Media

2021-02-25T09:31:00.001-10:00

Uma chamada SIP básica, estabelecida com sucesso, quando aceita pelo receptor, tem a resposta final 200 OK, a negociação do CODEC é feita e a chamada entra na sessão de mídia com ambas as extremidades conhecendo as capacidades uma da outra. Acredito que você não tenha, nenhuma dúvida sobre este mecanismo básico e principal.

Fonte em referencias.

Mas isso não tem nada a ver com o momento em que a mídia realmente inicia, às vezes você pode perceber que o outro lado está reproduzindo um IVR para pedir a entrada de um dígito sem atender sua chamada.

Portanto, o fluxo de mídia antes do estabelecimento da chamada é considerado mídia inicial. Não é a voz da pessoa com quem você deseja falar, mas sim tons do sistema, anúncios ou qualquer som que o outro lado deseja que você ouça, mesmos que muitas vezes você não ouça, por não ter uma tratativa em seu Dialplan. Isto ocorre com frequência, e se seu Dialplan, não tem uma tratativa correta, o app_dial.c vai estacionar a chamada, ou seja vai executar o res_musiconhold.c.

Uma implementação de alguma forma semelhante ao PSTN pode ser encontrada quando seu telefone celular tenta alcançar um número fora do sinal:

O número discado não está disponível no momento, tente novamente mais tarde.

Isso pode ser o que você ouve como resultado e, neste caso, seu provedor de serviços de telefonia não atendeu a sua chamada nem cobrou a tarifa da chamada.

180 Ringing

Conforme declarado na Bíblia SIP RFC3261, 180 é usado para alertar o UA chamador que recebeu um INVITE e está tocando.

A resposta 180 na maioria das vezes não carrega o corpo SDP, e o dispositivo que recebe essa resposta geralmente inicia um toque de retorno local para o usuário final. Isso quer dizer que o tom de toque que você ouve ao esperar que o receptor atenda não é uma viagem pela rede, mas sim configurável em seu dispositivo terminal (endpoint).

Vale ressaltar que as mesmas coisas acontecem quando alguma mensagem do tipo 4XX, 5XX, 6XX é recebido, seu dispositivo deve gerar alguns tipos de áudios informativos, para que o usuário possa notar que a chamada falhou, ou que foi sem sucesso, antes de desligar completamente.

183 Session Progress

A resposta 183 (Progresso da sessão) é usada para transmitir as informações. Os campos de cabeçalho ou corpo SDP, neste caso, podem ser usados para transmitir mais detalhes sobre o andamento da chamada.

Fonte em referencias - Early Media with SIP 183 response.

A resposta 183 contém corpo SDP e é geralmente usada em 3 casos:

Fazendo um RINGBACK da viagem na rede: o dispositivo que executa o UAC reproduzirá o fluxo de mídia enviado pelo UAS ao usuário para indicar que o receptor está sendo alertado.
Simplesmente reproduzir um som de mensagem de erro e, em seguida, desligar como afirmei acima.
Para a implementação de uma resposta de voz interativa: os tons DTMF podem ser reunidos junto com os pacotes de mídia.

É sobre a mídia antiga, simples, não é?

Detecting Early Media

Isso é sobre a mídia inicial, é simples, acima está a definição SIP sobre a mídia inicial, posso dizer que é bastante simples, mas na verdade, o UAC não poderia retransmitir as respostas SIP recebidas para decidir se inicia o local do RINGBACK ou para reproduzir a mídia da extremidade remota. Só porque a sinalização SIP e a mídia RTP estão em seu próprio caminho, o UAS pode iniciar a resposta 183 que contém o corpo SDP sem enviar nenhum pacote de mídia.

Fora isso, alguma implementação anexa ao corpo da resposta 180 o SDP e entra na primeira sessão de mídia sem respostas 183.

Portanto, para detectar a mídia inicial, o UAC também precisa verificar se os pacotes de mídia estão chegando em um determinado momento.

E graças ao RFC3960, algumas políticas para essas bagunças são recomendadas:

A menos que uma resposta 180 (toque) seja recebida, nunca gere toque local (RINGING);
Se um 180 (RINGING) foi recebido, mas não há pacotes de mídia de entrada, gere toque local (RINGING);
Se um 180 (RINGING) foi recebido e há pacotes de mídia de entrada, reproduza-os e não gere toque local (RINGING).

Essas políticas não são definidas como padrão a ser seguido em todos os dispositivos SIP, mas simplesmente afirmam:

Qualquer UA deve reproduzir pacotes de mídia de entrada (e interromper a geração de tom de toque local se estiver sendo executado).

Por último, mas não menos importante, quando a chamada deixa o estado de mídia inicial ao ser atendida, a resposta SDP no 200 OK deve corresponder à resposta SDP no 183/180 anterior, ou seja, nenhuma alteração na capacidade de mídia quando a chamada muda de sessão de mídia antecipada para sessão de mídia oficial (Early Media).

Bem, é isso, espero que faça sentido para você. Se possível, faça alguns rastreamentos com SNGREP/Wireshark de uma chamada SIP com Early Media podem ajudá-lo a entender com mais clareza.

Referências:

Andrew J. Prokop

Tools IETF: RFC3960

Tools IETF: RFC3261

Tkat's All Folks! (É por hoje é só, pessoal!).

Novo repositorio key para WineHQ - Debian e seus Forks

2021-01-06T01:12:00.002-10:00

Eu faço uso do NotePad++ em cima do Ubuntu 20.4 (Fork do Debian), ocorre que sempre que vai haver uma atualização recebia o erro a seguir:

Erro GPG: https://dl.winehq.org/wine-builds/ubuntu bionic InRelease: As assinaturas a seguir não puderam ser verificadas devido à chave pública não estar disponível: NO_PUBKEY 76F1A20FF987672FThe repository 'https://dl.winehq.org/wine-builds/ubuntu bionic InRelease' is not signed.

Para resolver este erro, faça um acesso a sua pasta root (ou o lugar onde se encontra o arquivo winehq.key.

Caso não saiba onde se encontra esse arquivo execute o comando a seguir:

# find / -name winehq.key
/root/winehq.key

Uma vez tendo o local do arquivo remova ele de seu sistema: Atenção! Tenha muito cuidado ao usar este comando e tenha em mente que está digitando corretamente o comando.

# rm -rf /root/winehq.key

Devido a migração para compilações OBS ter sido concluída, a chave do repositório WineHQ foi alterada. Então os usuários do Debian e do Ubuntu que usam a chave antiga (release.key ou winehq.key), necessita baixar a nova (winehq.key) e adicioná-la ao sistema APT, ou você continuara a receber a mensagem de erro sobre a chave ausente.

Para baixar e instalar a nova chave:

# cd /root

# wget -nc https://dl.winehq.org/wine-builds/winehq.key

# sudo apt-key add winehq.key

Recebendo o OK, execute:

# sudo apt update && apt upgrade && apt dist-upgrade

Tkat's All Folks! (É por hoje é só, pessoal!).

Asterisk® SCF™ + LUA: Configuração do LUA Dialplan (parte 03) - Final.

2020-12-26T07:39:00.001-10:00

Criado por Matthew Nicholson, modificado pela última vez por Rusty Newton, tradução técnica e adaptação para o Brasil por Angelo Delphini.

Dialplan LUA: Hints

No Asterisk® SCF™ versão 10 e superiores, as dicas (HINTS) do Dialplan (extensions.lua) podem ser especificadas de maneira semelhante à maneira como as extensões são especificadas em Dialplan CONF e AEL.

extensions.lua

hints = {
   default = {
      ["100"] = "SIP/100";
   };
 
   office = {
      ["500"] = "SIP/500";
   };
 
   home = {
      ["200"] = "SIP/200";
      ["201"] = "SIP/201";
   };
}

Dialplan LUA: Exemplos

Na sequencia alguns exemplos de Dialplan LUA em Asterisk® SCF™ versão 10 e superiores, o objetivo é as varias formas de organizar as extensões no Dialplan LUA.

Menos desordem

Em vez de definir cada extensão em linha, você pode usar este método para criar um arquivo extensions.lua mais organizado. Uma vez que a tabela de extensões e cada contexto são tabelas LUA normais, você pode tratá-las como tal e construí-las peça por peça.

extensions.lua

-- esta função serve como uma função de extensão diretamente --
function call_user(c, user)
   app.dial("SIP/" .. user, 60)
end
 
-- esta função retorna uma função de extensão --
function call_sales_queue(queue)
  return function(c, e)
      app.queue(queue)
   end
end
 
e = {}
 
e.default = {}
e.default.include = {"users", "sales"}
 
e.users = {}
e.users["100"] = call_user
e.users["101"] = call_user
 
e.sales = {}
e.sales["5000"] = call_sales_queue("sales1")
e.sales["6000"] = call_sales_queue("sales2")
 
extensions = e

Less Clutter v2

Neste exemplo, usamos uma função sofisticada para registrar extensões.

extensions.lua

function register(context, extension, func)
   if not extensions then
      extensions = {}
   end
 
   if not extensions[context] then
      extensions[context] = {}
   end
 
   extensions[context][extension] = func
end
 
function include(context, included_context)
   if not extensions then
      extensions = {}
   end
 
   if not extensions[context] then
      extensions[context] = {}
   end
 
   if not extensions[context].include then
      extensions[context].include = {}
   end
 
   table.insert(extensions[context].include, included_context)
end
 
-- this function serves as an extension function directly
function call_user(c, user)
   app.dial("SIP/" .. user, 60)
end
 
-- this function returns an extension function
function call_sales_queue(queue)
  return function(c, e)
      app.queue(queue)
   end
end
 
include("default", "users")
include("default", "sales")
 
register("users", "100", call_user)
register("users", "101", call_user)
 
register("sales", "5000", call_sales_queue("sales1"))
register("sales", "6000", call_sales_queue("sales2"))
register("sales", "7000", function()
   app.queue("sales3")
end)

Tópicos avançados em pbx_lua

Nos bastidores, uma série de coisas acontecem para tornar a integração de LUA ao Asterisk® SCF™ a mais perfeita possível. Alguns detalhes de como funciona essa integração podem ser encontrados a seguir.

extensions.lua Processo de carga

O arquivo extensions.lua é carregado na memória uma vez quando o módulo pbx_lua é carregado ou recarregado. O arquivo é então lido da memória e executado uma vez para cada canal que procura ou executa uma extensão baseada em LUA. Visto que o arquivo é executado uma vez para cada canal, pode não ser sábio fazer coisas como conectar-se a serviços externos diretamente do script principal ou construir sua tabela de extensões a partir de um serviço da web ou banco de dados.

Provavelmente é uma má ideia.

-- minha fantasia em extensions.lua --
 
extensions = {}
extensions.default = {}
 
-- pode ser uma má ideia, isto será executado sempre que um canal for criado --
data = query_webservice_for_extensions_list("site1")
 
for _, e in ipairs(data) do
   extensions.default[e.exten] = function()
      app.dial("SIP/" .. e.sip_peer, e.dial_timeout)
   end
end

A mesa de extensions

A tabela extensions é uma tabela LUA padrão e pode ser definida como você quiser. O módulo pbx_lua carrega e classifica a tabela quando necessário. As chaves na tabela são nomes de contexto e cada valor é outra tabela LUA contendo extensões. Cada chave na tabela de contexto é um nome de extensão e cada valor é uma função de extensão.

extensions = {
   context_table = {
      extension1 = function()
      end;
      extension2 = function()
      end;
   };
}

Para onde foram as prioridades?

Não há prioridades. O Asterisk® SCF™ usa prioridades para definir a ordem em que ocorrem as operações do Dialplan. O módulo pbx_lua usa funções para definir extensões e a execução ocorre dentro do interpretador LUA, as prioridades não fazem sentido neste contexto. Para o Asterisk® SCF™, cada extensão em pbx_lua aparece como uma extensão com uma prioridade. As extensões em LUA podem ser referenciadas usando o nome do contexto, extensão e prioridade 1, por exemplo GoTo(default,1234,1). Você só faria referência a extensões desta forma de fora de pbx_lua (ou seja, de extensions.conf ou extensions.ael). Com pbx_lua você pode apenas executar a função dessa extensão.

extensions.default["1234"]("default", "1234")

Lua Script Lifetime

O mesmo estado de LUA é usado durante o tempo de vida do canal do Asterisk® SCF™ em que está sendo executado, portanto, efetivamente, o script tem o tempo de vida do canal. Isso significa que você pode definir variáveis globais no estado de LUA e recuperá-las posteriormente de uma extensão diferente, se necessário.

Aplicativos, funções e variáveis

Detalhes sobre como acessar aplicações e funções do Dialplan LUA e variáveis de canal podem ser encontrados na página Interagindo com o Asterisk® SCF™ LUA (aplicativos, variáveis e funções) .

Ao acessar um aplicativo ou função dialplan ou uma variável de canal, um objeto de espaço reservado é gerado que fornece os métodos :get( ) e :set( ).

Variável de canal (channel): var é o objeto do espaço reservado

var = channel.my_variable
var:set("my value")
value = var:get("my value")

Função Dialplan: fax_modems é o objeto placeholder

fax_modems = channel.FAXOPT("module")
 
-- the function arguments are stored in the placeholder
 
fax_modems:set("v17")
value = fax_modems:get()

Aplicação Dialplan: Dial é o objeto placeholder

dial = app.dial
 
-- the only thing we can do with it is execute it
dial("SIP/100")

Há um pequeno custo na criação de objetos de espaço reservado, portanto, o armazenamento de objetos de espaço reservado usados com frequência pode ser usado como uma micro otimização. No entanto, isso nunca deve ser necessário e só fornece benefícios se você estiver executando micro benchmarks.

Tkat's All Folks! (É por hoje é só, pessoal!).

Aprenda Lua em 15 minutos!

Temos uma comunidade, ainda pequena no Telegram, para estudos exclusivos em Dialplan com LUA no Asterisk® SCF™, você é bem vindo! (Telegram: https://t.me/asteriskluabr).

Asterisk® SCF™ + LUA: Configuração do LUA Dialplan (parte 02)

2020-12-25T08:50:00.003-10:00

Criado por Matthew Nicholson, modificado pela última vez por Rusty Newton, tradução técnica e adaptação para o Brasil por Angelo Delphini.

Interagindo com o Asterisk® SCF™ Dialplan LUA (aplicativos, variáveis e funções)

A é feita com interação por meio de uma série de objetos predefinidos fornecidos por pbx_lua. A tabela app é usada para acessar aplicativos do Dialplan. Qualquer aplicativo do Asterisk® SCF™ pode ser acessado e executado como se fosse uma função anexada à tabela app. Variáveis e funções do Dialplan são acessadas e executadas através da tabela channel.

Conflitos de nomenclatura entre LUA e Asterisk® SCF™

Aplicativos do Asterisk® SCF™, variáveis ou funções cujos nomes entram em conflito com palavras reservadas de LUA ou contêm caracteres especiais devem ser referenciados usando o [ ] operador. Por exemplo, LUA 5.2 introduziu a GoTo instrução de controle que conflita com a aplicação GoTo() do Dialplan do Asterisk® SCF™. Então...

O seguinte fará com que pbx_lua.so falhe ao carregar com LUA 5.2 ou posterior porque GoTo é uma palavra reservada.

app.goto("default", 1000, 1)

A seguinte instrução funcionará com todas as versões LUA e o Dialplan do Asterisk® SCF™.

app["goto"]("default", 1000, 1)

Aplicativos do Dialplan

extensions.lua

app.playback("please-hold")
app.dial("SIP/100", nil, "m")

Qualquer aplicativo do Dialplan pode ser executado usando a tabela app. Os nomes dos aplicativos não diferenciam maiúsculas de minúsculas. Mas lembre que as melhores praticas de desenvolvimento de Dialplan, recomenda que seja app.HangUp( ) do que app.hangup( ). Os argumentos são passados para aplicações do Dialplan assim como os argumentos são passados para funções em LUA. Os argumentos de string devem ser colocados entre aspas, pois são strings LUA. Argumentos vazios podem ser passados como strings vazias, nil ou empty.

Variáveis de Canal

Definir uma variável

channel.my_variable = "my_value"

Depois disso, a variável de canal ${my_variable} contém o valor "my_value".

Lendo uma variável

value = channel.my_variable:get()

Qualquer variável de canal pode ser lida e configurada usando a tabela channel. Variáveis LUA, locais e globais podem ser usadas como normalmente fariam e não estão completamente relacionadas com variáveis de canal.

A seguinte instrução NÃO funcionará.

value = channel.my_variable -- não funciona como o esperado --

-- (value:get() pode ser usado para obter o valor após esta linha) --

Se o nome da variável for uma palavra reservada para LUA ou contiver caracteres que LUA considera especiais, devemos usar o [ ] operador para acessá-los.

channel["my_variable"] = "my_value"

value = channel["my_variable"]:get()

Funções Dialplan

Escrevendo uma função no Dialplan
`channel.FAXOPT("modems"):set("v17,v27,v29")`
Lendo uma função do Dialplan
`value = channel.FAXOPT("modems"):get()`

Observe o uso do `:`operador com os métodos `get()` e `set()`.

Se o nome da função for uma palavra reservada para LUA ou contiver caracteres que LUA considera especiais, devemos usar o [ ] operador para acessá-los.

`channel["FAXOPT(modems)"] =` `"v17,v27,v29"`
`value = channel["FAXOPT(modems)"]:get()`
As seguintes instruções NÃO funcionarão.

`channel.FAXOPT("modems") =` `"v17,v27,v29"` `-- erro de sintaxe --`
`value = channel.FAXOPT("modems") -- não funciona como esperado --`
`-- (value:get()` `pode ser usado para obter o valor após esta linha) --`

Os nomes das funções do Dialplan diferenciam maiúsculas de minúsculas.

Dialplan LUA, dicas e trunques

Operações de longa duração (AutoService)

Antes de iniciar operações de longa duração, um AutoService deve ser iniciado usando a função autoservice_start( ). Um AutoService garantirá que o usuário ouça um fluxo contínuo de áudio enquanto seu código LUA funciona em segundo plano. Este AutoService será interrompido automaticamente antes de executar aplicativos e funções do Dialplan e será reiniciado posteriormente. O AutoService pode ser interrompido usando autoservice_stop( ) e a função autoservice_status( ) retornará true um AutoService estiver em execução.

app.startmusiconhold()

autoservice_start()

do_expensive_db_query()

autoservice_stop()

app.stopmusiconhold()

No Asterisk® SCF™ 10 e posteriores, um AutoService é iniciado automaticamente para você por padrão.

Definindo Extensões Dinamicamente

Como as extensões são funções em pbx_lua, qualquer função pode ser usada, incluindo encerramentos. Uma função pode ser definida para retornar funções de extensão e usada para preencher a tabela de extensões.

extensions.lua

extensions = {}
extensions.default = {}
 
function sip_exten(e)
   return function()
      app.dial("SIP/" .. e)
   end
end
 
extensions.default[100] = sip_exten(100)
extensions.default[101] = sip_exten(101)

Criação de 'aliases' personalizados para construções integradas

Se você não gosta que a tabela app seja chamada de 'app' ou se acha que digitar 'channel' para acessar a tabela channel é muito trabalhoso, você pode renomeá-los.

Eu prefiro digitar menos

function my_exten(context, extensions)
   c = channel
   a = app
 
   c.my_variable = "minha nova variável de canal"
   a.dial("SIP/100")
end

Redefinindo a função print

LUA tem uma função "print" embutida que envia as coisas para o "stdout", mas para o Asterisk® SCF™, preferimos que a saída vá para o log detalhado. Para fazer isso, poderíamos reescrever a função print da seguinte maneira.

function print(...)

   local msg = ""

   for i=1,select('#', ...) do

      if i == 1 then

         msg = msg .. tostring(select(i, ...))

      else

         msg = msg .. "\t" .. tostring(select(i, ...))

end

end

   app.verbose(msg)

end

Dividindo a configuração em vários arquivos

O método require pode ser usado para carregar módulos LUA localizados em LUA_PATH. O método dofile pode ser usado para incluir qualquer arquivo por nome de caminho.

Usando Módulos Externos

Os módulos LUA podem ser carregados usando o método require LUA padrão. Algumas das funcionalidades fornecidas por vários módulos LUA já estão incluídas no Asterisk® SCF™ (por exemplo, func_odbc que fornece o que LuaSQL fornece). Geralmente é melhor usar código embutido no Asterisk® SCF™ em vez de módulos LUA externos. Especificamente, o módulo func_odbc usa um pool de conexão para fornecer recursos de banco de dados, onde, como com LuaSQL, cada canal teria que fazer uma nova conexão com o banco de dados por conta própria.

Compilando extensions.lua

O programa luac pode ser usado para compilar seu arquivo extensions.lua em bytecode LUA. Isso aumentará um pouco o desempenho, pois o pbx_lua não precisará mais analisar extensions.lua durante o carregamento. O compilador luac também detectará e relatará quaisquer erros de sintaxe. Para usar luac, renomeie seu arquivo extensions.lua e execute o seguinte.

Suponha que você nomeie seu arquivo extensions.lua para extensions.lua.lua

luac -o extensions.lua extensions.lua.lua

O módulo pbx_lua reconhece automaticamente a diferença entre um arquivo de texto LUA e um arquivo de bytecode LUA.

Tkat's All Folks! (É por hoje é só, pessoal!).

Aprenda Lua em 15 minutos!

Temos uma comunidade, ainda pequena no Telegram, para estudos exclusivos em Dialplan com LUA no Asterisk® SCF™, você é bem vindo! (Telegram: https://t.me/asteriskluabr).

Asterisk® SCF™ + LUA: Configuração do LUA Dialplan (parte 01)

2020-12-24T05:58:00.006-10:00

Criado por Matthew Nicholson, modificado pela última vez por Rusty Newton, tradução técnica e adaptação para o Brasil por Angelo Delphini.

O Asterisk® SCF™ suporta a habilidade de escrever instruções de Dialplan na linguagem de programação LUA. Este método pode ser usado como alternativa ou em combinação com extensions.conf e/ou AEL. O PBX LUA permite que os usuários usem todo o poder de LUA para desenvolver aplicativos de telefonia usando o Asterisk® SCF™. A configuração do Dialplan LUA é feita no arquivo extensions.lua. Lembro que o CORE/PBX do Asterisk® SCF™ aceita que os três arquivos seja utilizado pelo Dialplan simultaneamente extensions.conf, extensions.ael e extensions.lua.

Dependências

Para usar o pbx_lua, as bibliotecas de desenvolvimento lua devem ser instaladas antes que o Asterisk® SCF™ seja configurado e compilado. Você pode obter essas bibliotecas diretamente em http://lua.org , mas é mais fácil instalá-las usando a ferramenta de gerenciamento de pacotes da sua distribuição. O pacote provavelmente é denominado liblua5.1-dev, liblua-dev ou lua-devel, dependendo de sua distribuição GNU/Linux.

PBX LUA Básico

O arquivo extensions.lua é usado para configurar PBX LUA e é um Script LUA (em oposição a ser um arquivo de configuração de Asterisk® SCF™ padrão). Qualquer coisa que seja um código LUA adequado é permitido neste arquivo. O Asterisk® SCF™ espera encontrar uma tabela global chamada 'extensions' quando o arquivo for carregado. Esta tabela pode ser gerada como você desejar. A maneira mais simples é definir todas as extensões em linha, mas para Dialplans mais complexos podem ser necessários métodos alternativos.

Cada extensão é uma função LUA que é executada quando um canal chega a essa extensão. A função de extensão recebe o contexto atual e a extensão como os dois primeiros argumentos. Eles podem ser ignorados com segurança, se desejado. Não há prioridades (cada função de extensão é tratada como prioridade 1 pelo resto do Asterisk® SCF™). Os padrões são permitidos exatamente como em extensions.conf e a ordem de correspondência é idêntica.

extensions.lua

extensions = {
   default = {
      ["100"] = function(context, extension)
         app.playback("please-hold")
         app.dial("SIP/100", 60)
      end;
 
      ["101"] = function(c, e)
         app.dial("SIP/101", 60)
      end;
}

O arquivo extensions.lua pode ser recarregado, recarregando o módulo pbx_lua.

*CLI> module reload pbx_lua

Se houver erros no arquivo, eles serão relatados (no *CLI>) e o arquivo extensions.lua existente permanecerá em uso (tal como é com o CONF e AEL).

Os canais que existiam antes do comando reload ser emitido também continuarão a usar o arquivo extensions.lua existente.

Somente após o arquivo ser validado pelo módulo pbx_lua.so que será carregado no CORE/PBX em produção. Lembrando que é altamente recomendado que faça uso somente da versão Certified do Asterisk® SCF™ para produção junto ao seu cliente.

OBS: Os erros de tempo de execução são registrados e o canal no qual o erro ocorreu é desligado. Logo nunca faça manutenção em seu Dialplan em produção.

Referência Dialplan para LUA

Abaixo está uma referência rápida que pode ser usada para traduzir os conceitos tradicionais do Dialplan em extensions.conf para o poder do extensions.lua.

Padrões de extensões (Extension Patternes);
Include em contextos (Context Includes);
Rotações (Loops);
Variáveis (Variables);
Formularios (Applications);
Macros/GoSub;
Goto;

Padrões de extensões (Extension Patternes)

A sintaxe de correspondência de padrão de extensão na lógica funciona da mesma forma para extensions.conf e extensions.lua.

extensions.conf

[users]
exten => _1XX,1,Dial(SIP/${EXTEN})
 
exten => _2XX,1,Voicemail(${EXTEN:1})

extensions.lua

extensions = {}
extensions.users = {}
 
extensions.users["_1XX"] = function(c, e)
   app.dial("SIP/" .. e)
end
 
extensions.users["_2XX"] = function(c, e)
  app.voicemail("1" .. e:sub(2))
end

Include em contextos (Context Includes)

extensions.conf

[users]
exten => 100,1,Noop
exten => 100,n,Dial("SIP/100")
 
[demo]
exten => s,1,Noop
exten => s,n,Playback(demo-congrats)
 
[default]
include => demo
include => users

extensions.lua

extensions = {
   users = {
      [100] = function()
         app.dial("SIP/100")
      end;
   };
 
   demo = {
      ["s"] = function()
         app.playback(demo-congrats)
      end;
   };
       
   default = {
      include = {"demo", "users"};
   };
}

Rotações (Loops)

extensions.conf

exten => 100,1,Noop
exten => 100,n,Set(i=0)
exten => 100,n,While($[i < 10])
exten => 100,n,Verbose(i = ${i})
exten => 100,n,EndWhile

extensions.lua

i = 0
while i < 10 do
  app.verbose("i = " .. i)
end

Variáveis (Variables)

extensions.conf

exten => 100,1,Set(my_variable=my_value)
exten => 100,n,Verbose(my_variable = ${my_variable})

extensions.lua

channel.my_variable = "my_value"
app.verbose("my_variable = " .. channel.my_variable:get())

Formularios (Applications)

extensions.conf

exten => 100,1,Dial("SIP/100",,m)

extensions.lua

app.dial("SIP/100", nil, "m")

Macros/GoSub

As MACROS pode ser definidas em pbx_lua nomeando um contexto "macro-*" assim como em extensions.conf, mas geralmente onde você usaria macros ou GoSub em extensions.conf você simplesmente usaria uma função em LUA.

extensions.conf

[macro-dial]
exten => s,1,Noop
exten => s,n,Dial(${ARG1})
 
[default]
exten => 100,1,Macro(dial,SIP/100)

extensions.lua

extensions = {}
extensions.default = {}
 
function dial(resource)
   app.dial(resource)
end
 
extensions.default[100] = function()
   dial("SIP/100")
end

GoTo

Embora GoTo seja um STAPLE (grampo) extensions.conf, geralmente deve ser evitado em PBX_LUA em favor de funções.

extensions.conf

[default]
exten => 100,1,Goto(102,1)
 
exten => 102,1,Playback("demo-thanks")
exten => 102,n,Hangup

extensions.lua

extensions = {}
extensions.default = {}
 
function do_hangup()
   app.playback("demo-thanks")
   app.hangup()
end
 
extensions.default[100] = function()
   do_hangup()
end

A função app.goto() não funcionará como esperado em pbx_lua em Asterisk® SCF™ versão 1.8 ou inferior. Se você precisar usar a função app.goto() deve retornar manualmente o controle para o Asterisk® SCF™ usando o return para a função de extensão do Dialplan, caso contrário, a execução continuará após a chamada para app.goto(). As chamadas para app.goto() devem funcionar como esperado para o Asterisk® SCF™ versão 10 e superiores, mas ainda não devem ser necessarias na maioria dos casos.

In Asterisk 1.8, use return

function extension_function(c, e)
   return app.goto("default", "100", 1)
 
   -- without that 'return' the rest of the function would execute normally
   app.verbose("Did you forget to use 'return'?")
end

Tkat's All Folks! (É por hoje é só, pessoal!).

Aprenda Lua em 15 minutos!

Temos uma comunidade, ainda pequena no Telegram, para estudos exclusivos em Dialplan com LUA no Asterisk® SCF™, você é bem vindo! (Telegram: https://t.me/asteriskluabr).