WirelessBR |
WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade comercial, feito por voluntários, para divulgação de tecnologia em telecomunicações |
|
Série de artigos sobre VoIP (5) |
||
José de Ribamar Smolka Ramos |
Série
de artigos sobre
VoIP
Quinto artigo - Parte 06
Série VoIP (5) – Sinalização
(continuação)
ENUM, TGREP e TRIP:
Especialmente no caso SIP, onde os usuários e serviços são identificados por URIs (universal resource identifiers) da forma userid@domain, aparece um primeiro problema de localização: como mapear a identificação de usuários e serviços que eventualmente ainda estejam do lado “convencional” da rede (na forma de números telefônicos aderentes à recomendação E.164 da ITU-T) com URIs no formato padrão DNS (domain naming system) do TCP/IP?
Para endereçar este problema foi criado um working group do IETF chamado telephone number mapping[1]. Deste grupo surgiu a RFC 3761 (que substituiu a RFC 2916) E.164 to uniform resource identifiers (URI) dynamic delegation discovery system (DDDS) application (ENUM), que especifica a forma de inserção, dentro da estrutura de fully qualified domain names do DNS, de referências a números telefônicos no padrão E.164.
A solução do problema de mapeamento E.164/DNS não se esgota somente nesta RFC. Existem várias outras RFCs e drafts (umas vinte) que entram em detalhes sobre a forma de aplicar este tipo de solução a diversas situações práticas. Leitura obrigatória para quem queira se aprofundar no assunto.
Outro aspecto crítico para a interoperação de redes NGN, baseadas tanto no modelo SIP quanto no modelo H.323, é reconhecer que, entre domínios administrativos pertencentes a network providers diferentes (aquilo que, convencionalmente, chamamos de operadoras de serviços de telecomunicações), não existia uma forma padronizada para a troca de informação entre os gatekeepers (H.323) ou entre os proxy servers/redirect servers/location servers (SIP) para determinar quais devem ser os gateways preferenciais de encaminhamento de tráfego entre eles.
Para este problema foi criado mais um working group do IETF: IP telephony[2]. Do trabalho deste grupo temos duas RFCs e um draft a destacar:
RFC 2871 – A framework for telephony routing over IP;
RFC 3219 – Telephony routing over IP (TRIP);
draft-ietf-iptel-tgrep-07 – Telephony gateway registration protocol (TGREP).
Através dos mecanismos previstos nestes protocolos, é possível que os network providers negociem seus relacionamentos de peering, de uma forma muito semelhante à que é utilizada para negociação de dynamic routing IP entre autonomous systems diferentes. Na verdade, muitos dos conceitos destes protocolos foram “emprestados” do protocolo padrão para exterior routing, o BGP (border gateway protocol).
Conclusão:
Agora que cobrimos (superficialmente, é verdade) o cenário de sinalização em ambiente VoIP, estamos com quase todo o quadro geral desenhado.
Precisamos, ainda, discutir somente mais um tópico genérico (multicasting) antes de chegarmos ao primeiro ponto de convergência da nossa série de artigos.
Apesar do quadro técnico que estamos descrevendo ser, aparentemente, bem completo e coerente, a quantidade de detalhes e de problemas potenciais (técnicos e comerciais) para a adoção extensiva de VoIP pelas operadoras de telecomunicações é enorme.