GT-VOIP Relatório I.15

GT-VOIP Relatório I.15:
Ambiente VoIP Piloto - Cenário UFRJ
Março de 2003
Este relatório apresenta a proposta de telefonia baseada na Internet, para a instituição acadêmica da
UFRJ (Universidade Federal do Rio de Janeiro). O propósito principal é atender os usuários da UFRJ
que não são atingidos pelo plano de telefonia convencional da UFRJ, mas que têm cobertura de rede
Internet da UFRJ. Trata-se de um cenário de exemplo, que pode ser utilizado por outras instituições
de ensino no âmbito do piloto VoIP nacional.
RNP/REF/0204
Sinopse
A telefonia baseada na Internet tem sido apontada por diversos pesquisadores, como a opção
tecnológica que irá num futuro não muito distante substituir completamente a antiga rede telefônica
convencional, baseada em comutação de circuito, sem muitas facilidades para o usuário. Assim, o que
estamos verificando hoje em dia, é que a telefonia IP tem tido bastante interesse, mas colocá-la em
produção, é um verdadeiro desafio.
A instituição acadêmica, Universidade Federal do Rio de Janeiro, tem a abertura característica das
universidades, próprias para absorver as novas tecnologias. Neste terreno, encontramos o cenário
ideal para inserirmos este novo paradigma de telecomunicações usando a rede Internet. A idéia é que
os universitários, professores e funcionários da UFRJ usufruam a infra-estrutura da Rede IP da UFRJ
para realizarem suas ligações convencionais.
Assim, neste contexto, foi criada a idéia do cenário de Telefonia IP UFRJ. Primeiramente, para
atender aos órgãos da instituição que não dispõem de conectividade com a rede telefônica digital da
UFRJ, mas que por outro lado tem acesso a rede Internet. E num segundo momento, atender
necessidades do meio acadêmico por telefonia, com outros estados e internacionais e finalmente
reduzir os custos da instituição com ligações telefônicas com celulares locais, entre outros.
Este relatório apresenta este projeto “Cenário UFRJ”, analisando todas as questões referentes (como
aspectos de segurança, contabilização de chamadas, gerenciamento remoto) na proposição da
entrada em produção de um sistema de telefonia totalmente baseado em redes IP nesta comunidade.
GT-VoIP Relatório I.15
2
Sumário
Objetivos Gerais da Telefonia IP na UFRJ
Componentes do Sistema VOIP UFRJ
O Recurso do Auto-Atendimento Eletrônico
Implantação e Testes de IVR em Gateways VoIP Cisco
Proposta de Implementação de IVR Externo
Trabalhos Futuros envolvendo IVRs
Integração com Serviços LDAP
Contabilização das Chamadas
Protocolo RADIUS
Cabeçalhos RADIUS-Accouting
Aspectos de Sincronização e Casos Anômalos
Trabalhos Futuros envolvendo Contabilização de Chamadas
Bibliografia
ANEXOS
Utilizando a telefonia IP da UFRJ
Utilizando a Telefonia IP da UFRJ (Microsoft Netmeeting®)
Configurando o Microsoft Netmeeting
Fazendo uma Chamada VoIP com o Microsoft Netmeeting
Atendendo uma Ligação com o Microsoft Netmeeting®
Recebendo Ligações VoIP via Telefonia Convencional através de IVR
GT-VoIP Relatório I.15
4
5
9
10
11
12
13
14
14
15
17
17
18
19
19
20
24
26
27
28
3
1.
Objetivos Gerais da Telefonia IP na UFRJ
Em um projeto piloto de telefonia IP que se propõe a fazer com que a instituição, gradualmente migre
de um sistema de telefonia baseado em PBXs digitais interconectados, para um sistema de telefonia
baseado em dispositivos Internet ligados via Internet. É preciso traçar diversos objetivos gerais do
funcionamento de tal sistema, bem como montar perfis dos usuários, e validar todos os possíveis
cenários em que estes se encontrarão no uso diário da telefonia IP.
Entre os objetivos gerais do sistema de telefonia IP da UFRJ, podemos enumerar os seguintes:
1) Mobilidade pessoal: Capacidade de realizar a chamada IP sem saber previamente o endereço IP do
usuário. À medida que o usuário chamado mudar de posição (por ex.: rede celular), ou trocar seu
endereço IP (por ex.: Dynamic Host Configuration/DHCP), ele automaticamente vai alterando seus
registros, de modo que ao buscarmos este usuário pelo nome, sempre teremos a sua localização mais
atual;
Neste sentido, a telefonia IP torna fácil a instalação, e locomoção de telefones “virtuais” dentro da
UFRJ. Por exemplo, certo usuário que atende seu ramal “XXXX” normalmente em sua sala, pode em
algum período, estar em outra unidade do campus, ou em uma biblioteca com Internet. Porque não
“capturar” suas ligações, de modo, a ele estar sempre disponível.
Isso é diferente do
redirecionamento de chamadas típico da central telefônica, pois o usuário não precisa configurar o seu
telefone para repassar as ligações para outro telefone.
Outro exemplo da aplicação da mobilidade pessoal no sistema de telefonia IP da UFRJ, seria o caso
do professor, estar ausente da universidade, por causa da apresentação de trabalho cientifico em
congresso externo, e então conectado a rede Internet que ele pudesse realizar e receber chamadas
diretamente do seu ramal “virtual” da universidade.
2) Preço: A diminuição ou eliminação de custo nas ligações de longa distância na telefonia IP é um
fator complementar desejável e que surgirá com a implantação em larga escala de ambientes de
telefonia IP.
O uso da infra-estrutura da Rede Nacional de Pesquisa, cujo backbone IP interliga diversas
instituições acadêmicas, para a realização de ligações de longa distância é um dos objetivos principais
do projeto GT-VOIP. Portanto, para os usuários da UFRJ principalmente os professores, a
possibilidade de realizar suas ligações interestaduais de maneira simples e direta facilita a
colaboração entre grupos de pesquisa geograficamente distantes e também auxilia na comunicação
com fontes patrocinadoras da pesquisa nacional, como o CNPq.
Para o usuário não será mais necessário preencher vários formulários de autorização para realizar tais
ligações, nem é preciso se preocupar com o ônus que tais ligações dão a universidade. Com o
simples uso de um telefone IP, ele pode realizar suas ligações sossegado. Entretanto, o abuso da
utilização do sistema pode gerar um aumento nas ligações locais, principalmente aquelas para
celulares locais, que é considerado um dos maiores gastos de telefonia das instituições de ensino e
pesquisa. Portanto para este tipo de abuso, a solução é limitar, fiscalizar automaticamente e gerar
periodicamente relatórios detalhados dos usuários, de modo que eles possam ter consciência do bom
uso do sistema.
GT-VoIP Relatório I.15
4
2.
Componentes do Sistema VOIP UFRJ
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
GT-VoIP Relatório I.15
5
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
o
o
o
o
o
o
o
o
o
•
1502 Static TCP T.120
1718 Static TCP Gatekeepr Discovery
1719 Static UDP Gatekeeper RAS
1720 Static TCP H323 Call Setup
1731 Static TCP Audio Call Control
8080 Static TCP HTTP Server Push (Optional)
1024-65535 Dynamic UDP H245 Call Parameters
1024-65536 Dynamic UDP RTP (Video Data Streams)
1024-65537 Dynamic UDP RTP (Audio Data Streams)
1024-65538 Dynamic UDP RTCP Controle Information
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
GT-VoIP Relatório I.15
6
o
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
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.
GT-VoIP Relatório I.15
7
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.
•
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.15
8
3.
O Recurso do Auto-Atendimento Eletrônico
Define-se como auto-atendimento eletrônico os sistemas interativos de resposta de voz (IVRs) cujo
propósito é conectar as pessoas, usuárias de telefones convencionais, à serviços online, como
gerenciamento de contas bancárias, pregão da bolsa de valores, helpdesk automático, entre outras
aplicações. Os sistemas IVR empregam uma interface baseada em menus de voz, onde o usuário
interage através do teclado, empregando o uso de DMTF (dual-tone multifrequency) ou até usando a
própria voz, no caso de sistemas de reconhecimento de voz[1].
O uso do IVR permite que a telefonia IP seja implantada como um serviço extra, disponível através de
um ramal dedicado do PBX local, que deve ser acessado de forma explícita pelos usuários. O uso da
telefonia IP dessa maneira evita que PBXs tenham que ser reprogramados para uso transparente da
rede IP, o que pode não ser conveniente ou desejável nesta fase inicial de experimentação. Além do
mais, evita que todos os usuários tenham que ser pré-treinados para operar facilidades como
manipulação de códigos de escape, plano de discagem IP, e operação com segundo tom de
discagem. Com o IVR, um menu interativo, auto-explicativo, ajuda numa transição suave da telefonia
convencional para a baseada em IP, facilitando também o controle de acesso dos usuários ao
sistema.
Neste trabalho foram estudadas duas formas de implementação de sistemas IVR. A primeira
abordagem é baseada em scripts embutidos no próprio gateway (equipamento que realiza a
interoperação entre a Internet a telefonia convencional), enquanto que a segunda trata de um
ambiente IVR externo ao gateway. Fazendo um comparativo entre as abordagens, diz-se que a
primeira é direcionada para uma determinada tecnologia de gateway, pois, neste caso, o gateway teria
que suportar internamente funções de IVR como detecção de DTMFs, interpretadores de comandos,
máquinas de estado e ações de redirecionamento de chamada. Uma vez que a tecnologia está
presente no gateway, a implantação e configuração do ambiente são facilitadas. Apresentaremos a
implantação de um sistema deste tipo na UFRJ, usando um roteador Cisco 2600, com placas de
telefonia analógica VIC e o IOS 12.2(11), com suporte ao sistema TCL IVR 1.0 para desenvolvimento
interno de scripts de auto-atendimento [4].
A segunda proposta, usando IVR externo, é mais independente e libera o gateway do ônus destas
funções específicas, permitindo evolução do serviço IVR sem comprometimento do gateway. Esta
seria a solução indicada para ambientes com gateways VoIP (como por ex. o Alcatel OminiAccess
512) sem suporte a IVR. Neste caso, o gateway deve suportar o redirecionamento através de serviços
suplementares [2][3], ou extensão Facility H.225, para interação com o IVR. Discutiremos a
implantação de um serviço IVR de apoio à telefonia IP na UFRJ e o desenvolvimento de um protótipo
de sistema IVR externo, passível de ser acoplado a gateway VoIP.
GT-VoIP Relatório I.15
9
Implantação e Testes de IVR em Gateways VoIP Cisco
A proposta de extensão IVR no ambiente VoIP baseado em Cisco, chamado de “TCL IVR
Applications”, permite desenvolver aplicações que vão desde o simples redirecionamento de
chamadas, até sistemas complexos de “Call Center” e de VoIP pré-pago, com consultas a código de
acesso do usuário, associação a uma conta corrente do mesmo e verificação se existe saldo
necessário para a realização de cada ligação [4].
Toda esta flexibilidade permite idealizar vários cenários interessantes. Optamos por desenvolver um
script de redirecionamento que pudesse enviar ligações da telefonia convencional da UFRJ para
usuários que estão conectados ao backbone IP da UFRJ, mas não atendidos por ramal telefônico do
PBX. Com o apoio do IVR, estes usuários podem ser acessados por “ramais virtuais”, através de
clientes H.323 rodando em desktops multimídia.
A figura 1 apresenta a arquitetura deste sistema. Quando um usuário no ramal #3354 deseja falar com
o “ramal virtual 4001”, ele dispara uma ligação para o sistema de telefonia IP da UFRJ, programado
para o ramal #4000. Esta ligação segue até as interfaces analógicas FXO do gateway e é atendida
automaticamente pelo programa IVR associado. Este programa toca uma mensagem de boas-vindas,
e pede ao usuário para discar o “ramal virtual” desejado. O usuário então disca #4001. O gateway
consulta seu plano de discagem. Verifica que o número se enquadra na regra 4XXX, anexa um prefixo
de “número virtual” [5] e faz uma busca ARQ ao gatekeeper por este número. O gatekeeper, por sua
vez, que já tem cadastrado em sua tabela o endereço da estação multimídia chamada, faz a ligação
para a estação remota.
Gatekeeper
PC Multimídia
02125984001
Ramal #3354
Plano de Discagem
(Gatekeeper)
02125984001 - PC
Multimídia
LAN
Interfaces
FXO
PBX
Mapeadas
no Ramal
4000
Figura 1 - Cenário IVR
Interno e Relacionamento
com Ambiente H.323
Cisco 2600
c/ TCL IVR
Plano de Discagem
(Gateway)
4 XXX - converte p/
0212598 4 XXX
Procurar no Gatekeeper
Para construir este ambiente, desenvolvemos um script TCL IVR contendo basicamente as primitivas
acceptCall (aceitação da chamada vinda do PBX), promptAndCollect (apresenta um arquivo de áudio
e logo depois coleta dígitos DTMFs – com possibilidade de escape durante a apresentação) e
placeCall (usando os dígitos coletados para criar uma chamada para o destino). Também foi usada
uma máquina de estados contendo eventos como “conexão ativa”, “enviando a chamada” e “falha”.
Entre as dificuldades enfrentadas, podemos relatar que os scripts TCL IVR só funcionam quando
“assinados” com a ferramenta lockScript da Cisco, cuja única versão disponível é para plataforma
GT-VoIP Relatório I.15
10
Solaris, ou, alternativamente, pelo uso da opção de desativação de assinaturas com o comando “test
voip scripts” [6]. No nosso ambiente, utilizamos a ferramenta lockScript para resolver este problema.
Outra característica associada à plataforma Solaris é o formato dos arquivos de áudio, que contém as
mensagens de voz para os usuários. O TCL IVR usa somente arquivos com extensão “.au”, sendo
esta extensão associada a áudio gerado em Solaris. Por isso, também gravamos nossos próprios
arquivos de áudio em estação Solaris com microfone. No futuro, usaremos outras ferramentas para
converter os formatos.
Seguindo a descrição de problemas, podemos mencionar a dificuldade em detecção de erros neste
ambiente. Apesar do comando “debug voip ivr” estar ativado, a interpretação do log gerado tornou-se
penosa, devido à enorme quantidade e velocidade com que as informações são apresentadas, e à
falta de documentação descritiva sobre o significado das linhas geradas pelo depurador. (Tabela 1).
Nov 28 00:45:18.441: App ivr_ufrj: Handling callID 52
Nov 28 00:45:18.441: callingNumber=, calledNumber=5521, redirectNumber=
Nov 28 00:45:18.441: accountNumber=,guid=1acb.27d8.98f4.006b.0000.0000.2071.a5e8
Nov 28 00:45:18.441: peer_tag=12
Nov 28 00:45:18.441: ccCallHandoff (callID=0x34)
Nov 28 00:45:18.445: :/acceptCall/
Tabela 1 – Saída do debug voip ivr após o teste de uma ligação
Uma vez finalizado o desenvolvimento do script, tratamos de integrá-lo a um ambiente H.323. Para
tanto, utilizamos um plano de discagem no gateway baseado em dial-peers (Cisco). Neste plano,
quando o usuário disca um número de “ramal virtual”, este número casa com o padrão 4XXX,
recebendo um prefixo e sendo pesquisado no gatekeeper (gnugk [7]), que tem a localização daquele
telefone IP.
Proposta de Implementação de IVR Externo
No laboratório VoIP, têm sido feitos testes de homologação com gateways de diversos fabricantes e a
presença de um sistema IVR embutido não é uma característica usual. Por exemplo, o equipamento
Alcatel OmniAccess 512 com placas VoIP não apresenta tais características, muito menos produtos
da Planet ou Huawei. Considerando a importância da replicação do cenário com IVR para acesso
suave à rede VoIP, estamos desenvolvendo uma solução de um sistema IVR externo, com
capacidade de redirecionamento de chamada, conforme mostrado na Figura 2.
Neste segundo ambiente, aparece a figura de associação direta entre uma interface de telefonia com
um dispositivo remoto. Isso é chamado PLAR (Private-line automatic ringdown). Ela provê um
mecanismo onde, quando a linha estiver no estado off-hook, o telefone remoto vai ser chamado sem
que nenhum digito adicional tenha sido digitado. A maioria dos gateways VoIP implementa esta
funcionalidade.
GT-VoIP Relatório I.15
11
Gatekeeper
PC Multimídia
02125984001
Plano de Discagem
(Gatekeeper)
02125984001 - PC
Multimídia
Ramal #3354
LAN
Interfaces
FXO
PBX
Mapeadas
no Ramal
4000
Figura 2 - Cenário IVR
Externo e Relacionamento
com Ambiente H.323
Alcatel OA512
Plano de Discagem
(Gateway)
PLAR para o IVR
Externo
DTMF
IVR Externo
c/ Serviço Suplementar
Captura DTMF
Pesquisa Gatekeeper
Transfere Chamada
A implementação do IVR externo requer uma conjunção de comportamentos. O IVR externo deve
permitir criar múltiplas instâncias de serviço. Ele deve conter todo o mecanismo para identificação dos
DTMFs, sejam eles enviados via H.245 Alphanumeric IE, ou H.245 Signal IE. Esta máquina IVR
externa deve suportar uma linguagem de script flexível para o desenvolvimento das aplicações. Uma
linguagem que está sendo bastante utilizada neste contexto é o VoiceXML, onde são desenvolvidos
grafos de decisão contendo os diálogos (arquivo de áudio) e as ações. Tanto o gateway, como o IVR
deve obrigatoriamente suportar ou o serviço suplementar H.450.2 [3] de transferência de chamada ou
a facilidade específica da sinalização H.225 (facilityreason: callforwarded) [9], para que a mídia de
áudio possa ser redirecionada ao destino.
Trabalhos Futuros
Este trabalho abrange os sistemas de auto-atendimento baseados em diálogos de voz e interação
com o usuário sendo implantados para formar um ambiente amigável de auto-atendimento, visando
facilitar o uso da telefonia Internet na UFRJ. Das duas propostas de IVR para viabilizar tal projeto, uma
delas já está em funcionamento. A outra está sendo efetivada com o desenvolvimento da solução com
IVR externo. A opção para fazer isto é usar programas de código aberto como o OpenIVR, do projeto
OpenH323 [8], que utiliza-se de scripts VoiceXML para atuar, e integrar, nesse programa, os serviços
suplementares. A maioria destes serviços, já padronizados pela ITU-T, estão disponíveis na
OpenH323. Testes complementares devem ser conduzidos com o uso de interfaces digitais E1, pois
estas darão maior abrangência ao sistema, visto que cada aplicação TCL IVR é executada
concorrentemente por cada canal de telefonia.
Uma proposta de cooperação possível é unir esforços entre o GT-VOIP e o GT-Diretórios no sentido
de estender este ambiente de acesso, com a criação de senhas para os usuários, categorias de
acesso para os mesmos, e um crédito virtual pré-alocado para o bom uso do sistema pelos usuários.
Isto seria possível através da integração entre IVR, um servidor de autenticação como o RADIUS e um
serviço de diretórios LDAP. Nesta base LDAP nacional, os usuários estariam sendo autenticados
dependendo de sua posição na universidade, seja como professores, alunos, ou funcionários. Assim,
quando alguém discar para o ramal do serviço VoIP nacional automaticamente estaria sendo
identificado pelo seu código, e checada a sua senha perante esta base, bem como as condições de
uso de VoIP.
GT-VoIP Relatório I.15
12
4.
Integração com Serviços LDAP
Para o caso de VOIP, o processo de localização e autenticação está normalmente embutido na
sinalização. Questões de negociação de quem paga a chamada, chamada a cobrar etc devem estar
resolvidas dentro das primitivas de serviço de sinalização. Ou poderia ser resolvida através de
middleware geral, assumindo que caso uma pessoa não seja achada para estabelecimento de uma
conversa interativa, automaticamente se poderia fornecer a opção do envio de uma mensagem de
texto ou de voz. Neste envio, o e-mail da pessoa pode não ser necessário, pois quem faria o envio da
mensagem seria o sistema de gerenciamento de usuários acionado quando da tentativa de
localização do usuário de voz. Seria interessante ter esta facilidade, ou simplesmente, ao invés de
retornar o sinal de ocupado ou usuário não encontrado ou registrado, retornar o e-mail do usuário.
Essa forma mais simples é outra possibilidade, mas certamente bem viável na medida que um
diretório LDAP armazena todas as informações de uma pessoa, incluindo permissões de acesso a
telefonia normal, VOIP, e-mail, etc.
Ações nesse sentido têm sido abordadas tanto por Videnet como por Shiboleth. Mas pode ser que o
interfaceamento com VOIP não tenha sido explorado a fundo. O mundo SIP tem apresentado a
integração direta com DNS e vai aparecer em curto prazo propostas de extensão dessa integração
com diretórios de uma forma mais ampla. É preciso fazer um levantamento rápido e abrangente que
servirá de base para uma proposta VoIP Nacional. Lembrando que a integração de soluções para SIP
e H.323 deve estar sempre em foco. Existe uma interação do uso de diretório com cenários aonde
podemos alocar a uma pessoa um crédito virtual para uso do sistema, que seria descontado a cada
chamada, dependendo do tipo e duração da chamada. Cenários desse tipo podem ser imaginados,
ainda que a cobrança pelo uso do VOIP seja apenas virtual. Mas imaginar que temos um atarifação de
uso em andamento pode servir de base para projeções futuras. Um pré pago VOIP virtual poderia ser
imaginado. Acho que podemos usar a criatividade e imaginar como suportaríamos a coleta de uso em
vários cenários. Soluções poderiam ser encaminhadas e alguns desses cenários eventualmente
implemenentados. Contabilidade de uso é assunto do Peixoto e pode ter interação com LDAP,
dependendo do cenário. Se a contabilidade de uso coletar o uso do PBX, então podemos realizar um
cenário complexo, com relatórios de controle e uso interessantes, crédito virtual pré alocado, etc. O
cenário fica mais complexo quando imaginamos que o serviço VOIP possa ser visto como um serviço
comum para todos no Piloto, e, estando numa determinada instituição, possa usar o serviço de lá
descontando em meus créditos virtuais armazenados e guardados na UFRJ. Contabilidade de créditos
entre instituições pode ocorrer. Acho que temos a possibilidade de propor alguma coisa interessante
neste sentido, talvez reproduzindo experiências de outras áreas, como a celular.
No cenário VOIP na RNP, podemos ter usuários na UFRJ que são de classes diferentes: professores,
administrativos, terceirizados, empresas no campus, etc. Cada um destes indivíduos terá tratamento
diferenciado, eventualmente. A implementação do tratamento diferenciada tem que ser pensada e
organizada num framework que envolve também plano de numeração e arquitetura de gateways e
gatekeepers, e cuja implementação é afetada pelos recursos de sinalização, filtros, IVRs, permissões,
listas de acesso, etc. Não podemos esquecer que temos que ter uma arquitetura VOIP completa, para
que o impacto na evolução dos serviços possa ser avaliado. A estrutura de operação dos DGKs e
como deve ser estabelecida a operação peer a peer deve ser definida e possíveis extensões
identificadas. Por exemplo, o uso de grupo multicast ou registro dinâmico. O GnuGK tem que ser
avaliado a fundo, pois ele será a base de operação dos sevriços. Aliás, todos devem estar na lista de
discussão do grupo OpenH.323 e acompanhar os temas e questões em debate.
GT-VoIP Relatório I.15
13
5.
Contabilização das Chamadas
Uma das importantes demandas do piloto é que, com o aumento da utilização de VoIP e a aplicação
de priorização para diferenciar tal tráfego na rede, torna-se necessário manter um sistema de
monitoramento das ligações em produção. Com este sistema, é possível verificar o nível de acesso ao
serviço, e auxiliar na verificação da demanda de utilização do mesmo, tornando-se ferramenta útil para
planejamento de expansões do sistema VoIP nacional.
Alguns requisitos são fundamentais para este sistema. Robustez, onde no caso do servidor de
contabilização apresentar uma falha, deveria estar previsto outro servidor redundante. A idéia, neste
caso, é que não sejam perdidos os registros da chamada, comumente apelidados de bilhetes na
telefonia convencional. Outro requisito é a confiabilidade no envio dos pacotes contendo os bilhetes ao
servidor. É importante ressaltar que os bilhetes são o insumo básico do sistema de contabilização; é
através destes bilhetes que podemos apresentar três tipos de informação: utilização do sistema,
relatórios operacionais de falhas e relatórios sobre o dimensionamento.
Neste trabalho, descreveremos um estudo realizado sobre a contabilização de chamadas IP usando
cliente/servidor RADIUS (Remote Authentication Dial In User Service) [10], visto sua aderência aos
requisitos citados. Também detalharemos as mensagens de contabilização, sejam elas padronizadas
ou específicas de um fabricante (VSAs - Vendor Specific Attributes). No experimento realizado foi
utilizado um gateway Cisco 2600. O IOS testado 12.2(11) tem a capacidade de atuar como cliente
RADIUS, e enviar informações de bilhetagem chamadas de CDRs (Call Detail Records) para um
servidor RADIUS. A implementação de servidor RADIUS adotada para estes testes foi o FreeRadius
[11].
Protocolo RADIUS
Trata-se de um protocolo de autenticação entre um servidor de acesso (NAS) e um serviço
compartilhado, muito comum no gerenciamento de acesso discado de provedores Internet. O
protocolo utiliza UDP como transporte (portas 1812 e 1813). Tem a característica de prover
redundância de servidores, permitindo uma rápida mudança de servidor de autenticação no caso de
falha. O protocolo também segue uma arquitetura cliente-servidor, onde o cliente RADIUS monta as
mensagens para serem enviadas ao servidor RADIUS.
Estas mensagens podem ser:
•
Access-Request, enviada para solicitar um serviço;
•
Access-Accept, aceitação do serviço;
•
Access-Reject, rejeição do pedido do serviço;
•
Access-Accounting, contabilização do serviço, que no nosso caso é o tipo mais importante.
Quando um cliente RADIUS, embutido no gateway VoIP, for configurado para usar a metodologia de
contabilização [12], ele inicia o serviço gerando uma mensagem “Accounting Start”. Esta mensagem
descreve qual tipo de serviço será usado, quem está realizando aquela ligação, para quem se destina,
e qual trecho da ligação está sendo monitorado (trecho VoIP ou PSTN, considerando a ligação que
passa por um gateway tem os dois trechos, ou call-legs). Este cliente então envia esta mensagem
para o servidor que por sua vez confirma a sua recepção. No final do uso do serviço VoIP, o cliente
gera uma mensagem “Accounting Stop”, descrevendo as mesmas informações do pacote Start, e
opcionalmente estatísticas sobre o tempo de uso, quantidade de pacotes de entrada e saída, entre
outras. Novamente este pacote será enviado para o servidor RADIUS, que também confirma sua
recepção (Figura 1).
GT-VoIP Relatório I.15
14
Servidor
RADIUS
Call-Leg VoIP
Início da Chamada:
(1) - Cliente H.323 Inicia uma Chamada VoIP
(2) - Contabiliza o start no call-leg VoIP
(3) - Interface de Telefonia inicia chamada
para o ramal desejado
(4) - Contabiliza o start no call-leg PSTN
Call-Leg PSTN
Final da Chamada:
(5) - Ramal Telefônica colocado no gancho
finaliza a Chamada VoIP
(6) - Contabiliza o stop no call-leg PSTN
(7) - Interface de Rede sinaliza para o cliente
H.323 o final da chamada
(8) - Contabiliza o stop no call-leg VoIP
2 4
8 6
1
PC Multimídia
c/ Cliente H.323
Figura - 1
3
7
Obs.: Todas as mensagens
entre cliente e servidor
RADIUS são confirmadas
Ramal
5
Central Telefônica
Roteador Cisco 2600
c/ cliente RADIUS embutido
As requisições de contabilização (tanto start quanto stop) são submetidas ao servidor RADIUS pela
rede. Portanto, o cliente RADIUS deve continuar re-enviando a mensagem de contabilização após um
certo tempo, até que ela seja recebida e confirmada pelo servidor. Se nenhuma resposta for recebida
após este número de vezes de retransmissão, o cliente passa a redirecionar suas mensagens para um
servidor alternativo.
Os registros start não têm por definição os detalhes do tempo de conexão necessários para o sistema
de contabilidade, pois a ligação ainda não foi atendida. Portanto, toda informação detalhada está
contida nos registros stop. No caso da implementação Cisco, é possível trabalhar com as duas formas
tanto start-stop quanto stop-only. Enquanto a segunda (stop-only) vai atender relativamente bem os
registros de ligações completadas, conectadas e desconectadas. No caso em que a ligação não se
completa, é com base na mensagem start que descobrimos a taxa de erro, ou de troncos ocupados de
nosso sistema [13].
Cabeçalhos RADIUS-Accouting
Detalhando um pouco os cabeçalhos do protocolo RADIUS, podemos dizer que existem alguns
cabeçalhos padronizados, como o Acct-Session-Id (valor 44), e outros específicos dos fabricantes, os
chamados VSA (Vendor-Specific Attribute). Tais cabeçalhos podem ser interpretados apropriadamente
no servidor RADIUS através do uso de dicionários que contém a sintaxe daquelas mensagens. No
caso do gateway Cisco, ele possui várias mensagens VSAs, que podem ser embutidas em uma
mensagem padronizada Acct-Session-Id, quando estivermos trabalhando com servidor RADIUS que
não suporte VSAs.
Alguns cabeçalhos importantes são mostrados na tabela abaixo. É importante observar que cada
trecho da ligação é chamado de "call-leg". Portanto para analisar uma ligação completa passando pelo
gateway, é preciso checar os dois call-legs (VoIP e PSTN) que contenham o mesmo h323-conf-id.
GT-VoIP Relatório I.15
15
Mensagem Start Resumida (Call-Leg VoIP)
Mensagem Stop Resumida (Call-Leg VoIP)
Called-Station-Id = 552125983354
Acct-Status-Type = Start
h323-conf-id = 4A879FA1 AFB41E41
9521908B 17373FDC
h323-call-origin = answer
h323-call-type = VoIP
Called-Station-Id = 552125983354
Acct-Status-Type = Stop
h323-conf-id = 4A879FA1 AFB41E41 9521908B
17373FDC
h323-call-origin = answer
h323-call-type = VoIP
h323-connect-time = 16:58:09.760 BRDT Mon Nov
25 2002
h323-disconnect-time = 17:12:09.760 BRDT Mon
Nov 25 2002
h323-disconnect-cause = 10
h323-remote-address = 146.164.247.206
•
•
•
•
•
•
•
•
Acct-Status-Type: diz se a mensagem é do tipo start ou stop;
h323-conf-id: chave que descreve uma ligação completa. O valor que for encontrado no call-leg
da telefonia convencional será o mesmo no lado da telefonia IP.
h323-call-origin: esta é a visão do cliente RADIUS embutido no roteador Cisco 2600, em relação a
ligação. Quando ele estiver respondendo uma ligação que está vindo da Internet o valor será
answer, se estiver originando uma ligação será origin.
h323-call-type: qual trecho está sendo usado, o trecho Internet ou telefonia pública.
h323-connect-time: a hora precisa da aceitação da ligação. A partir deste momento os fluxos de
mídia podem ser iniciados, portanto, este é o momento do início da ligação;
h323-disconnect-time: a hora exata da finalização da ligação. Registra o fim da mesma;
h323-disconnect-cause: código de desconexão. No exemplo acima, o valor 10 significa que a
desconexão foi normal, porém poderíamos ter outros tipos de desconexão, por exemplo, com a
queda de um link;
h323-remote-address: o endereço IP do cliente H.323 que iniciou a chamada.
No caso das mensagens VSAs Cisco, além destes valores H.323 mais comuns apresentados, temos
outros que trazem alguma informação adicional sobre a qualidade de serviço de uma chamada
monitorada.
VSA Cisco com Informações sobre a Qualidade da Ligação (exemplo):
vad-enable=true: indica se VAD (Voice Activity Detection) foi habilitada.
codec-bytes=160: especifica o tamanho do payload do pacote de voz.
coder-type-rate= g729abr8: indica o codificador negociado e sua taxa.
receive-delay= 25 ms: indica o tempo médio do buffer de playout mais a latência do decoder.
round-trip-delay= 2 ms: atraso de ida e volta entre o sistema local e o remoto no backbone.
hiwater-playout-delay=67ms: indica o tempo máximo que o buffer de playout obteve durante aquela
chamada.
late-packets=0: número de pacotes recebidos que chegaram muito tarde para serem tocados pelo
decodificador durante a chamada.
lost-packets=1: número de pacotes perdidos durante a chamada.
h323-voice-quality=5: Valor representando pelo cálculo da degradação da qualidade da voz (ICPIF)
[4] da conexão, provida pelos processadores de sinal digital. Os números pequenos representam a
melhor qualidade.
noise-level= -74. Nível médio de ruído da chamada (Em dBm).
GT-VoIP Relatório I.15
16
Aspectos de Sincronização e Casos Anômalos
Para poder armazenar registros com o tempo exato de conexão e desconexão, torna-se necessário
que o gateway implemente funcionalidades de sincronização de relógio através do Network Time
Protocol (NTP). Um manual sobre como implementar essa configuração está disponível em [6].
Outro cuidado que os administradores do serviço VoIP devem ter é com a possibilidade dos casos de
bilhetagem excepcionais. Em certos cenários, onde o servidor RADIUS não receber uma resposta do
cliente em uma janela de tempo, ele não enviará a confirmação, forçando o cliente a enviar registros
novamente. Algumas vezes, estes registros da chamada poderão ficar duplicados. A única diferença
entre estes registros duplicados é o par AV (Attribute-Value) Acct-Delay-Time. Nos registros
duplicados o valor Acct-Delay-Time é incrementado (sendo o primeiro valor de Acct-Delay-Time = 0),
todos os outros campos permanecem os mesmos. É de responsabilidade da aplicação de
contabilização descartar estes pacotes duplicados quando da exibição dos resultados.
Trabalhos Futuros
Este trabalho demonstra uma implementação de um sistema de contabilização de chamadas baseado
em um ambiente RADIUS. Atualmente, esta configuração já está em produção no gateway do
laboratório de VoIP da UFRJ. Como proposta de trabalhos futuros, pretendemos desenvolver uma
interface de visualização das chamadas realizadas, bem como apresentar da melhor maneira possível
as informações presentes nas VSAs de qualidade de serviço. Esperamos que este ferramental possa
fazer parte de um sistema de gerência VoIP nacional amplo, com suporte também a informações
disponíveis em MIBs, e o acesso a uma base de bilhetagem centralizada.
GT-VoIP Relatório I.15
17
Bibliografia
[1] Speech-Enabled Interactive Voice Response Systems. Tutorial do International Engineering
Consortium Website. http://www.iec.org/online/tutorials/speech_enabled/
[2] ITU-T Recommendation H.450.1. Generic functional protocol for the support of supplementary
services in H.323. Genova, Suiça. 1997.
[3] ITU-T Recommendation H.450.2. Call Transfer Supplementary Service for H.323. Genova,
Suiça, 1997.
[4] Davidson, J. e Fox T. Deploying Cisco Voice over IP Solutions. Cap. 10.Cisco Press, 2002.
[5]
Proposta
de
Plano
de
Discagem
VoIP
Nacional.
Website
VoIP/UFRJ.
http://www.voip.nce.ufrj.br/index_dialplan_pt.htm. Último Acesso em 28/03/2003.
[6] TCLWare Frequently Asked Questions. Cisco Systems Website. http://www.cisco.com.
Document ID: 17762. Último Acesso em 28/03/2003.
[7] GnuGK – GNU Gatekeeper. http://www.gnugk.org. Último Acesso em 27/03/03.
[8] Projeto OpenH323 – http://www.openh323.org. Último Acesso em 29/03/03.
[9] ITU-T Recommendation H.225. Call Signaling Protocols and Media Stream Media
Packetization for Packet-Based Multimedia Communication Systems. Genova, Suiça. 2001.
[10] IETF RFC 2138. "Remote Authentication Dial In User Service (RADIUS)". Abril, 1997.
[11] Website do Projeto de Servidor FreeRADIUS. http://www.freeradius.org/. Último Acesso em
28/03/2003.
[12] IETF RFC 2139. "RADIUS Accounting". Abril, 1997.
[13] ITU-T Recommendation G.113. ICPIF Transmission impairments due to speech processing.
Genebra, Suíça, 2000.
[14] Huff, Ted. Configuration Guide for AAA Billing Features in Cisco Voice-enabled Routers and
Access
Servers.
Out,
1997.
Obtido
no
Site
da
AARNet.
http://www.aarnet.edu.au/services/voip/index.html
[15] Implementando o serviço NTP na sua rede local. CAIS - Centro de Atendimento a Incidentes
de
Segurança
da
RNP.
Agosto
2000.
Último
Acesso
em
31/03/2003.
http://www.rnp.br/cais/ntp/manual_ntp_v1b.pdf
GT-VoIP Relatório I.15
18
8.
ANEXOS
Utilizando a telefonia IP da UFRJ
O sistema experimental de telefonia IP da UFRJ possibilita aos usuários o acesso ao sistema
telefônico atual através de ramais virtuais cedidos pelo VoIP a um determinado usuário e associado a
um computador. Um ramal virtual é um número de quatro dígitos diferente dos ramais já existentes na
UFRJ (ramais reais). O sistema VoIP (Voice Over IP) oferece aos seus usuários a comunicação com
qualquer outro ramal virtual, ramal real e até mesmo telefones externos à UFRJ.
•
Requisitos necessários:
É necessário ter um microcomputador com o sistema operacional MS-Windows® equipado de
multimídia (placa de som, caixas de som e microfone) e com o MS-NetMeeting® instalado e
configurado.
Como funciona:
O sistema VoIP está baseado no uso de duas tecnologias:
1. GateKeeper: Registra os usuários no sistema e gerencia as chamadas.
2. IVR (Interactive Voice Response): O IVR atende a chamada, toca uma mensagem de boasvindas e solicita que se digite o ramal do usuário.
GT-VoIP Relatório I.15
19
Utilizando a Telefonia IP da UFRJ através do Microsoft Netmeeting®
•
Instalando o MS-Netmeeting para MS-Windows 98® ou MS-Windows Me®
Com o MS-Windows 98® ou MS-Windows Me® já carregado clique em iniciar, configurações,
painel de controle, adicionar ou remover programas. Selecione a guia instalação do windows, em
seguida clique em comunicações.
Instalando o MS-NetMeeting® - 1
Clique em detalhes e marque a opção NetMeeting. Clique em OK. Será solicitado o CD de instalação
do MS-Windows. Reinicie o computador se necessário.
Instalando o MS-NetMeeting® - 2
GT-VoIP Relatório I.15
20
Clique em iniciar, executar, digite “conf” sem aspas e clique OK. A janela de configuração do MSNetMeeting® irá se abrir. Clique em avançar.
Configurando o MS-NetMeeting®
Preencha as informações solicitadas.
Configurando o MS-NetMeeting®
GT-VoIP Relatório I.15
21
Desmarque a opção efetuar logon em servidor de diretório, clique em avançar, escolha o seu tipo de
conexão, clique em avançar, avançar de novo e de novo.
Configurando o MS-NetMeeting®
Configurando o MS-NetMeeting®
GT-VoIP Relatório I.15
22
Agora começa o teste de áudio, clique em testar e depois avançar. O próximo teste é do microfone,
clique avançar e concluir.
Configurando o MS-NetMeeting®
GT-VoIP Relatório I.15
23
Configurando o Microsoft Netmeeting para a Telefonia IP da UFRJ
Depois de ter feito a instalação do MS-NetMeeting®, é necessário que você se registre no GateKeeper
UFRJ, para isso é preciso seguir as etapas abaixo:
1.
2.
Abra o MS-NetMeeting®
No menu ferramentas, aponte para opções
Configurando o MS-NetMeeting®
3.
Na guia geral, preencha seus dados (nome, sobrenome, e-mail)
Configurando o MS-NetMeeting®
4.
5.
6.
Clique no botão chamada avançada
Seleciona a opção use um GateKeeper para fazer chamadas
Em GateKeeper digite: gatekeeper.voip.nce.ufrj.br
GT-VoIP Relatório I.15
24
7.
8.
9.
10.
11.
12.
Selecione a opção efetuar logon usando o meu nome de conta
Em nome da conta digite o seu nome
Selecione efetuar logon usando meu número de telefone
Em telefone digite o seu ramal virtual (550212598 + o ramal virtual)
Clique em OK
Clique em OK de novo
Configurando o GateKeeper UFRJ
Veja o ícone no canto do MS-Netmeeting®, se ele estiver azul, você está conectado. Caso
contrário, clique em chamar e depois em efetuar logon em vitoria.voip.nce.ufrj.br. (OBS.: Substitua
vitoria.voip.nce.ufrj.br por gatekeeper.voip.nce.ufrj.br)
Indicação que você está conectado ao GateKeeper UFRJ
GT-VoIP Relatório I.15
25
Fazendo uma Chamada VoIP com o Microsoft Netmeeting
Para fazer uma ligação você deve digitar o ramal virtual da pessoa que você deseja chamar e clicar
em chamar (ícone com um telefone ao lado). Para finalizar essa chamada basta clicar no botão com o
fone do telefone e uma seta para baixo.
Fazendo uma chamada
Uma outra maneira de chamar uma pessoa é pelo nome. Você deve escrever o nome da pessoa que
você quer falar e clicar em chamar. Esse procedimento é válido somente quando se chama uma outra
pessoa do sistema VoIP.
Para ligar para um ramal da UFRJ é preciso digitar 55212598 + o ramal de quatro dígitos.
Para fazer uma ligação para fora da UFRJ você deve digitar 5521 + o número de oito dígitos.
Atenção: O sistema VoIP não realiza chamadas interurbanas ou internacionais.
GT-VoIP Relatório I.15
26
Atendendo uma Ligação com o Microsoft Netmeeting®
Você pode escolher entre atender uma chamada ou ignorá-la, bastando clicar em um dos
respectivos botões abaixo.
Atendendo uma chamada
Quando você aceita uma chamada, você e a pessoa que te ligou estão em uma ligação, como fica
identificado na barra inferior do MS-NetMeeting®.
Em uma chamada
É possível ajustar o volume do microfone e da caixa de som pelo botão .
Alterando o volume
GT-VoIP Relatório I.15
27
Recebendo Ligações VoIP via Telefonia Convencional através de IVR
Para que uma pessoa possa ligar para você é preciso que ela saiba o número do VoIP mais o seu
ramal virtual. O procedimento é descrito dessa forma:
1.
2.
3.
4.
Liga-se para o número do VoIP
Escuta a mensagem de saudação
Digita o ramal virtual desejado
Espera a pessoa atender ou desliga se estiver ocupado
O número do Auto-Atendimento Eletrônico VoIP da UFRJ é
2598- 3191
GT-VoIP Relatório I.15
28