Kamailio - Entendendo a lógica de roteamento.

 

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

 

"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™

    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.