Problema de SIP e NAT em Intranet.

 

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).