GT-VOIP Relatório I.5

GT-VOIP Relatório I.5:
Proposta de Numeração VoIP Nacional
Janeiro de 2003
Este relatório apresenta o plano de numeração preliminar definido com base na experiência em
montar e gerenciar o ambiente VOIP na Universidade Federal do Rio de Janeiro, e na interoperação
entre UFRJ e o Grupo de Trabalho de Voz sobre IP da Internet2.
RNP/REF/0204
Sinopse
Estamos elaborando, no escopo do projeto GT-VOIP, algumas especificações a serem usadas pelas
instituições ligadas a RNP na criação de um plano de discagem único dentro do backbone RNP,
especificamente para VoIP. Neste sentido, precisamos analisar todos os possíveis cenários, para que
nenhum usuário fique sem telefonia.
Este relatório apresenta uma proposta de plano de numeração originada da discussão sobre os
trabalhos realizados pelo mundo afora, é importante notar que desejamos que o impacto na operação
atual do plano de numeração dos PBXs das instituições seja mínimo. Para que o usuário possa fazer
uso do Piloto VOIP, ele deverá discar um código de acesso específico a este serviço. Dessa forma, a
operação normal via rede pública de telefonia estará sempre habilitada e será uma prerrogativa do
usuário passar ou não pelo serviço VOIP.
Em cada instituição haverá a necessidade de um trabalho de divulgação do novo serviço e esta
estratégia deverá ser organizada de forma institucional, com informações sendo disponibilizadas nas
home pages das instituições, divulgação nos fóruns colegiados, etc.
A estratégia vislumbrada pelo GT-VOIP para incentivar a utilização de VOIP no Piloto é divulgar de
forma regular as estatísticas de qualidade e de uso do Piloto, identificando a matriz de tráfego, o
tráfego gerado por cada instituição, a qualidade média do Piloto, a qualidade média por rota, etc. Os
dados quantitativos servirão para garantir o sucesso do Piloto junto à comunidade e incentivar a
ampliação do serviço.
Com a entrada em operação do Piloto e a interconexão deste serviço com os serviços VOIP da
Internet 2 e de outras redes, algum ajuste no plano de numeração poderá ocorrer. Normas para o
endereçamento VOIP estão em discussão e recomendações superiores poderão afetar a forma de
oferta do serviço. O GT-VOIP acompanhará as decisões nacionais e internacionais nessa área e fará
os ajustes necessários ao plano de numeração e forma de operação do Piloto. .
GT-VoIP Relatório I.5
2
Sumário
Introdução – Arquitetura VoIP UFRJ
Softwares e Equipamentos Utilizados
Definição dos Cenários - Base para a Construção do Plano de Discagem
Cenário 1- Ligação de Telefone Virtual Local para Telefone Virtual Local
Cenário 2- Ligação de Telefone Virtual Local para Telefone Virtual Remoto
Cenário 3- Ligação de Telefone Virtual Local para Telefone Convencional do PBX Local
Cenário 4- Ligação de Telefone Virtual Remoto para Telefone Convencional do PBX Local
Cenário 5- Ligação de Telefone Virtual Local para Telefone Convencional da Operadora
Cenário 6- Ligação de Telefone Convencional do PBX para Telefone Virtual Local
Cenário 7- Ligação de Telefone Convencional do PBX para Telefone Virtual Remoto
Cenário 8 - Ligação de Telefone Convencional do PBX para outro Telefone Convencional
do PBX (via RNP)
3
4
8
8
9
10
10
10
11
11
12
Cenário 9- Ligação de Telefone Convencional da Operadora para Telefone Virtual Local
Cenário 10- Ligação de Telefone Convencional da Operadora para Telefone Virtual Remoto
Cenário 11- Ligações Internacionais
Apêndice – Sugestão para Numeração de Ramais Virtuais
13
13
14
15
GT-VoIP Relatório I.5
3
1.
Introdução – Arquitetura VoIP UFRJ
•
Estamos elaborando, no escopo do projeto, algumas especificações a serem usadas pelas
instituições ligadas a RNP para a criação de um plano de discagem único dentro do backbone
RNP. Neste sentido, precisamos analisar todos os possíveis cenários, para que nenhum usuário
fique sem telefonia.
•
É importante ressaltar que todo o modelo é baseado em H.323 pela facilidade de obtenção de
softwares e pela grande quantidade de fabricantes, bem como, por que este é o protocolo padrão
sendo usado atualmente na rede de telefonia IP da Internet2.
•
O exemplo proposto, e explicado aqui, usa como piloto o projeto de plano de discagem
VOIP/UFRJ, idealizado para solucionar um grande número de problemas das instituições. Entre
os problemas mapeados, temos casos particulares na UFRJ de que certos centros/departamentos
não têm acesso a telefonia convencional no campus, embora tenha rede local. Portanto, é um dos
objetivos de implantar VOIP na UFRJ, auxiliar tais grupos de usuários, para que fazendo uso de
telefones em software, e usando as redes locais, que estes usuários possam fazer chamadas
para a telefonia do campus e receber ligações.
•
Apresentaremos um modelo genérico do ambiente VOIP implantado na UFRJ, e que poderia ser
replicado em outros campii universitários do Brasil. Nestes cenários estão contempladas umas
séries de softwares, hardwares, serviços, que foram devidamente testados no Lab. VOIP. E que
são extremamente úteis para a implantação, desenvolvimento e manutenção de um site VOIP.
GT-VoIP Relatório I.5
4
Softwares e Equipamentos Utilizados
•
Netmeeting - software disponível em qualquer Windows 98/2000/XP. (Basta digitar conf em
Iniciar->Executar). Trata-se de um cliente H.323 completo, com a possibilidade de realizar
áudio/vídeoconferencias e compartilhamento de aplicativos. Também tem a possibilidade de usar
serviços de um Gateway H.323, ou registrar usuários em um servidor Gatekeeper.
•
Softphone (Cisco) - software que gerencia uma linha telefônica virtual no ambiente Cisco AVVID
(CTI port), para usá-lo é necessário um Call Manager, neste são configurados parâmetros como o
login do usuário, o número da linha virtual associada, e os serviços a serem usados (Chamada
em Espera, Transferência de Chamada, Voicemail). Ele não interopera sozinho com outros
dispositivos H.323, a não ser pelo uso do Call Manager.
•
GnomeMeeting/OpenPhone - Versão Linux do Netmeeting, baseado no projeto OpenH323,
extende as funcionalidades de compartilhamento de aplicativos, whiteboard, algo não presente
nos clientes OpenPhone e Ohphone.
•
Creative VoIP Blaster - Placa especial para conectar um aparelho telefônico numa porta USB do
computador. Usando-se os drivers desenvolvidos no âmbito do OpenH323, e os programas
openphone/ohphone, com opção para VoipBlaster, o telefônico conectado ao computador tornase um telefone IP H.323. Foram feitos alguns testes de interoperabilidade com Netmeeting, outros
clientes H.323, Gatekeeper e Gateway, aparentemente todas as funcionalidades estão presentes,
mas algumas inconsistências quanto aos codificadores de áudio persistem.
•
OpenPhone/Ohphone - software open source disponível em http://www.openh323.org, executa
em ambientes Windows, Linux, FreeBSD, e Solaris. Trata-se de um cliente H.323 completo, com
possibilidade de áudio/videoconferência. Interopera com outros dispositivos H.323 como
gateways/gatekeepers. Possui suporte a sinalização H.235 necessária para autenticação de
usuários por login e senha.
•
OpenMCU - Servidor de conferência H.323. Através do registro no Gatekeeper de um apelido, ou
número, vários usuários ligando para este número entram numa mesma sala de conferência.
Ideal para reuniões virtuais. Requer uma máquina com considerável poder de processamento
para a mixagem dos fluxos multimídia em tempo real, entretanto não realiza a transcodificação
dos fluxos.
•
Configuração de Firewall
o 80 Static TCP HTTP Interface (Optional)
o 389 Static TCP ILS Registration (LDAP)
o 1502 Static TCP T.120
o 1718 Static TCP Gatekeepr Discovery
o 1719 Static UDP Gatekeeper RAS
o 1720 Static TCP H323 Call Setup
o 1731 Static TCP Audio Call Control
o 8080 Static TCP HTTP Server Push (Optional)
o 1024-65535 Dynamic UDP H245 Call Parameters
o 1024-65536 Dynamic UDP RTP (Video Data Streams)
o 1024-65537 Dynamic UDP RTP (Audio Data Streams)
o 1024-65538 Dynamic UDP RTCP Controle Information
GT-VoIP Relatório I.5
5
•
Gatekeeper
o Opengatekeeper foi desenvolvido inicialmente pela Egoboo, empresa inglesa
especializada em consultoria na área de telefonia IP. Ele possui as capacidades de:
rotear chamadas via modo GK-routed (onde o GK faz o redirecionando das mensagens
como intermediário da comunicação), suportar o uso de prefixos para acessar gateways,
suportar diversos tipos de alias H.323, logar as atividades de chamadas e registros,
encaminhar pesquisas de endereços para GKs vizinhos.
o openh323proxy foi desenvolvido pela Abdus Salam International Centre for Theoretical
Physics, centro de pesquisa localizado em Trieste, Itália. Ele foi desenvolvido para
solucionar problemas de firewall no ambiente H.323. É baseado no projeto
Opengatekeeper, mantendo todas as funcionalidades do mesmo, e estendendo uma
característica de redirecionamento de mídia (RTP proxy). Ele permite rotear o tráfego
RTP (áudio e vídeo) e o tráfego T.120 (dados compartilhados) através do gatekeeper,
sem que estes fluxos sejam trocados diretamente entre os terminais.
o OpenGK foi desenvolvido pela empresa australiana Equivalence Pty, mantenedora do
projeto OpenH323. Entretanto, possui apenas o modo de chamada direta implementado
o
(GK Direct Call Mode – quando o GK repassa ao cliente chamador o IP do cliente
chamado, sem fazer mais nenhuma intermediação). Ele também não pode configurar
gatekeepers vizinhos para propagar buscas, uma importante desvantagem. Por outro
lado possui suporte a serviço Web e objetos de criptografia e autenticação segundo o
padrão H.235, algo não implementado nos outros Gatekeepers.
GNUGK o mais completo gatekeeper open-source disponível, com capacidades de
filtragem de ligações e integração de registros com LDAP.
•
NTP - Os programas NTP Server e Client usam o protocolo NTP para sincronizar o relógio do
computador, ajustando-o a partir de uma fonte de referência de relógio como um GPS. Ele prove
a precisao de milisegundos em uma rede LAN, e da ordem de dezenas de milisegundos em
WANs. Para o propósito da telefonia IP é importante manter os relógios dos gateways e
servidores, como gatekeeper, para gravar com precisão a hora/min/seg das ligações.
•
Gateways - equipamentos instalados nas instituições que irão permitir a interconexão da telefonia
tradicional à rede de dados. Estes gateways serão configurados com interfaces analógicas, ou
digitais, dependendo da disponibilidade de ramais analógicos e de troncos digitais,
respectivamente, no PBX da instituição. Através do protocolo H.323 será possível que um usuário
da rede possa ligar de sua estação, ou de um telefone IP, para um ramal interno, para um ramal
das outras instituições, para outro terminal H.323 na Internet, ou mesmo para a rede pública de
telefonia.
•
Telefone Interno (Ramal do PBX, por exemplo) - Ligado a rede privada do campus, permite
fazer discagem direta a ramal e chamadas externas através do PBX. No contexto do ambiente
VOIP este telefone poderia ter acesso a rede VoIP através de um código de escape do PBX.
Como hoje em dia acontece quando temos o código 0, para acessar a rede pública, poderíamos
ter um código #0 para ligações para a rede VoIP.
•
Telefone Externo (Residencial, por exemplo) - Ligado a uma rede de telefonia, e cujo plano de
discagem é o dado pela operadora. No contexto do ambiente VOIP este telefone poderia ter
GT-VoIP Relatório I.5
6
acesso a rede VoIP através de uma discagem simples para o PBX da instituição, autenticando
através de um programa IVR e então obtendo um segundo tom de discagem (na rede VoIP).
No cenário apresentado temos as seguintes redes interconectadas:
•
Backbone RNP - Diversas redes de universidades interconectadas por um backbone
de alta performance. É importante dar prioridade para as chamadas telefônicas dentro
do backbone para garantir uma qualidade aceitável.
o Obs.: Este ambiente VOIP da UFRJ, é um modelo a ser seguido pelas demais
instituições.
•
No backbone Interno da UFRJ, temos um conjunto de softwares e hardware de
telefonia IP que são exemplos de "ramais virtuais" no ambiente de Telefonia IP da
UFRJ. Para os propósitos do Plano de Discagem UFRJ, todos eles devem se registrar
automaticamente, com seus números virtuais, no Gatekeeper.
o Se o Gatekeeper implementar as funcionalidades H.235 de autenticação via
login/senha, convém ao administrador criar as "contas" para os usuários, e
permitir registros e ligações somente por usuários devidamente autenticados.
o A sub-rede VOIP-UFRJ mostra um exemplo de interoperação com a
telefonia convencional através de um gateway protegido, com uma infraestrutura para monitoramento e contabilização das chamadas, bem como para
programação de serviços de voz.
o Dentro da Rede Interna de Telefonia da UFRJ temos um conjunto de centrais
telefônicas interconectadas que provêm telefonia convencional para o campus.
Estas centrais possibilitam realizar chamada direta a ramal (DID). Ou seja, o
ramal #3354, se quiser chamar o ramal #3191, basta digitar estes 4 números.
o Para acessar a Rede de Telefonia Pública (Telemar), é preciso utilizar um
código de escape 0, seguido de 8 números para ligações para telefones
externos, sejam estes ligações locais, interurbanos ou DDI da telefonia pública.
GT-VoIP Relatório I.5
7
2.
Definição dos Cenários - Base para a Construção do Plano de Discagem
Cenário 1- Ligação de Telefone Virtual Local para Telefone Virtual Local
•
Neste cenário (Fig.2), os clientes H.323 devem se registrar com um número que corresponda ao:
0 (ramal virtual) + código da cidade + código da instituição + ramal virtual qualquer. Este número
ao ser anunciado no Gatekeeper permitirá que pessoas de outros estados possam ligar para este
usuário.
•
Para ligar de um ramal virtual para outro ramal virtual, o usuário deverá digitar o número completo
(de 11 digitos). Isso pode ser penoso para o usuário, mas é uma forma de anunciar números
virtuais nacionalmente e diferenciá-los dos números reais acrescidos do DDD. A maioria dos
programas cliente H.323 possui funcionalidades de "Speed Dial" onde é possível associar um
número de atalho para determinado número.
•
Com relação a arquitetura, os clientes sinalizam RAS para o GK, e o firewall no caminho permitirá
que isso ocorra. Uma vez registrado, o plano de discagem do GK é automaticamente atualizado.
E toda vez que os clientes fizerem requisições de chamada para um número de um cliente virtual,
esta será redirecionada para o IP correspondente.
OBS.: O conceito de ramal virtual implica numa numeração completamente nova para atingir os
clientes H.323 baseados em PCs multimídia. Ele soluciona o problema de receber uma ligação IP a
partir de um telefone analógico, pois ele poderia ser atingido via Gateway.
GT-VoIP Relatório I.5
8
Cenário 2- Ligação de Telefone Virtual Local para Telefone Virtual Remoto
•
No próximo cenário (Fig.3), podemos ter 2 situações: a primeira é que todos os clientes H.323 se
registram em um mesmo Gatekeeper (ex. GK UFRJ), ou eles se registram em GK diferentes,
distribuindo a carga de chamadas nacionalmente, e cada Gatekeeper fica sendo vizinho do outro.
No primeiro cenário, uma pesquisa de qualquer número é prontamente respondida pelo GK. No
segundo cenário, precisamos esclarecer que vizinho em H.323 significa que, caso o número
procurado não esteja no plano de discagem daquele GK, ele pode consultar o GK vizinho
(configurado) para fazer a resolução do número. Acreditamos que a 2º situação é mais
interessante para a RNP.
•
É importante lembrar que os GK também são responsáveis por gerenciar a banda passante,
portanto, eles têm controle de admissão de chamadas, bem como sendo um GK Proxy, a mídia
pode ser transportada através dele, e implementam NAT.
•
Outra característica é que a busca pelo número entre GK vizinhos NÃO é repassada em cascata.
GT-VoIP Relatório I.5
9
Cenário 3- Ligação de Telefone Virtual Local para Telefone Convencional do PBX Local
Cenário 4- Ligação de Telefone Virtual Remoto para Telefone Convencional do PBX Local
Cenário 5- Ligação de Telefone Virtual Local para Telefone Convencional da Operadora
•
Estes cenários são muito parecidos, por isso agregamos os mesmos (Fig.4). A principal diferença
nestes cenários é a presença do Gateway H.323. Este equipamento tem a tarefa de converter
uma ligação telefônica para uma ligação VoIP. Do ponto de vista da central telefônica (em relação
ao Gateway) é como se tivessemos um equipamento realizando a discagem e conexão telefônica
normalmente. Por outro lado, em termo de ambiente H.323, é preciso registrar um prefixo, não
mais um número completo como no caso dos ramais virtuais. O Gateway H.323 então envia uma
mensagem de registro para o Gatekeeper contendo o prefixo do PBX da instituição. Uma vez
registrado; todas as ligações que vierem de Telefones Virtuais Locais que tiverem aquele prefixo,
serão encaminhadas para o Gateway H.323.
•
No caso do telefone virtual ser remoto, pelo princípio dos GKs vizinhos, uma chamada que estiver
vindo da UFMG, por exemplo, será repassada para o GK correspondente daquele prefixo.
Aparece no cenário, um segundo plano de discagem, neste caso é preciso prestar atenção, para
verificar para que interface será enviada a ligação. Deve-se especificar uma interface que esteja
conectada ao PBX.
•
No exemplo da Fig. 4, o Gateway UFRJ está registrando dois prefixos, um que permite fazer
ligações para ramais internos da UFRJ, pois o Gateway "disca" XXXX (4 números), ou para
telefones externos na rede da operadora, pela discagem de 0XXXXXXXX (9 números).
•
Obs.: Nunca é possível fazer uma chamada VoIP até um Gateway e depois pelo Plano de
Discagem dele, redirecionado para outro endereço IP. Quando habilitamos o servidor RADIUS
neste cenário, significa que o Gateway H.323 em questão tem um cliente RADIUS embutido, e ele
pode logar todas as ligações que estão sendo feitas via Gateway.
GT-VoIP Relatório I.5
10
Cenário 6- Ligação de Telefone Convencional do PBX para Telefone Virtual Local
Cenário 7- Ligação de Telefone Convencional do PBX para Telefone Virtual Remoto
•
Agora temos um cenário mais complexo. Onde aparece também o plano de numeração do PBX.
Este plano do PBX é dependente do tipo de interface que está conectando o PBX ao gateway. Se
tivermos uma interface de tronco (E&M E1), é possível criar um código de escape (como o código
0 para a rede externa), ou usar um serviço suplementar do PBX, #7, que então nos dará um
segundo tom de discagem para a Internet.
•
Ou pode-se realizar discagem direta à ramal, onde os valores do ramal seriam repassados para o
Gateway. No caso de realizar ligações a telefones virtuais locais com mais facilidade. Tomando o
cuidado de no Gateway anexar os prefixos correspondentes a instituição.
•
A outra opção, no caso de interface FXO é criar no PBX um ramal #4000 (por exemplo), que
redirecione as ligações para as portas do Gateway H.323, a fim de prover ao usuário da telefonia,
um segundo tom de discagem. Esse segundo tom de discagem, é uma discagem diretamente
relacionada com o plano de discagem do Gateway, podendo então realizar ligações para a
Internet.
GT-VoIP Relatório I.5
11
Cenário 8 - Ligação de Telefone Convencional do PBX para outro Telefone Convencional do
PBX (via RNP)
•
Ainda pensando no modelo da Fig. 5, caso o usuário da telefonia queira fazer uma chamada para
outro estado via Internet. Ele deve realizar da seguinte forma:
•
Imagine que o usuário esteja na UFRJ e queira fazer uma ligação para UFMG. No telefone
convencional da sala dele, ele começa discando 4000. O ramal que redireciona as ligações da
Internet.
•
Então este usuário vai ouvir um segundo tom de discagem. Este segundo tom de discagem é o
tom para ligar para a Internet. E finalmente ele disca os 10 números de uma ligação DDD, no
caso da UFMG, imaginemos que este usuário ligasse para o número real 3134994001.
•
Esta ligação chegaria até o Gateway H.323, onde uma regra no plano de discagem, especifica
que quando 10 números são digitados, ele deve enviar a requisição para o Gatekeeper. Se o GK
da UFRJ não tiver este prefixo registrado, pelo princípio dos GKs vizinhos, ele enviaria para o GK
UFMG, que então teria uma entrada indicando : 313499XXXX -> IP do Gateway da UFMG.
•
O Gateway da UFRJ passaria então a realizar a ligação VoIP para o Gateway da UFMG. E o
Gateway da UFMG teria um plano de discagem 3134999XXXX, onde o Gateway da UFMG
repassaria os últimos 4 números para o PBX da UFMG, realizando a chamada com sucesso.
GT-VoIP Relatório I.5
12
Cenário 9- Ligação de Telefone Convencional da Operadora para Telefone Virtual Local
Cenário 10- Ligação de Telefone Convencional da Operadora para Telefone Virtual Remoto
•
Este cenário pode ser usado quando um professor de outra instituição encontra-se em
um congresso fora dos domínios físicos da universidade, mas que precisa realizar
ligações no intuito da instituição.
•
Para realizar este cenário precisamos de uma aplicação integrada ou independente
chamada IVR (Interactive Voice Response). Este sistema permite enviar uma
mensagem de boas vindas, e o usuário pode interagir com o sistema de voz digitando
número de acordo com os menus que são apresentados.
•
No caso, deste cenário de ligação de longa distância, a idéia é desenvolver um script
IVR, dar uma mensagem de boas vindas, e pedir uma autenticação via senha numérica.
Depois de passada esta autenticação, este sistema IVR daria o segundo tom de
discagem, e permitiria o usuário autenticado à partir da rede de telefonia externa,
realizar ligações para a Internet.
GT-VoIP Relatório I.5
13
Cenário 11- Ligações Internacionais
•
O cenário de ligações internacionais necessita de um software Gatekeeper diferente, que permita
realizar a triangulação entre GKs do Brasil e GKs dos EUA, Europa, Austrália. A Cisco
desenvolveu um sistema chamado Directory Gatekeeper, que permite realizar isso. Também
existem propostas de desenvolvimento de tal Gatekeeper no meio acadêmico. Com este DGK, é
possível discar para números de universidades nos EUA, e fazer a ligação via Internet.
GT-VoIP Relatório I.5
14
Apêndice – Sugestão para Numeração de Ramais Virtuais
O H.323 suporta dois tipos de endereçamento, através de alias ou através de números de extensões.
Alias é um endereço alfa-numérico no formato [email protected]. Os números de extensões
são um endereçamento somente numérico contendo os caracteres 0,1,2,3,4,5,6,7,8,9,#, e *. O mesmo
conjunto de caracteres encontrado em aparelhos telefônico.
A discagem numérica é bastante útil para dispositivos que são limitados apenas ao conjunto de
caracteres telefônicos, e esta discagem pode ser usada para prover um endereçamento parecido com
o da telefonia para os usuários H.323 conectando em seus desktops locais.
De longe, o modo preferido de endereçamento é o alfanumérico no qual o “usuário” é um endereço
definido dentro de uma zona e o gatekeeper.domain é qualificado totalmente como nome de domínio
DNS para resolver qual gatekeeper ao qual o usuário estará registrado [Recomendação H.323 Anexo
O).
Em geral, toda a discagem deveria ser enviada desta forma, pois se trata de uma maneira fácil de usar
a metodologia de resolução de recursos, baseada na Internet, para procura de endereços de
gatekeeper.
Embora esta discagem baseada em DNS seja preferível, ainda existe uma grande necessidade de
suportar discagem numérica, pois aplicações com a discagem baseada em IP nativamente são
poucas. A grande maioria das aplicações de vídeo e voz sobre IP tem uma forte necessidade de ter
interface com a PSTN. A integração estreita com a PSTN será uma característica chave de
implementações de redes IP. Uma rede na qual usuários de vídeo e voz podem ser facilmente
alcançável por telefones analógicos, telefones celulares e terminais H.320 é essencial para a
aceitação para este modelo de comunicação.
Exemplos nos quais a discagem numérica poderia ser usada incluem
1 – Uma discagem de telefonia PSTN em um gateway H.323, usando DID, IVR, ou discagem em uma
zona secundária;
2 – Qualquer telefone IP que tenha somente um painel numérico;
3 – Um sistema H.320 emulando um terminal h.323 em uma rede IP. O sistema h.320 terá somente
capacidade de discagem numérica.
Dentro do contexto do projeto VideNet [Internet Videoconference], eles desenvolveram uma forma de
criar números virtuais, que prestigiam os telefones analógicos, e possibilitam os últimos três casos
apresentados, possam atingir usuários baseados em desktops PCs multimídia.
Neste caso foi desenvolvidos um novo esquema de endereçamento com a seguinte estrutura:
GT-VoIP Relatório I.5
15
A estrutura da string de discagem é como se segue:
SZZZ9G9EEEEE
S: Prefixo de Escape para Zona H.323. O número “0” é definido pelo plano de discagem como prefixo
requerido para todas as discagens fora de seu domínio. Recentemente, Jeff Pulver, tentou padronizar
um número de escape para a Internet, como se fosse um código de país, ou internacional. O código
da Internet é o 87810.
ZZZ: Identificador da Rede ou Sub-Rede. Este é um campo de string de tamanho variável base-9 com
9 dígitos. Ele é derivado do seguinte algoritmo.
o
Obtenha o formato binário do espaço de endereço IP alocado para a subrede sob cujo
controle administrativo do gatekeeper reside. Esta é a porção da rede do endereço IP e é
normalmente derivado pelo mascaramento de um endereço IP com uma máscara de
sub-rede.
o
Delete todos os digitos que estão fora da máscara, deixando somente a porção de rede
do endereço.
o
Anexe no começo um “1” a esquerda desta string. Isto tornará quaisquer zeros
precedentes significativos. Converta este número binário para a base-9.
9: Delimitador. Como o identificador da Rede está no formato base-9, o caracter ‘9’ não aparecerá.
Portanto, isto tornará possível o uso de um delimitador ao final do identificador da Rede.
G: Número do Gatekeeper. Este é um número definido pelo administrador da zona administrativa,
sendo um número variável base-9 cujo número referencia um gatekeeper em particular da rede
apontada pelo identificador de rede, permitindo que múltiplos gatekeeper estejam presentes em uma
certa rede. Esta string pode ser omitida, ou quando aparece estará entre delimitares "9" .
9: Delimitador. Este delimitador aparece ao final do número do gatekeeper.
EEEEE: Número do Ramal Virtual (Extensão). Este número é definido pelo administrador da Zona
H.323 como sendo o ramal virtual ou extensão de um usuário H.323. Ele tem o tamanho variável e
pode ser compatível ou mapeável com o DID ou final do seu número telefônico. Embora os
administradores possam associar com qualquer número que eles escolherem. Este string numérica
pode ser definida com base-10.
ZZZ9G9: Prefixo da Zona Administrativa. Quando observado em conjunto, este número ZZZ9G9
completo significa o Prefixo da Zona Administrativa.
GT-VoIP Relatório I.5
16
Segue um exemplo da Utilização de Números Virtuais:
O seguinte exemplo usa o endereço de rede classe B unc.edu 152.2.x.x e define um Prefixo de Zona
Administrativa para um Gatekeeper cujo número é 1.
Endereço de Rede: 152.2.x.x
Octetos do Endereço de Rede Transformados em Binários: 10011000.00000010
Formato Binário do Endereço de Rede: 1001100000000010
Anexando o 1 no começo: 11001100000000010
Conversão Intermediária para Base 10: 104450
Prefixo na Base 9: 168245
Número do Gatekeeper: 1
Prefixo da Zona Administrativa: 168245919
Versão "legível" da Zona Administrativa: 168 245 919
Número de Extensão do Usuário John: 6101
Número Telefônico Virtual IP do Usuário John = (87810) 168 245 919 6101
Portanto o usuário John tem agora mais uma opção para telefonia, e mobilidade pessoal:
Telephone DID: 919.226.6101
Número de Dígitos do DID mapeado através do Gateway: 4 (ex. ‘6101)
Prefixo da Zona Administrativa H.323: 168 245 919
Extensão H.323: 6101
Número da Telefonia Convencional: (919) 226-6101
Número da Telefonia H.323: (168 245 919) 6101
GT-VoIP Relatório I.5
17