Proposta de Numeração VoIP Nacional

Transcrição

1 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

2 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

3 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) 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 GT-VoIP Relatório I.5 3

4 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

5 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, Voic ). 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 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 Dynamic UDP H245 Call Parameters o Dynamic UDP RTP (Video Data Streams) o Dynamic UDP RTP (Audio Data Streams) o Dynamic UDP RTCP Controle Information GT-VoIP Relatório I.5 5

6 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 (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. o 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

7 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

8 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

9 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

10 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

11 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

12 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 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 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 : XXXX -> 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 XXXX, 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

13 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

14 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

15 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 user@gatekeeper.domain. 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

16 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 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

17 Segue um exemplo da Utilização de Números Virtuais: O seguinte exemplo usa o endereço de rede classe B unc.edu x.x e define um Prefixo de Zona Administrativa para um Gatekeeper cujo número é 1. Endereço de Rede: x.x Octetos do Endereço de Rede Transformados em Binários: Formato Binário do Endereço de Rede: Anexando o 1 no começo: Conversão Intermediária para Base 10: Prefixo na Base 9: Número do Gatekeeper: 1 Prefixo da Zona Administrativa: Versão "legível" da Zona Administrativa: Número de Extensão do Usuário John: 6101 Número Telefônico Virtual IP do Usuário John = (87810) Portanto o usuário John tem agora mais uma opção para telefonia, e mobilidade pessoal: Telephone DID: Número de Dígitos do DID mapeado através do Gateway: 4 (ex. 6101) Prefixo da Zona Administrativa H.323: Extensão H.323: 6101 Número da Telefonia Convencional: (919) Número da Telefonia H.323: ( ) 6101 GT-VoIP Relatório I.5 17