Tecnologia líder no mercado de telecomunicações

Posts para » Session Border Controller

SIP, SIP-I ou SIP-T?

Um cabo Ehernet, esta é a simplicidade de um tronco SIP.

Um cabo Ehernet, esta é a simplicidade de um tronco SIP.

Recentemente várias pessoas tem me perguntado a diferença entre SIP, SIP-I e SIP-T e quais as implicações entre as diferentes versões.  Neste artigo vou explicar a diferença e suas implicações.

SIP – O SIP é definido pela RFC3261 e é o protocolo de telefonia IP mais popular do mundo. O crescimento dos troncos SIP nos últimos anos nos mostra claramente que o futuro da telefonia é software e não hardware.  Padrões ultrapassados como o T1/E1 limitados a 1.5 e 2Mbps, respectivamente, estão com seus dias contados.  Mesmo na telefonia celular o Voz sobre LTE é todo baseado em SIP. Os mais recentes aplicativos OTT (over the top) também são baseados em SIP e XMPP.

SIP-T – Definido na RFC 3372 em 2002. Ele foi criado para permitir o encapsulamento de informações da telefonia convencional, mais especificamente o ISUP (ISDN User Part) dentro do SIP. Ele faz uma tradução direta entre as mensagens SIP e as mensagens ISUP como mostrado abaixo.

        SIP phone         Proxy                    MGC          PSTN
     |-----INVITE----->|                       |             |
     |                 |--------INVITE-------->|             |
     |<---100 TRYING---|                       |-----IAM---->|
     |                 |<------100 TRYING------|             |
     |                 |                       |<----ACM-----|
     |                 |<---------18x----------|             |
     |<------18x-------|                       |             |
     |                 |                       |<----ANM-----|
     |                 |<--------200 OK--------|             |
     |<-----200 OK-----|                       |             |
     |-------ACK------>|                       |             |
     |                 |----------ACK--------->|             |
     |========================Conversation===================|
     |-------BYE------>|                       |             |
     |                 |----------BYE--------->|             |
     |                 |                       |-----REL---->|
     |                 |<--------200 OK--------|             |
     |<-----200 OK-----|                       |<----RLC-----|

O ISUP é encapsulado em um corpo multimime. Em outras palavras o SIP carrega o SDP Session Description Protocol e o ISUP no mesmo pacote.  Como consequência, o SIP-T é incompatível com muitos clientes e gateways que não suportam este tipo de codificação. Por isto muitas vezes é necessário uma conversão de SIP-T para SIP normalizando os cabeçalhos e esta é uma das funções do nosso Session Border Controller. Abaixo você pode ver o encasupamento de SDP e ISUP dentro do pacote SIP.

ISUP sobre SIP

Foi descrito também um mapeamento das mensagens de erro na RFC3398.  Este documento mostra claramente como se convertem os códigos de erro de uma rede ISDN para uma rede SIP.  Ainda no contexto do SIP-T a RFC3326 especifica o cabeçalho Reason, onde podem ser transportados os códigos originais do ISDN (Q.850).

      Reason: SIP ;cause=200 ;text="Call completed elsewhere"
      Reason: Q.850 ;cause=16 ;text="Terminated"

O SIP-I é uma variação do SIP-T, mas definida pela ITU na norma Q1912.5. Ele aproveita todas as definições usadas no SIP-T que é mais antigo (2002). O SIP-I é um protocolo mais completo que o SIP-T e além do que era previsto para o SIP-T ele também define recursos adicionais nos seus Anexos A (BICC/ISUP) e B (Interworking SIP ISUP) que são pouco usados.

Implicações práticas

SIP-I e SIP-T são incompatíveis com gateways e telefones comuns. Para terminar chamadas SIP-I ou SIP-T é preciso ter um equipamento que consiga decodificar as mensagens ISUP como,  por exemplo,  um Session Border Controller que neste caso atua como um gateway SIP-I ou SIP-T para SIP.

A diferença básica entre SIP-I e SIP-T é a tabela de tradução de mensagens. No SIP-I o cabeçalho Reason com o código Q.850 das mensagens de erro é obrigatório, no SIP-T não.

No SIP-I e SIP-T você preserva todas as informações da rede pública, incluindo os bits de chamada a cobrar e o “no-charge” por exemplo. é possível no SBC decodificar qualquer campo do ISUP e encapsulá-lo em outro cabeçalho SIP para leitura em equipamento comum.

Em outras palavras usando SIP-I ou SIP-T você pode usar circuitos de 1Gbps para terminar milhares de chamadas simultâneas sem necessitar de nenhum hardware proprietário, apenas servidores de “prateleira”.  Em um cliente,  nosso SBC está terminando 2000 chamadas simultâneas em SIP-I há mais de dois anos, sem dúvida uma grande economia em termos de gateways, espaço nos racks, energia elétrica e cabos.

Conclusão

Operadoras e Call Centers devem considerar imediatamente a adoção de troncos SIP-I como uma forma de reduzir custos e complexidade. Com a queda das tarifas de interconexão, o uso de circuitos SIP-I pode substituir não apenas circuitos E1/T1, mas também gateways GSM (chipeiras).  As principais operadoras do Brasil já disponibilizam estes circuitos no seu setor de atacado. Além disso não há nenhuma perda de sinalização, permitindo uma qualificação de chamadas precisa e robusta. Se precisar de equipamentos que falem nativamente SIP-I converse com a SipPulse, nós somos especialistas em SIP.


Para que serve um SBC, Session Border Controller?

sbc_ss

Um dos equipamentos mais controversos do mercado é o Session Border Controller (SBC). O problema é que esta sigla significa coisas diferentes para pessoas diferentes. Existem duas boas definições de SBC, a da wikipedia que é mais voltado ao público geral e da RFC5853 para o público mais técnico. Ambas definem muito bem o papel deste equipamento.

Neste artigo vamos explicar para que serve o SBC e como aplicá-lo.  Abaixo seguem os principais casos de uso para um SBC.

Ponto de demarcação

O principal caso de uso de um SBC é a demarcação entre duas redes de voz de operadoras diferentes.

SBC Backend

SBC Backend

O caso clássico é o entroncamento SIP.  A operadora oferece uma conexão ethernet, por exemplo, com um endereçamento /30 (apenas dois endereços IPs). Para que as redes SIP consigam se interconectar é preciso um dispositivo que faça o NAT. O SIP tem uma peculiaridade de embutir os endereços IP da camada de rede dentro da camada de sessão o que impede que firewalls comuns atendam estes requisitos.

Além da demarcação e NAT, algumas traduções tem destaque e são muito comuns no SBC Back End

  • Tradução de SIP para SIP-I ou SIP-T
  • Tradução IPv6 p/ IPv4
  • Conectividade com o Skype For Business (SIP sobre TCP)

Os recursos mais importantes do SBC Back End são:

  • Ocultação de topologia
    • A rede externa não deve saber nada sobre a rede interna
    • Gestão de tráfego de mídia Controlar chamadas simultâneas
      • Controle de chamadas por segundo
      • Travessia de NAT
        • Os endereços devem ser traduzidos de forma transparente até a camada de sessão (SIP)
      • Segurança
        • Prevenção de ataques DOS e Floods (Se o SIP trunk for Internet)
      • Compatibilidade
        • Suporte à SIP-I e SIP-T
        • Manipulação de cabeçalhos
        • Transcodificação
        • IPv4<->IPV6
        • Correção de sinalização defeituosa
      • Anti-Fraude
        • Em troncos SIP internacionais, é importante prevenir fraudes com Premium Rate Numbers.

Acesso remoto

O segundo caso mais comum de SBC é o de acesso remoto e registro transparente.

SBC Front End

SBC Front End

Neste caso é permitida a entrada de clientes vindos da Internet dentro da estrutura interna. É cada vez mais impensável deixar que todos os equipamentos de rede estejam expostos na Internet.  Se já é difícil proteger um equipamento, imagine todos.  O SBC neste caso funciona como ponto único de entrada. Na maioria dos casos esta função é feita por um proxy intermediário chamado outbound proxy.  Os recursos importantes neste caso são:

  • Registro transparente através do SBC
    • O telefone deve se registrar através do SBC e não nele
    • Ocultação de topologia e travessia de NAT
      • Clientes de fora não enxergam gateways ou outros elementos internos
    • Compatibilidade
      • IPv4<->IPv6
    • Segurança
      • Prevenção de Denial of Service

Hardware ou Software?

Os primeiros SBCs eram baseados em hardware proprietário.  Os mais famosos eram os da ACME Packet (adquirida pela Oracle) e Sonus que se mantém com marca própria. Na essência um SBC é puramente software.

Existem três grandes vantagens em usar um SBC por software, é possível virtualizar, é possível usar em nuvem e principalmente, você não fica limitado ao hardware oferecido pelo fabricante. Se quiser pode aumentar significativamente o poder do hardware mantendo o mesmo software. Além disso o tempo médio de reparo é muito mais rápido. Já imaginou ter de trocar um appliance de SBC re-exportando e importando de novo.

Conclusão

Na SipPulse nós produzimos a mais de oito anos o nosso SBC que é usado em dezenas de operações comercias no Brasil.  O SBC é um software sofisticado então fizemos de tudo para criar um software fácil de usar, totalmente configurável pela interface gráfica e que atende aos dois casos, Acesso Remoto e Ponto de Demarcação.  É muito comum fabricantes converterem gateways em SBCs, simplesmente substituindo uma interface E1 por uma interface SIP, mas isto não atende a todos os requisitos definidos.


Session Border Controller da SipPulse agora disponível na ShopVoIP

SBC_Front_landing_page-228x228Os preços do novo SBC da SipPulse estão agora disponiveis no ShopVoip  http://www.shopvoip.com.br/index.php?route=product/category&path=141.  Solicite atendimento especializado  no caso de dúvidas ou customizações. O sistema funciona a partir de 15 sessões até 2000 licenciado por software. Dois modelos principais o SBC-1000 até 300 sessões e o SBC-2000 até 2000 sessões com fonte redundante. Você pode proteger sua plataforma VoIP ou softswitch, balancear carga, normalizar cabeçalhos e números e interconectar com outras operadoras. Consulte-nos para projetos especiais.