Instalando e Configurando o PBX-IP Do Fone@RNP

Sumário

Sumário Capítulo 01 - Apresentação Apresenta brevemente a RNP, os serviços avançados e o fone@RNP. Apresenta o processo de adesão

Capítulo 02 - Introdução à telefonia Apresenta um breve histórico da tecnologia e as características relevantes sobre telefonia, úteis para o planejamento do serviço de voz.

Capítulo 03 - Introdução à VoIP Apresenta as tecnologias e principais protocolos que dão suporte ao serviço fone@RNP. SIP, SDP, RTP, CODECs, VoIP, Gateway, Proxies, etc....

Capítulo 04 - Arquitetura do fone@RNP v.2012 Apresenta como o serviço foi pensado. Enumera e define cada componente da solução: as “caixinhas” do serviço. Apresenta todos os hardwares utilizados na solução.

Capítulo 05 - Gateway Transparente (GWT) Gateway Transparente (GWT) 2.0 Roteiro de instalação e configuração do GWT, de acordo com material já desenvolvido. Gateway Transparente Analógico Equipamento CIP850, Intelbrás

Capítulo 06 - O SIP Router Local (SRL) Apresenta o SRL. Ensina a instalar e operar o SRL.

Capítulo 07 - O PBX IP Corporativo Apresenta os PBX IP Corporativo. Ensina a instalar e operar os PBX IP.

Capítulo 08 - PBX IP Acadêmico Apresenta o PBX IP Acadêmico com roteiro de instalação e configuração, incluindo integração com CAFe

Capítulo 09 - Casos de uso Apresenta 8 cenários prováveis de uso do fone@RNP

Capítulo 10 - Estatísticas Apresenta o Sistema de Estatísticas Nacionais e as estatísticas de cada módulo do fone@RNP.

Serviço fone@RNP v.2012 Manual do serviço de telefonia IP da RNP

2

Sumário

Anexos 1. 2. 3. 4. 5. 6. 7. 8. 9.

Planejamento para instalação do fone@RNP Configuração de Firewall Instalação Manual do SRL Caderno de testes Formulário Técnico – Levantamento de informação Ajuste de temporização do R2 Instalação do GWT com servidor + placas + kommuter Expressões Regulares A MIB Estendida do fone@RNP

Abreviações CDR DNS GWT GWT-a ICMP IP NTP PABX PBX POTS PSTN RTCP RTFC RTP SBC SDP SIP SNMP SRC SRL SRTP TCP ToIP UDP VoIP

Call Detail Record (Detalhamento dos Registros de Chamadas) Domain Name System Gateway Transparente Gateway Transparente Analógico Internet Control Message Protocol Internet Protocol Network Time Protocol Public Automatic Branch Exchange Public Branch Exchange Public Old Telephony Service (utilizada como sinônimo de da rede analógica) Public Switched Telephony Network RTP Control Protocol Rede de Telefonia Fixo Comutada Realtime Transport Protocol Session Border Controller Session Description Protocol Session Initiation Protocol Simple Network Management Protocol SIP Router Central SIP Router Local Secure RTP Transmission Control Protocol Telephony over IP (Telefonia sobre IP) User Datagram Protocol Voice over IP (Voz sobre IP)


3

Sumário


4

Capítulo 01

Apresentação

Serviço fone@RNP v.2012

Manual do serviço de telefonia IP da RNP

Capítulo 1 – Apresentação Sobre o curso O curso “Serviço fone@RNP v.2012” é uma atualização do curso “Serviço fone@RNP”. Este curso apresenta o serviço de telefonia IP da RNP, oferecido à suas instituições parceiras. Aborda as tecnologias que servem de alicerce para seu funcionamento e, principalmente, apresenta a instalação e operação do serviço e seus componentes. Objetivo: Ensinar o profissional técnico a instalar, operar e manter os dispositivos que compõem o serviço fone@RNP em sua instituição. Público alvo: Engenheiros, analistas, técnicos e outros profissionais responsáveis pelo serviço de telefonia IP das instituições parceiras, bem como quaisquer outros interessados em soluções de Voz sobre IP. Ao final do curso o profissional será capaz de instalar e manter o serviço fone@RNP em sua instituição.


5

Capítulo 01

Apresentação

AVISO! O serviço fone@RNP, baseado na tecnologia de Voz sobre Protocolo Internet (VoIP), é uma aplicação que utiliza a infraestrutura de redes IP para encaminhar ligações telefônicas. Por isso mesmo, assim como qualquer outra implementação do serviço de telefonia sobre IP, está sujeita às vantagens e desvantagens do IP. Diante disto, a Rede Nacional de Ensino e Pesquisa possui o dever de informar que não é responsável por quaisquer danos ou prejuízos causados pelo mau uso do serviço fone@RNP, principalmente relacionados à qualidade das chamadas e à segurança contra invasões e outros ataques aos dispositivos hospedados nos clientes. A implantação e manutenção de um serviço de telefonia IP não é trivial, e requer profissionais qualificados para exercer tais tarefas. É necessário que o profissional técnico responsável pelo serviço na instituição esteja atento aos riscos da implantação do serviço de telefonia IP. É fortemente recomendado que a instituição adote práticas de Qualidade de Serviço (QoS) em sua rede IP. É imprescindível que ele promova e coordene o diálogo entre as equipes de redes, segurança e de telefonia (ou equivalentes) de sua instituição. Além disso, independente da adoção do PBX IP (educacional ou corporativa), lembramos que continua sendo necessário que a instituição cliente mantenha uma equipe de suporte para seu PABX, seja ela interna ou terceirizada. A RNP se preocupa com a segurança do sistema e a qualidade das ligações. O fone@RNP é dotado de uma série de funções e subsistemas que tratam essas questões de forma mais eficiente possível.


6

Capítulo 01

Apresentação

Visão básica da RNP A RNP é primeira rede de acesso à Internet no Brasil. Sua missão é promover o uso inovador de redes avançadas no Brasil. Foi criada em 1989 pelo Ministério da Ciência e Tecnologia (MCT) com o objetivo de construir uma infraestrutura de rede Internet nacional para a comunidade acadêmica. A rede começou a ser montada em 1991. Em 94, já atingia todas as regiões do país. Entre 2000 e 2001, a rede foi totalmente atualizada para oferecer suporte a aplicações avançadas. Desde então, a Rede Ipê possui pontos de presença em todos os estados brasileiros. Desde 2002, é uma Organização Social (OS) vinculada ao Ministério da Ciência, Tecnologia e Inovação (MCTI) e mantida por esse em conjunto com os ministérios da Educação (MEC), Cultura (MinC) e Saúde (MS). Um universo estimado em mais de um milhão usuários da comunidade acadêmica brasileira se beneficia dessa infraestrutura que estimula o progresso da ciência e da educação superior no país. A rede Ipê é a primeira rede óptica nacional acadêmica da América Latina, inaugurada pela RNP em 2005. O backbone da rede Ipê foi projetado para garantir não só a largura de banda necessária ao tráfego Internet usual (navegação web, correio eletrônico, transferência de arquivos), mas também o uso de serviços e aplicações avançadas e a experimentação. A infraestrutura engloba 27 Pontos de Presença (PoPs), um em cada unidade da federação, além de ramificações para atender mais de 500 instituições de ensino e pesquisa em todo o país, beneficiando mais de 3,5 milhões de usuários. Em 2010, a rede Ipê passou por um grande salto qualitativo, atingindo a capacidade agregada de 233,2 Gbps, um aumento de 280% em relação à capacidade agregada anterior. Nesta nova rede, que é a sexta geração do backbone operado pela RNP, as velocidades multigigabits (acima de 1 Gbps) estão disponíveis para 24 dos 27 PoPs. A ampliação foi resultado de acordo de cooperação com a empresa de telecomunicações Oi, que proverá à RNP infraestrutura de transmissão em fibras ópticas para uso não-comercial e participará de projetos de Pesquisa & Desenvolvimento (P&D) de interesse comum. Agente de integração de iniciativas acadêmicas no Brasil e na América Latina, a RNP tem papel de destaque na Cooperação Latino Americana de Redes Avançadas (RedCLARA). A rede Ipê tem uma conexão de 1,45 Gbps com a rede desta iniciativa, que integra atualmente 15 países da América Latina. Além disto, por meio de uma conexão de 20 Gbps operada em parceria entre a RNP e a Academic Network at São Paulo (ANSP), a rede Ipê se conecta a outras infraestruturas acadêmicas internacionais, como a norte-americana Internet2 e a europeia Géant, e à Internet comercial mundial.


7

Capítulo 01

Apresentação

Figura 1.1 - Rede Ipê, em

Serviços Avançados na RNP Desde 2000, a Rede Nacional de Ensino e Pesquisa (RNP) tem se dedicado à promoção do uso de aplicações avançadas em redes de computadores. Telefonia sobre a rede Internet, TV digital transmitida pela rede, educação a distância, videoconferência IP e Identidade Digital são algumas das aplicações que estão sendo implantadas na forma de serviços para os usuários. Os serviços avançados disponibilizados pela RNP às suas organizações usuárias são resultados de processos de inovação e prospecção, de acordo com as necessidades dos clientes, em atividades de análise de cenários e tendências com parceiros como a academia, o setor empresarial e as principais redes acadêmicas mundiais. Os principais benefícios dos serviços da RNP são facilitar e promover a comunicação, a colaboração a distância e a disseminação de conhecimento. As informações sobre os serviços disponibilizados pela RNP para suas organizações usuárias e comunidades de clientes especiais e estratégicos encontram-se consolidadas no Catálogo de


8

Capítulo 01

Apresentação

Serviços, estando os mesmos classificados da seguinte forma: Comunicação e Colaboração, Disponibilização de Conteúdos Digitais, Gestão de Identidade, Hospedagem Estratégica e Suporte à Rede Acadêmica.

Comunicação e Colaboração A RNP oferece aos seus clientes os seguintes serviços de comunicação e colaboração: Conferência Web, fone@RNP, Videoconferência, Telepresença e fileSender@RNP.

Gestão de identidade A RNP reúne as Instituições Federais de Ensino Superior (Ifes), Unidades de Pesquisa (UPs) e demais instituições acadêmicas em uma rede de confiança, por meio dos serviços: Comunidade Acadêmica Federada (CAFe) e Infraestrutura de Chaves Públicas para Ensino, Pesquisa (ICPEdu) e eduroam.

Suporte à rede acadêmica Gerenciado e operado pela RNP, o Ponto Federal de Interconexão de Redes (FIX) é um Ponto de Troca de Tráfego (PTT) que viabiliza a interconexão entre redes, aumentando a eficiência da transferência de dados.

Disponibilização de conteúdos digitais Através de sua rede inteligente de distribuição de vídeo digital, a RNP provê os serviços de Vídeo sob Demanda, Transmissão de Sinal de TV, Transmissão de Vídeo ao Vivo e Videoaula@RNP.

Hospedagem estratégica O Internet Data Center (IDC) é o serviço de hospedagem de equipamentos e servidores dentro do modelo conhecido como colocation. Este serviço fornece uma infraestrutura de segurança, física e lógica, para clientes estratégicos para o sistema nacional de CT&I, Cultura e Saúde, com garantias de disponibilidade e operação ininterrupta.

Apoio a serviços O Service Desk é uma instância de apoio, voltada à resolução de dificuldades que as instituições clientes dos serviços possam encontrar na entrega, acesso ou utilização dos mesmos. O Catálogo de Serviços e outras informações podem ser encontradas na página de Serviços da RNP, .

O serviço Fone@RNP O fone@RNP é o serviço que tem como objetivo interconectar a rede de telefonia dos clientes da RNP. Ele utiliza a tecnologia de Voz sobre IP (VoIP). A solução começou a ser desenvolvida em 2002, como um grupo de trabalho (GT) no âmbito do programa de pesquisa e desenvolvimento, fomentado pela própria RNP. Melhoramentos nessa solução permitiu pôr em produção e oferece-la como serviço para as instituições de ensino e pesquisa brasileiras. O principal objetivo deste serviço é economizar recursos financeiros com chamadas de longa distância para telefones fixos, que no Brasil são relativamente caras, custando aproximadamente 10 vezes mais que uma ligação local. Não há custo para adesão ao serviço. As instituições clientes do fone@RNP podem realizar


9

Capítulo 01

Apresentação

chamadas entre elas sem qualquer custo. Elas também podem realizar chamadas de longa distância para telefones na rede pública de telefonia (RTFC), desde que haja na cidade-destino outro cliente do fone@RNP. Como este é um serviço colaborativo, nenhuma das chamadas são cobradas da instituição que originou a mesma, incluindo aquelas que terminaram na rede pública. Neste caso, a universidade na cidade de destino da ligação é quem paga a conta destas chamadas. Na prática, o custo das ligações à distância é convertido em custo de ligações locais, gerando uma economia significativa, conforme comparação indicada no parágrafo anterior. Ademais, os recursos financeiros que as instituições de ensino e pesquisa clientes do serviço utilizam para pagar a conta de telefone têm a mesma origem orçamentária, ou seja, os cofres do Governo Brasileiro. Então, quando as universidades economizam dinheiro, na verdade, o Governo Brasileiro é que está, de fato, economizando recursos. Assim, expandir o número de clientes do fone@RNP é um fator muito importante não apenas para o serviço ou para seus clientes, mas para tornar possível economizar mais recursos públicos, no curto e longo prazos. Cada instituição que adere ao serviço tem a oportunidade de economizar não apenas para ela mesma, mas também ajuda a outras instituições a economizar da mesma forma.

O GT-VoIP O serviço Fone@RNP é fruto direto de um programa de Pesquisa e Desenvolvimento da RNP. Teve como marco inicial a criação do Grupo de Trabalho – VoIP em maio de 2002 com a ideia de pesquisar e gerar um produto final que funcionaria como alternativa ao tradicional sistema de telefonia. O objetivo principal do GT é a implantação de um serviço experimental de telefonia no backbone RNP, permitindo às instituições usuárias utilizar suas redes para estabelecer comunicação de voz a partir de seus PBXs, telefones IP e/ou estações de trabalho. Como produto final deste GT, em 2004, o LabVoIP do NCE/UFRJ definiu a arquitetura e implantou o serviço Fone@RNP em 17 instituições pilotos em 10 estados do território brasileiro. Neste momento, comunicação de voz sobre IP não era mais novidade devido à popularidade de sistemas como o MSN ou Skype, que permitiam aos usuários realizarem comunicação de computador para computador. Não obstante a isto, o serviço Fone@RNP permite a comunicação não só com os dispositivos VoIP do computador, mas também integra o serviço aos ramais convencionais das instituições e aos números da rede pública de telefonia, RTFC. A integração dos números da rede pública faz parte da ideia colaborativa do serviço. As chamadas originadas em uma instituição serão encaminhadas por outro cliente situado na mesma localização do destino discado, realizando uma chamada local para alcançar o telefone destino.

O Projeto VoIP4All Com a evolução do Grupo de Trabalho GT-VoIP a serviço, houve a necessidade de expandi-lo para mais instituições usuárias. Para esta demanda, a RNP criou o projeto VoIP4All que teve como objetivo a adesão de 77 instituições ao serviço em todo o país. Foram adquiridos servidores, placas de interface de telefonia, telefones IP básicos e telefones IP Avançado. Sendo parte do projeto, o LabVoIP foi contratado para prestar suporte às instituições durante o período de implantação do serviço e para desenvolver o treinamento básico e avançado ao serviço, oferecidos a dois técnicos de cada instituição beneficiada pelo projeto. Os treinamentos se dividiram em quatro turmas básicas e quatro turmas avançadas, totalizando assim 164 alunos de 82 instituições (7 instituições foram convidadas além das 77 iniciais).


10

Capítulo 01

Apresentação

Projeto de melhoria do fone@RNP Seguindo o caminho da evolução do serviço, em 2012 a RNP deu início ao projeto de melhoria do fone@RNP. Nessa ocasião, o serviço foi totalmente redesenhado. Sua estrutura, que antes era dependente de dois servidores em cada cliente, foi completamente modularizada permitindo maior escalabilidade, maior confiabilidade e aumenta consideravelmente sua eficiência. Como resultado, o serviço é capaz de conferir maior economia para seus clientes. Além disso, também foi desenvolvido um módulo com funções de um PABX tradicional, inexistente na versão anterior. Para identificar as versões do fone@RNP, chamamos a versão mais antiga de distribuição 2008 e a mais nova de distribuição 2012. Este livro se dedica a apresentar a nova versão, a distribuição 2012 do fone@RNP. A figura 1.2 apresenta a arquitetura do fone@RNP distribuição 2012, com seus módulos e conexões com outras redes que oferecem serviço de telefonia IP.

Figura 1.2 - arquitetura do fone@RNP, distribuição 2012. O detalhamento das funções de cada módulo será apresentado num capítulo adiante.

Evolução dos clientes do fone@RNP A evolução da telefonia IP, principalmente do protocolo SIP, e as novas demandas solicitadas ao serviço Fone@RNP, levaram o mesmo a uma nova arquitetura baseada no SIP. Esta evolução forneceu uma reestruturação das instituições participantes. A etapa de instalação do serviço na instituição passou a ser automatizada com scripts de instalação e arquivos de configurações padrões e informações de roteamento foram transferidas à base de dados. Tais


11

Capítulo 01

Apresentação

alterações forneceram ao serviço um novo patamar de estabilidade e agilidade na implantação e manutenção. Em paralelo ao projeto de melhoria, em 2012 também foi executado o projeto de ampliação dos clientes do fone@RNP. Dado sua importância e sucesso, o projeto foi repedido ano após ano até o momento da escrita deste livro. Expandir o número de clientes do fone@RNP é um fator muito importante não apenas para seus clientes, mas para tornar possível economizar mais recursos públicos da União, no curto e longo prazos. Cada instituição que adere ao serviço tem a oportunidade de economizar não apenas para ela mesma, mas também ajuda a outras instituições a economizar da mesma forma. Em março de 2012 o serviço Fone@RNP contava com a participação de pouco mais de 100 instituições usuárias compostas por unidades de ensino federais, unidades da RNP, unidades da EMBRAPA e instituições convidadas. A partir daí, também os Institutos Federais de Educação, Ciência e Tecnologia (IFs) começaram a aderir ao serviço. A próxima figura mostra o crescimento dos clientes do fone@RNP. As duas rampas entre 2009-2010 e 2012-2013, degraus em 2014 e outra rampa em 2015 evidenciam os projetos com objetivo de ampliar o número de clientes do serviço. Em janeiro de 2014 o serviço passou a contabilizar apenas as instituições ativas, o que explica a redução no número de instituições nesta data. 250

Histórico completo

200

150

100

50

0 Jan-08

Jan-09

Jan-10

Jan-11

Jan-12

Jan-13

Jan-14

Jan-15

Figura 1.3 - Histórico de clientes do fone@RNP.

Alcance do fone@RNP Além de encaminhar chamadas entre as instituições participantes do fone@RNP, o serviço também completa chamadas para telefones na rede pública em toda cidade onde há um cliente.


12

Capítulo 01

Apresentação

Caso haja indisponibilidade temporária em qualquer localidade, as chamadas serão encaminhadas normalmente, de forma transparente, através da rede pública.

Alcance internacional do fone@RNP Além das universidades e instituições brasileiras, o fone@RNP também é capaz de encaminhar ligações via IP de forma transparente para instituições clientes das Redes Nacionais de Pesquisa (NRENs) de vários países. Para isso, o fone@RNP utiliza uma tecnologia chamada Eletronic Number Mapping (ENUM) e consulta as árvores e164.arpa e NRENum.net. Há também casos

onde a RNP estabelece acordos bilaterais com entidades em outros países ou instituições internacionais, como a RedClara. A disponibilidade do serviço nas instituições desses países não está sob controle da RNP e depende das Redes Nacionais e da própria instituição de destino. Da mesma forma, caso não seja possível encaminhar a ligação pela rede IP, as chamadas serão completadas normalmente, de forma transparente, pela rede tradicional de telefonia. Confira a lista de instituições nacionais clientes e de outros países com quem a RNP é capaz de encaminhar ligações via SIP na página do serviço, no portal da RNP.

Processo de adesão ao fone@RNP A adesão ao serviço é aberta a todos as instituições clientes da RNP que disponham de técnicos com conhecimento básico em VoIP para realizar a gestão e a operação da infraestrutura local. As instituições também devem contar com uma conexão adequada à Rede Ipê para suportar o tráfego decorrente da demanda. A solicitação deverá ser realizada pelo contato técnico da instituição usuária, estando de acordo com a sua Política de Uso e ciente sobre o Guia do Usuário, enviando uma mensagem para o Service Desk pelo e-mail [email protected]. Os profissionais da RNP responderão ao contato enviando a Política do Serviço e o Termo de Adesão, onde a instituição formaliza a sua concordância com a Política e indica os profissionais que serão os responsáveis pelo serviço junto à RNP. Esses técnicos também são convidados a preencher um formulário descrevendo seu ambiente de telefonia. Logo depois, é marcada uma entrevista técnica entre os profissionais da instituição e da RNP, visando encontrar a melhor solução para atender às necessidades da Instituições. Depois disso, a RNP auxilia com a instalação e configuração da solução, até sua completa homologação no fone@RNP.


13

Capítulo 01

Apresentação


14

Capítulo 02

Introdução à telefonia



Capítulo 2 – Introdução à telefonia


15

Capítulo 02


Um pouco de história Assim como diversas outras áreas da ciência moderna, a telefonia teve como impulso a descoberta da Eletricidade e do Magnetismo em 1830 por Michael Faraday. A primeira invenção feita após este impulso foi por Samuel Morse em 1837, o Telégrafo Elétrico. Invenção que permitiu a comunicação entre dois pontos ligados por fios condutores de eletricidade. A invenção do telefone é um tópico de grande discussão, já que três cientistas se apresentam na história como inventores do mesmo. Inicialmente o italiano Antonio Meucci em 1851 construiu um telefone eletromagnético nomeado de telettrofono para conectar seu escritório ao seu quarto, localizado no andar acima, para se comunicar com a sua esposa que sofria de reumatismo. Passando por dificuldades financeiras, Meucci não pode dar continuidade a sua invenção e acabou o vendendo ao senhor Alexander Graham Bell. Bell utilizou a descoberta de Meucci para dar continuidade a suas pesquisas sobre o telefone. Em 1876, Bell patenteou o telefone mesmo sem ter ainda conseguido realizar uma ligação na US. Patent Office. Curiosamente, sua requisição chegou horas antes de outro inventor, Elisha Gray. Com a patente obtida, Bell pode trabalhar pacificamente na sua invenção e posteriormente fundar a American Telephony & Telegraphy Company (AT&T). O sistema de telefonia desenvolvido por Bell inicialmente definia uma comunicação ponto a ponto entre dois equipamentos, sendo um deles ativo – gerando pulso elétrico – e outro passivo – não gerando pulso elétrico.

Circuito elétrico equivalente Deixando de lado as discussões sobre a paternidade da telefonia, desde sua invenção até a era digital, não houveram muitas mudanças na forma de transportar a voz de um ponto ao outro. O esquema básico para que um aparelho telefônico pudesse se comunicar com outro aparelho sempre foi modelado com um circuito elétrico. De fato, o conjunto de telefones e fios realmente forma um circuito elétrico fechado, conforme ilustrado na figura abaixo.

Inicialmente, um par de fios ligava dois telefones. Se um destes quisesse falar com outro ponto, outro par de fios era lançado entre ele e o novo participante. Seria necessário ligar todos os


16

Capítulo 02


locais a todos os outros locais onde fosse necessária a comunicação. Usando esta arquitetura, a telefonia expandiu-se de forma desorganizada, já que locais detinham mais de um telefone para que fosse possível se comunicar com localidades diferentes, observando que cada telefone se comunicava com apenas uma localidade. Por exemplo, para interligar 3 pontos, A, B e C, seria necessário haver 2 telefones em cada localidade. No ponto A, um telefone e seu circuito se liga ao ponto B e outro telefone e seu circuito se liga a C. Da mesma forma, no ponto B haveria o segmento BA e BC e, em C os segmentos CA e CB.

Aumentando para 12 pontos em uma cidade, não bastaria haver 12 +

%&' %&() &

= 66 linhas

(quantidade de diagonais mais lados). Seria preciso também haver dois telefones para cada uma das 66 linhas, ou seja, 132 telefones divididos nas 12 localidades. Exatamente 11 telefones para cada um dos 12 pontos!

Logo se percebeu que esta “arquitetura de rede” não era adequada, pois, no mínimo, era de difícil expansão.

Arquitetura hierárquica e em estrela Serviço fone@RNP v.2012 Manual do serviço de telefonia IP da RNP

17

Capítulo 02


Bell identificou também este problema e planejou uma comunicação hierárquica de telefonia, implantando centrais de telefonia nas cidades e definindo todos os telefones instalados como assinantes desta central.

Os assinantes eram interligados às centrais e a partir das centrais poderiam se comunicar com qualquer outro assinante. Este sistema evoluiu até os dias de hoje e atualmente não há a necessidade de solicitar à telefonista da central para estabelecer a comunicação com o assinante final e as inúmeras centrais existentes nas diversas cidades podem ser comunicar.

A nova topologia também tentava resolver problemas de disponibilidade, inserindo enlaces duplicados. O desenho era um misto de malha no núcleo e estrela nas bordas, próximo aos terminais telefônicos. A próxima figura ilustra esta arquitetura mista, onde é possível identificar um núcleo em malha formando uma estrela de novas malhas intermediárias que, no acesso, volta a formar estrelas para alcançar o usuário final.


18

Capítulo 02


Depois de algum tempo, umas ideias foram evoluindo e outras perecendo. Os telefones ganharam teclas que podiam ser usadas para alcançar endereços específicos na rede de telefonia e, conjuntamente, as centrais foram se tornando automáticas, com comutação dos circuitos sendo executadas por relés. Ao mesmo tempo em que as telefonistas iam perdendo seus empregos, maior quantidade de telefones podia ser inserida no sistema.

Encaminhamento das chamadas Para efetuar uma ligação telefônica, o usuário deve digitar a rota até seu destino final. Por exemplo, +55 21 2102-9600, o número do escritório da RNP no Rio de Janeiro, é definido pelas rotas +55 = Roteadores do Brasil + 21 = roteadores da cidade do Rio (e vizinhança) + 2102 = endereço da central local que atende a área entre Botafogo e Urca, na porta que leva ao PABX da RNP + 9600 = número do ramal a ser alcançado dentro do PABX da RNP. Hoje, a portabilidade mudou um pouco essa lógica, e um número de telefone pode ser alocado para outra localidade ou mesmo para outra operadora telefônica. Dito de outra forma, o endereço de um telefone não está mais diretamente atrelado à rota para alcançá-lo. A seguir, a figura abaixo ilustra a comparação de tamanho entre uma central dos anos 50 em relação à altura de um homem.


19

Capítulo 02


Protocolos e sinalização Para tornar a automação de ligações telefônicas possível, era necessário criar um código que todos os telefones e centrais entendessem. Algumas tentativas de construir um protocolo de sinalização foram experimentadas. Algumas usavam 8 ou 7 fios que foram deixadas de lado para dar lugar a protocolos que utilizam 2 fios por assinante. Normalmente, a sinalização analógica utiliza a janela de frequências que o ouvido humano é capaz de perceber e pode ser realizada utilizando os mesmos fios que são utilizados para transportar a voz. Por isso é possível ouvir os tons de controle como ocupado e chamando, os pulsos produzidos ao se discar um número em telefones mais antigos e, mais atualmente, o DTMF (Dual Tone Multi-Frequency), utilizado para enviar para a central os dígitos de 0 a 9 mais ‘*’ e ‘#’ e outros 4 símbolos adicionais, ABCD. Em 1927, a primeira chamada de voz transatlântica foi feita utilizando ondas de rádio. Inovações durante as duas Grandes Guerras fizeram surgir os primeiros telefones móveis. Nos anos 60, os telefones passavam a ser endereçados apenas por caracteres numéricos e os primeiros cabos transatlânticos eram lançados para possibilitar as ligações intercontinentais. Também em 1962, foi lançado o primeiro satélite para telefonia. Ainda na era analógica, surgiu também a telefonia celular. Assim como no início do surgimento dos telefones fixos, os telefones celulares eram caros e pouco eficientes. A seguir, as figuras ilustram exemplos de telefones móveis.


20

Capítulo 02


Hoje em dia, na maior parte do Brasil, apenas as ligações entre o assinante residencial e a central da rede fixa é analógica. Nas empresas, semelhante à situação do assinante residencial, a ligação dos ramais ao PABX também é feita de forma analógica na grande maioria das vezes.

Telefonia Digital Após alguns anos, a tecnologia digital evoluiu e se mostrou mais confiável, mais econômica e mais eficiente que a analógica. A transmissão digital de dados começou a substituir a tecnologia analógica.

Hoje, para ligação entre centrais telefônicas, normalmente se utiliza tecnologia digital. Os tons de controle, mensagens de linha, os dígitos e até a voz são agora enviados entre as centrais utilizando bits, 0’s e 1’s. Não é comum no Brasil, mas também é possível utilizar comunicação digital entre um telefone residencial e a sua central. Nas empresas, a situação é semelhante: telefones digitais são usados para um número reduzido de funcionários, pois eles são mais caros e poucas pessoas realmente precisam das funcionalidades adicionais suportadas por esses telefones. A rede de telefonia cresceu e a tecnologia avançou. As centrais deixaram de ser eletro-


21

Capítulo 02


mecânicas e surgiram as CPAs, ou Centrais de Programa Armazenado, que são como computadores especializados em realizar a comutação das ligações. Consequentemente, protocolos de sinalização mais adequados foram desenvolvidos. Dentre eles pode-se destacar o Sistema de Sinalização nº 7, SS7 (da família ITU Q.7xx) muito utilizado entre as centrais das operadoras de telefonia e a Rede Digital de Serviços Integrados, RDSI (ITU Q.931), ou ISDN em inglês, mais utilizado nas comunicações entre as centrais das companhias operadoras e os PABX digitais dos assinantes. No Brasil, a sinalização definida como padrão para a comunicação entre a operadora e o assinante de tronco digital é a R2-D/MFC-5C (Multi Frequencial Compelida) – Prática Telebrás SDT 210.110.703. Entretanto, várias operadoras de telefonia oferecem para seus assinantes de troncos digitais o protocolo ISDN, que é mais moderno e mais rápido. Na América Latina também é comum a utilização da sinalização R2-Digital. Também a rede de telefonia celular evoluiu para uma rede digital. No Brasil, a ANATEL, Agência Nacional de Telecomunicações, chegou a marcar data, 30/06/2008, para o fim das operações com celulares analógicos. Entretanto, a Agência resolveu suspender a decisão, adiando para fevereiro de 2013 o desligamento do sistema. E mais uma vez, a Agência resolveu dar uma sobrevida à rede analógica de celular até dezembro de 2015, por conta de clientes do RuralCel, um serviço de telefone fixo onde não há cabeamento de linhas convencionais. De acordo com a ANATEL, em meados de 2010 já não havia mais linhas celulares analógicas ativas no Brasil.

Digitalização da voz - PCM Figuras dessa sessão foram retiradas da página http://www.teleco.com.br/tutoriais/tutorialconvdados/pagina_3.asp

O acrônimo PCM significa Pulse-Code Modulation, que em português pode ser traduzido como Modulação por Código de Pulso. Essa modulação atribui códigos de 8 bits a pulsos amostrados e quantizados. São 8.000 amostras por segundo, a partir de um sinal analógico que pode variar de 1 Hz até 4 kHz. Não é por coincidência que esse intervalo contém o intervalo de frequência da voz humana, que varia de 300 Hz até 3 kHz. E ainda bem que o ouvido humano também capta e entende sinais nessa faixa de frequência! O PCM pode ser compreendido como o processo de digitalização da voz utilizado no serviço telefônico. Esse processo é compreendido por 4 etapas, onde as 3 primeiras são muito evidentes. Amostragem > Quantização > Compressão > Codificação

O padrão G.711 utiliza o PCM para digitalização da voz e as leis de compressão lei-A (a-law), utilizada na Europa e no Brasil, e Lei-μ (u-law), mais utilizada nos Estados Unidos e Japão.


22

Capítulo 02


Amostragem

Na amostragem, como o próprio nome diz são retiradas amostras do sinal de voz em intervalos regulares de tempo, o intervalo de amostragem. A quantidade de amostras no tempo é a frequência de amostragem. Segundo o Teorema de Nyqist, é necessário que a frequência de amostragem seja o dobro (ou maior) que a frequência máxima do espectro do sinal. Nesse caso, um sinal de 4kHz implica 8.000 amostras por segundo.

Quantização

A quantização é o processo de conversão da amplitude da amostra obtida na etapa anterior em valores discretos pré-definidos. São utilizados 256 intervalos de quantização no G.711. Esse processo insere pequenas distorções do sinal quantizado em relação ao sinal real.


23

Capítulo 02


Com o objetivo de minimizar a distorção causada pela quantização, nessa etapa também ocorre o procedimento de compressão. Há duas possibilidades para a compressão: Lei-A ou Lei-μ, ambas descritas na recomendação G.711.

Codificação

A codificação é a maneira como os níveis quantizados são representados de forma binária. Para representar os 256 níveis de quantização, são necessários 8 bits (28=256). As 8000 amostras por segundo vezes 8 bits por amostra resultam uma taxa de bits de 64.000 bits por segundo (64kbps).

O que é TDM? É muito comum os profissionais de telefonia se referirem à telefonia tradicional utilizando o termo “TDM”. TDM significa Time Division Multiplexing, que em português quer dizer Multiplexação por Divisão de Tempo. Em outras palavras, é o compartilhamento de um meio de transmissão por diversas fontes de informação, utilizando o tempo como referência para mesclar essas informações. No caso da telefonia, as fontes de informação são as linhas (ou canais) telefônicos. As chamadas telefônicas são digitalizadas e transformadas em bits. Depois, as várias chamadas são organizadas e enfileiradas formando um único “trem de bits”. Esse trem de bits é encaminhado pelo meio de transporte utilizando a técnica TDM.


24

Capítulo 02


TDM é uma técnica de transmissão digital utilizada largamente nos enlaces de telefonia entre operadoras e centrais privadas, os PABX. Essa técnica simula a divisão de tempo em fatias (ou slots) digitais. Cada fatia transporta um canal, ou seja, uma ligação. Na prática, o que o TDM faz é utilizar o meio de transmissão para transmitir mais de uma informação (quase) ao mesmo tempo.

E1/T1 e PDH Os equipamentos nas pontas dos enlaces TDM não precisam ter seus relógios sincronizados. Ao invés disso, cada linha de transmissão possui seu próprio sincronismo. Cada um com seu equipamento par, após configuração de um como Master e outro como Slave, no próprio trem de bits, no quadro 0, o equipamento Master envia a informação de sincronismo. O equipamento Slave recebe a informação e sincroniza a linha de transmissão. Agora será possível para ambos realizar a multiplexação dos 32 canais, um após o outro. Esse método de sincronização é chamado plesiócrono, ou quase síncrono. Com esse método foi possível criar toda uma hierarquia de comunicação, multiplexando cada vez mais informação no mesmo meio de transmissão. Essa hierarquia é chamada de PDH, Plesiochronos Digital Hierarchy, ou Hirarquia Digital Pesiócrona. Um enlace E1 é o primeiro degrau na hierarquia PDH. Cada agregação de 4 canais E1 forma o próximo no nível da hierarquia para um canal E2, de 8 Mbps. Ao agregar 4 canais E2 a hierarquia sobe para um canal E3, de 34 Mbps. 4 E3 formam um E4, de 140 Mbps. Até, 4 E4 formarem um E5, de 565 Mbps.

Em telefonia, dos 32 canais de uma E1, 2 são utilizados para sincronismo e sinalização e nos outros 30 canais são transmitidas as ligações telefônicas. Outra característica dos canais E1 é que há um meio de transmissão em um sentido e outro meio de transmissão no sentido contrário. Dito de outra forma, o A linha E1 que liga os equipamentos A


25

Capítulo 02


e B possui dois ‘cabos’: um para enviar informação de A para B e outro para enviar informação de B para A.

Há outras formas de combinar canais. Nos Estados Unidos e no Japão o canal básico de 64 kbps é multiplexado em enlaces de 24 canais, totalizando 1.544 Mpbs. É conhecido por T1, ou DS1. Daí, seguem agregando de 4 em 4, formando a hierarquia até T4 ou DS4.

RDSI ou R2-Digital Esses 2 termos causam bastante confusão para quem está começando a estudar Voz sobre IP e não tem conhecimento em telefonia. Ambos se referem à sinalização telefônica. Para que uma ligação ocorra, centrais telefônicas trocam sinalização de linha (ocupado, chamando, livre) e sinalização entre registradores (números envolvidos, categorias, ...). Eles são o equivalente digital para esses sinais.

R2-Digital No Brasil é instituído a utilização de R2-Digital para sinalização de linha e MFC para sinalização de registro. A R2D/MFC é uma Sinalização por Canal Associado (CAS). Isso significa que a sinalização de cada chamada ocorre pelo mesmo canal que a ligação está sendo executada. MFC é o acrônimo para Multifrequencial Compelida, que indica que cada dígito ou informação é enviada utilizando um sinal DTMF (Multifrequencial) e que a próxima informação só segue depois de se receber uma resposta do outro equipamento. A sinalização MFC possui variantes. O R2 Digital é utilizado em vários países da América Latina. No Brasil é utilizada a variação 5C.

RDSI / ISDN O protocolo RDSI - Rede Digital de Serviços Integrados (do inglês ISDN - Integrated Services Digital Network) é mais atual e mais rápido que o R2. Ele é uma Sinalização por Canal Comum (CCS), que utiliza um único canal, o 16o slot de tempo, para transmitir a sinalização dos outros 30 canais de voz, no caso uma E1. Essa configuração é também conhecida como 30B+D. O RDSI (ISDN) é utilizado nos Estados Unidos e em grande parte do mundo. No Brasil, várias operadoras entregam enlaces RDSI. Algumas oferecem um pouco de resistência. Outras até preferem essa sinalização. Interessante: Houve uma tentativa de implantar o sistema digital para o assinante de telefonia. O produto foi introduzido pela antiga Telemar, sob o nome de DVI, mas não vingou. A tecnologia utilizava a configuração 2B+D, com dois canais para voz (ou ‘Internet discada’) e um para sinalização.


26

Capítulo 02


Cabos e Conexões Para transportar toda essa informação no formato de zeros e uns (0s e 1s) é necessário um meio físico, um meio de transporte desenhado especificamente para esse tipo de informação. Normalmente, ao se adquirir um ou mais enlaces E1 com a operadora telefônica local, independente do protocolo (ISDN ou R2D), o que se recebe são portas Rx e Tx, um par para cada E1 contratada, na forma de conectores coaxiais como os da figura abaixo.

Estes são conectores BNC-fêmea. Os cabos coaxiais devem ter impedância de 75 Ohms e máximo de 400 metros. Mesmo assim, a grande maioria das instalações não chegam a 10 metros. Frequentemente, se utiliza cabos finos. Os conectores devem ser BNC-macho, como na figura abaixo.

Entretanto, alguns PABX possuem conectores ligeiramente diferentes. Abaixo seguem exemplos de conectores e adaptadores do tipo IEC e do tipo F.


27

Capítulo 02


Tráfego e Dimensionamento de canais Os canais de telefonia são um recurso caro, finito e, em alguns casos, escasso. É necessário otimizar ao máximo sua utilização. Por exemplo, um escritório com 100 ramais normalmente não possui 100 canais de saída/entrada para a rede pública de telefonia. Observe que na maior parte do tempo, os ramais dos colaboradores ficam desligados, no gancho. Além disso, é possível observar que há períodos de maior ou menor utilização dos telefones durante o decorrer do dia. As mesmas observações podem ser feitas para tipos diferentes de escritórios, bairros, campus ou toda uma universidade. Então, para dimensionar a quantidade ideal de linhas telefônicas que irá atender a uma localidade, é preciso saber quantos ramais são utilizados simultaneamente durante o período de maior utilização do dia. Para otimizarmos o sistema é necessário calcular o número ideal de canais com a rede pública. A este cálculo dá-se o nome de dimensionamento de canais. Para tanto, é necessário conhecer o conceito de tráfego telefônico, o conceito de grau de serviço e as tabelas de Erlang.

Tráfego Telefônico (A) A intensidade de tráfego em um sistema telefônico pode ser definida como o somatório dos tempos das chamadas telefônicas em um determinado período de tempo. É comum utilizar o período de uma hora, medindo-se geralmente nos 60 minutos mais movimentados. Hora de Maior Movimento (HMM) O período de 60 minutos (hora) cuja ocupação dos canais é máxima é conhecido como HMM, a Hora de Maior Movimento. A HMM é encontrada através de simples observação do interesse de tráfego telefônico de determinada localidade. Perceba no gráfico a seguir que há dois períodos no dia onde o tráfego telefônico é elevado, sendo o intervalo de 10 horas da manhã o de maior movimento.


28

Capítulo 02


Voltando ao cálculo do tráfego, por exemplo, o escritório hipotético citado acima faz 15 chamadas de 2 minutos cada (em média) durante sua HMM. Pode-se afirmar que o tráfego durante a hora mais movimentada do dia é A= (15 chamadas x 2 minutos) / 60 minutos = 30 minutos / 60 minutos ==> A = 0,5 Erl Note que o Tráfego é uma divisão de tempo por tempo, resultando em uma medida adimensional chamada Erlang (Erl).

Grau de Serviço (GoS) Grau de Serviço (GoS) é definido como o percentual de chamadas da oferta total de tráfego que se admite perder, ou seja, é o percentual de chamadas que podem ser perdidas por falta de canais disponíveis. Este valor é assumido (‘chutado’ não seria a melhor palavra!) pelos administradores ao realizar o dimensionamento. Continuando no escritório do exemplo, admite-se perder 0,3% das tentativas de chamadas para fora do escritório. Neste caso, GoS = 0,3%.

Cálculo de canais e Tabelas de Erlang Para calcular o número de canais necessários para atender às especificações de um sistema de telefonia existe uma fórmula um tanto complicada que está apresentada abaixo a título de ilustração, mas vamos poupá-los de decifrar.


29

Capítulo 02


● ● ●

A = Tráfego Oferecido N = Número de Canais para escoar o tráfego Pb = Probabilidade de Bloqueio. Ao invés da longa explicação da fórmula, apresentamos as Tabelas de Erlang. Com elas é possível obter o número de canais necessários para atender à demanda, considerando o GoS.

A utilização da Tabela de Erlang é bem simples. 1. Localize a coluna correspondente ao grau de serviço desejado. 2. Nesta coluna, localize o valor imediatamente superior ao tráfego esperado. 3. Identifique o valor de N, que ocorre no início de cada linha. Este é o valor desejado, que significa o número de canais necessários para atender ao seu sistema.

De acordo com o caso do exemplo acima, são necessários 4 canais com a rede pública para atender um tráfego de 0,5 Erl (equivalentes a 15 chamadas de 2 minutos durante uma hora), com um GoS de 0.3%

Observação: Para o dimensionamento de ambientes com filas de atendimento, como callcenters, o metodo é ligeiramente diferente e utiliza outras tabelas de Erlang. No site erlang.com esta tabela de Erlang está completa. Existem ainda algumas calculadoras disponíveis na internet. Esta é a referência para uma delas, disponibilizadas pelo site Teleco. < http://www.teleco.com.br/erlangb.asp>


30

Capítulo 02


Plano de Numeração Nacional Para alcançar corretamente essa quantidade gigantesca de aparelhos telefônicos (fixos e moveis) no mundo é necessário haver uma rígida padronização na formatação dos “endereços” dos telefones. No Brasil, a ANATEL define o Plano de Numeração da seguinte forma: Para as chamadas locais são discados 8 dígitos para telefones fixos ou 9 dígitos para celulares. No momento da escrita desse livro, o Brasil está passando pela migração de 8 para 9 dígitos para os celulares. Essa mudança deve ser concluída até o fim do ano de 2016. Chamadas a cobrar devem utilizar o prefixo 9090 antes do número.

http://grandeseventos.anatel.gov.br/images/ORIENTACOES-GENERAL_INFO/Info-Guia5.12%20atualizado%209o%20dgito.png

Para chamadas de Longa Distância Nacional (LDN), o plano de discagem nacional é 0 + CSP + CA + NÚMERO , onde: CSP = 2 dígitos do Código de Seleção de prestadora CA = 2 dígitos do Código de Área

Para chamadas LDN a cobrar, inclua o dígito 9 antes do prefixo LDN (0): 90+0+CSP+CA+NÚMERO


31

Capítulo 02


http://grandeseventos.anatel.gov.br/images/ORIENTACOES-GENERAL_INFO/Info-Guia-%20LDN%20-%205.3.png

Para chamadas de Longa Distância internacional (LDI), o plano de discagem nacional é 00 + CSP + CP + (CA+NÚMERO) , onde: CP = Código do pais, que pode ter de 1 a 3 dígitos.

http://grandeseventos.anatel.gov.br/images/ORIENTACOES-GENERAL_INFO/LDI%20-%20Internacional.png

Terminais telefônicos dentro de Centrais Privadas (PABX)


32

Capítulo 02


No Brasil, quando o terminal telefônico está ligado a um PABX tradicional analógico ou digital, é comum utilizar o dígito 0 (zero) para solicitar acesso ao tronco externo, ou como comumente se ouve dizer, para “pegar linha”. Depois disso, devem ser marcados os dígitos do número a ser alcançado na RTFC como se o usuário estivesse em sua própria casa, normalmente seguindo o Plano Nacional. Entretanto, nos PBX IP não é necessário alocar um tronco de saída, ou seja, não é necessário digitar o primeiro 0 (zero), para acesso à linha externa. Mesmo assim, é recomendável manter a forma de discar (0, para “pegar linha”) para que não haja impacto na cultura de utilização dos telefones pelos usuários.


33

Capítulo 02



34

Capítulo 03

Introdução à VoIP



Capítulo 3 – Introdução à VoIP


35

Capítulo 03


Voz sobre IP é a tecnologia em que se baseia o serviço de telefonia sobre IP. Há vários protocolos e recomendações associadas à VoIP. O SIP e H.323 são os mais conhecidos destes protocolos, mas existem outros como MGCP, RTSP etc. O fone@RNP utiliza SIP para sinalização das chamadas telefônicas. Este capítulo apresenta o SIP e outros componentes que fazem parte da solução de telefonia IP da RNP.

Protocolo de iniciação de sessão – SIP O protocolo de iniciação de sessão (Session Initiation Protocol – SIP) foi desenvolvido pela Internet Engineering Task Force (IETF) na década de 90. Sua primeira versão, lançada em 1996, foi chamada inicialmente de Session Invitation Protocol, onde sua função era basicamente estabelecer a sessão. Outras funcionalidades, como controles para conferências, foram introduzidas na versão 2.0, lançada em 1997. Em fevereiro de 1999, o SIP foi proposto como um padrão e publicado na RFC 2543. Sua última versão (SIPv2) foi publicada na RFC 3261 em 2002, substituindo a versão anterior. O SIP é utilizado para estabelecer, manter e encerrar conferências multimídia em uma arquitetura cliente/servidor — o originador é o usuário cliente e o destino é o usuário servidor. Existem as versões SIP-T IETF, SIP-I ITU e SIP-I ANSI, similares ao SIP, mas com diferenças sutis, utilizadas para tunelar mensagens ISUP ou outras sinalizações telefônicas através de redes IP. Em uma sessão SIP, um servidor e um cliente terão total controle sobre a sessão, podendo ser de transmissão de voz, vídeo ou bate-papo. O SIP utiliza outros protocolos para complementar sua função. Os dois mais conhecidos são: ● Real Time Protocol / Real Time Control Protocol (RTP/RTCP) ● Session Description Protocol (SDP) Padronizado pelo IETF na RFC 1889, o Real Time Transport Protocol (RTP) foi projetado para permitir que os receptores compensem o jitter e a perda de pacotes introduzidos pelas redes IP. Sua última versão é o Secure RTP (SRTP), publicada na RFC 3711. Inclui as seguintes informações: ● Tipo de dado transportado; ● Timestamps; ● Número de sequência. O protocolo de controle de transporte em tempo real (Real Time Control Protocol – RTCP) foi projetado para trabalhar em conjunto com o RTP. Em uma sessão RTP, os participantes enviam periodicamente pacotes RTCP para receberem informações sobre a qualidade da entrega dos dados, sobre jitter e sobre a perda de pacotes. O protocolo de descrição de sessão (Session Description Protocol – SDP), definido pela IETF na RFC 2317, é utilizado em conjunto com o protocolo SIP para definir as sessões, tipo de mídia, CODECs, portas para transporte de mídia e criptografia.

Características do protocolo SIP


36

Capítulo 03


● ● ●

SIP é baseado em texto SIP é baseado em Requisições e Respostas SIP é independente da camada de transporte

O Protocolo de Iniciação de Sessão é um protocolo de aplicação que utiliza o modelo “requisiçãoresposta”, similar ao HTTP, para iniciar sessões de comunicação interativa entre usuários. Sua rápida adoção talvez esteja relacionada principalmente à sua simplicidade (possui apenas seis métodos), à sua independência em relação ao protocolo de transporte (pode funcionar com UDP ou TCP), por ser baseada em texto e, assim como o HTTP, o SIP leva os controles da aplicação para o terminal, eliminando a necessidade de uma central de comutação.

Funcionalidades As principais funcionalidades do SIP são: • Localização do usuário • Disponibilidade do usuário • Capacidades do usuário • Estabelecimento de sessão • Gerência de uma sessão estabelecida

O que o SIP não é e não faz: ● ● ● ● ● ●

Não é um protocolo de transferência de dados Transporta pequenas mensagens, mas não grande quantidade de dados Não fornece suporte para QoS Não tem a finalidade de substituir todas as características da telefonia Não é um protocolo de reserva de recurso Não é um protocolo para controle de dispositivos

O SIP não é um protocolo milagroso desenvolvido para solucionar todos os problemas da comunicação. Não tem o objetivo de substituir todas as características e serviços providos pela rede comutada de telefonia com serviços idênticos. Não é um protocolo de transferência como o HTTP, que foi desenvolvido para transportar uma quantidade grande de dados. O SIP transporta uma pequena quantidade de dados requerida para configurar comunicações iterativas (pequenas mensagens de texto). Também não age como um dispositivo de reserva de recursos, por não prover QoS, apenas interagindo com protocolos desenvolvidos para suportar QoS. Não é um protocolo que substituirá a PSTN, sendo bem diferente dos modelos de chamadas telefônicas e dos protocolos de sinalização de telecomunicação. O SIP pode interagir com a PSTN por meio de gateways, mas esta não é sua função principal. O SIP não provê serviços. Ele provê primitivas que podem ser utilizadas para montar um serviço, por exemplo, o serviço de Telefonia sobre IP.

Elementos de uma rede SIP


37

Capítulo 03


Uma rede SIP típica contém basicamente dois tipos de elementos: telefones ou EndPoints, chamados User Agent e os servidores, chamados de proxy servers. O User Agent (UA) é uma entidade lógica da arquitetura SIP e se subdivide em User Agent Client (UAC) e User Agent Server (UAS). O UAC (User Agent Client) executa a função de cliente da aplicação e é responsável por iniciar uma chamada SIP enviando requisições. O UAS (User Agent Server) é a parte com função de servidor e permanece “ouvindo” a rede, aguardando requisições. Um user agent chamador atua como UAC quando envia uma mensagem de requisição INVITE e recebe resposta das requisições feitas. Um user agent chamado se comporta como um UAS quando este recebe a requisição INVITE e retorna uma resposta. Esta situação muda quando a pessoa chamada decide enviar um BYE e terminar a sessão. Neste caso, o user agent chamado (que envia BYE) se comporta como um UAC e o user agent chamador atua como um UAS. Dito de outra forma, o UAC e UAS só existem durante a transação SIP (SIP Transaction).

Os servidores (ou SIP Proxies) são elementos encarregados de executar o registro dos telefones e o encaminhamento das chamadas entre os diferentes domínios. São usados para traduzir nomes e números de identificação dos UA para o endereço IP em que eles estão instalados. Os SIP Proxies são classificados de acordo com sua função principal: ● Registar ou Servidor de registro: Servidor onde os telefones IP se registram para que possam ser encontrados quando uma chamada chega para eles. ● Redirect Server ou Servidores de redirecionamento: Servidor utilizado apenas para indicar rotas alternativas. Responde às requisições com mensagens 3xx. ● Servidor Proxy: Seu propósito é receber requisições e encaminhá-las para o destino. Sua função principal é rotear as chamadas. Também podem exercer funções de controle, admissão e segurança. Podem ser de dois tipos: ○ Proxies Stateless não mantêm o estado das chamadas. Eles reencaminham as mensagens para o destino ou para outro proxy. São mais simples e mais rápidos. São similares às “centrais tandem” da velha telefonia. Armazenam poucas informações e são indicados para implementação de centrais trânsito, a fim de evitar congestionamentos. ○ Proxies Stateful mantêm o estado das chamadas. Podem se encarregar de tarefas como bilhetagem e contabilização. São mais lentos e consomem mais recursos computacionais.

.

atlanta.com proxy

. . . biloxi.com proxy

.

. .

Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | |


38

Capítulo 03


|--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | |

Figura – Comunicação entre dois domínios diferentes A figura acima foi retirada da RFC 3261 e representa o “Trapézio do SIP”, onde Alice, utilizando o proxy atlanta liga para Bob, no proxy biloxi. Neste caso, os servidores em questão são ‘Stateless’, pois não se mantém na chamada até sua finalização.

Também é possível observar o trapézio SIP em um cenário hipotético com duas companhias, A e B, com dois servidores proxy diferentes, um para cada. Neste caso, observe a etapa onde o proxy A encontra o endereço do proxy B. O funcionário Joe da companhia A deseja se comunicar com o funcionário Bob da companhia B. O usuário Joe utiliza o endereço “sip:[email protected]” para fazer uma ligação para o usuário Bob. O


39

Capítulo 03


user agent de Joe não sabe a localização de Bob, mas está configurado para enviar todas as chamadas para o servidor SIP “proxy.a.com” de sua companhia. O servidor proxy de A descobre que o usuário “sip:[email protected]” está em uma companhia diferente, então irá procurar servidor SIP proxy da companhia B e enviar o convite para lá. Os endereços dos servidores proxy da companhia B podem estar pré-configurados no “proxy.a.com”, ou o proxy de A utilizará os registros DNS SRV para encontrar os servidores proxy de Bob. O convite chega até “proxy.b.com”, que sabe que Bob tem condições de atender a chamada em seu telefone. Então o proxy envia o convite para o endereço do telefone IP de Bob. Servidor de redirecionamento (Redirect Server)

Figura 2.3 – Funcionamento do redirect server

1. Servidor que recebe uma requisição e retorna uma resposta contendo uma lista da localização atual do cliente 2. Gera respostas do tipo 3xx para as requisições feitas. Um servidor de redirecionamento (redirect server) mapeia um endereço em zero ou mais novos endereços associados a um cliente, que não é nada mais do que um servidor gerador de respostas 3xx para as requisições que recebe, direcionado o cliente ao contato com um conjunto de URIs alternativos. Pode ser utilizado para a implementação de serviços de voz, como o correio eletrônico, ou para a configuração de rotas alternativas. Neste cenário, o redirect server recebe a requisição e consulta o destinatário no banco de dados criado pelo servidor de registro (registrar). Depois disso, uma lista da localização atual do usuário é criada e enviada ao originador da requisição em uma resposta SIP 3xx da classe de resposta de redirecionamento. O originador da requisição extrai a lista de endereços e envia outra requisição diretamente para eles.

Servidor de registro (Registrar Server) O servidor de registro é um dos elementos da arquitetura SIP, onde se recebe os registros dos usuários. Ele extrai a informação de sua localização atual (endereço IP, porta e username) e a armazena em um banco de dados. Armazena informações sobre os locais onde uma parte pode ser encontrada, trabalhando em conjunto com o servidor de redirecionamento e o servidor proxy. O propósito do banco de dados é mapear clientes em uma mesma zona, permitindo que sejam


40

Capítulo 03


encontrados no momento de uma requisição.

Figura 2.4 – Funcionamento do servidor de registro Este cenário demonstra um exemplo de um servidor de registro (registrar), no qual uma mensagem REGISTER contendo o endereço de registro “sip:[email protected]” e o endereço de contato “sip:[email protected]:5060”, em que 1.2.3.4 é o endereço IP do telefone enviado ao servidor de registro, que extrai a informação e a armazena em um banco de dados local. Se tudo correr bem, o servidor de registro envia uma mensagem de resposta 200 OK ao telefone e o processo de registro termina corretamente.

Mensagens SIP A comunicação SIP determina a troca de várias mensagens, que podem ser transportadas via UDP ou TCP, sendo o primeiro o método mais usual. Uma mensagem pode ser 1) Requisição do cliente para o servidor ou; 2) Resposta do servidor para o cliente. ●

●

SIP Requests ○ Uma mensagem SIP enviada do cliente ao servidor com o propósito de invocar uma operação em particular SIP Responses ○ Quando um UA (User Agent) ou um proxy server recebe uma requisição e envia uma resposta

Mensagem de requisição SIP (SIP Requests) O formato de uma requisição SIP é caracterizado pela utilização de uma linha de requisição como primeira linha. Cada linha de requisição é formada por um método (tipo de operação de requisição), um endereço e pela identificação da versão SIP utilizada. São especificados seis métodos para a versão corrente do SIP. Porém, outros métodos foram definidos por extensões do SIP. Com relação ao endereço, o formato é definido como uma URI SIP, uma SIPS ou uma URI genérica.


41

Capítulo 03


Tabela 2.1 - Métodos de requisições no SIP/2.0 Há ainda os métodos estendidos de requisição. Eles estão enumerados na tabela abaixo.

Tabela 2.2 – Métodos de requisições estendidos Exemplo de SIP Request INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 195.37.77.100:5060;rport Max-Forwards: 10


42

Capítulo 03


From: "jiri" ;tag=76ff7a07-c091-4192-84a0-d56e91fe104f To: sip:[email protected] Call-ID: [email protected] CSeq: 2 INVITE Contact: sip:213.20.128.35:9315 User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username=“renatoduarte", realm=“rnp.br", algorithm="MD5", uri="sip:[email protected]", nonce="3cef753900000001771328f5ae1b8b7f0d742da1feb5753c", response="53fe98db10e1074 b03b3e06438bda70f" Content-Type: application/sdp Content-Length: 451 Continua com linhas SDP... A primeira linha indica que a mensagem INVITE é usada para estabelecer uma sessão. A URI da primeira linha SIP “[email protected] SIP/2.0” é chamada de Request URI e contém a URI da pessoa chamada. Um SIP request pode conter um ou mais cabeçalhos Via, que são usados para guardar o endereço da requisição. Eles são utilizados para o roteamento de SIP Responses (respostas SIP). A mensagem INVITE contém apenas um cabeçalho Via criado pelo user agent que envia a requisição. Sobre o campo Via podemos dizer que o user agent está executando no endereço 195.37.77.100, na porta 5060. Nos campos do cabeçalho To e From identifica-se quem irá receber o convite e de quem está sendo recebido determinado convite para determinada sessão. Também possui um campo Tag que serve como um identificador de diálogo.

Mensagem de resposta (SIP Response) É muito similar às requisições, exceto pela primeira linha. Caracterizada pela utilização de uma linha de status como linha de início, formada pela Identificação da versão SIP, Código de status numérico, Código de resultado com três dígitos e Frase textual Existem seis classes do tipo SIP Responses: 1xx – Resposta informativa 2xx – Respostas de sucesso 3xx – Respostas de redirecionamento 4xx – Respostas de falha de requisição 5xx – Respostas de falha em servidor 6xx – Respostas de falha global 1xx Usadas para respostas provisórias, que dizem ao receptor que a requisição feita foi recebida, mas o resultado ainda está em processo. 2xx Respostas finais de sucesso, em que o originador da requisição sempre as receberá. Também terminam transações. 3xx


43

Capítulo 03


Respostas usadas para redirecionamento do chamador. Fornecem informações sobre a nova direção do usuário ou sobre um serviço alternativo que o chamador precisa usar para satisfazer a ligação. 4xx Respostas utilizadas para indicar que houve erro da parte de quem enviou a requisição; erro na sintaxe ou por não ter sido bem preenchida pelo servidor. Resposta de falha de requisição. 5xx Utilizadas para indicar que houve um erro da parte do servidor. Resposta de falha no servidor. 6xx Usada para indicar que a resposta não pode ser completada em nenhum servidor. Resposta de falha global.

Exemplo de SIP Response SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68 From: sip:[email protected] To: sip:[email protected];tagi=794fe65c16edfdf45da4fc39a5d2867c.b713 Call-ID: [email protected] CSeqi: 63629 REGISTER Contact: Msip:[email protected]:5060;transport=udp>;q=0.00;expires=120 Server: Sip EXpress router (0.8.11pre21xrc (i386/linux)) Content-Length: 0 Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=5110 req_src_ip=66.87.48.68 req_src_port=5060 in_uri=sip:iptel.org out_uri=sip:iptel.org via_cnt==1" Este exemplo de SIP Response mostra que as respostas são bem similares às requisições, exceto na primeira linha, que contém a versão do protocolo (SIP/2.0), o código da resposta e a frase textual. Os códigos têm a intenção de serem processados pelas máquinas, não sendo muito amigáveis aos humanos, mas facilitando para que as máquinas façam o parse deles. Já a frase textual é legível aos humanos, descrevendo o resultado do processo.

Um exemplo mais completo Aqui retomamos o Trapézio do SIP.


44

Capítulo 03


Figura 2.6 – Chamada SIP com proxies O proxy server recebe uma requisição INVITE e envia uma resposta 100 (trying) para o softphone da Alice. A resposta 100 (trying) indica que a requisição INVITE foi recebida e que o proxy está trabalhando por ela para rotear a mensagem INVITE para seu destino. Respostas no SIP usam código com 3 dígitos seguidos de uma frase descritiva. Esta resposta contém os mesmos campos To, From, Call-ID, CSeq e Via, que permitem que o softphone da Alice correlacione a resposta com a mensagem INVITE enviada. O servidor proxy “atlanta.com” localiza o proxy no servidor “biloxi.com”, possivelmente executando um tipo de procura no servidor de DNS para encontrar o servidor SIP que serve ao domínio “biloxi.com”. Como resultado, este obtém o endereço IP do servidor proxy “biloxi.com” e envia a requisição INVITE para lá. Antes de enviar a requisição, o servidor proxy “atlanta.com” adiciona um campo Via adicional que contém seu próprio endereço. O servidor proxy “biloxy.com” recebe a requisição INVITE e responde com 100 (trying) ao servidor proxy “atlanta.com” indicando que recebeu a requisição INVITE e a está processando. O servidor proxy consulta o banco de dados, geralmente chamado de “location service”, que contém o endereço IP atual do Bob. O servidor proxy “biloxi.com” adiciona outro campo Via no cabeçalho com o seu endereço para a requisição INVITE e a envia ao telefone SIP do Bob. O telefone SIP do Bob recebe a requisição INVITE e alerta ao Bob que existe uma chamada de Alice. O telefone SIP do Bob indica essa ação com uma mensagem de resposta 180 (ringing), que é roteada pelos dois proxies na direção reversa. Cada proxy utiliza o campo Via do cabeçalho para saber para onde enviar a resposta, depois elimina-as do topo da mensagem. Quando o softphone da Alice recebe a resposta 180 (ringing), a informação é passada para Alice, talvez utilizando tom de áudio “ringback” ou mostrando uma mensagem na tela do softphone dela. Quando Bob atende à ligação, o seu telefone SIP envia uma mensagem 200 (OK) para indicar que a ligação foi atendida. A mensagem 200 (OK) contém o corpo da mensagem juntamente com a


45

Capítulo 03


descrição de mídia SDP (Session Description Protocol) do tipo de sessão que Bob está esperando estabelecer com Alice. Se Bob resolvesse não atender à chamada, uma mensagem de erro seria retornada em vez da mensagem 200 (OK), e a sessão de mídia não existiria.

Protocolo SDP SDP significa Session Description Protocol (Protocolo de Descrição de Sessão). É um formato para a descrição dos parâmetros de inicialização de mídia streaming. Foi publicado pela IETF como RFC 2327 e substituído pela RFC 4566. A mídia streaming é o conteúdo visto ou ouvido durante um envio de dados. Durante o processo de estabelecimento de uma sessão, é necessário negociar a mídia a ser utilizada (voz, vídeo ou dados) e as respectivas informações para a transmissão dessa mídia, como o padrão do CODEC e o protocolo de controle para transmissão. Enquanto o SIP especifica o processo para o anúncio da descrição das informações de uma sessão, o SDP especifica apenas o formato para descrição dessas informações. A descrição das informações de uma sessão SDP é inteiramente representada de forma textual. Isto permite uma variedade de formas de transporte da informação e possibilita que ferramentas baseadas em texto possam gerar e processar as descrições das sessões, de forma que os valores dos atributos podem utilizar todo o conjunto de caracteres do UTF-8. Uma mensagem SDP é composta por uma série de linhas denominadas campos. Os nomes são abreviados por uma só letra. A formatação das linhas de texto está descrita da seguinte forma: Tipo do campo = valor do campo. Por exemplo, no campo mídia (m), o SDP usa um código para listar os CODECs que poderão ser utilizados na sessão. Os códigos correspondentes aos CODECs para os diversos tipos de mídia são detalhados na RFC 3551. m=áudio 3456 RTP/AVP 0,3,4 e 5 (0=PCM G711, 3=GSM, 4=G.723 e 5=DVI4) A tabela abaixo mostra os campos e sua descrição.


46

Capítulo 03


Tabela 2.3 – Campos da requisição SDP Exemplo: v=0 o=renatoduarte 2890842807 2890842807 IN IP4 serv.esr.rnp.br s=Resultado Anual u=http://www.esr.rnp.br/resultados c=IN IP4 serv.esr.rnp.br t=2873397496 0 m=audio 30530 RTP / AVP 0 97 101 a=rtpmap:0 PMCU/8000 a=rtpmap97 G726-32/8000 a=rtpmap101 G726/8000 a=ptime:20

Real-time Transport Protocol – RTP O Real-time Transport Protocol (RTP) é um protocolo que oferece funções direcionadas para


47

Capítulo 03


aplicações que transmitem fluxos de dados em tempo real, como áudio, vídeo e dados de simulações, por meio de serviços de rede unicast e multicast. Esse tipo de fluxo deve ser transportado utilizando o UDP, pois o TCP possui controle de fluxo, que diminui a taxa de transmissão em caso de perda de pacotes. Assim, é natural que o RTP funcione sobre o UDP ao invés do TCP, evitando o controle de fluxo e retransmissões. O custo disso é a pouca confiabilidade e a falta de ordenação na chegada dos pacotes. A retransmissão de pacotes também não é uma característica desejada em fluxos de áudio e vídeo interativos, uma vez que o pacote retransmitido normalmente não chega ao receptor a tempo de ser utilizado. Alguns protocolos mais sofisticados de streamming calculam a probabilidade de o pacote ser retransmitido, permitindo que ele possa chegar a tempo de ser processado. Assim, apenas em caso positivo o pacote é retransmitido. Resumidamente, o serviço RTP inclui: ● Identificação do tipo payload ● Numeração sequencial ● Marcas temporais (timestamping) ● Monitoração da entrega de dados ● Permite interpolação ● Não trata da reserva de recursos e não garante qualidade de serviço (QoS) em tempo real. Funcionando sobre o UDP, soma-se a estas algumas informações de sequenciamento e de timestamp necessárias para a sincronização de imagem e áudio e para possibilitar o sequenciamento correto pela aplicação. O RTP possibilita à aplicação identificar perdas e avaliar quanto tempo uma amostra pode permanecer armazenada em um buffer aguardando a chegada do próximo pacote. A recomendação Secure RTP (RFC 3711) permite uso de criptografia e autenticação das mensagens RTP e RTCP.

Formato do pacote RTP

Os doze primeiros octetos estão presentes em todos os pacotes de um fluxo de dados de uma sessão RTP.


48

Capítulo 03


Figura 2.8 – Mensagem RTP V (Version) – Versão do RTP; P (Padding) – Indica a presença ou não de preenchimento das posições finais do pacote com um ou mais bytes que não fazem parte da carga; X (Extention) – Indica presença ou não de extensão de cabeçalho; CC (CSRC Counter) – Contador do número de identificadores CSRC após o cabeçalho fixo; M (Marker Bit) – Delimita um conjunto de dados relacionados, o início de uma rajada de áudio ou o fim de um quadro de vídeo; PT (Payload Type) – Indica o formato da carga do RTP e determina sua interpretação pela aplicação; Sequence Number – Incrementado em cada pacote RTP e utilizado pelo receptor para detectar perda de pacote ou para restaurar a própria sequência; Timestamp – Utilizado pelo receptor para sincronização e cálculo do jitter; SSRC (Synchronization Source) Identifier – Utilizado para identificar um fluxo específico em uma sessão RTP. Necessário para o receptor agrupar pacotes com o mesmo SSRC para a reprodução; CSRC (Contributing Source) Identifiers – Lista de identificadores CSRC inseridos por mixers.

Quando pacotes RTP relativos a um fluxo chegam ao seu destino, o número de sequência de cada pacote é examinado para determinar a sequência correta dos dados, e também para registrar a fração de dados (por exemplo, amostras de áudio ou quadros de vídeo) perdidos. O valor do timestamp do cabeçalho RTP pode ser utilizado para determinar o atraso entre a fonte e o receptor. O valor do timestamp é marcado pelo transmissor do fluxo no momento do envio dos dados. Conforme os pacotes do fluxo chegam ao receptor, a variação no espaçamento entre pacotes (variação do atraso ou jitter) pode ser examinada, e durante a reprodução, essa informação pode ser utilizada para cálculo de um buffer dinâmico, com a finalidade de eliminar a variação do atraso e, ao mesmo tempo impor o menor atraso possível, de forma que o decodificador possa reproduzir a mídia mantendo uma boa experiência de interatividade.

Real-time Transport Control Protocol – RTCP


49

Capítulo 03


Resumidamente, é o controle do RTP. A frequência de transmissão de pacotes de controle pode variar com a quantidade de participantes em uma sessão, uma vez que, em caso de uma quantidade muito alta, o fluxo de dados de controle pode comprometer os fluxos de dados. Uma das melhorias que a atualização da RFC-3550 traz é justamente o desempenho do protocolo RTCP com um novo algoritmo para cálculo do tempo de transmissão dos pacotes deste protocolo em conferências. O RTCP complementa o transporte de dados feito pelo RTP. Ele possibilita o monitoramento da entrega de dados de forma escalável em redes multicast. Seu funcionamento é baseado na transmissão periódica de pacotes de controle para todos os participantes de uma sessão RTP. O RTCP provê o feedback da qualidade da distribuição, útil para CODECs adaptativos e para a detecção de problemas locais ou globais. O identificador CNAME é utilizado para associar múltiplos streammings, como voz e vídeo. Controla a taxa que os participantes devem enviar informações de controle para que o fluxo de dados não seja prejudicado. Provê um mínimo de informações de controle. Informações mais detalhadas, necessárias para algumas aplicações devem ser providas por nível superior. Há 5 tipos de pacotes RTPC definidos na especificação do RTP, um para cada mensagem: SR, RR, SDES, BYE e APP. Sender Report (SR) – Para estatísticas de transmissão e recepção de participantes que são transmissores ativos em uma sessão; Receiver Report (RR) – Para estatísticas de recepção de participantes que não são transmissores ativos em uma sessão; Source Description (SDES) – Itens que descrevem um transmissor em uma sessão, como o CNAME; BYE – Para indicar o fim da participação de uma aplicação em uma sessão; APP – Para funções específicas da aplicação; O cabeçalho dos pacotes RTCP tem em comum 5 campos que ocupam 32 bits: 1. Número da versão (V) – O número da versão atual do RTP é 2. Não existem planos para introduzir novas versões, e as versões antigas são utilizadas raramente hoje em dia. 2. Padding (P) – Indica que o pacote foi preenchido com bits além do seu tamanho natural. Este tipo de expediente é necessário quando são utilizados alguns algoritmos de criptografia que necessitam de blocos com tamanho constante. 3. Contagem de itens (IC) – Indica o número de itens contidos em um pacote. Normalmente utilizado para indicar o número de receiver reports contido no pacote. 4. Tipo do pacote (PT) – Identifica o tipo de informação contida no pacote. Atualmente existem 5 tipos. 5. Comprimento (Length) – Indica o tamanho do conteúdo do pacote contido após este cabeçalho comum.


50

Capítulo 03


Empacotamento da voz - CODEC A codificação de áudio consiste na captura dos sinais mecânicos do som (ondas sonoras) e transformação destes em sinais digitais. Primeiro ocorre a captura do som e sua transformação em sinal elétrico e, depois, ocorre sua digitalização. A técnica utilizada em telefonia é o PCM (Pulse Code Modulation), que já foi estudado no capítulo 2 - Introdução à telefonia.

Codec CODEC é uma abreviação de codificador-decodificador. Eles especificam como os sinais analógicos da voz devem ser codificados em dados digitais, permitindo ou não a compressão dos dados, com ou sem perda de informação. Na verdade, CODECs são algoritmos para codificação de sinais. Para voz, grande parte dos padrões são baseados na codificação da forma de onda (PCM – Pulse Code Modulation). Um CODEC comprime os dados, eliminando informações redundantes e previsíveis, tanto em áudio como em vídeo. Os dados passam por uma conversão analógica-digital, compreendendo a amostragem do sinal. Gera-se, então, um formato digital, denominado Pulse Code Modulation (PCM). O PCM realiza 8 mil amostras por segundo (carregando 125µsec em cada amostra), devido ao teorema de Nyquist, que diz que essa medida é suficiente para capturar toda a informação em um canal telefônico com largura de banda de 4 KHz. Em uma amostragem menor, a informação transmitida seria perdida; já em uma amostragem maior, nenhuma informação adicional seria acrescentada. Esta técnica, o PCM, é o coração do sistema moderno de telefonia. Como consequência, todos os intervalos de tempo dentro do sistema telefônico são múltiplos de 125 µsec.

Técnicas de codificação Codificação de forma de onda A codificação de forma de onda de sinais de voz é baseada principalmente na predição linear, e o esquema mais utilizado é o Adaptive Differential Pulse Code Modulation (ADPCM). Os codificadores de forma de onda são os que propiciam voz de melhor qualidade, mas são os que despendem a maior taxa de bits, em geral com taxas superiores a 30 kbps. Codificação paramétrica O estudo da natureza do sinal (no caso da telefonia, a voz) é essencial para obter máxima compressão, embora com sensível perda de qualidade. Os codificadores paramétricos, também denominados vocoders (voice coders), utilizam no decodificador um modelo de produção de voz, cujos parâmetros são estimados e transmitidos pelo codificador a intervalos curtos de tempo (10 a 30 ms). A classe de codificadores paramétricos mais utilizada é a dos vocoders LPC (Linear Predictive Coding). Os vocoders conseguem codificar os sinais de voz a taxas de no máximo cerca de 2 kbps, mas com qualidade entre ruim e regular. Codificação híbrida Usa conceitos das duas outras formas de codificação (codificação paramétrica e codificação em


51

Capítulo 03


forma de onda), procurando um balanço entre qualidade e taxa de compressão. Os codificadores híbridos são esquemas que combinam características dos codificadores de forma de onda e dos vocoders. Atualmente, a maioria dos codificadores híbridos utiliza o modelo de codificação Code Excited Linear Predictive (CELP), com taxas de bits entre 4 e 16 kbps, proporcionando qualidade muito melhor do que a dos vocoders. Alguns deles propiciam qualidade muito próxima da obtida com os codificadores de forma de onda. Com base nos tipos de codificação citados, concluímos que os codificadores de forma de onda são os que proporcionam voz com melhor qualidade, mas despendem maior taxa de bits. Em geral, taxas superiores a 30 kbps.

Sobre atraso/delay Um fator importante a ser considerado é o delay inserido pelo codificador. O processo computacional de codificar e, na outra ponta, decodificar os pacotes significa inserir mais atraso na comunicação. De maneira geral, quanto menor for a taxa do CODEC, maior será seu delay, mas também depende muito da complexidade do algoritmo e da implementação do CODEC. Em uma rede de pacote, onde os pacotes de voz podem sofrer grandes atrasos, a escolha do CODEC em função do atraso do mesmo pode ser um diferencial do projeto, principalmente se existem enlaces onde o delay é crítico, como em uma conexão via satélite. Em redes com grande disponibilidade de banda, um CODEC indicado é o G.711, que possui taxa de transmissão a 64 Kbits/seg, mas com delay (de processamento) próximo de zero, boa qualidade e livre de licença.

Comparação entre as técnicas A tabela abaixo mostra um resumo da faixa de frequência, taxas de transmissão e latência utilizada nos principais padrões de codificação de áudio.

Tabela 2.4 – Quadro comparativo de CODECs


52

Capítulo 03


O padrão G.711 é um dos melhores disponíveis (embora o conceito de “melhor” seja relativo), com delay próximo de zero, mesmo que sua taxa de transmissão de bits seja muito alta (64 Kbits/seg), consumindo muita banda em comparação com os demais CODECs. Seu grande diferencial é que está livre de licença, sendo um fator a considerar para projetos com disponibilidade de banda. Outro fator a considerar é que este é um CODEC lossless e não perde informação, sendo utilizado em transmissão de fax. O padrão G.729 possui taxa de 8 Kbits/seg e é muito utilizado no mercado. É um CODEC ITU com a necessidade de compra de licença, pois seu algoritmo foi patenteado. Existem as versões G729a, menos complexa que a G729, e a versão G729b, com capacidade de inserir ruído de conforto nas ligações que utilizam VAD (detecção de atividade de voz). O padrão G 723.1 possui taxas menores que o G.729, é um CODEC ITU e também necessita de pagamento de licença. Possui taxas de 6,3 ou 5,3 Kbits/seg e seu atraso é da ordem de 37,5 mseg. O CODEC iLBC tem fonte aberta, sem exigência de pagamento de licença, sendo uma boa opção de solução. Sua taxa é da ordem de 13,3 Kbits/seg.

G.711 A função básica do algoritmo é codificar a voz utilizando 8 bits por amostra; a banda de entrada de voz é amostrada a 8 kHz, mantendo a largura de banda de 300 a 3400 Hz. Com isso, cada canal de voz precisa de 64 kbps. Dois algoritmos foram definidos no padrão ITU-T G.711: U (ulaw) e A (alaw); o primeiro é utilizado na América do Norte e no Japão, o segundo, na Europa e no resto do mundo. O princípio do codificador G.711 é que se deve utilizar a quantização com escala logarítmica para obter uma relação sinal/ruído independente da intensidade. Isso foi possível duplicando o passo de quantização a cada vez que a intensidade do sinal era duplicada; deste modo obteve-se uma constante. G.729 O codificador G.729 codifica sinais de voz a uma taxa de 8 kbps usando o modelo CS-ACELP (Conjugate Structure Algebraic Code Excited Linear Prediction), que é baseado no modelo de codificação CELP. Ele é projetado para operar com o sinal de voz de entrada já convertido para o formato PCM uniforme, com 16 bits/amostra e taxa de amostragem de 8 kHz. O codificador G.729 trabalha com quadros de 10 ms (ou 80 amostras), que são divididos em dois subquadros de 5 ms (ou 40 amostras). Cada quadro de 10 ms do sinal de voz é analisado para extrair os parâmetros do modelo CELP: os coeficientes preditores do filtro de síntese, os índices dos dicionários fixo e adaptativo e seus respectivos ganhos. Esses últimos são os parâmetros da excitação, determinados para cada subquadro de 5 ms. Esses parâmetros são codificados e transmitidos. No decodificador, esses parâmetros são recuperados para construir a excitação e obter os parâmetros do filtro de síntese. O sinal de voz é reconstruído passando a excitação pelo filtro de síntese de ordem 10. Depois de reconstruído, o sinal de voz é passado por um pós-filtro para melhorar a qualidade do sinal de saída. G.723.1 O codificador G.723.1 tem duas taxas de bits associadas a ele, de 5,3 e 6,3 kbps. Ele codifica sinais de voz quadro a quadro usando codificação preditiva linear baseada em análise por síntese


53

Capítulo 03


(CPLbAS). A codificação em taxa alta (6,3 kbps) usa um modelo MP-MLQ (Multipulse Maximum Likelihood Quantization) para gerar o sinal de excitação, enquanto a codificação em taxa baixa (5,3 kbps) usa um modelo ACELP (Algebraic Code Excited Linear Prediction). O tamanho dos quadros é de 30 ms (ou 240 amostras). O codificador G.723.1 é projetado para operar com o sinal de voz de entrada já convertido para o formato PCM uniforme, 16 bits/amostra e taxa de amostragem de 8 kHz. iLBC O codificador iLBC utiliza o algoritmo de predição linear e suporta dois comprimentos básicos, quadros de 20 ms a 15.2 kbps e de 30 ms a 13.33 kbps. Quando o codificador trabalha com quadros de comprimento de 20 ms, produz 304 bits de saída por quadro, e para um comprimento de 30 ms por quadro, produz 400 bits de saída, os quais devem ser empacotados para serem transmitidos. Os dois modos para quadros de diferentes tamanhos operam de maneira similar. A descrição do algoritmo resulta em um sistema de codificação de voz com resposta controlada diante da perda de pacotes, similar à especificada no PCM com perda de pacotes no padrão ITU-T G.711, que opera a uma taxa fixa de 64 kbps. Algumas das aplicações para este codificador estão nas formas de comunicação em tempo real, como telefonia, videoconferência, áudio e envio de mensagens.

CODECs de banda larga | CODECs de alta definição G.722 O CODEC G.722 é conhecido como CODECs de banda larga ou também como CODECs de alta definição (High Definition - HD). Ele possui uma faixa de frequência maior do que os demais, em 7kHz. Isso faz com que ele capture mais detalhes da voz. É baseado na téncia sub-band ADPCM (SB-ADPCM). Esse CODEC utiliza 14 bits para determinar cada amostra de some consome até 64kbits/seg (mais os cabeçalhos de transporte, rede e enlace). G.722.2 O G.722.2 é um CODEC de voz mais moderno, que utiliza a técnica AMR-WB, Adaptative MultiRate Wideband, desenvolvido com base no AMR e com metodologia similar a ACELP. Esse CODEC é capaz de se adaptar às condições de rede, reduzindo ou aumentando o bitrate, sempre tentando entregar a melhor qualidade de voz que a rede permite. É licenciado pela VoiceAge Corporation.

Resumo Agora que já é conhecido a maior parte das técnicas aplicadas na tecnologia de voz sobre IP, é possível fazer um resumo sobre como todos os componentes se interligam. 1.

O usuário A tira o telefone IP do gancho e disca o número de B


54

Capítulo 03


2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

O telefone de A envia um INVITE para seu proxy local (ou seu PBX IP) O proxy local localiza e identifica o Proxy de B (ou seu PBX IP) O proxy de B encontra o telefone B (seu ramal no PBX) A e B (e seus proxies) negociam os parâmetros da sessão usando SDP A ligação é estabelecida A voz dos interlocutores é codificada, digitalizada e comprimida nos respectivos telefones IP, utilizando o CODEC negociado durante o estabelecimento da chamada A informação da voz digitalizada é enviada utilizando o RTP Os pacotes de voz chegam do outro lado e são enfileirados para que possam ser decodificados corretamente A informação da voz é desempacotada, decodificada e reproduzida Depois de algum tempo, alguém decide desligar e, ao colocar o telefone de volta no gancho, que envia um BYE para o outro lado A ligação é desconectada.


55

Capítulo 03



56

Capítulo 04 Arquitetura do fone@RNP v2012



Capítulo 4 – Arquitetura do fone@RNP v2012

AVISO O serviço fone@RNP, baseado na tecnologia de Telefonia sobre Internet Protocol (IP), é uma aplicação que utiliza a infraestrutura de redes IP para encaminhar ligações telefônicas. Por isso mesmo, está sujeita às vantagens e desvantagens do IP. A implantação e manutenção de um serviço de telefonia IP não é trivial, e requer profissionais qualificados para exercer tais tarefas. É necessário que o profissional, responsável técnico pelo serviço na instituição, conheça os riscos da implantação deste serviço. É necessário que ele promova e coordene o diálogo entre as equipes de redes, segurança de redes e de telefonia (ou equivalentes). A RNP se preocupa com a segurança do sistema e a qualidade das ligações. O fone@RNP é dotado de uma série de funções e subsistemas que tratam essas questões de forma mais eficiente possível. Entretanto, não pode garantir que o sistema nunca será invadido, nunca terá mau uso, ou nunca sofrerá por consequência de parâmetros Qualidade de Serviço (QoS) inadequados. A Rede Nacional de Ensino e Pesquisa, RNP, possui o dever de informar que não é responsável por quaisquer danos ou prejuízos causados pelo uso do serviço fone@RNP, principalmente relacionados à qualidade das chamadas e à segurança do sistema contra invasões e mau uso.


57


Arquitetura do novo fone@RNP Recentemente, o fone@RNP passou por um projeto de evolução, onde foi totalmente redesenhado. Sua estrutura, que antes era dependente de dois servidores em cada cliente, foi modularizada e permite maior escalabilidade, maior confiabilidade e aumenta consideravelmente sua eficiência, conferindo maior economia para seus clientes. Além disso, também foi desenvolvido um módulo com funções de um PABX tradicional, inexistente na versão anterior. Para identificar as versões do fone@RNP, chamamos a versão mais antiga de distribuição 2008 (ou simplesmente fone 2008) e a mais nova de distribuição 2012 (ou simplesmente fone2012). A figura 1 apresenta a arquitetura do fone@RNP distribuição 2012, detalhando seus módulos e conexões com outras redes que oferecem serviço de telefonia IP.

Figura 1. Arquitetura completa do fone@RNP.

A caixa (ou módulo) que se encontra próximo ao mapa mundi identificada como SBC, que significa Session Border Controller (Controlador Sessão de Borda), é responsável pelo controle da comunicação entre o fone@RNP e outras redes de telefonia IP, dentro ou fora do país. É através deste dispositivo que as chamadas de/e para instituições mapeadas pelo NRENum.net[1] são encaminhadas. É também através do SBC que o fone@RNP se comunica com o PIT-VoIP[2]. Este módulo está sendo desenvolvido para a distribuição 2012, baseado na solução do SRL, a ser detalhado mais a frente. Atualmente, é utilizado o servidor “proxy externo”, da versão 2008, para executar esta função. Para executar a função de SBC no nível das instituições, separando o perímetro interno e externo,


58


estão sendo utilizados os próprios SRLs, com função principal de “esconder” a rede VoIP do cliente. As demais caixas serão apresentadas abaixo.

SIP Router Central (SRC) No primeiro nível, mais acima, se encontra o SIP Router Central (SRC). Este módulo é responsável por manter a informação de cada cliente e das rotas para encaminhamento das chamadas entre as várias instituições e entre redes externas. Ele conhece todos os dispositivos do nível abaixo e só aceita INVITEs vindos deles. No SRC encontram-se todas as rotas para os números alcançados pelo fone@RNP, sejam eles internos dos clientes, números na RTFC ou números virtuais do fone@RNP. As informações de rota são publicadas no DNS, em registros NAPTR, de acordo com o protocolo ENUM [RFC-6116].

SIP Router Local (SRL) No segundo nível (e a partir daí) já se encontram equipamentos que ficam sob responsabilidade das instituições clientes. O segundo módulo que aparece (da esquerda para direita) é o SIP Router Local (SRL). Ele é equivalente ao SRC, mas instanciado nas premissas dos clientes. O SRL contém as rotas para encaminhamento das chamadas entre os dispositivos SIP sob domínio da instituição responsável por ele, só aceitando também chamadas vindas destes dispositivos. O SRL pode ser instanciando mais de uma vez dentro da mesma instituição. Isso significa que o próprio SRL pode ser hierarquizado, criando níveis de atendimento e isolando logicamente os campi das Instituições clientes. Quando um INVITE chega ao SRL, ele realiza uma pesquisa ENUM para verificar o endereço SIP equivalente ao número discado. Pode receber como resposta 1) a indicação de encaminhamento pelo SRC quando a chamada é para outro cliente do fone ou para uma cidade onde haja um cliente ou; 2) a indicação de outro modulo SRL, PBX IP ou para um GWT da própria instituição quando a chamada é para um telefone analógico da própria instituição ou para um telefone na RTFC local.

Na próxima camada, a terceira de cima para baixo, estão o Gateway Transparente (GWT) e o PBX IP, que serão descritos nos próximos parágrafos. Nessa camada é possível utilizar não só os dispositivos desenvolvidos para o fone@RNP, mas também qualquer dispositivo SIP, desde que seja compatível com a RFC 3261 (SIP versão 2.0).

PBX IP O PBX IP é uma implementação especial de um PABX tradicional, desenvolvido para o fone@RNP, que procura atender às demandas comuns do serviço de telefonia de uma grande universidade brasileira. Foi desenvolvido primeiramente pela Universidade Federal de Santa Catarina (UFSC), para atender a UFSC, e foi melhorado para atender a todos os clientes do fone.


59


O PBX IP deve receber INVITES apenas do SRL diretamente acima. Todas as chamadas feitas a partir de um PBX IP devem ser encaminhadas para o SRL. Como visto nos parágrafos anteriores, o SRL fica responsável por indicar a rota correta para o número de telefone desejado. O PBX IP conta com duas versões: uma que se chama corporativa, para atender aos funcionários e outra que chamamos acadêmica, para atender aos alunos das universidades. Esta última versão possui integração com o serviço de Identidade Digital da RNP, a CAFe, Comunidade Acadêmica Federada. Essa integração permite a implementação de uma característica única no PABX IP desenvolvido pelo serviço. É a função de autoatendimento, onde o aluno é capaz de solicitar seu próprio ramal IP em um página web, sem a intervenção de qualquer funcionário.

Gateway Transparente (GWT) O Gateway Transparente (GWT), de acordo com o modelo acima, pode aparecer na segunda camada, diretamente ligado ao SRC ou na terceira camada, abaixo de um SRL. O GWT é a peça fundamental do novo fone@RNP. Ele faz a ligação entre o serviço de telefonia digital tradicional e o serviço de telefonia IP. A quarta camada representa os tradicionais dispositivos PABX e as redes de telefonia, ou seja, PABX legados e as operadoras telefônicas. Os PABX legados, pré-existentes nas instituições, podem ser totalmente integrados ao serviço fone@RNP. Inclusive, ligações entre telefones IP e telefones tradicionais poderão ser executadas com números abreviados (4 dígitos) e de forma transparente. Da mesma forma que o PBX, o GWT espera receber INVITES apenas no SRL. E também só deve encaminhar INVITES para seu SRL. Ele é capaz de entregar ligações na RTFC ou em um PABX legado com interface digital. Inicialmente, a RNP desenvolveu apenas um GWT para interfaces digitais de telefonia, RDSI ou R2Digital. Posteriormente, a RNP adaptou a configuração de um dispositivo de mercado para que ele seja utilizado no fone@RNP como um GWT analógico.

A imagens dos dispositivos estão disponíveis no repositório do fone@RNP, nos links: SRC http://repositorio-fone.rnp.br/fone2012/SRC/VM/release/1.0/update-20150327/SRC2012-M1.ovf GWT http://repositorio-fone.rnp.br/downloads/IMG_FONERNP_2012_20130613.iso SRL http://repositorio-fone.rnp.br/fone2012/SRL/VM/release/1.0/update-20150313/FoneRNP-SRL-v2.ovf PBX-IP Corp http://repositorio-fone.rnp.br/fone2012/PBX-IP/VM/release/2.0/FoneRNP-PBXIP-v3-m1/FoneRNP-PBXIP-v3-m1.ovf http://repositorio-fone.rnp.br/fone2012/PBX-IP/VM/release/2.0/FoneRNP-PBXIP-v3-m2/FoneRNP-PBXIP-v3-m2.ovf PBX-IP Acad http://repositorio-fone.rnp.br/fone2012/PBX-IP-ACAD/VM/1.0/stable/FoneRNP-PBXIP-ACAD.ovf


60


Com exceção do GWT, todos os dispositivos do novo fone@RNP podem ser implementados em máquinas virtuais. Além disso, todos eles podem ter duas instâncias, para fins de redundância, contribuindo para alta disponibilidade do serviço. Se uma máquina parar, a outra assume o trabalho automaticamente. O GWT é o único módulo que precisa ser implementado em uma máquina real, pois precisa de uma placa de telefonia para interligar com a rede de telefonia convencional. O GWT também pode ser embarcado em dispositivo próprio, especializado nessa tarefa. Neste caso, chamamos de GWT2.0, o “verdinho”.

[1] NRENum.net é um serviço ENUM para academia. Foi originalmente concebido no âmbito de TERENA (TransEuropean Research and Education Networking Association). Este serviço possibilita alcançar via VoIP números de telefones tradicionais nas Universidades dos países participantes. No momento da escrita desse artigo, 34 países fazem parte do NRENum.net. [2] PIT-VoIP é um serviço de Voz sobre IP oferecido pela RedCLARA para as redes acadêmicas (NRENs) associadas. Ele estabelece um relacionamento de confiança entre SIP proxies das NRENs da América Latina.


61


A arquitetura típica do fone@RNP A instituição típica Tipicamente, as instituições clientes do fone@RNP são multi-campi, ou seja, possuem prédios em vários locais distantes uns dos outros - o cenário perfeito para a utilização do fone@RNP.

Alguns clientes do fone@RNP possuem uma estrutura mais simplificada, às vezes, com apenas um prédio ou escritório. De qualquer forma, pode ser modelada aqui como uma simplificação da instituição típica apresentada nesse livro.

Características do cenário Reitoria: A reitoria possui um PABX digital, com uma ou mais interfaces E1, ligado diretamente na operadora telefônica. Pretende utilizar o PBX IP do fone@RNP para expandir seu serviço de telefonia e para economizar com chamadas telefônicas. Campus A: O Campus A é novo. O PABX existente é velho e não tem contrato de manutenção. Possui um link E1 para telefonia. O PABX antigo será substituído pelo PBX IP do fone@RNP. Campus B: Já possui PABX IP de outro fabricante. Interface com RTFC já está configurada e deve ser


62


aproveitada. Não haverá qualquer tipo de modificação nesse campus, além da participação no serviço. Campus C: O campus C é o menor e mais distante de todos. Possui um PABX com 4 troncos analógicos e alguns ramais. Outras considerações: ●

●

A instituição pretende utilizar o PBX IP acadêmico, para poder oferecer ramais para seus alunos. Eles poderão fazer qualquer chamada que não gere custo para nenhuma instituição cliente. A instituição estuda contratar um Provedor de telefonia pela internet (ITSP, a sigla em inglês) para conseguir melhores preços nas ligações para celulares. A adesão dos campi é opcional.

Observação: As situações descritas acima existem na rede do fone@RNP.

Arquitetura típica Sempre baseado na premissa que a rede IP (LAN e WAN) foi revisada pela instituição e é adequada, de forma que suporte o serviço de Voz sobre IP, é possível apresentar alguma solução para o ambiente proposto.


63


Fluxos de comunicação entre os dispositivos Fluxo de Sinalização A sinalização do ambiente de telefonia IP da RNP é, como já se sabe, baseada no protocolo SIP (RFC 3261). Utiliza como transporte para sinalização o UDP e não é criptografado. Abaixo, é apresentado o tráfego de sinalização esperado entre os componentes da arquitetura de referência, indicando as portas preferenciais para se utilizar no serviço do fone@RNP.

● ●

SRC (UDP 5060) <> SRL (UDP 5071); SRL (UDP 5060) <> PBX-IP ACADÊMICA (UDP 5080);


64


●

Telefone IP (UDP 5060) <> PBX-IP ACADÊMICA (UDP 5080);

● ● ●

SRL (UDP 5060) <> GWT (UDP 5071); SRL (UDP 5060) <> PBX-IP CORPORATIVA (UDP 5080); Telefone IP (UDP 5060) <> PBX-IP CORPORATIVA (UDP 5080);

● ●

SRC (UDP 5060) <> GWT (UDP 5071); SRL (UDP 5060) <> Central IP (5060).

Fluxo de mídia O fluxo de mídia (áudio/vídeo) utiliza portas altas negociadas na etapa de estabelecimento das chamadas. Também utiliza o protocolo UDP e não há criptografia. O CODEC preferencial é o G.711. Recomenda-se habilitar a função de media proxy nos seguintes componentes: ● SRL; ● PBX-IP ACADÊMICA. Caso seja utilizada a configuração recomenda por este documento, deverão existir os seguintes fluxos de mídia: ● SRL <> SRL; ● SRL <> PBX-IP ACADÊMICA; ● PBX-IP ACADÊMICA <> Telefone IP; ● Telefone IP <> Telefone IP.

Exemplos ilustrados para fluxo de mídia e sinalização Exemplo1: Telefone IP chamando número na RTFC

1. 2. 3. 4. 5.

INVITE do telefone IP para o PABX INVITE do PABX para o SRL INVITE do SRL par ao GWT Mídia entre Telefone e GWT, passando pelo PBX Entrega da ligação para RTFC pela E1 do GWT

NOTE que o SRC não toma conhecimento da chamada que ocorre dentro de uma instituição! NOTE também que o SRL não fica no caminho da mídia para chamadas entre peers.

Exemplo2: Telefone IP chamando outra instituição cliente


65


1. 2. 3. 4. 5. 6. 7.

INVITE do telefone IP para o PBX IP INVITE do PABX para o SRL da 1a instituição INVITE do SRL para o SRC INVITE do SRC para o SRL da 2a instituição INVITE do SRL para o PBX IP INVITE do PBX IP para o Telefone IP Mídia entre os dois telefones IP, mas passando pelos PABX e SRLs. a. Mídia NÃO passa pelo SRC. Nunca!

NOTE que o SRL fica no caminho da mídia para chamadas entre um peer e o ambiente externo.

Sobre firewall e portas de comunicação nos servidores Uma característica importante da tecnologia de voz sobre IP é que os firewalls precisam estar configurados corretamente para que a comunicação ocorra. Uma vez que firewalls são largamente utilizados e, de fato, são essenciais para segurança de redes, grande atenção deve ser dedicada à configuração desses dispositivos para que o fone@RNP funcione corretamente. Abaixo seguem as informações dos dispositivos do fone@RNP e as portas em que esperam receber pacotes.

#1 #2 #3 #4 #5 #6 #7 #8

Deve estar aberto somente para os peers, para maior segurança Somente entre entre os peers (Redundantes) Somente para hosts de gerência Somente para equipe de operação/manutenção Somente localhost Público Internet Provisionamento telefones CDR FONE/RNP


66


#9 Entre SRC e SRL (Fone2014) ORIGEM: SRC/SRL - Opensip udp/5060 #1 - ISC-Bind udp/tcp 53 #1 - MySQL tcp/3306 #2 - OpenLDAP tcp/389 #2 - SNMP udp/161 #3 - APACHE tcp/443 #4 - APACHE - FONE-ESTATISTICAS tcp/8443 #8 - APACHE - Troca de Rotas Automatizada (SRC e SRL) tcp/8443 #9 (Fone@2014) - ICMP/ECHO REQUEST/REPLAY #1 (Para medição da qualidade, fone@2014) ORIGEM: GWT - asterisk udp/5071 #1 - asterisk-rtp udp/10.000-20.000 #6 - ISC-Bind udp/tcp 53 #1 - MySQL tcp/3306 #5 - SNMP udp/161 #3 - APACHE tcp/443 #4 - ICMP/ECHO REQUEST/REPLAY #1 (Para medição da qualidade, fone@2014) ORIGEM: PBX-IP - Corp - Opensip udp/5080 #1 - ISC-Bind udp/tcp 53 #1 - media-proxy udp/50000:60000 #6 (se ativo) - MySQL tcp/3306 #2 - OpenLDAP tcp/389 #2 - RSYNC tcp/873 #2 - SNMP udp/161 #3 - APACHE tcp/443 #4, #7 - APACHE tcp/80 #6, #7 - ICMP/ECHO REQUEST/REPLAY #1 (Para medição da qualidade, fone@2014) ORIGEM: PBX-IP - Acadêmico - Opensip udp/5080 #1 - media-proxy udp/50000:60000 #6 (recomendado estar ativo, para o nathelper funcionar) - ISC-Bind udp/tcp 53 #1 - MySQL tcp/3306 #2 - OpenLDAP tcp/389 #5 - SNMP udp/161 #3 - APACHE tcp/443 #4 - APACHE tcp/80 #6 - ICMP/ECHO REQUEST/REPLAY #1 (Para medição da qualidade, fone@2014)

A maior parte dos problemas que tivemos na instalação do trio GWT + SRL + PBXIP foi por consequência de confusão na configuração das portas dos serviços. As portas UDP 10000-20000 devem ser liberadas a partir do GWT


67


As portas UDP 50000-60000 devem ser liberadas a partir do PBX-IP A porta UDP 5060 é para SRLs, a 5071 para GWT e a 5080 para PABX.

Seguem alguns endereços importantes na arquitetura: SRC-RJ 200.143.193.54 SRC-DF 200.130.35.113 Monitoramento SNMP da RNP 200.130.77.77 Serviço de estatísticas do fone 200.143.193.54:8443 Repositório de arquivos e imagens 200.130.35.236 Servidor de Hora 200.144.121.33:123 Servidor de Hora (alternativo) ----

------monitora.rnp.br ---repositório-fone.rnp.br ntp.cais.rnp.br a.npt.br; b.ntp.br; c.rnp.br

Outro resumo interessante para configuração de firewalls e dos próprios dispositivos: porta SIP do SRL é 5060 porta SIP do GWT é 5071 porta SIP do PBX é 5080 Sempre que estiver na dúvida, sempre que configurar um módulo do fone@RNP, volte aqui e revise os fluxos para configurar corretamente seu firewall.

Testes de chamadas (Checklist) Após a instalação da solução e depois de cada instalação de um módulo do fone será necessário testar se todos os tipos de chamadas podem ser realizados normalmente. Tomemos um hipotético Campus A como referência. Todas os tipos e direções de chamadas devem ser testadas, sempre que for cabível, conforme listadas abaixo.

Ligações dentro do Campus A ● ● ● ●

Ligações feitas a partir de telefones IP para telefones IP; Ligações feitas a partir de telefones analógicos para telefones analógicos; Ligações feitas a partir de telefones IP para telefones analógicos; Ligações feitas a partir de telefones analógicos para telefones IP.

Ligações “entrantes” no Campus A ●

●

●

Ligações para dentro do Campus A, com origem na RTFC ○ Para ramais IP; ○ Para ramais analógicos. Ligações para dentro do Campus A, com origem em outro Campus da mesma instituição ○ Para ramais IP; ○ Para ramais analógicos. Ligações para dentro do Campus A, com origem em outro cliente do fone@RNP ○ Para ramais IP; ○ Para ramais analógicos.


68


Ligações “saintes” do Campus A ●

●

●

●

Ligações para fora do Campus A, para outro Campus da mesma instituição ○ A partir de telefones IP; ○ A partir de telefones analógicos. Ligações para fora do Campus A, para outra instituição do fone@RNP no mesmo DDD ○ A partir de telefones IP; ○ A partir de telefones analógicos. Ligações para fora do Campus A, para outra instituição do fone@RNP em outro DDD ○ A partir de telefones IP; ○ A partir de telefones analógicos. Ligações para fora do Campus A, mas dentro da mesma cidade ○ A partir de telefones IP para números locais na RTFC ■ Celulares ■ Fixos ○ A partir de telefones analógicos para números locais na RTFC, celulares ou fixos. ■ Celulares ■ Fixos ○ Ligações para fora do Campus A, para números na RTFC em outro código de área ■ Celulares ■ Fixos ○ A partir de telefones IP para números DDD na RTFC ■ Celulares ■ Fixos ○ A partir de telefones analógicos para números DDD na RTFC ■ Celulares ■ Fixos

Ligações para serviços especiais 1XX 1XX XXXX 0X00 XXXXXXX 9090 XXXXXXXX 90CA XXXXXXXX Esses testes devem ser repetidos a cada modificação no serviço de telefonia, em todos os sites dos clientes.

Encaminhamento das chamadas Uma importante premissa do novo fone@RNP diz que o encaminhamento das ligações sempre deve ser feito de forma transparente ao usuário final.

O plano de numeração recomendado


69


Como já foi verificado em capítulo anterior, o Plano de Discagem (ou Plano de Numeração) descreve a forma como são realizadas as chamadas no serviço de telefonia. Além dos dígitos do Plano Nacional, os usuários dentro das instituições normalmente também precisam discar o 0 (zero) para “pegar linha” ou para simular essa situação em PBX IP, evitando mudar a cultura dos usuários. 0 (linha) + NÚMERO, para ligações locais; 0 (linha) + 0 (PrefixoLDN) + CSP + CA + NÚMERO, para ligações à distância e; 0 (linha) + 00 (Prefixo LDI)+ CSP + PC + (CA+NÚMERO), para ligações internacionais. A RNP recomenda manter o mesmo Plano de Numeração existente, independente da tecnologia ou da localidade. Então, não deve haver diferença na forma de discar, esteja um ramal atrás de um PABX IP ou tradicional, seja analógico ou digital.

Integração de PABX legado e IP utilizando 4 dígitos O fone@RNP foi desenhado de forma a permitir a fácil expansão da rede de telefonia de suas instituições clientes. A utilização de um PBX IP, juntamente com o GWT e SRL permite a integração dos ramais IP e legados através de discagem abreviada, tipicamente implementada com 4 dígitos. Também é possível utilizar 3 ou 5 dígitos. Além disso, através do serviço de DDR (das operadoras) também é possível encaminhar automaticamente ligações que chegam pela RTFC tanto para os ramais analógicos quanto para os ramais IP, no novo PBX IP. Obviamente, a solução final depende de análise do plano de numeração e da distribuição de DDRs em cada instituição.

Planejamento para instalação do fone@RNP É importante que não só os procedimentos de instalação, mas também as características do serviço na sua instituição estejam claramente documentadas. Então, escreva um Plano de mudança para sua instituição. Se desejar, utilize o Plano de Mudança de exemplo, que se encontra na seção de anexos, adaptando para a realidade de sua instituição.


70



71

Capítulo 05 Módulo Gateway Transparente



Capítulo 5 – Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)


72



Sobre o Gateway Transparente - GWT O Gateway Transparente (GWT) é o módulo fundamental do novo fone@RNP. Ele faz a ligação entre o serviço de telefonia digital tradicional das instituições e o serviço de telefonia IP da RNP de forma transparente, isto é, sem que o usuário do serviço telefônico precise decidir se quer usar ou não o fone@RNP. Com este módulo, o fone@RNP consegue alcançar reduções expressivas na conta de telefonia das instituições clientes, com valores de cerca de 30% a 80% das chamadas à longa distância para números fixos. Mas atenção, este número pode variar bastante, para mais e para menos, dependendo do perfil de cada instituição.

O GWT foi desenhado para trabalhar com outros módulos do fone@RNP e com quaisquer PABX legados, pré-existentes nas instituições. Ele espera receber INVITES apenas do SRL ou SRC. E também só deve encaminhar INVITES para seu SRL ou SRC. Ele é capaz de entregar ligações para serem terminadas na RTFC ou em um PABX legado com interface digital. O GWT suporta os protocolos RDSI – Rede Digital de Serviços Integrados (em inglês, ISDN – Integrated Services Digital Network) ou R2Digital (R2D) nas interfaces de telefonia e suporta o protocolo SIP versão 2 na interface IP, de acordo com a RFC 3261.


73


O GWT é uma solução formada por um conjunto de partes, cada uma com uma função específica. É possível destacar 4 partes principais:

•

•

•

•

Programas do fone@RNP o Em conjunto com o Sistema Operacional (Ubuntu), Asterisk, OpenSIPS, OpenLDAP, Mysyql, Apache e outros, é responsável pela interface gráfica de configuração do GWT, pelo backup das configurações e pelo funcionamento do GWT em conjunto com o serviço fone@RNP. Servidor (com interface de rede IP) o Responsável por abrigar o Sistema Operacional e programas do GWT. Pode variar bastante, tanto no poder computacional quanto de fabricante ou montador. Não há rigidez quanto à requisitos de disco, memória ou mesmo velocidade da CPU. De forma geral, um servidor mediano atual é suficiente. Placas de telefonia digital (E1) o Responsáveis pela interface com a rede de telefonia tradicional. A RNP começou utilizando placas fabricadas pela Digium, a mesma empresa responsável pela evolução do Asterisk, mas depois evoluiu e está utilizando atualmente placas da empresa brasileira Khomp, sediada em Florianópolis. Kommuter o Dispositivo de fabricação nacional, também pela Khomp, responsável pela sobrevivência do serviço de telefonia no caso de parada do servidor.

GWT 2.0 Em 2013, foi testada e aprovada uma solução de hardware para telefonia com portas E1 e Kommuter integrados, de fabricação nacional, onde seria possível embarcar todo o software necessário ao funcionamento do GWT, integrando totalmente as 4 partes citadas acima. A essa solução a RNP deu o nome de GWT 2.0. Essa ação facilitou substancialmente os processos de: • aquisição de hardware, eliminando importações • composição da solução, reduzindo o número de fornecedores • instalação do software, que agora virá pronto, já embutido no hardware • manutenção, já que o fornecedor é nacional e com ótimo relacionameneto com a RNP. Portanto, restou ao cliente do GWT 2.0 ligar os cabos e configurá-lo.

Este capítulo tratará da configuração do Gateway transparente 2.0, implementado em hardware nacional, da empresa Khomp. Para informações sobre como instalar o GWT com servidores Dell + Placas Digium + Kommuter, veja a parte de anexos.

Gateway Transparente 2.0

O GWT 2.0 é módulo do fone@RNP GWT embarcado em hardware nacional que já contempla portas E1 para telefonia digital, by-pass (kommuter) e todos os recursos computacionais necessários para rodar o fone@RNP.


74


1. Ligando os cabos A ligação física do GWT 2.0 é muito fácil. Reserve o cabo de força para liga-lo apenas no final da operação. Tomemos por base a figura que apresenta a visão da parte de trás do GWT. Há pelo menos 5 portas que parecem ser portas ethernet. As duas portas da metade superior estão sobre um fundo preto. Este é o módulo das placas E1. Portanto, não são portas de rede! A porta E1 que fica mais à esquerda deve ser ligada ao balun que vai ligar ao tributário da operadora. A porta E1 que se localiza à direita deve ser ligada ao balun que vai se ligar ao PABX da instituição. Há a possibilidade do GWT apresentar mais módulos. Note que há mais dois espaços para inserção de módulos adicionais. As portas que se localizam na metade de baixo são as portas de rede. Utilize a porta mais à esquerda para ligar o cabo UTP ao seu swtich. Deixe as demais portas livres. Por fim, ligue o cabo de energia e ligue o GWT.

Internet SRL ou SRC Fone@RNP


75


2. ACESSANDO E CONFIGURANDO O GWT

2.1.

Configurando uma estação para acessar o GWT

Para ilustrar este guia, foi utilizando o sistema operacional Windows 7. Caso você esteja utilizando outra versão do Windows ou mesmo outro sistema operacional, será necessário adequar as instruções à sua estação de trabalho. O GWT vem pré-configurado com o endereço IP 10.255.255.1. Para acessá-lo, coloque seu desktop ou outra máquina no mesmo segmento de rede, por exemplo: 10.255.255.5. Clique no botão “Iniciar”, “Painel de Controle”, “Rede e Internet”, “Central de Rede e Compartilhamento” e do lado esquerdo escolha, “Alterar as configurações do adaptador” (Figura 1):

Figura 1

Aparecerá a tela conforme imagem da Figura 2:

Figura 2


76


Clique com o botão direito na placa de rede do computador, e escolha a opção “Propriedades” (Figura 3):

Figura 3

Selecione “Protocolo TCP/IP Versão 4” e clique em “Propriedades” (Figura 4).

Figura 4


77


Selecione a opção “Usar o seguinte endereço IP:” e preencha os campos de acordo com a Figura 5. Clique em OK para salvar a configuração.

Figura 5

Para testar, execute um comando através do prompt de comando. Clique no botão “Iniciar”. No campo destinado a “Pesquisar programas e arquivos”, digite CMD e tecle ENTER (Figura 6).


78


Figura 6

Na tela do prompt digite: “ping 10.255.255.1”, tecle ENTER. O resultado deve ser semelhante à Figura 7.

Figura 7

Feche o prompt e, utilizando o navegador de sua preferência, digite o endereço “ https://10.255.255.1” (Figura 8). Neste guia, foi utilizado o Google Chrome.


79


Figura 8

Ignore o aviso do certificado auto assinado. Clique em “Continuar mesmo assim”.

2.2.

Acessando e configurando o GWT

Seguindo os passos anteriores, será exibida a tela de login:


80


Figura 9

Informe os seguintes dados para o acesso: Usuário: Password:

admin gwt.admin

Troque a senha padrão do administrador imediatamente!! Após fazer o acesso, será exibida a tela inicial, semelhante à Figura 10. Observe no canto superior direito que o módulo “Gateway” está selecionado. Esta é a tela de monitoramento do GWT, que indica quais serviços estão funcionando ou não, informações do hardware, informações de rede e outros detalhes.


81


Figura 10

Para fazer a configuração do GWT, acesse a tela de administração do sistema, clicando em “Sistema” no canto superior direito (Figura 10 (1)).

Figura 11

Nesta tela é possível criar um novo usuário (3), ou editar as informações de um usuário existente (4), além de fazer as configurações para o funcionamento do equipamento (2).


82


Inicialmente, edite o usuário Admin e ALTERE a senha padrão, para uma que você tenha controle (Figura 12).

Figura 12

Feitas as configurações anteriores, devemos em seguida configurar o firewall para evitar a perda de acesso ao servidor, quando este for configurado com IP público.

2.2.1.

Configurações ->Firewall

O início da configuração do GWT será feito pelo firewall, pois será preciso cadastrar o IP da máquina e/ou rede que fará a gerência do GWT. Se for feita alguma alteração de IP antes da configuração da gerência, poderá ocorrer a perda do acesso ao GWT. No menu “Configurações” clique na opção “Firewall”. Role a página até o final e localize a área que contém “Rede de Gerência” (Figura 13).


83


Figura 13

Observe na Figura 14, que o IP 10.255.255.0, está cadastrado, e deve permanecer assim até a finalização da configuração, pois ele permitirá acesso a esta rede caso algo saia errado. Você deve removê-lo em uma segunda etapa.

Figura 14

Agora inclua as demais redes de onde você poderá realizar manutenção no GWT. Clique no botão e informe o IP da máquina/rede que fará o acesso ao GWT e a máscara da rede, conforme exemplos na Figura 14. Clique em “Salvar” e depois em “Aplicar Configurações”. Na área “Ações”, ainda na página do Firewall (Figura 15), forneça os IPs que poderão enviar mensagens SIP ao GWT (no caso SRC ou SRL). Se o ambiente estiver conectado ao SRL, somente esses IPs são necessários. Insira também a porta 8443 TCP com origem no endereço IP 200.143.193.54/32. Este é o servidor que busca informações de CDR para o sistema de estatísticas nacionais.


84


Seguem alguns endereços importantes na arquitetura: SRC-RJ 200.143.193.54 SRC-DF 200.130.35.113 Monitoramento SNMP da RNP monitora.rnp.br Serviço de estatísticas do fone 200.143.193.54:8443 Repositório de arquivos e imagens repositório-fone.rnp.br Servidor de Hora ntp.cais.rnp.br Servidor de Hora (alternativo) a.npt.br; b.ntp.br; c.rnp.br Após configurar o firewall revisando os parâmetros de sua instituição, clique em Salvar e depois Aplicar.

Figura 15

1.2.2. Configurações -> Ambiente: Configuração Inicial Nesta opção, o administrador poderá inserir ou editar configurações de funcionamento do serviço FONE@RNP. No menu “Configurações”, do lado esquerdo da página, na opção “Ambiente” (Figura 16), existem algumas guias que serão descritas a seguir.


85


Figura 16

a) Guia Instituição Guia que contém as informações da instituição e do responsável pela administração do serviço Fone@RNP. Clique na guia Instituição e preencha com os dados do solicitados. Ao concluir clique em “Salvar Alterações”.

Figura 17

Ø Sigla: Sigla corresponde a instituição que está sendo instalado o GWT. Não deve ser utilizado espaços em branco nem mais de uma palavra para a sigla. Caso necessário, utilize um traço; Ø Campus: Campus ou unidade correspondente a instituição em que está sendo instalado o GWT; Ø Nome da Instituição: Nome completo da instituição; Ø Nome do responsável para contato: Nome da pessoa que ficará responsável pelo serviço na instituição; Ø Telefone para contato: Telefone de contato do responsável, preferencialmente, telefone móvel; Ø E-mail para contato: Correio eletrônico de contato do responsável.


86


b) Guia Sistema

Guia responsável pelas configurações do Sistema do GWT, abaixo a descrição de cada campo, conforme mostrado na Figura 18.

Figura 18

Ø Hostname: Nome do servidor no domínio. Não deve conter espaços em branco; Importante: No “Hostname” a padronização adotada para o FONE@2014 é “GWT-sigla da instituição”, Ex.: O IFPE Campus de Garanhuns/PE, por exemplo, será “GWT-IFPEGUS”. Ø IP: Preencher com o IP que será destinado ao GWT. ESTE IP DEVE SER PÚBLICO; Ø Máscara: Máscara de Rede do IP; Ø Gateway: IP do Gateway da rede; Ø NTP1 e NTP2: Endereços dos servidores de NTP (Ex. ntp.cais.rnp.br, a.ntp.br, b.ntp.br); Ø DNS Resolver1 e DNS Resolver 2: Esses servidores de nomes devem ser capazes de resolver zonas de ENUM; Ø Domínio: O domínio ao qual o GWT pertence.

Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Alterações”.

c) Guia Aplicar Configurações Após configurar o ambiente, é necessário aplicar as configurações do sistema, para que todas as alterações surtam efeitos. Para isso, você deve acessar no menu “Ambiente”, a opção “Aplicar Configurações”, conforme Figura 19.


87


Figura 19

Ø Configurações de Sistema: quando selecionada, aplica as configurações que foram feitas no que se diz respeito ao sistema, como alterações nas guias Instituição, Sistema e Gerência; Ø Configurações de Asterisk (TDM, ENUM, Proxy SIP): quando selecionada, aplica as configurações que foram feitas no que se diz respeito ao GWT e seus serviços. Marque as duas caixas de opção (“Configurações de Sistema” e “Configurações de Asterisk” e clique no botão “Aplicar configurações selecionadas”. Lembre-se após esse procedimento, você perderá o acesso ao GWT. Para obter novamente o acesso ao GWT, você terá que reconfigurar a rede da sua máquina e acessar, via browser, o novo IP que foi configurado no GWT. Após alterar o IP da máquina, o Suporte do FONE@RNP deverá efetuar a liberação do IP do GWT (IP público) no repositório do serviço de modo que possa fazer as atualizações disponíveis.


88


1.2.3. Configurações -> Sistema: Atualizando o GWT

No menu “Configurações”, selecione “Sistema” e, em seguida, a opção “Atualizações”. Se houver alguma atualização disponível, será exibido conforme a figura 20. Para atualizar, basta clicar então em “Atualizar aplicações” e aguardar a execução do procedimento. Na sequência, clique na guia “Ações” e em “Reiniciar Servidor”.

Figura 20

1.2.4. Configurações-> Ambiente: Finalizando a Configuração

a) Guia Gerência Nesta tela é possível definir comunidades SNMP de Read-Only para gerência do ambiente,

desviar logs para um servidor centralizado e ainda definir um servidor para envio de e-mails. No quadro SNMP, configure com sua comunidade e a rede de gerência, caso sua instituição possua um sistema de gerência de redes. O serviço de monitoramento da RNP já é automaticamente inserido e não fica explícito aqui. Você deve apenas configurar a firewall para permitir o acesso do servidor da RNP. O servidor de e-mail permite realizar relay de forma autenticada. Se você tem um relay de emails em sua instituição, configure com esse parâmetro para receber mensagens de alerta desse módulo do fone. Você também pode configurar um servidor de syslog. Para desabilitar o relay para um syslog externo, forneça o endereço 127.0.0.1.


89


Figura 21

b) Guia TDM Nesta opção, serão definidos os prefixos dos números da instituição, e como será realizado o

encaminhamento interno no GWT. Na área “Telefonia convencional”, deve ser informado os dados atuais de telefonia da instituição.

Figura 22


90


Ø Código do País: Não é necessário incluir o sinal ‘+’. Digite 55 para Brasil; Ø DDD: Deve ser preenchido com o código de área da localidade da instituição cliente; Ø Prefixo: São os 4 primeiros dígitos do número telefônico da instituição. Por exemplo, a RNP-RJ possui o número (21) 2102-9660. O prefixo é 2102; Ø Código da Operadora: É o CSP, código de seleção da prestadora. Ex: 31 (Oi), 21 (Embratel); Ø Linha Externa: Se existe algum número programado, para ser digitado para acessar a PSTN. Normalmente, é utilizado 0 (“para dar linha”). Caso não possua, deixe em branco. Ø Ramal PBX Inicial e Final: Informações da faixa de ramal PABX convencional, onde o GWT encaminhará as chamadas recebidas para o tronco conectado ao PABX. Os campos na área “VoIP” devem ser preenchidos com informações fornecidas pela RNP: Ø Prefixo: São os 4 primeiros dígitos (do total de 8 dígitos) dos números de telefones virtuais. Esses prefixos são informados pela RNP ao cliente durante a adesão e são válidos APENAS dentro do serviço Fone@RNP; Ø Ramal Inicial: São os 4 últimos dígitos (do total de 8 dígitos) que especificam o primeiro ramal do intervalo que o cliente deseja utilizar como números virtuais. Esses números são determinados pelo administrador do fone@RNP na instituição; Ø Ramal Final: São os 4 últimos dígitos (do total de 8 dígitos) que especificam o último ramal do intervalo que o cliente deseja utilizar como números virtuais. Esses números são determinados pelo administrador do fone@RNP na instituição; Ø Ramal Padrão de Saída: é o número que será apresentado como origem das chamadas feitas pela instituição. Normalmente, se utiliza o tronco-chave; Ø Ramal da URA: É o ramal que deve ser discado para acesso ao sistema de telefonia IP, utilizado no fone versão 2008. Está presente aqui para fins de compatibilidade com as versões anteriores do fone. Área externa Ø Valor do Minuto: Valor estimado do custo do minuto de uma chamada telefônica. Utilizado para cálculo aproximado da economia. Os Botões de período de contabilização são utilizados para definir o intervalo de tempo que se deseja apresentar a estimativa de economia.

c) Guia ENUM O GWT utiliza mais de uma árvore ENUM em sua lógica interna para encaminhamento das chamadas.


91


Nesta guia, deve-se definir quais tabelas ENUM o GWT irá consultar para verificar se existe rota IP para o número discado. Caso o GWT esteja conectado ao SRL, deverá ser habilitada a tabela local para ativar a consulta de rotas do SRL criadas pela instituição.

Figura 23

Ative todas as tabelas de pesquisa. Clicando em “Selecionar” (Figura 23) em todas as opções. Só ative a tabela ‘Local’ se estiver utilizando o SRL. Em seguida, clique em “Salvar as Alterações” (Figura 24).

Figura 24

d) Guia Proxy SIP Define as informações referentes ao GWT e IPs do SIP-Router (Central ou Local) (Figura 25).

Figura 25

Ø Realm VoIP: Colocar o voiprealm da instituição. Ex: ufsc.br ou voip.ufsc.br; Ø IP do Gateway: Endereço IP no qual o GWT irá escutar. Esse endereço deve ser o mesmo fornecido da Guia Sistema, campo IP (Figura 18);


92


Ø Porta do Gateway: Recomenda-se deixar a padrão: 5071; Ø IP SIP Router: Colocar os endereços do SRL ou SRC, de acordo com a topologia escolhida.

e) Guia Serviços Habilitados Para iniciar um serviço basta clicar em “Selecionar”, e para parar clique em “Cancelar”.

Figura 26

Após finalizar as configurações do ambiente, repita o procedimento para aplicar as configurações, conforme descrito no item 1.2.2 c.

1.2.5. Configurações-> Placas: Configuração das Placas E1

Para acessar o módulo de configuração do EBS da Khomp, clique em “Mostrar Módulo de Configurações Khomp” (Figura 27). Feito isto será exibida a tela conforme Figura 28.


93


Figura 27

Para acessar o módulo de configuração Khomp, utilize as credenciais: Usuário: config Senha: config


94


Figura 28

Após o acesso, será exibida a tela conforme Figura 29.

Figura 29


95


Na interface da Khomp, selecione as opções “Configuração”, “Dispositivos”, “Procurar” (Figura 30).

Figura 30

Selecione o dispositivo encontrado e clique em “Adicionar” (Figura 31).


96


Figura 31

Clique na imagem do dispositivo para fazer a sua configuração (Figura 32).

Figura 32

Será exibida a tela conforme a figura 33, onde você deverá configurar o IP e o sincronismo das placas. Utilize o IP 192.0.2.201.


97


Figura 33

A seguir, configure o tipo de sinalização utilizado no seu link e o clock. O link 1 será o link da operadora e deverá “Receber” o clock. O link 0 irá “Gerar” clock (Figura 34). Ao final, clique em “Salvar”.

Figura 34


98


Deve-se alterar o número de dígitos de entrada dos canais R2. Para a placa da PBX configure com 20 dígitos e para a placa da PSTN configure com 4 ou 8, dependendo de quantos dígitos serão de identificação serão encaminhados para a operadora (Figura 34a).

Figura 34a

Você será redirecionado para a visão do dispositivo, conforme a Figura 35, onde não mais consta o erro exibido anteriormente (Figura 32).

Figura 35


99


Em seguida, habilite o serviço Asterisk em “Ambiente”, “Serviços Habilitados” e clique em “Salvar Alterações”. (Figura 36).

Figura 36

Ao acessar, pela interface do Khomp, a opção de monitoração dos serviços, você poderá obter um erro conforme Figura 37.

Figura 37


100


Caso isto ocorra, reinicie o servidor no menu “Sistema”, “Ações”, “Reiniciar Servidor” (Figura 38).

Figura 38

Acesse novamente a opção de monitoração dos serviços Khomp e verifique se o serviço Asterisk está ativo (Figura 39). Observe que agora já são exibidas as interfaces dos links 0 e 1.

Figura 39


101


O próximo passo é fazer a configuração das placas. Selecione a primeira placa, clicando no ícone da coluna “Editar”, e preencha os dados conforme mostrado na Figura 40. Esta placa refere-se ao contexto da PBX.

Figura 40

Em seguida, configure a segunda placa com o contexto PSTN, conforme demonstrado na Figura 41.


102


Figura 41

Volte ao menu “Ambiente”, “Aplicar as Configurações”. Seleciona a opção “Configurações de Asterisk” e aplique as configurações selecionadas (Figura 42).

Figura 42


103


Habilite em seguida o Kommuter, no menu “Ambiente”, “Serviços Habilitados”, e salve as alterações, aplicando novamente as configurações em seguida.

Figura 43

1.2.6. Configurações-> Backup Esta opção permite a criação de arquivos de backup, bem como restaurar a configuração importando as informações de um arquivo de backup existente. Caso aconteça alguma falha de hardware no servidor ou por algum motivo você tenha que trocálo, os dados de configuração de seu ambiente podem ser facilmente restaurados, otimizando o tempo de instalação e configuração.

Figura 44

Crie um arquivo de backup, clicando no botão “Backup do arquivo M4”, e escolha onde irá guardar o arquivo. Caso seja necessário restaurar as configurações, basta clicar no botão “Escolher arquivo” e apontar onde o arquivo M4 estaria e em seguida clicar no botão “Enviar”.


104


2. MONITORAMENTO Na figura 26, no início deste documento, foi mostrado na tela com o módulo Gateway (Canto superior direito da página) ativado. Nesta página serão apresentados erros de não conformidade com algum serviço monitorado, que merece atenção e devem ser corrigidos para evitar problemas de disponibilidade ou segurança.

Figura 45

Clique no módulo “Gateway” (canto superior direito da página) para abrir a página de monitoramento (Figura 51). Observe que quando executado a ação anterior, no lado esquerdo da página nas opções do menu “Monitoramento”, podemos escolher “TDM” ou “Canais”. Clique na opção “TDM”

Figura 46


105


Quando clicado na opção “TDM” (Figura 52) é possível monitorar as interfaces (placa 1 e placa 2) conectadas na PABX e PSTN, informando visualmente um status das interligações. A Figura-53 mostra como ficará a tela após tudo configurado corretamente.

Figura 47

Clique no botão “Detalhes”

Ao clicar no botão “Detalhes”, sua página deve ficar semelhante à Figura 54. Onde são exibidos todos os canais de comunicação e seu status.

Figura 48

É possível também visualizar o que está sendo trafegado no GWT, no menu “Configurações”, clicando em Canais, depois em “Detalhes”

, e será exibida uma tela semelhante à Figura 55. Observe que existe

uma ligação em andamento. O sistema mostra as duas ‘pernas’ da ligação.


106


Figura 49

3. CONTABILIZAÇÃO No menu contabilização, existem as opções que nos dão relatórios de como está o comportamento do serviço Fone@RNP no GWT. Neste menu existem as opções: Estatísticas, Chamadas Completadas, Não Completadas e Mais Chamados (Números mais discados).

3.2. ESTATÍSTICAS Nesta opção “Estatísticas” do menu “Contabilização” é possível acompanhar a observar graficamente as estatísticas das ligações do ambiente. Abrange ainda estatística de “Estimativa de Economia” e exibe os valores em moeda corrente, observe a Figura 56.

Figura 50

3.3. COMPLETADAS Na opção é mostrado o CDR (Call Detail Record ou Registro de Detalhes da Chamada - registro de uma ligação (conexão) telefônica) das chamadas completadas pelo GWT. Esta tela também exibe o tipo de terminal utilizado para fazer essa ligação: se foi IP, PSTN ou PABX. Observe a Figura 57.


107


Figura 51

3.4. NÃO COMPLETADAS Mostra o CDR das chamadas não completadas pelo GWT (Figura 58), informa o motivo por que não completou e com o tipo de terminal utilizado para realizar a chamada IP, PSTN ou PaBX. Note que chamadas “não completadas” nem sempre significa um problema. Uma ligação para um número ocupado ou inexistente gera um registro (CDR) de não completamento.

Figura 52


108


3.5. MAIS CHAMADOS Em “Mais Chamados”, no menu “Monitoramento”, o administrador tem acesso as informações de

uma base de reputação do GWT, onde fornece informações sobre os destinos. Este relatório foi desenvolvido para ajudar a detectar falhas em alguma entrega através de rede IP (Figura 59).

Figura 53


109


Gateway Transparente Analógico (GWTa) Uma das solicitações mais recorrentes que a equipe do fone@RNP recebia das instituições era uma solução para que as instituições que não possuem enlaces digitais E1 pudessem participar ativamente do serviço. Inicialmente, foi esboçada a especificação de uma solução a qual teria capacidade de atender aos requisitos funcionais da demanda. Em continuidade a esta ação, foi iniciada uma busca nos sites (Internet) e agendada reuniões com os principais fabricantes, objetivando identificar quais equipamentos poderiam funcionar como GWT analógico. Após essas ações com os principais fabricantes de equipamentos de telefonia IP com sede ou representante no Brasil, identificamos que o aparelho CIP850, fabricado pela Intelbrás, possui características compatíveis com o tipo de uso proposto e capaz de atender as especificações mínimas. Adicionalmente, o equipamento apresentou opções de uso superiores as necessidades definidas. Muito simplificadamente, o CIP850 possui capacidade para 50 ramais (ou troncos) SIP, mais 8 portas analógicas, FXS ou FXO, agrupadas de 2 a 2. É importante ressaltar que outros equipamentos também podem ser utilizados, como Gateways AudioCodes ou um conjunto de servidor + placas Digium). Entretanto, do ponto de vista financeiro, o equipamento utilizado aqui é significativamente mais barato que outras soluções estudadas. ATENÇÃO!! O CIP850 não conta com Firewall interna!! Recomendamos fortemente sua instalação atrás de um firewall. Recomendamos fortemente a troca da senha de administrador imediatamente após o primeiro acesso ao equipamento. Recomendamos fortemente utilizar senhas fortes para os ramais! JAMAIS use como senha o mesmo número do ramal ou o nome do usuário ou qualquer combinação desses dois!

Roteiro para instalação e configuração

CIP850 no fone@RNP 2012 O que é o CIP 850? O equipamento CIP850 fabricado pela empresa brasileira Intelbras é um PABX IP de pequeno porte com interfaces analógicas para ramais e para troncos (FXSes e FXOs) e conta também com a possibilidade de criar ramais e troncos IP através do protocolo SIP ou IAX.

Características básicas ● ● ● ●

Capacidade máxima de 50 afiliações (troncos + ramais) Capacidade máxima de 8 portas analógicas para FXO/FXS (Modularizado de 2 em 2) Suporte a cancelamento de ECO de 16ms Suporte a Codecs de Áudio (G711, G729) e Vídeo (H.261, H.263, H.263+, H.264)


110


Objetivo O principal objetivo no uso do CIP850 é a possibilidade de integrar ao fone@RNP pequenos escritórios onde exista troncos analógicos. Existe também a possibilidade da utilização integrada de telefones analógicos e telefones IP diretamente nesta unidade. O CIP850 pode ser utilizado como única solução de telefonia em unidades pequenas. O equipamento conta com recursos como grupo de ramais, definição de categorias, salas de conferência, correio de voz, etc. Entretanto, o escopo desse trabalho não prevê a configuração de tais recursos. Pré-requisito para utilização do CIP850 Deve existir uma instância do SIP Router Local (SRL) na instituição atendida pelo CIP850. Cenário considerado

Especificações técnicas

Capacidade máxima

50 linhas e/ou ramais IP 8 linhas e/ou ramais analógicos

Atendimento Automático DISA

Incorporado

Identificação de chamadas

Incorporado via DTMF e/ou FSK

Codecs de áudio

G.711 U/A, G.729

Codecs de vídeo

H.261, H.263, H.263+, H.264

Numeração dos ramais

Flexível (qualquer número)

Peso

2 Kg


111

Capítulo 05 Módulo Gateway Transparente Dimensões

432 x 44,45 x 169 mm

Alimentação AC

90-240 Vac Bivolt automática, 50 ou 60 Hz

Potência máxima

14 W

Alcance de linhas e ramais

Linhas: 2000 Ohms Ramais: 1100 Ohms (incluindo o telefone)

Proteção elétrica

Nos troncos, ramais e alimentação AC contra transientes e oscilações da rede

Proteção de programação

Uso de memória flash

Cancelamento de ECO

16 ms

Interface Ethernet

1 porta RJ45 10/100

Protocolo SIP

SIP Intelbras (solução proprietária compatível SIP 2.0)

Processador

Blackfin BF 537 600 MHz

Memória

Flash NAND 256 MB


112


Painel Frontal

LED no Painel Frontal

Painel Traseiro


113


Instalação Física do CIP 850 Instalação das placas FXOs e FXSs O PABX IP CIP 850 possui a capacidade máxima de 8 portas FXO e/ou FXS. As 8 portas são definidas através de placas modulares para uso da interface em 2 em 2 portas. Caso o equipamento não esteja com os módulos previamente instalados, será preciso que siga os seguintes procedimentos: 1. Desconecte a central da alimentação elétrica; 2. Retire os parafusos da parte posterior da central; 3. Com a central aberta encaixe as placas conforme a figura a seguir:

Identifique a porta que a interface FXO e/ou FXS estará conectada

Montagem em rack 19” (EIA) As dimensões da central CIP 850 atendem ao padrão EIA - Electronic Industries Alliance, permitindo sua instalação em Rack 19 polegadas. A central CIP 850 necessita de 1 U de altura disponível no Rack para sua correta fixação. Para instalar corretamente o equipamento no Rack, siga os seguintes procedimentos: 1. Desconecte a central da rede elétrica; 2. Instale os dois suportes em L (acompanham o produto), parafusando-os nas laterais da central, conforme figura a seguir:

3. Escolha a posição desejada no rack e parafuse a central, conforme figura a seguir:


114


Fixação da central no rack 4. Conecte o cabo de alimentação à central em uma tomada elétrica; 5. Conecte a central à rede através da porta Ethernet e conecte as linhas ou aparelhos telefônicos às portas analógicas (caso as interfaces FXS e/ou FXO estejam instaladas). Atenção: Para garantir a ventilação correta e a dissipação do calor, não obstrua as laterais da central.

Montagem em uma superfície lisa A central pode ser posicionada sobre uma superfície lisa como uma mesa ou uma prateleira. Para instalar neste tipo de ambiente, siga o seguinte procedimento: 1. Desconecte a central da rede elétrica; 2. Fixe os quatro pés de borracha (acompanham o produto) na base da central, conforme a figura a seguir. Os pés de borracha são autoadesivos, retire a proteção para possibilitar a colagem;

Fixação dos pés de borracha 3. Conecte o cabo de alimentação à central e, em seguida, a uma tomada elétrica; 4. Conecte a central à rede através da porta Ethernet. Conecte as linhas ou aparelhos telefônicos às portas analógicas (caso as interfaces FXS e/ou FXO estejam instaladas).


115


Aterramento O aterramento é realizado pelo cabo tripolar que acompanha o produto.

Acoplamento Na falta de energia elétrica, a central realiza o acoplamento. Para que ocorra o acoplamento, os jumpers J5 e J6 (placa CPU) devem estar fechados. Para o correto funcionamento do acoplamento, obrigatoriamente deverá constar no slot 1 uma placa FXO, e no slot 4 uma placa FXS. Caso não exista a conexão de placas distintas ou na ordem pré-definida, os jumpers deverão permanecer abertos, conforme padrão de fábrica. Obs: Os jumpers J5 e J6 são abertos de fábrica.

Configuração Lógica da Central Definições e Conceitos básicos Para correta configuração da central, alguns conceitos devem ser entendidos, tais como:

•

Juntores: Troncos que permitem aos ramais realizarem e receberem ligações externas. Os juntores operam como sendo a ponte de conexão entre a central privada e a pública. Pode-se configurar juntores analógicos, SIP e IAX.

•

Ramais: Usuários que podem originar e receber chamadas, operando como linhas telefônicas internas. A central CIP 850 disponibiliza a configuração de ramais analógicos, SIP e IAX.

•

Rota: As rotas são utilizadas pelos ramais para efetuar chamadas externas (para rede pública, outra central ou um provedor de serviços VoIP) através dos juntores.

Plano de numeração da Central A Central CIP 850 tem um plano de numeração completamente configurável. Além de permitir a troca de numeração dos ramais, podem ser alterados os códigos das funcionalidades oferecidos aos usuários.


116


Sinalização dos aparelhos telefônicos A central CIP 850 somente trabalha com sinalização por tom, não suportando a sinalização por pulso (decádico). O uso das teclas * ou # é essencial para utilização dos serviços disponibilizados ao usuário.

Configurando a Central A central CIP 850 é configurada através do programador web. Para acessá-lo, o endereço IP da central deve estar na mesma faixa de endereço IP da rede do(s) computador(es) que fará(ão) a configuração.


117


Informações de fábrica ao iniciar o uso do CIP 850

•

Endereço IP: 10.0.0.50 •

Máscara: 255.0.0.0

•

Login: admin

•

Senha: 1234

Para alterar o IP de fábrica da central CIP 850 (10.0.0.50), conecte a central CIP 850 diretamente ao computador, conforme a figura a seguir.

No computador, coloque o endereço de rede, na mesma faixa do endereço de rede de fábrica

da

central

10.0.0.51/255.0.0.0).

CIP

Desta

850

forma,

(ex.: pode-se

acessar no navegador o IP de fábrica da central CIP 850 e alterar a rede conforme necessidades.

Abra o browser de sua preferência e acesse http://10.0.0.50 utilizando o usuário admin e a senha 1234. Observação: Sempre que realizar qualquer alteração clique no botão Aplicar/Salvar para que não perca a configuração.


118


Alterar senha do usuário para acesso WEB Para alterar a senha do usuário no acesso WEB do CIP 850, é preciso acessar o Sistema e a opção Configurações. A aba Geral já será carregada automaticamente.

TROQUE A SENHA DE ADMINISTRADOR AGORA!

Configurando a interface de rede Para alterar o endereçamento IP do CIP 850, é preciso acessar o Sistema e a opção Configurações. E escolha a opção Rede. Para o projeto fone@RNP o equipamento pode estar associado a um IP Privado, contudo, a saída da rede privada obrigatoriamente deverá ter um IP fixo associado.


119


Alterar configuração de Data e Hora Para alterar as configurações de Data e Hora do CIP 850, é preciso acessar o Sistema e a opção Configurações. Selecione a aba Data/Hora.


120


Alterar configuração de SIP

Para

alterar

as

configurações

básicas do protocolo SIP no CIP 850, é preciso acessar o Sistema e a opção Configurações. Selecione a aba SIP. No campo Endereço Externo é essencial que se cadastre o valor do IP fixo associado ao NAT na qual será identificado pelo SRL. No campo Bind Address é o endereço IP do equipamento CIP 850.


121


Criando Juntor CIP850 para acesso ao fone@RNP Para cadastrar o Juntor (tronco) do fone@RNP no CIP 850, é preciso acessar o Portas e a opção Juntoroes. Selecione a opção Adicionar SIP para cadastrar um Juntor SIP que será configurado o fone@RNP.

Para esclarecer algumas informações, é importante saber que: •

Número piloto: Número enviado como identificação externa pelo Juntor;

•

ID Juntor: quando mais de um juntor SIP configurado em uma mesma central CIP 850 for registrado em uma mesma operadora ou asterisk, ou seja, mesmo IP de destino, deve ser configurado um identificador (número associado ao juntor) onde a central utiliza para rotear/encaminhar as chamadas entrantes;

•

Modo de operação de DTMF: Permite selecionar o modo como os DTMFs serão enviados pelo juntor;

•

Permitir reinvites: Se habilitado, permite que após estabelecida a chamada a mídia seja trocada diretamente entre os ramais sem passar pela central;

•

Substituir reinvites por updates: Envia um UPDATE ao invés de um novo INVITE. Na maioria dos casos não existem diferenças exceto para algumas funcionalidades como por exemplo uma renegociação do SDP;

•

SIP Qualify: Permite selecionar o tempo máximo de resposta para que o juntor seja considerado ativo;

•

Limite de chamadas: Permite selecionar o número de chamadas (entrantes e saintes somadas)que podem ser estabelecidas através desse Juntor; Ao carregar a opção de Adicionar SIP, o formulário de cadastro será disponibilizado no

padrão abaixo. Atentem-se as informações de cadastro para que o serviço funcione perfeitamente.


122


1. Nome: Fone 2012 (Nome utilizado para identificar o Juntor) 2. Número piloto: YYXXXXXXXX (Número de identificação da Central através deste juntor. Exemplo: 2131891050) 3. Atendente diurno: Bridge (permite a função central de transito) 4. Atendente noturno: Bridge (permite a função central de transito) 5. Direção: Bidirecional (pode efetuar e receber o retorno da consulta); 6. Usuário: CIP850 (informação cadastrada no SRL) 7. Senha: foneatrnp (informação cadastrada no SRL) 8. Servidor: Endereço do servidor SRL da sua instituição 9. Porta: 5060 (Porta padrão SIP 5060) 10. Enviar pedido de registro: Sim (Manter o CIP 850 registrado e assim com tronco funcional) 11. Permitir reinvites: Não permitir (SRL não permite reinvites) 12. Fromuser: Manter informação não preenchida; 13. Fromdomain: Manter informação não preenchida


123


Após executar essas configurações o status do Juntor SIP deverá estar indicando REGISTRADO, conforme a imagem:

Criando Juntor CIP850 para acesso aos canais Analógicos O CIP 850 cria automaticamente os Juntores associados aos canais Analógicos FXOs instalados. Desta forma, ao acessar o menu Portas e a opção Juntores será listado todas as Portas de 1 a 8 que estiverem com módulo FXS. Para editar a configuração destes módulos, basta clicar na opção do lápis ao nome do juntor e escolher as configurações melhor associado ao cenário da sua instituição.

Configurandos no CIP 850 Após a configuração dos juntores analógicos e o juntor SIP do fone@RNP, é preciso configurar o roteamento das chamadas. Para isto, clique na opção Roteamento e depois na opção Rotas. O CIP 850 para funcionar corretamente no fone@RNP 2012 precisa configurar duas rotas de acesso. A primeira rota é a rota de acesso direto a operadora. Para isto, clique em adicionar rota e preencha o formulário de cadastro com as seguintes informações: •

Nome: operadora

•

Acesso: 5

•

Categoria Livre: sim

•

Sem bilhetagem: sim

•

Juntores Utilizados: Transfira para a caixa de seleção Juntores Utilizados todos os juntores ativos de FXS (Juntores que começam com o nome PORTAX)

•

Mantenha o Fone2012 na caixa de selação Juntores Disponíveis.

A segunda rota é a rota de acesso comum do serviço que incluirá o Juntor Fone 2012. Para


124


isto, clique em adicionar rota e preencha o formulário de cadastro com as seguintes informações: •

Nome: RotaFone

•

Acesso: 0

•

Categoria Livre: sim

•

Sem bilhetagem: sim

•

Juntores Utilizados: Transfira para a caixa de seleção Juntores Utilizados primeiramente o juntor Fone2012 e posteriormente todos os juntores ativos de FXS (Juntores que começam com o nome PORTAX).

•

Importante que o primeiro juntor na caixa de Juntores Utilizados seja o Fone2012.

Desta forma configuramos o dígito 0 como acesso para encaminhar chamadas para o Juntor RotaFone, portanto, todo número que for discado com 0 na frente (ex. 0 048 9999-9999) será encaminhado para o SRL.


125


Configurando ramais no CIP 850 Clicar em ramais, depois em adicionar SIP.

Configurar ramais de 3 ou 4 posições e adicionar a RotaFone.


126


Configurando os CODECs.


127



128

Capítulo 06

SIP Router Local - SRL



Capítulo 6 – SIP Router Local (SRL)


129

Capítulo 06


Sobre o SIP Router Local – SRL O SIP Router Local (SRL) é o módulo do fone@RNP responsável por manter a informação de cada dispositivo SIP, da manipulação (reescrita) de números, quando necessário, e das rotas para encaminhamento das chamadas entre os diversos campi e/ou dispositivos SIP da instituição e o núcleo do serviço fone@RNP. O SRL só aceita INVITEs vindos dos dispositivos cadastrados nele ou dos SRCs. No SRL encontram-se todas as rotas para os números alcançáveis pela instituição cliente, sejam eles números internos (dos ramais dos PABX pré-existentes), números na RTFC ou números virtuais do fone@RNP. As informações de rota ficam armazenadas no LDAP e são publicadas no DNS, em registros NAPTR, de acordo com o protocolo ENUM [RFC-6116]. O SIP Router Local (SRL) é equivalente ao SRC, mas instanciado nas premissas dos clientes. O SRL pode ser instanciando mais de uma vez dentro da mesma instituição. Isso significa que o próprio SRL pode ser hierarquizado, criando níveis de atendimento e isolando logicamente os campi das Instituições clientes. Quando um INVITE chega ao SRL, ele realiza uma pesquisa ENUM para verificar o endereço SIP equivalente ao número discado. Pode receber como resposta 1) a indicação de encaminhamento pelo SRC quando a chamada é para outro cliente do fone ou para uma cidade onde haja um cliente ou; 2) a indicação de outro modulo SRL, PBX IP ou para um GWT da própria instituição quando a chamada é para um telefone analógico da própria instituição ou para um telefone na RTFC local. O SRL é preferivelmente implementado como uma Máquina Virtual. A RNP utiliza VMWare, mas é possível implementar em qualquer outro fabricante ou tecnologia de virtualização, embora a RNP não dê suporte para outras VMs. O SRL é implementado SEMPRE em duplas com finalidade de promover a ‘alta disponibilidade’ do serviço. Se um servidor parar de responder por qualquer motivo, o outro deve assumir e o serviço de telefonia não deve parar. Por isso, escolha servidores de virtualização diferentes para instalar os SRLs, de preferência, distantes geograficamente.

Quando usar o SRL? O único caso em que o SRL é dispensável é quando há apenas um GWT em uso pela instituição cliente. Qualquer outro caso, o uso do SRL é recomendável. Mesmo que pareça trivial a ligação de um dispositivo SIP diretamente ao fone@RNP, é recomendado a instalação de um (par de) SRL na instituição cliente. O SRL isola a rede interna, no domínio do cliente, do ‘core’ do serviço do fone@RNP. Fazendo uma analogia para redes IP, ligar um PABX diretamente ao SRC seria igual a querer conectar uma estação de trabalho diretamente em um roteador do backbone. Além disso, o SRL instalado na rede local da instituição diminui consideravelmente o tempo de resposta das mensagens de controle e, consequentemente, o tempo de conexão das chamadas. O SRL também faz manipulações no número discado, formatando de acordo com a recomendação E.164 para que as pesquisas por rotas sejam padronizadas ou ainda, adequando-o para integração com outros dispositivos do fone@RNP.


130

Capítulo 06


As mensagens que os dispositivos SIP ligados ao SRL devem esperar como resposta quando uma chamada não pode ser realizada seguem listadas abaixo. • 404 - Not Found: Sem Rota • 408 - Request Timeout: O outro lado não responde. Pode estar indisponível. • 503 - Serviço Indisponível: Enviado pelo GWT quando a E1 apresenta problemas • 486 - Busy: O número discado está ocupado. • 487 - Request Terminated: O usuário chamou determinado número e cancelou antes de atender ou chamou até cair.


131

Capítulo 06


Roteiro de instalação e configuração 1. INTRODUÇÃO Este guia apresenta como instalar, configurar e gerenciar o SIP Router Local (SRL), componente do fone 2012 responsável por realizar o controle, encaminhamento e contabilização das chamadas no ambiente local da instituição. Este guia foi elaborado com suporte as seguintes versões: •

Web: 1.0.35 - 07/01/2014

•

Core: 1.0.64 - 07/01/2014

O guia está dividido em Pré-Instalação, Instalação, configuração dos componentes e documentação de uso de todos os dos módulos desenvolvidos até a versão atual.



132

Capítulo 06


2. PRÉ-INSTALAÇÃO O SIP Router Local pode ser instalado tanto em máquina física quanto em máquina virtual, através de procedimento manual ou via imagem do VMware. Para se instalar o componente de forma redundante, é necessário realizar o procedimento de instalação duas vezes. Recomenda-se o uso da imagem VMware. Os requisitos mínimos para a operação da mesma são os seguintes: ü Memória: 2GB RAM; ü Armazenamento: 50 GB; ü Sistema Operacional: Linux Debian 6.0.6; ü VMware 5.0 e VMware-Tools instalado (somente quando instalado como máquina virtual). Tenha em mãos os endereços IP do servidor de máquinas virtuais e dos novos servidores que serão instalados. Neste momento é necessário entrar em contato com o Suporte do FONE@RNP, para que seja liberado o IP da máquina que está baixando os pacotes para instalação e assim prosseguir com a instalação.

3. INSTALAÇÃO O SIP Router pode ser instalado manualmente, partindo de um Sistema Debian, ou através de imagem disponível de VMWare. Abaixo é detalhado o procedimento para máquinas virtuais, utilizando VSphere Client. A instalação manual será apresentada em um documento anexo.

3.1.

INSTALAÇÃO VIA IMAGEM VMWARE

Você deve ter instalado em uma estação de trabalho o programa “VMware vSphere” para acessar o servidor de VMs da sua instituição, que hospedará o SRL. Para iniciar a instalação do SRL siga os procedimentos abaixo:

Acessar o servidor de VMs através do VMware vSphere Client.


133

Capítulo 06


Figura 54 – Tela de login cliente VMware vShere


134

Capítulo 06


Iniciar processo de importação da máquina através do menu “File > Deploy OVF Template...”

Figura 55

- VMware vShere: Importar VM: File -> Deploy OFV Template


135

Capítulo 06


No campo “Deploy from a file or URL”, definir a URL para selecionar o arquivo do template da VM: http://repositorio-fone.rnp.br/fone2012/SRL/VM/release/1.0/update-20150313/FoneRNPSRL-v2.ovf

Figura 56 - VMware vShere: Importar VM: Deploy form a file or URL

Prosseguir com a instalação


136

Capítulo 06


Figura 57 - VMware vShere: Importar VM: Continuar

Definir um nome para a máquina

Figura 58 - VMware vShere: Importar VM: Definir nome da VM


137

Capítulo 06


Definir o Resource Pool para colocar a máquina

Figura 59 - VMware vShere: Definição do Resource Pool

Definir o disco a ser alocado para o SRL


138

Capítulo 06


Figura 60 - VMware vShere: Escolha o local de onde armazenar

Definir o formato do disco, selecionar “Thick Provision Lazy Zeroed”

Figura 61- VMware vShere: Modo de disco: Thick

Definir a rede a ser alocada para o SRL


139

Capítulo 06


Figura 62 - VMware vShere: Selecionar a rede

Finalizar a importação da VM

Figura 63 - VMware vShere: Importar VM: Finalizar o processo

Após ter concluído o processo de importação da VM, ligar a VM e a instalação estará concluída.


140

Capítulo 06


3.2.

Instalação com outros servidores de virtualização

Alternativamente, é possível realizar a instalação da máquina virtual utilizando outras soluções de virtualização. Neste caso, a RNP não dará suporte nesta etapa, cabendo à instituição cliente concluir a instalação da máquina virtual.


141

Capítulo 06


4. ACESSANDO E CONFIGURANDO O SRL 4.1.

CONFIGURANDO UMA ESTAÇÃO PARA ACESSAR O SRL

O SRL está pré-configurado com o endereço IP 10.255.255.10/24. Para acessá-lo, é preciso colocar uma estação de trabalho no mesmo segmento de rede do novo SRL, ou seja, 10.255.255.0/24. Essa estação de trabalho pode ser uma máquina real, com a devida configuração de switches. Alternativamente, um método menos trabalhoso talvez seja instalar uma estação de trabalho virtual no mesmo servidor de máquinas virtuais e acessá-la remotamente, como um Desktop Virtual. Abaixo seguem os passos a serem executados:

Na estação de trabalho já ligada na mesma rede do SRL, clique no botão “Iniciar”, depois em “Painel de Controle”, depois em “Central de Rede e Compartilhamento”. Do lado esquerdo escolha “Alterar as configurações do adaptador” (Figura 17): Se a tentativa de acesso for de dentro do servidor de máquinas virtuais, basta adicionar um novo IP dentro da placa de Rede do TCP/IP. Observação: Se a máquina virtual estiver atrás de um firewall, é preciso ficar atendo às configurações e permissões de acesso. Observação: Para ilustrar este guia, foi utilizado o sistema operacional Windows 7. Caso você esteja utilizando outra versão do Windows ou mesmo outro Sistema Operacional será necessário adequar as instruções à sua estação de trabalho.

Figura 64– Windows 7: Configuração do adaptador de rede



142

Capítulo 06


Figura 65 - Windows 7: Configuração do adaptador de rede (2)

Depois clique com o botão direito em cima da placa de rede do computador, e escolha a opção “Propriedades” (Figura 14):


Neste momento será feita a configuração do IP da máquina no mesmo segmento de rede do SRL, para ser iniciado o acesso. Dê um clique duplo em “Protocolo TCP/IP Versão 4”, conforme selecionado na Figura 15


143

Capítulo 06



Selecione a opção “Usar o seguinte endereço IP:” e digite, por exemplo, 10.255.255.5, de acordo com a Figura 16, e depois clique no botão OK.


144

Capítulo 06



Para testar se o SRL está ‘alcançável’, execute um comando através do prompt de comando. Clique no botão “Iniciar”. No campo destinado a “Pesquisar programas e arquivos” clique e digite CMD e tecle ENTER (Figura 17).

Figura 69 - Windows 7: Teste de conectividade entre estação de trabalho e SRL


145

Capítulo 06


Na tela do prompt digite: “ping 10.255.255.10” e tecle ENTER. O resultado deve ser com o da Figura 18, indicando que o SRL pode ser acessado pela sua estação de trabalho.

Figura 70 - Windows 7: Teste de conectividade entre estação de trabalho e SRL (2)

Saia da tela acima digitando “exit” e tecle ENTER. Abra o navegador de sua preferência e digite o endereço https://10.255.255.10 (Figura19).


146

Capítulo 06


Figura 71 – Acesso a interface WEB do SRL através do Firefox.

Aceite o certificado auto assinado. Clique em “Entendo os riscos” e, depois, no botão “Adicionar exceção...”. Aparecerá uma janela na qual você deve clicar no botão “Confirmar exceção de segurança”.

4.2.

CONFIGURAÇÃO PRELIMINAR DO SRL

Seguindo os passos anteriores, aparecerá a seguinte tela:


147

Capítulo 06


Figura 72 – SRL: Tela de Login inicial

Digite os seguintes dados para o acesso iniciais: Usuário: admin Senha: srl.admin Após logar, a Tela inicial será semelhante à Figura 21. No canto superior esquerdo se encontra o logo de identificação do SRL (1); a extrema direita se encontra a data de acesso no sistema, nome do usuário de acesso e a opção de sair do sistema – Logout (2); abaixo se encontram os menus que o usuário tem habilitado no sistema (3). Ao entrar no ambiente pela primeira vez com o usuário admin, o usuário acessa o primeiro item do menu “Status”, no qual o usuário tem acesso ao Status da máquina e o Status do Ambiente.


148

Capítulo 06


1

2

3

Figura 73 - SRL: Tela de Status

5. STATUS Na tela da guia Status o administrador consegue obter as informações referentes à utilização dos recursos da máquina do SRL e do ambiente (Figura 38).


149

Capítulo 06


Figura 74 – Tela de Status da Máquina e do Ambiente SRL

As informações contidas nesta seção são as seguintes (A - Figura 39, B - Figura 40, C - Figura 41 e D - Figura D):

Ø Número de CPUs e Porcentagem de Utilização (A): é listado a quantidade de CPUs alocadas para o SRL, assim como seu modelo e velocidade, contendo ao lado o percentual de utilização de cada uma. Ø Memória Efetiva, Memória Utilizada e Swap (A): Memória Efetiva é a memória efetivamente sendo usada pelo sistema; Memoria Utilizada é o total de memória utilizada contando a memória em cache; e swap é o total de memória utilizada como swap. Ø Número de processos (A): número de processos rodando no SRL. Serviço fone@RNP v.2012 Manual do serviço de telefonia IP da RNP

150

Capítulo 06


Ø Endereço IP (A): endereço IP alocado para o SRL; Ø Uptime (A): quantidade de tempo contada em dias, horas e minutos que o SRL está no ar desde a última reinicializada. Ø Carga média do sistema (B): carga média do SRL no último minuto, nos últimos 5 minutos e na última hora. Ø Partições e Porcentagem de Utilização (C): lista de partições utilizadas pelo SRL, contendo respectivamente suas porcentagens de utilização. Ø Versão das Tabelas do ENUM (D): listagem das versões das tabelas ENUM utilizadas pelo SRL. As tabelas listadas são as seguintes: o enum.local: gerenciada pelo próprio SRL, na aba Rotas; o enum.fonernp.central: Contem rotas internas do Fone@RNP. Gerenciada pelos SRC, obtidas através de transferência DNS. o enum.pbx.central: Contem rotas de PBX do Fone@RNP. Gerenciada pelos SRC, obtidas através de transferência DNS. o enum.pstn.central: Contem rotas de PBX do Fone@RNP. Gerenciada pelos SRC, obtidas através de transferência DNS. o O formato de “Versão” é a data de última alteração da tabela mais um número de 2 dígitos. Ø Informações Gerenciais (D): contém o número de peers configurados, quantidade de rotas configuradas, número de chamadas completadas e não completadas e a quantidade de chamadas dos últimos 5 minutos. Abaixo tem um gráfico mês a mês contendo o número de chamadas completadas e não completadas.


151

Capítulo 06


Figura 75 – Informações de CPU e Memória do Sistema, Endereço IP e Número de Processos

Figura 76 – Carga média do sistema


152

Capítulo 06


Figura 77 – Informações de utilização das partições


153

Capítulo 06


Figura 78 – Status do Ambiente

5.1.1. Configurações Para realizar as configurações do sistema, o administrador deve acessar o menu “Configurações”. Nesta seção, devem ser inseridas as informações pertinentes a instituição. Cada aba de configuração vai ser detalhada nas seções subsequentes.


154

Capítulo 06


Figura 79 - SRL: Configurações: Instituição

a) Aba Instituição Aba que contém as informações da Instituição, o responsável pela Administração do serviço Fone@RNP e configuração das Estatísticas Nacionais. Clique na guia Instituição e preencha com os dados solicitados. Ao concluir clique em “Salvar Configurações”.

Figura 80 - SRL: Configurações: Instituição, exemplo

INFORMAÇÕES GERAIS:


155

Capítulo 06


Ø Sigla: Sigla corresponde à instituição que está sendo instalado o SRL Ø Campus: Campus ou Unidade corresponde à instituição que está sendo instalado o SRL Ø Nome da Instituição: Nome completo da instituição. Existe um Bug, que será corrigido (a quantidade de caracteres não deve ser superior a 20). Ø Nome do responsável para contato: Nome da pessoa que ficará responsável pelo serviço na instituição. Ø Telefone para contato: Telefone de contato do responsável, preferencialmente, telefone móvel. Ø E-mail para contato: Correio eletrônico de contato do responsável. ESTATÍSTICAS NACIONAIS: Ø ID da Instituição: ID de identificação da instituição no serviço de Estatísticas Nacionais da RNP, da antiga versão do serviço fone@rnp. Essa informação é vital para o sistema de estatísticas. A RNP poderá fornecer o ID de sua instituição. Ø DDD Padrão: DDD padrão da Instituição para fins de contabilização nas Estatísticas Nacionais da RNP. b) Aba Sistema Aba responsável pelas configurações do Sistema do SRL. É onde se configura o SRL com um dispositivo de rede. Abaixo a descrição de cada campo, conforme mostrado na Figura 24.

Figura 81 - SRL: Configurações: Sistema

Ø Hostname – Nome do servidor no domínio. Importante: No “Hostname” a padronização adotada para o FONE@2012 é “SRL-sigla da instituição-0X”, no qual o X deve ser substituído por 1 ou 2, indicando respectivamente, o SRL principal e secundário. Ex.: Na RNP em Brasília terá os seguintes hostnames: SRL-RNPDF-01 e SRLRNPDF-02. OBS: Utilize um hostname qualificado. Não utilize: “_”, “:”, ou outro caractere que não forme um FDQN (Fully Qualified Domain Name). FQDN é o nome dado a computadores e domínios de redes de computadores após a atribuição do Domínio. Ø IP – Aqui é inserido o endereço IP definitivo que será destinado ao SRL. ESTE IP DEVE SER PÚBLICO. Ø Máscara – Máscara de Rede do SRL. Ø Gateway – É o endereço IP do Gateway dessa rede.


156

Capítulo 06


Ø NTP1 e NTP2 – Servidores NTP, para manter o relógio do servidor sincronizado. Por exemplo, ntp.cais.rnp.br, a.npt.br ou b.ntp.br. Ø DNS Resolver1 e DNS Resolver 2 – Esses servidores devem ser capazes de resolver zonas de ENUM. Caso não possua servidores capazes de resolver DNS ENUM, repita os endereços dos SRCs 1 e 2. Ø Domínio – O endereço ao qual o SRL pertence. Ø Timezone – Fuso horário que deve ser definido para ser adotado para o SRL.

Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Configurações”.

c) Aba Gerência Nesta tela é possível definir comunidades SNMP de Read-Only para gerência do ambiente, desviar logs para um servidor centralizado e ainda definir um servidor para envio de e-mails. No quadro SNMP, configure com sua comunidade e a rede de gerência, caso sua instituição possua um sistema de gerência de redes. O serviço de monitoramento da RNP já é automaticamente inserido e não fica explícito aqui. Você deve apenas configurar a firewall para permitir o acesso do servidor da RNP. O servidor de e-mail permite realizar relay de forma autenticada. Se você tem um relay de e-mails em sua instituição, configure com esse parâmetro para receber mensagens de alerta desse módulo do fone. Você também pode configurar um servidor de syslog. Para desabilitar o relay para um syslog externo, forneça o endereço 127.0.0.1.


157

Capítulo 06


Figura 82SRL: Aplicar Configurações: Confirmar

Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Configurações”. d) Aba Proxy SIP Nesta aba são definidas as informações referentes ao SRL atuando como um SIP Proxy, os endereços IP dos SRCs (SIP Router Centrais), portas de comunicação e prioridades. Veja a Figura 31.

Figura 83 - SRL: Configurações Proxy SIP

Ø Realm VoIP: Colocar o voip REALM da instituição: ex: fone.rnp.br ou voip.ufsc.br ou ufsc.br Ø IP do SIP Router: Endereço IP no qual o SRL irá escutar. Esse endereço deve ser o mesmo indicado da Aba Sistema, campo IP (Figura 24). Ø Porta do SIP Router: Recomenda-se deixar a padrão: 5060


158

Capítulo 06


Ø IP SIP Router Central 1, Porta SIP Router Central 1, IP SIP Router Central 2, Porta SIP Router Central 2: Colocar os endereços e portas dos SRCs, os quais no ambiente da RNP são: 200.143.193.54:5060 e 200.130.35.113:5060. Ø IP Proxy SIP DNS Srv 1, Prioridade, IP Proxy SIP DNS Srv 2, Prioridade: Definição dos endereços IP e prioridade que serão utilizados para configurar a zona DNS que responderá pelas configurações de rotas ENUM. Utilizar os endereços IP do SRL1 e do SRL2. As prioridades devem ser definidas conforme desejar, seguindo padrão de configuração conforme prioridades do DNS. Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Configurações”. ATENÇÃO! Clique em Salvar configurações, mas AINDA NÃO APLIQUE AS CONFIGURAÇÕES!! Neste momento, devemos configurar o firewall para que não percamos o acesso ao servidor. Depois voltaremos às próximas abas de configuração.

5.1.1.1.Firewall Além de controlar o iptables (acesso na camada 3, de rede), a aba ‘firewall’ e sua seção ‘Gerência’, também é responsável por configurar e controlar o acesso a pastas do apache (acesso na camada 7, de aplicação). Deixar de configurar a aba firewall nesse momento poderá comprometer toda o procedimento de configuração do SRL, pois deixará o usuário sem alternativas para acessá-lo novamente. No menu superior, clique na opção ‘Firewall’ para acessar suas configurações. Localize a área/seção “Rede de Gerência” (Figuras 25 e 26).


159

Capítulo 06


Figura 84 - SRL: Configurações do Firewall

Observe na Figura 26, que o IP 10.255.255.0, está cadastrado. Ele deve permanecer assim até a finalização da configuração, pois permitirá acesso a partir desta rede caso algo saia errado. Você deve removê-la em uma segunda etapa.

Figura 85 SRL: Configurações do Firewall – Rede Gerência

Agora inclua as demais redes de onde você poderá realizar a configuração e manutenção do SRL. Clique no botão e depois no campo onde deve digitar o IP. Seguindo o exemplo, digite o IP da máquina que fará o acesso ao SRL. Neste ponto, já temos as condições suficientes para aplicar as modificações e retomarmos as configurações na aba ‘Configurações’ e suas sub-abas. Insira também a porta 8443 TCP com origem no endereço IP 200.143.193.54/32. Este é o servidor que busca informações de CDR para o sistema de estatísticas nacionais.


160

Capítulo 06



---- ---- monitora.rnp.br ---- repositório-fone.rnp.br ntp.cais.rnp.br a.npt.br; b.ntp.br; c.rnp.br

Vamos, agora, terminar a configuração do firewall interno para podermos prosseguir e aplicar todas as configurações realizadas até agora. Ao incluir todas as redes de onde será possível acessar o SRL, clique no botão “Salvar” e depois em “Aplicar Configurações” (Figura 26). Agora é hora de aplicar as configurações realizadas até aqui. e) Aba Aplicar Configurações Após configurar o ambiente, é necessário aplicar as configurações do sistema, para que todas as alterações surtam efeitos.

Figura 86 - Configurações Proxy SIP

Ø Configurações de Sistema: quando selecionada, aplica as configurações que foram feitas no que diz respeito ao sistema, como alterações nas guias, Instituições, Sistema e Gerência.


161

Capítulo 06


Ø Configurações de Proxy SIP: quando selecionada, aplica as configurações que foram feitas no que diz respeito ao SRL e seus serviços. Ø Realizar sincronização LDAP: quando selecionada, realiza a sincronização do LDAP dos dois SRL configurados na instituição. Marque as duas caixas de opção “Configurações de Sistema” e “Configurações de Proxy SIP” e clique no botão “Aplicar configurações selecionadas”. Aparecerá uma tela de confirmação. Selecione o botão “OK” para aceitar a aplicação das configurações. O SRL irá aplicar as primeiras configurações configuradas e reiniciar com o novo IP. Realizar o acesso com o novo IP após o SRL ter reiniciado e continuar com a configuração do mesmo.

Figura 87 - SRL: Aplicar configurações

Figura 88 - SRL: Aplicar Configurações: Confirmar

Neste ponto a conectividade com o servidor é perdida.


162

Capítulo 06


Agora você deve colocar a estação de trabalho (de onde você está acessando o SRL) na rede gerência que foi configurada há pouco. Acesse o novo endereço IP via HTTP - ex: http://200.237.192.210 (Figura 29). Depois, aceite o certificado auto assinado clicando em “Entendo os riscos” e “Adicionar exceção...”. Aparecerá uma janela onde você deve clicar no botão “Confirmar exceção de segurança”. Entre com o usuário admin e suas credenciais para continuar as configurações. OBS: Esses avisos de segurança são reportados pelo browser devido ao uso do certificado auto-gerado. Não é necessariamente um problema.


163

Capítulo 06


Figura 89SRL: Aceitar certificado

Retomando a configuração do servidor, voltemos à aba Configurações > Serviços Habilitados. f)

Aba Serviços Habilitados

Para iniciar um serviço basta clicar em “Selecionar” e para parar um serviço, clicar em “Cancelar”.

Figura 90– Habilitar / Desabilitar Serviços

Habilite todos os serviços!


164

Capítulo 06


5.1.2. Atualização Após ter realizado as configurações iniciais, é necessário realizar a atualização do SRL para obter a última versão do software deste componente. Para tal, acesse o menu superior “Atualização”, e clique no botão “Atualizar Aplicações” (Figura 34) e, em seguida, aceite a atualização clicando no botão “OK” (Figura 35).

Figura 91 – Atualizações

Figura 92 – Atualizações: Confirmar ação.

Logo após, aparecerá a tela com as configurações aplicadas e uma caixa de texto verde na qual informa da necessidade de aplicar as configurações (Figura 36). Clique no link Configurações de Ambiente destacado nesta caixa de texto. Você será redirecionado para a tela de aplicação de configurações.


165

Capítulo 06


Figura 93 - Atualizações: Log da atualização e próximos passos.

Aplique a configuração selecionando as opções “Configurações de Sistema” e “Configurações de Proxy SIP” (Figura 37).

Figura 94 – Aplicar Atualizações


166

Capítulo 06


6. REPLICAÇÃO LDAP ENTRE DOIS SRLs É possível para o fone@RNP funcionar com apenas um SRL por instituição. Entretanto, é aconselhável ter 2 SRLs instalados e funcionando em redundância para aumentar a disponibilidade do serviço. Internamente, no SRL existem módulos que operam de forma redundante e outros não. Os que operam de forma redundante são os que mais sofrem alterações e que precisam estar sincronizados. Os módulos redundantes são: Peers, Rotas e País. Os demais, não são redundantes e operam de forma independente. Para habilitar a replicação dos dados entre os SRLs, é necessário que os dois SRLs estejam instalados e configurados até o passo 4 do manual de instalação. Uma vez que essa condição tenha sido atendida, prossiga com os passos abaixo. Faça login no primeiro SRL. Acesse a guia “Configurações”, aba “Gerência”, seção “Replicação LDAP” e altere os seguintes parâmetros (Figura 86):

Ø Server ID: preencher com o valor “1” o primeiro SRL; Ø Server Provider: preencher com o endereço IP do segundo SRL; Ø Habilitar Replicação: habilitar campo para realização de replicação.

Figura 95 – Replicação do LDAP

Logo após ter preenchido os valores, clique no botão “Salvar Configurações”. Depois, vá para a guia “Configurações”, aba “Aplicar Configurações”. Marque “Configurações de Sistema”, clique no botão “Aplicar Configurações Selecionadas” (Figura 87) e no botão “OK” (Figura 88) para confirmar ação.


167

Capítulo 06


Figura 96 – Aplicar configurações

Figura 97- Aplicar configurações: Confirmar

Importante: Após realizada a aplicação das configurações, deve entrar na guia “Firewall” e clicar em “Aplicar Configurações”, para que as configurações do espelhamento do LDAP sejam refletidas nas regras de firewall. Agora, faça login no segundo SRL. Acesse a guia “Configurações”, aba “Gerência”, seção “Replicação LDAP” e altere os seguintes parâmetros (Figura 89):

Ø Server ID: preencher com o valor “2” o segundo SRL; Ø Server Provider: preencher com o endereço IP do primeiro SRL; Ø Habilitar Replicação: habilitar campo para realização de replicação.


168

Capítulo 06


Figura 98 – Replicação LDAP

Logo após ter preenchido os valores, clique no botão “Salvar Configurações”. Depois vá para a guia “Configurações”, aba “Aplicar Configurações”. Marque “Configurações de Sistema” e “Realizar sincronização LDAP”. Clique no botão “Aplicar Configurações Selecionadas” (Figura 90) e no botão “OK” (Figura 91) para confirmar ação.

Figura 99 – Aplicar configurações para Replicação

Figura 100 – Confirmar Forçar replicação

7. PEERS Um peer (ou parceiro) é o equivalente a uma instituição (ou ao equipamento SIP desta instituição) que será ligado ao fone@RNP. Um peer pode ser o GWT do fone@RNP, um gateway de outro fabricante, o PBX-IP (do fone@RNP ou de terceiros) ou outro SRL.


169

Capítulo 06


Na guia Peers vamos realizar o gerenciamento dos peers cadastrados no SRL. Nesta tela, é possível inserir, excluir e alterar um peer (Figura 43). A listagem contida nesta tela possui os peers cadastrados no SRL. As informações listadas nesta tela são: Sigla, Nome, Website, E-mail e Telefone. Pode-se visualizar 5 seções distintas: filtro de exibição de resultados: 20, 25, 50, etc., que significam a quantidade de linhas a serem apresentadas na tabela (1); campo de pesquisa dos Peers (2); tabela de exibição dos peers (3); botões para cadastro e exclusão de peers (4); e botões de paginação da tabela de peers (5).

2

1 3

4

5

Figura 101 – Módulo Peers: Possibilidades de filtro e visualização


170

Capítulo 06


7.1.

CADASTRO DE UM NOVO PEER

Para realizar o cadastro de um novo peer, na tela de Peers clique no botão “Cadastrar”.

Figura 102 – Cadastro de um novo peer

Após clicar no botão “Cadastrar”, irá aparecer a tela de gerenciamento do Peer (Figura 45). Esta tela contém as seguintes abas com as seguintes informações cadastrais:

o Dados do Peer: Dados gerenciais do peer, incluindo compatibilização com o sistema de estatísticas nacionais do fone@RNP 2008: Sigla [*]: sigla adotada para identificar o peer no SRL, podendo ser a sigla da instituição de interesse; ATENÇÃO: A string “SRL” é uma palavra reservada e não pode aparecer no campo Sigla. Nome [*]: nome de identificação do peer; Website: website de identificação do peer, podendo ser o website da instituição; Telefone: telefone de contato do peer; E-mail: e-mail de contato do peer; Estatísticas Nacionais [*] - ID da Instituição e DDD Padrão: estes dados são utilizados para a adequação ao sistema de estatísticas nacionais do fone@RNP 2008. O ID da instituição identifica uma instituição no sistema de estatísticas e o DDD Serviço fone@RNP v.2012 Manual do serviço de telefonia IP da RNP

171

Capítulo 06


Padrão é utilizado quando não é possível identificar corretamente o DDD pelo número de origem. o Endereço: Dados do endereço de contato da instituição para fins de gerenciamento, sendo que os dados são auto descritivos - CEP, Logradouro, Número, Complemento, Bairro, Cidade, Estado e País. o Responsável: Dados sobre o responsável por administrar o peer, contendo os seguintes dados de cadastro - Nome, Telefone e E-mail. o Troncos: Dados referentes ao endereçamento IP dos equipamentos do peer e sobre que tabelas devem ser exportadas para o peer: Status: Opção para ativar ou desativar o peer. Quando o peer é desativado, suas rotas deixam de valer no serviço; Tipo do Peer: Define o tipo do peer (origem e destino) que é utilizado na contabilização, quando não consegue definir qual o tipo de ligação através das marcações do ambiente; Endereço do SIP Proxy [*] [**]: Define qual é o endereço do peer, que pode ser um SIP Proxy ou um gateway. Deve ser preenchido de acordo com o formato: “[ENDEREÇO IPv4]:[PORTA]”, ex: 10.20.30.40:5071 Endereço dos Servidores DNS [**]: Define quais são os servidores que receberão as tabelas ENUM (local e as centrais – fone@RNP, PBX e PSTN). Para dispositivos do fone@RNP, repita o endereço IP do peer, mas sem a informação de porta. Deixe em branco caso o peer não seja um dispositivo do fone@RNP. Este campo temo seguinte formato: “[ENDEREÇO IPv4]”, considerando como porta padrão a do DNS (UDP 53); Completar para: Define se o peer vai acessar a tabela local. A princípio, devem-se selecionar todas as tabelas sem Serviço fone@RNP v.2012 Manual do serviço de telefonia IP da RNP

172

Capítulo 06


restrições. As tabelas centrais são automaticamente exportadas conforme os privilégios gerenciados no SRC. [*] Campos obrigatórios. [**] Para adicionar o campo, é necessário clicar no botão logo ao lado o do campo correspondente, logo após seu preenchimento. O campo será listado na listagem abaixo do próprio campo. Caso deseje-se remover um valor associado ao campo que esteja na listagem abaixo, deve-se selecionar o campo e pressionar o botão

ao lado da listagem dos campos.

Figura 103 – Cadastro de Peer: Dados

Após ter preenchido com os campos obrigatórios e os desejados para questões de gerenciamento, devese clicar no botão adicionar (Figura 45). O SRL controla caso tenha algum campo faltando ser preenchido e retorna uma mensagem de aviso autoexplicativo logo após clicar no botão “Adicionar” (Figura 46). Caso o peer tenha sido cadastrado com sucesso, aparecerá uma mensagem de confirmação de cadastro após clicar no botão Adicionar (Figura 47).


173

Capítulo 06


Figura 104 – Cadastro de Peer: Dados, itens obrigatórios


174

Capítulo 06


Figura 105 – Cadastro de Peer: Cadastro finalizado

7.2.

EDIÇÃO DE UM PEER EXISTENTE

Para editar um peer existente, deve-se mover o mouse em cima de uma das linhas da listagem de peers cadastrados, até que o cursor do mouse apareça uma “mãozinha” e esta linha fique em tom de cinza (Figura 48). Logo após, dê um clique com o mouse para aparecer a tela de edição do mesmo (Figura 49). Note que esta tela e seus campos são os mesmos da Figura 45 quando se realizar um cadastro de um peer novo, alterando o botão “Adicionar” para o botão “Atualizar”. Pode-se alterar qualquer campo e no final pressionar o botão “Atualizar”.

Figura 106 – Peers Edição


175

Capítulo 06


Figura 107– Peers Edição 2

7.3.

EXCLUSÃO DE UM OU MAIS PEERS EXISTENTES

Para excluir um ou mais peers, deve-se selecionar os peers desejados para realizar a exclusão e logo após clicar no botão “Excluir selecionados” (Figura 50). Ao remover os peers, as rotas cadastradas para o mesmo também serão removidas. Um aviso é mostrado. Clique em “OK” para confirmar ou “Cancelar” para não realizar a exclusão dos peers selecionados.

Figura 108 – Peers Excluir


176

Capítulo 06


7.4.

PROCURANDO

INFORMAÇÕES

SOBRE

OS

PEERS

CADASTRADOS Para realizar uma procura dos peers, basta digitar os termos de pesquisa no campo “Procurar” (Figura 51). O filtro é aplicado conforme são digitados os termos de pesquisa e a seleção aparece na planilha abaixo.

Figura 109 - Procurar

8. ROTAS No contexto do fone@RNP, as rotas estão relacionadas aos números de telefone e o peer responsável por terminar a ligação telefônica feita para este determinado número. Por exemplo, para ligar para +55 21 2102-9600, um dos peers que terminam essa chamada é o escritório da RNP na cidade do Rio de Janeiro, na tabela de PBX, o que significa que este é um número dentro da própria instituição. Ao clicar na guia Rotas, serão listados os peers previamente cadastrados. Nesta tela, é possível realizar o gerenciamento das rotas dos peers cadastrados previamente no SRL. Nesta tela, é possível inserir, excluir e alterar rotas referentes aos peers (Figura 52). As informações listadas nesta tela são: Sigla, Nome, Website, E-mail e Telefone. Pode-se visualizar 5 seções distintas: filtro de exibição de resultados: 20, 25, 50, etc. (1); campos de aplicação das rotas cadastradas e verificação de encaminhamento ENUM (2), campo de pesquisa das rotas (3); tabela de exibição dos peers (4); e botões de paginação da tabela de peers (5). Figura 110 - Rotas

Para se gerenciar as rotas de cada peer, deve-se mover o mouse para cima de uma das linhas da

2

listagem até o peer desejado, quando esta linha fica em tom de cinza (Figura 53). Logo após, dê um clique para que abra a tela de gerenciamento de rotas do peer selecionado (Figura 54).

3

A listagem contida nesta tela possui informações das rotas do peer. As informações listadas nesta tela são: Código de País, Código de Área, Prefixo inicial, Prefixo final, Prefix, Strip, Destino, Prioridade e Status.

4


5 177

Capítulo 06


Pode-se visualizar 8 seções distintas: navegação hierárquica indicando em qual peer está sendo gerenciado as rotas (1); filtro de exibição de resultados: 20, 25, 50, 100, 200 e 500 (2); campos de aplicação das rotas cadastradas, importação e exportação de rotas (3), campo de pesquisa das rotas (4); tabela de exibição das rotas do peer selecionado (5); opção para excluir todas as rotas cadastradas (6); botões de cadastro, exclusão e atualização de rotas (7); e botões de paginação da tabela de rotas (8). Figura 111 - Escolha de um peer

Figura 112 – Cadastro de rotas para um peer

8.1.

CADASTRO DE UMA NOVA ROTA

Para realizar o cadastro de uma nova rota, deve-se selecionar um peer na guia Rotas e clicar no botão “Cadastrar”. Figura 113 – Botão Cadastro de Rotas

Após clicar no botão “Cadastrar”, irá aparecer a tela de gerenciamento da rota (Figura 56). Esta tela contém as seguintes informações cadastrais que devem ser preenchidas:

Ø Código de área: define o código de área da terminada rota, ou mais especificamente, este campo se refere ao DDD sem o código de nação. Ex: Rio de Janeiro - DDD 21; Ø Prefixo inicial e Prefixo final: define o início da faixa e o final da faixa de números de determinada rota. Os dois campos devem conter o mesmo número de dígitos; Ø Strip: número de dígitos que serão suprimidos do número chamado após a definição da rota. Ex: 554837211000 com strip de 4 fica como 37211000; Ø Prefix: sequência de caracteres alfanuméricos que será incluída após a definição da rota. Ex: 554837211000 com prefix “TESTE” fica como TESTE554837211000; Serviço fone@RNP v.2012 Manual do serviço de telefonia IP da RNP

178

Capítulo 06


Ø Prioridade: definição de prioridade da rota. Quanto menor o número, mais prioritário. Para os mesmos números de prioridades, serão chamados os destinos simultaneamente; Ø Proxy SIP: seleção do destino que deve ser encaminhado para esta especificação de rota. Este campo é buscado nos endereços do SIP Proxies definidos na aba Troncos do Guia peers; Ø Protocolo: definição do protocolo para ser usado pela rota (UDP ou TCP). Por padrão, definir como sendo UDP; Ø País: selecionar o país da rota. Este campo define o Código do País, o qual é definido na Guia “País”; Ø Status: opção para ativar ou desativar a rota. Figura 114 -

Após ter preenchido com os campos, deve-se clicar no botão Cadastrar (Figura 56). Caso os campos “Código de área”, “Prefixo inicial” e “Prefixo final” não estejam preenchidos, o sistema retorna o erro da Figura 57. Para os demais erros, o sistema retorna mensagens autoexplicativas. Figura 115

Observe que as rotas são formadas através de faixas numerais que são formadas com os seguintes campos: “Código de País + Código de Área + Prefixo inicial” até “Código de País + Código de Área + Prefixo final” Exemplo: País

: Brasil (implica em “Código de País” = 55)

Código de Área

: 48

Prefixo Inicial

: 37210000

Prefixo Final

: 37219999


179

Capítulo 06


A faixa de números será definida pelos telefones: 554837210000 até 554837219999 O sistema está preparado para gerenciar as rotas conflitantes, o qual aponta para os diversos destinos levando em consideração suas prioridades, independentes de serem ou não faixas de rotas exatamente iguais.

8.2.

EDIÇÃO DE UMA ROTA EXISTENTE

Para editar uma rota existente, mova o mouse para cima de uma das linhas da listagem de rotas cadastradas até que o cursor do mouse apareça uma “mãozinha” e esta linha fique em tom de cinza (Figura 58). Logo após, dê um clique com o mouse para aparecer a tela de edição da mesma (Figura 59). Note que esta tela e seus campos são os mesmos da Figura 56, quando se realiza um cadastro de uma rota nova, alterando o botão “Cadastrar” para o botão “Salvar”. Pode-se alterar qualquer campo e no final pressionar o botão “Salvar”. Figura 116 – Edição de rota

Figura 117– Edição de rota

8.3.

EXCLUSÃO DE UMA OU MAIS ROTAS EXISTENTES

Para excluir uma ou mais rotas, deve-se selecionar as rotas desejadas para realizar a exclusão e logo após clicar no botão “Excluir selecionados” (Figura 60). Figura 118 – Exclusão de rota

8.4.

EXCLUSÃO DE TODAS AS ROTAS

Para excluir todas as rotas, deve-se clicar no link “Excluir Todas as Rotas” (Figura 61). Figura 119– Exclusão de rota


180

Capítulo 06


8.5.

ATUALIZAÇÃO DE MÚLTIPLAS ROTAS

Para a realização de atualização de vários campos simultaneamente, devem ser selecionados as linhas que a serem atualizadas e, em seguida, clicar no botão “Atualizar selecionados” (Figura 62). Irá aparecer a tela com os possíveis campos para serem atualizados. Deve-se alterar os campos desejados e checá-los para definir quais devem ser alterados, conforme exemplo da Figura 63. Em seguida, clicar no botão “Salvar”. Figura 120– Atualização de Múltiplas rotas

Figura 121 – Atualização de Múltiplas rotas

8.6.

APLICAÇÃO DAS ALTERAÇÕES DE ROTAS

Logo após serem incluídas, excluídas, alteradas, habilitadas e/ou desabilitadas as rotas e/ou peers, deve-se aplicar as modificações para que de fato sejam consideradas como válidas. Para tal, na guia rotas deve-se clicar no botão “Aplicar alterações” (Figura 64) e logo em seguida clicar no botão “Aplicar” (Figura 65) para se sejam aplicadas as alterações feitas. Figura 122 – Aplicar Alterações (1)

Figura 123 – Aplicar Alterações (2)

8.7.

PROCURANDO

INFORMAÇÕES

SOBRE

AS

ROTAS

CADASTRADAS Existem 2 (duas) formas de busca das rotas cadastradas. As duas formas podem ser aplicadas tanto na tela de visualização da listagem de peers (Figura 52) ou na listagem das rotas do peer selecionado (Figura 54). O filtro é aplicado conforme são digitados os termos de pesquisa e a seleção aparece na planilha abaixo. A diferença da busca é o resultado, todavia a forma de operação é a mesma. Na primeira os resultados conterão a listagem dos peers que foram filtrados com os parâmetros de busca e na segunda as rotas de determinado peer.


181

Capítulo 06


A primeira forma de busca, é a busca por atributo. Esta considera todos os campos da planilha como campos de filtro, sendo que o campo “Tipo” deve ser definido como “Atributo”. Figura 124

A segunda forma de busca é a busca de rotas ativas. Esta realiza o filtro dos peers buscando como critério de pesquisa uma rota no formato E.164, ou seja, deve-se inserir no campo o número inteiro de busca a partir do código de país. Ex: caso deseje-se buscar as instituições que possuam rotas para o número +55-48-37216335, deve-se selecionar como tipo de busca a opção “Rotas Ativas” e no campo de busca inserir o valor “554837216335” (Figura 67 - visão peers e Figura 68 - visão rotas de determinado peer). Figura 125 - visão peers

Figura 126 - visão rotas de determinado peer

8.8.

VERIFICAR ENCAMINHAMENTO DNS ENUM

Para verificar o encaminhamento de rotas nas zonas de encaminhamento DNS ENUM, deve-se clicar no botão “Verificar Encaminhamento” na guia Rotas (Figura 69). Figura 127 – Verificar encaminhamento - pesquisa por atributo

Em seguida, deve-se entrar com o número completo no formato E.164 conforme explicado na seção 6.6, sendo que ao digitar o número de busca o sistema vai realizar o filtro para verificar em qual zona a rota se encontra cadastrada (Figura 70). É possível verificar detalhes do registro, clicando no ícone ao lado da zona ENUM (Figura 71). Caso o status apresente como “OK”, é porque existe rota na zona ENUM, caso apresente como “SEM ROTA!”, é porque não existe rota ENUM nesta zona. Figura 128 - Verificar encaminhamento – pesquisa por rota


182

Capítulo 06


Figura 129 - Verificar encaminhamento - pesquisa por rota (2)

8.9.

EXPORTAÇÃO/IMPORTAÇÃO DE ROTAS

Na guia Rotas, visão Peers, pode-se facilmente exportar as rotas clicando no ícone “Exportar Rotas”. Vai ser criado um arquivo com todas as rotas do peer. Para poder se importar, basta clicar no ícone “Importar Rotas”, selecionar o arquivo com as rotas de importação e clicar em “Enviar”. Caso esteja marcado para “Preencher com valores padrão se o valor não estiver setado”, os campos que no arquivo não estiverem configurados serão utilizados os campos preenchidos da interface.

9. CONTABILIZAÇÃO Na guia Contabilização é possível realizar a contabilização das chamadas que passam pelo SRL. Esta tela é autoexplicativa, sendo que devem ser selecionados os peers de origem e os peers de destino, selecionar o intervalo de contabilização desejado e informar o tipo de relatório desejado. O relatório que esta tela gera pode ser no formato em tabela, nas quais as ligações completadas e não completadas aparecem em linhas de tabelas distintas (Figura 73); pode ser no formato em matriz, nos quais aparecem os Peers nas linhas e colunas e contém a quantia de chamadas e total de tempo das ligações completadas e não completadas em tabelas distintas (Figura 74); e ainda pode ser no formato de gráficos (Figura 75). Figura 130 - Módulo Contabilização

Figura 131 – Chamadas completadas

Figura 132 – Matriz de Tráfego – Chamadas Completadas

Figura 133 – Visualização em forma de gráficos


183

Capítulo 06


10.USUÁRIOS Na guia Usuários é onde são gerenciados os usuários do SRL. Nesta guia é possível incluir, excluir, alterar e visualizar os usuários cadastrados (Figura 76).

Figura 134 – Cadastro de usuários do sistema

Os campos de cadastro desta guia são os seguintes (Figura 77):

Ø Ø Ø Ø Ø Ø

Login: login do usuário para acesso no SRL; Senha: senha do usuário para acesso ao SRL; Nome: nome do usuário por extenso; E-mail: e-mail de contato do usuário; Telefone: telefone de contato do usuário; Privilégios: seleção dos módulos e modo de acesso (escrita/leitura ou somente leitura) que o usuário terá acesso.

Figura 135 – Cadastrando um usuário

11. PAÍS Na guia País é possível cadastrar os países que o SRL terá conhecimento para formar as rotas. Nesta guia é possível incluir, excluir, alterar e visualizar os países cadastrados (Figura 78).

Figura 136 – Cadastro de prefixos de Países e Códigos internos se necessário

Os campos de cadastro desta guia são os seguintes (Figura 79):

Ø Sigla: sigla do país; Ø Nome: nome do país; Ø Código Nação: código de nação do país de cadastro; Serviço fone@RNP v.2012 Manual do serviço de telefonia IP da RNP

184

Capítulo 06


Ø

Rota Final: expressão regular que define o número em formato E.164 completo que um país tem, importante para definir corretamente as rotas no SRL. Para adicionar novas expressões, deve clicar no ícone e para remover uma expressão deve-se clicar no ícone . Figura 137 – Expressão regular que compõe os telefones do PAIS

Para testar se a expressão está correta, deve-se entrar um número completo no formato E.164 no campo “Teste de Rota” e verificar se está de acordo (verde) com uma das expressões listadas (Figura 80). Figura 138 – Validação de rota - verificar o Match

12.SISTEMA 12.1.

ATUALIZAÇÕES

Na guia Sistema, aba “Atualizações” é possível realizar a atualização do sistema (Figura 81) de forma semelhante como foi explicado na seção 4.2.2, destacando que esta funcionalidade foi movida de abas somente, diferentemente do que estava descrito na seção citada. Figura 139 – Suporte a atualização do sistema

12.2.

AÇÕES

Na guia sistema, aba “Ações” é possível reiniciar ou desligar o SRL, bastando clicar nos ícones correspondentes a cada ação (Figura 82).

Figura 140 – Ações: Reiniciar/Desligar servidor


185

Capítulo 06


13.CONSOLE Na guia Console, é possível visualizar os logs do Opensips e do Apache2 (acesso e erros), podendo selecionar filtros através de expressões regulares. Pode-se também alterar a taxa de atualização e número de linhas consideradas para filtro no arquivo especificado (Figura 83).

Figura 141 – Aba Console

14.BACKUP/RESTORE No Fone@RNP distribuição 2012, foi desenvolvida uma ferramenta para criação de arquivos de backup, ou seja, será possível, após finalizar TODAS as configurações do SRL ou sempre que desejado, criar um arquivo de backup. Esta ferramenta está na aba “Backup” no menu superior (Figura 84). Além de criar, é possível restaurar a configuração importando as informações de um arquivo backup. É importante manter uma cópia de segurança (Backup) das configurações, porque, caso aconteça alguma falha de hardware no servidor, ou por algum motivo você tenha que trocá-lo, os dados de configuração de seu ambiente podem ser facilmente restaurados, otimizando o tempo de instalação e configuração.

Figura 142 – Backup / Restore

Crie um arquivo de backup, clicando no botão “Backup do arquivo M4” e escolha onde irá guardar o arquivo. Caso seja necessário restaurar as configurações, basta clicar no botão “Escolher arquivo” e apontar onde o arquivo M4 estaria e em seguida clicar no botão “Enviar”.

15.LOGS Na guia Logs é possível verificar os eventos que ocorrem no SRL na questão da administração e gerência do mesmo, podendo verificar detalhes de cada ação (Figura 85).

Figura 143 – Logs do Sistema


186

Capítulo 06



187

Capítulo 07

PBX IP



Capítulo 7 – PBX IP Corporativo


188

Capítulo 07

PBX IP

Sobre o PBX IP O PBX IP é uma implementação especial de um PABX tradicional, desenvolvido para o fone@RNP, que procura atender às demandas comuns do serviço de telefonia de uma grande universidade brasileira. Foi desenvolvido primeiramente pela Universidade Federal de Santa Catarina (UFSC), para atender às necessidades da UFSC. Quando da solicitação de incorporação dessa solução ao fone@RNP, foi modificado para se integrar ao serviço e melhor atender a todos os clientes do fone.

É muito importante ressaltar que a RNP não atuará como mantenedora do PABX das instituições, mesmo se elas optarem por instalar o PABX do fone@RNP. Nós desenvolvemos a solução e estamos oferecendo-a para uso nas instituições em conjunto com os outros módulos do serviço fone@RNP. Mas, exatamente como quando uma instituição escolhe utilizar qualquer outro PABX, seja ele Siemens, Avaya, Cisco, Leucotron, Intelbrás, Asterisk, Elastix, SNEP ou qualquer outro fabricante, é necessário que a instituição contrate uma empresa (ou possua o conhecimento internamente) para manter seu PABX funcionando corretamente. Atualmente, no momento da escrita desse livro, para realizar o trabalho de mantenedor do PABX IP do fone@RNP, a RNP conta com a equipe do PoP-SC, que desenvolveu o PABX, e com a CAM Tecnologia, que nos dá suporte no fone@RNP. O PBX IP foi desenhado para funcionar com outros módulos do fone, tendo como pré-requisito, a instalação de um SRL. Além disso, a terminação de ligações na RTFC deve ser feita por um gateway (idealmente o GWT) configurado como um peer do SRL que controla este domínio. O PBX IP deve receber INVITES apenas do SRL diretamente acima. Todas as chamadas feitas a partir de um PBX IP devem ser encaminhadas para o SRL. Conexões de áudio e vídeo podem seguir entre o PBX e o SRL e o PBX e outros dispositivos deste domínio. Como visto nos parágrafos anteriores, o SRL fica responsável por indicar a rota correta para o número de telefone desejado. O PBX IP conta com duas versões: uma que se chama corporativa, para atender aos funcionários e outra que chamamos acadêmica, para atender aos alunos das universidades. Esta última versão possui integração com o serviço de Identidade Digital da RNP, a CAFe, Comunidade Acadêmica Federada. Essa integração permite a implementação de uma característica única no PABX IP desenvolvido pelo serviço. É a função de autoatendimento, onde o aluno é capaz de solicitar seu próprio ramal IP em uma página web, sem a intervenção de qualquer funcionário.

O PBX IP também é preferivelmente implementado como uma Máquina Virtual. A RNP utiliza VMWare, mas é possível implementar em qualquer outro fabricante ou tecnologia de virtualização, embora a RNP não dê suporte para outras VMs. O PBX IP é implementado SEMPRE em duplas, para garantir a Alta Disponibilidade do serviço. Se um servidor parar de responder por qualquer motivo, o outro deve assumir e o serviço de telefonia não deve parar. Por isso, escolha servidores de virtualização diferentes para instalar os SRLs, de preferência, distantes geograficamente.


189

Capítulo 07

PBX IP



190

Capítulo 07

PBX IP

Roteiro de instalação e configuração – PBX IP Corporativo 16.INSTALAÇÃO A instalação do módulo PBX-IP Corporativa está disponível na forma de duas imagens de máquinas virtuais (VM Virtual Machine, neste documento sempre será referenciada como VM1 para a Máquina Virtual 1 e VM2 para a Máquina Virtual 2), pré-configuradas no formato OVF (Open Virtualization Format), facilitando assim sua implementação. Para cada VM será necessário um IP Público e mais um terceiro endereço IP que será utilizado para a redundância no Virtual Router Redundancy Protocol (VRRP). Estas imagens requerem do sistema hospedeiro: • Ambiente VMware; • 35GB de HD; • 2GB de RAM; • 2 interfaces de rede, 1 com IP público e 1 interface para conexão direta entre os dois PBX-IP, para realizar procedimentos de redundância; • Tamanho do download: 1 GB. Importante: As duas PBX-IP funcionam em modo redundante e devem estar no mesmo segmento de rede. Após a importação das VMs, configurar a primeira interface de rede de cada VM para a sub-rede de telefonia e a segunda interface, com uma VLAN interna de comunicação entre as duas máquinas. Configuração do DNS (EXEMPLO) Na configuração do DNS da instituição, devem ser incluídas as entradas das duas máquinas, mais o IP virtual, e o domínio de provisionamento, o qual será utilizado para configuração dos telefones IP. A configuração deve ser realizada conforme modelo a seguir, adequando os endereços IP e nomes conforme cada instituição. m1.lab IN A 10.10.2.109 m2.lab IN A 10.10.2.110 vrrp.lab IN A 10.10.2.111 adm.voip CNAME vrrp.lab _sip._udp.adm.voip SRV 5 10 5080 vrrp.lab _sip._udp.adm.voip SRV 10 10 5080 m1.lab _sip._udp.adm.voip SRV 15 10 5080 m2.lab aprov.voip CNAME vrrp.lab As imagens poderão ser importadas diretamente pelo hypervisor, a partir das seguintes URLs: LINK DA VM1


191

Capítulo 07

PBX IP

•

http://repositorio-fone.rnp.br/fone2012/PBX-IP/VM/release/2.0/FoneRNP-PBXIP-v3m1/FoneRNP-PBXIP-v3-m1.ovf

LINK DA VM2 • http://repositorio-fone.rnp.br/fone2012/PBX-IP/VM/release/2.0/FoneRNP-PBXIP-v3m2/FoneRNP-PBXIP-v3-m2.ovf Os demais passos demonstram um procedimento básico de importação através do cliente VMware vSphere. Faça o deploy da VM1 utilizando o LINK DA VM1 de acordo com as figuras de 1 a 10, depois, repita o mesmo procedimento para a VM2 utilizando o LINK DA VM2.

Figura 144: Cliente vShere - DeployOFV.

Figura 145: DeployURL.


192

Capítulo 07

PBX IP

Figura 146: Detalhes da VMvSphere.

Na tela abaixo, é solicita qual será o nome da máquina virtual, aconselhamos deixar no formato que virá no arquivo .OVF como mostra na imagem abaixo:


193

Capítulo 07

PBX IP

Figura 147: Definição do nome da VM.

Figura 148: Escolher em qual pool a VM será implantada.


194

Capítulo 07

PBX IP

Figura 149: Escolha do local para armazenamento.

Figura 150: Formato do disco - Selecionar "1 – Thick Provision Lazy Zeroed".


195

Capítulo 07

PBX IP

Figura 151: Escolher a qual rede a VMdeverá ser associada.


196

Capítulo 07

PBX IP

Figura 152: Confirmar e iniciar processo de download.

Figura 153: Status do deploy.

Após finalizar a importação, ligue a VM. Acesse o seu console conforme a figura 11


197

Capítulo 07

PBX IP

Figura 154: Final do BOOT - Console VMWARE.

Realize o sincronismo das bases MySQL da PBX-IP O primeiro passo é verificar se há conectividade entre as VMs. Cada PBX possui uma segunda interface de rede especificamente para o sincronismo do mysql. É necessário que essas interfaces se alcancem uma a outra. Após essa verificação, execute os passos abaixo. Feito o deploy das duas VMs, inicie as mesmas e acesse a console da PBX-IP da VM1 e execute os passos abaixo. Depois repita os mesmos passos para a VM2. Login: root Password: pbxip.root pbxip-m1# mysql -p Enter Password: mysql.admin mysql> stop slave; Query OK, 0 rows affected (0.02 sec) mysql> reset slave; Query OK, 0 rows affected (0.04 sec) mysql> start slave;


198

Capítulo 07

PBX IP

Query OK, 0 rows affected (0.06 sec) mysql> show slave status\G Após a execução do comando acima a saída deve ser semelhante ao texto abaixo: *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.0.2.2 Master_User: replicant Master_Port: 3306 .... Agora execute: mysql> exit pbxip-m1# exit Lembre-se: Execute este procedimento na segunda máquina.

Quando entrar na interface gráfica, antes de iniciar a configuração do PBX IP, lembre-se de verificar se as duas máquinas estão sincronizadas.


199

Capítulo 07

PBX IP

17.ACESSANDO E CONFIGURANDO 17.1.

CONFIGURANDO UMA ESTAÇÃO PARA ACESSAR A

PBX-IP Para ilustrar este guia, foi utilizando o sistema operacional Windows 7. Caso você esteja utilizando outra versão do Windows ou mesmo outro Sistema Operacional será necessário adequar as instruções à sua estação de trabalho. Abaixo seguem os passos a serem executados. Os passos seguintes serão executados para a VM1 depois basta executar os mesmos procedimentos para a VM2. Como mostrado na Figura 11, a PBX-IP vem pré-configurado na VM1 com o endereço IP 10.255.255.20, as demais interfaces de rede seguem na sequência, IP VM 2: 10.255.255.21, IP da VRRP: 10.255.255.22. Para acessar o servidor de outra máquina, coloque-a no mesmo segmento de rede do servidor, por exemplo: 10.255.255.5. Clique no botão “Iniciar”, depois em “Painel de Controle”, depois em “Central de Rede e Compartilhamento” e, do lado esquerdo escolha, “Alterar as configurações do adaptador” (Figura 155):

Figura 155: Windows 7 - Central de rede e compartilhamento.



200

Capítulo 07

PBX IP

Figura 156: Windows 7-Conexões de rede.

Depois clique com o botão direito no ícone da placa de rede do computador, e escolha a opção “Propriedades” (Figura 157):

Figura 157: Windows 7 - Configurar adaptador Ethernet.

Neste momento será feita a inserção do IP da máquina no mesmo segmento de rede da PBX-IP, para ser iniciado o acesso. Dê um clique duplo em “Protocolo TCP/IP Versão 4”, conforme selecionado na Figura 15815.


201

Capítulo 07

PBX IP

Figura 158: Windows 7 - Propriedades TCP/IP.

Selecione a opção “Usar o seguinte endereço IP:” e digite o IP exemplo 10.255.255.5 de acordo com a Figura 16, e depois clique no botão OK.

Figura 159: Windows 7 - Configurando endereçamento IP.

Para testar, execute um comando através do prompt de comando. Clique no botão “Iniciar”. No campo destinado a “Pesquisar programas e arquivos” clique e digite CMD e tecle ENTER (Figura 16017).


202

Capítulo 07

PBX IP

Figura 160:Windows 7 - Menu iniciar.

Na tela do prompt digite: “ping 10.255.255.20”, tecle ENTER e o resultado deve ser exatamente como o da Figura 18.

Figura 161:Prompt DOS -Ping para componente.

Feche a tela do prompt e abra o navegador de sua preferência, digitando o endereço https://10.255.255.20/PBX-IP (Figura 162).


203

Capítulo 07

PBX IP

A máquina a partir da qual o acesso está sendo feito deve estar na mesma LAN das máquinas que serão acessadas. Para este guia, utilizamos o Chrome.

Figura 162:Certificado de segurança para aceite.

Os componentes do fone@2012 utilizam certificados auto assinados para não deixar que informações de administração e configuração trafeguem em texto plano pela rede. Clique em “Entendo os riscos” caso apareça esta mensagem, e depois clicar em “Continuar mesmo assim”


204

Capítulo 07

PBX IP

18.CONFIGURANDO O PBX-IP

Figura 163: Tela de login

Digite os seguintes dados para o primeiro acesso: Usuário: Password:

admin pbxip.admin

Após o primeiro acesso, troque a senha de administrador imediatamente!! No canto superior direito, clique em “Sistema”, depois em “Administradores”. Edite o administrador padrão e certifique-se de utilizar uma senha forte! Após efetuar o login, será exibida a tela de Status ou visão geral do ambiente representada na Figura2.


205

Capítulo 07

PBX IP

Figura 164: Tela Visão Geral

Nesta tela, é possível verificar: - Status dos serviços; - Estatísticas da central; - Status do ambiente; - Status de replicação do banco de dados; - Status administrativo e operacional dos servidores master (VM1) e slave (VM2). OBS: A sincronização entre o máster (VM1) e o slave (VM2), como indicado pelas grandes setas vermelhas na figura 21, pode demorar alguns minutos, por isso os serviços podem aparecer como desabilitados (ícone vermelho) por algum tempo. Caso o sincronismo não tenha sido realizado com sucesso, repita o procedimento de sincronização do mysql informado anteriormente, no início desse capítulo. No canto superior direito, é informado o nome do usuário que está logado, e há a opção “Sair”. Ainda nesta posição, é possível alternar entre as opções de configuração e gerência do Sistema e da Central PBX-IP. À esquerda da tela, há um menu com opções para administração e controle de funcionalidades e serviços relacionados aos ramais que serão gerenciados pelo ambiente.


206

Capítulo 07

PBX IP

18.1.

Administradores

Nesta opção é possível fazer o gerenciamento dos administradores do ambiente PBX-IP, cadastrando usuários e definindo permissões de acesso. Para o cadastro de um usuário, é necessário informar os dados de login, nome e-mail e unidade à qual o usuário é vinculado. Além disso, devem ser marcadas as opções de módulos e acessos que o usuário poderá visualizar e/ou modificar no sistema. Os módulos que não forem selecionados na criação de um usuário, não serão visíveis a ele na aba “Central” da PBX-IP quando este usuário estiver logado. É possível marcar os acessos como somente leitura, nos quais o usuário não poderá fazer alterações. Para dar permissão total, basta deixar a opção “somente leitura” desmarcada.

Figura 165: Cadastro usuário admin

18.2.

Logs

Todo o histórico de ações do usuário da PBX-IP fica registrado no log do ambiente, permitindo identificar quais operações foram executadas por ele, quando e a partir de qual IP este acesso foi feito. Ao clicar sobre uma das linhas de registro de log, é aberta uma aba abaixo do registro, detalhando as modificações realizadas por aquela operação. Assim, rastrear operações indevidas ou incorretas de modo a fazer as correções necessárias. É possível filtrar os resultados do log por data, por usuário, por IP de origem do acesso ou até mesmo por tipo de ação executada.


207

Capítulo 07

PBX IP

Figura 166: Log do Sistema

18.3.

Menu Configurações

Sistema

18.3.1.

Firewall

O início da configuração da PBX-IP será pelo Firewall, pois vamos precisar inserir o IP da máquina que fará a gerência do PBX-IP. Se fizermos alguma alteração de IP antes de configurarmos a gerência, poderemos perder o acesso ao PBX-IP. No cabeçalho, à direita, clique em ‘Sistema’. No menu à esquerda, clique em ‘Firewall’. Deverão ser liberados também os endereços NTP, DNS, Estatísticas do fone, monitoramento etc. Na opção “Ações” é onde serão fornecidos os endereços IP que poderão enviar mensagens SIP ao GWT (no caso SRC ou SRL). Se o ambiente estiver conectado ao SRL, somente esses IPs são necessários. Após configurar o firewall revisando os parâmetros de sua instituição, clique em ‘Salvar’ e depois ‘Aplicar’. A aplicação de regras de firewall pode demorar alguns minutos caso não seja possível, ainda, resolver nomes.


208

Capítulo 07

PBX IP


209

Capítulo 07

PBX IP

Figura 167: Firewall


18.3.2.

---- ---- monitora.rnp.br ---- repositório-fone.rnp.br ntp.cais.rnp.br a.npt.br; b.ntp.br; c.rnp.br

Configuração -> Sistema

a) Guia Instituição Ainda na seção ‘Sistema’, no menu à esquerda, clique também em ‘Sistema’. Acesse a aba “Instituição” Neste item são registradas informações sobre a instituição. Estas informações são utilizadas para diversos processos internos, algumas são somente para registro e outras são utilizadas para gerar o certificado auto assinado para acesso nas telas administrativas. Os seguintes dados devem ser preenchidos: Ø Nome da Instituição: Nome completo da instituição; Ø Sigla: Sigla corresponde a instituição que está sendo instalada a PBX-IP; Ø Campus: Campus ou Unidade corresponde a instituição que está sendo instalada a PBX-IP; Ø Nome do responsável para contato: Nome da pessoa que ficará responsável pelo serviço na instituição; Ø E-mail para contato: Correio eletrônico de contato do responsável; Ø Telefone para contato: Telefone de contato do responsável, preferencialmente, telefone móvel; Ø Telefone para contato: Telefone de contato do responsável, preferencialmente, telefone móvel; Ø CEP: Código de endereçamento Postal; Ø Endereço, Bairro, Cidade, Estado, País: Informações de endereço postal da instituição; Ø CPNJ: Número correspondente ao Cadastro Nacional da Pessoa Jurídica da instituição; Ø Websiste: Site WEB da Instituição. Após realizar o preenchimento dos dados da instituição, não esquecer de salvar.


210

Capítulo 07

PBX IP

Figura 168: Configuração do Sistema - Dados da Instituição

b) Sistema Nesta aba é feita a parametrização das configurações do sistema, devendo ser preenchidos os seguintes campos: Ø IP- Aqui é inserido o endereço IP que será destinado a PBX-IP Administrativa. ESTE IP DEVE SER PÚBLICO! Após a configuração do IP, deve ser alterada a VLAN da VM para acessar a máquina. Ø Máscara - Máscara de rede do IP; Ø Gateway- É o endereço IP do gateway da instituição; Ø MTU - Tamanho máximo da MTU no segmento LAN, padrão: 1500; Ø Hostname - Nome do servidor no domínio; Importante: No “Hostname” a padronização adotada para o FONE@2012 é “PBXIP-adm-sigla da instituição”, Ex.: RNP / Brasília, será, “PBXIP-DF-RNP”. Importante2: No “Hostname” não utilizar: “_” “;” “.” Ou outro caractere que possa quebrar na formação do FDQN (fully qualified domain name) Ø Ø

Ø Ø

NTP1 e NTP2- Utilizar os servidores NTP da instituição. Caso não possua, utilizar: pool.ntp.br e ntp.cais.rnp.br; DNS Resolver1 e DNS Resolver 2 - Caso a instituição possua servidor de DNS, ou tenha algum que deseje apontar, inserir nesses campos. Esses DNS´s devem ser capazes de resolver zonas de ENUM. Domínio- O endereço ao qual a PBX-IP pertence. TimeZone - Selecionar de acordo com o Timezone de sua região. A entrada e saída do horário de verão é realizada automaticamente.


211

Capítulo 07

PBX IP

Figura 169: Configurações do Sistema – Dados do Sistema

c) Gerência Na aba Gerência, é possível parametrizar as informações de acesso SNMP/RO, Syslog, SMTP e Acesso WEB da interface administrativa da PBX-IP. Ø SNMP: § Comunidade - Comunidade SNMP somente leitura; § Rede de Gerência - Rede de gerência para onde a comunidade de leitura terá acesso. Ø SYSLOG: § IP - Endereço IP do servidor syslog de sua instituição; § Porta - Porta onde o servidor estará escutando (Padrão: 514). § Protocolo - Protocolo de transporte, atualmente suportado TCP e UDP (Padrão: UDP). Syslog: Para desabilitar o envio remoto via syslog, apontar para o IP 127.0.0.1. Ø SMTP § Servidor SMTP: nome ou endereço IP do servidor SMTP responsável por encaminhar os e-mails da PBX-IP Administrativa; § Servidor do servidor SMTP: Porta do servidor SMTP utilizada para receber os e-mails. Ex: 25, 465. § E-mail de origem: e-mail utilizado para compor as mensagens; § Autenticação SMTP: Marcar caso o serviço de e-mail requeira autenticação: § Usuário: usuário utilizado para autenticação de envio;


212

Capítulo 07

PBX IP

• Senha: senha do usuário para autenticação. Ø Acesso WEB: Define a partir de quais redes é possível acessar as interfaces administrativas e de WebService: § WWW [1 – 5]:Redes onde as interfaces administrativas poderão ser acessadas, isto é, /PBX-IP/; § WebService: Rede ou Host de onde o WebService da PBX-IP para criação de ramais poderá ser acionado. Ø Importante: Acesso WWW: Liberar somente para a rede de gerência da instituição ou equipe de suporte RNP. Ø Importante2: Acesso WebService: O método atual de autenticação é através do IP de origem. Somente liberar para o IP de sua aplicação caso deseje interagir com a PBX-IP. Para desabilitar, deixar em branco.

Figura 170: Configurações do Sistema - Gerência

Ø Acesso Provisionamento: Define a partir de quais redes, os telefones IP podem acessar o servidor de provisionamento para buscar configurações: § Domínio Aprovisionamento: nome do servidor de provisionamento. Ex: prov.voip.instiuição;


213

Capítulo 07

PBX IP

Redes: devem ser incluídas as redes nas quais há telefones IP que precisam acessar o servidor de provisionamento. Podem ser incluídas até 5 redes diferentes. Ex: X.X.0.0/16 . Ø Catálogo Telefônico: Define a visibilidade do catálogo telefônico, delimitando qual é o escopo de rede da instituição. Os acessos ao catálogo a partir de IPs que casem com o definido poderão visualizar todas as informações do ramal/usuário. Já os acessos de redes externas, não irão visualizar alguns ramais/usuário, nem os nomes de contatos e responsáveis; § Rede Interna: Segue o padrão de expressão regular /^10.10./ para definir qual é a rede interna da instituição; § Email: E-mail para o qual serão enviadas notificações de alterações de erros no catálogo. §

Figura 171: Configurações do Sistema - Gerência Provisionamento

d)

Proxy SIP

Ø PBX: VoIP REALM-REALM que será utilizado para atender ao serviço VoIP. Ex: voip.instituicao.br; Ø OpenSIPs: Porta -Porta onde o SIPProxy (OpenSIPS) irá atender requisições. Padrão: 5080; Ø OpenSIPs: Nível de Debug -Nível de log que será gerado pelo OpenSIPs. Escolha entre 0e 7. Recomenda-se utilizar 1. Ø Midia Server: Porta -Porta UDP onde o Asterisk responsável por executar funções de Servidor de Mídia irá atender requisições (padrão: 5071). Não pode ser a mesma do OpenSIPs. O Acesso dessa porta somente será realizado pelo OpenSIPs. Ø VRRP/UCARP: IP virtual para implementação de failover entre o servidor Master e o Slave. Ø Importante: Para que o REALM funcione será necessário criar as entradas DNS SRV apontando para a PBX-IP, informando em qual porta o proxy irá trabalhar.

Ø Portas SIPProxy e Mídia Server: Recomenda-se evitar o uso da porta 5060 para utilizar dispositivos SIP, pois é a maior fonte de incidentes de scans devido ao seu interesse comercial.


214

Capítulo 07

PBX IP

Figura 172: Configurações do Sistema - Proxy SIP

5.3.1.5 SIP Router

Configuração dos parâmetros do SIP Router Local (SRL) da Instituição que será utilizado pelo ambiente: Ø Ø Ø Ø

IP Master: Endereço IP do SipRouter Local (SRL) de sua Instituição (Máquina 1); Porta Master: Porta do SipRouter Local (Máquina 1). Padrão: 5060; IP Slave: Endereço IP do SipRouter Local (SRL) de sua Instituição (Máquina 2); Porta Slave: Porta do SipRouter Local (Máquina 2). Padrão: 5060;

Ø Importante: A PBX-IP somente aceita convites de chamadas (INVITES) de peers válidos (SIP Router Locais) ou usuários autenticados. INVITES não autenticados ou de fontes desconhecidas são negados. Ø Importante: O SRL somente aceita INVITES dos peers válidos. O uso da porta 5060 pode ser utilizado sem grade impacto na segurança. Para saber como configurar um peer no SRL, consultar o Guia de Implementação do SRL – FONE@RNP Versão 2012.


215

Capítulo 07

PBX IP

Figura 173: Configurações do Sistema - SIPRouter

5.3.1.6 TDM

Parâmetros de telefonia convencional: Ø Ø Ø Ø Ø Ø Ø Ø

Código de País: Código do País / CN: Para o Brasil utilizar 55; DDD: Código DDD da instituição; Prefixo: Prefixo TDM da instituição; Código da Operadora: Código da operadora de longa distância. Ex: Embratel 21; Linha Externa: Código extra para acesso alinha externa. Ex: 0; Ramal PBXIP Inicial: Ramal inicial no prefixo TDM que será atendido por essa PBX-IP; Ramal PBXIP Final: Ramal final no prefixo TDM que será atendido por essa PBX-IP; Ramal Padrão de Saída: Ramal no prefixo TDM utilizado para completar ligações através da URA da PBX-IP.

Parâmetros de VoIP: Numeração Interna do Fone@RNP Ø Prefixo: Prefixo fornecido pela RNP para uso interno da instituição. Ex: 1XXX; Ø Ramal Inicial: Ramal inicial no prefixo VoIP que será atendido por essa PBX-IP; Ø Ramal Final: Ramal final no prefixo VoIP que será atendido por essa PBX-IP.

Figura 174: Configurações do Sistema - TDM


216

Capítulo 07

PBX IP

5.3.1.7 Serviços

Os serviços disponíveis nesta opção podem ser habilitados/desabilitados clicando sobre o serviço desejado.

Figura 175: Configurações do Sistema - Serviços

5.3.1.8 Aplicar Modificações feitas na configuração do sistema devem ser aplicadas para ter efeito. Basta selecionar os itens onde as configurações devem ser aplicadas. Normalmente, seleciona-se os três itens: Sistema, OpenSips e Asterisk. Em seguida, clicar em aplicar e aguardar.

Figura 176: Configurações do Sistema - Aplicar

5.3.3 Permissões de Discagem Os tipos de chamadas permitidas pelo ambiente são mapeados através de expressões regulares, definidas nesta seção. Esses tipos são os perfis que permitem a cada usuário realizar (ou não) ligações para determinados tipos de telefones. A combinação das chamadas efetuadas com as expressões definidas é utilizada para geração de relatórios, contabilização de custos (para chamadas tarifadas) e geração de faturas, bem como a identificação dos tipos de chamadas autorizadas na configuração individual de cada usuário.


217

Capítulo 07

PBX IP

Existe um campo para teste de número destino, no qual é possível testar com quais regras um determinado número destino casa.

Figura 177: Permissões de Discagem

5.3.4 Plano de Discagem Define como os números discados pelos usuários serão encaminhados para o próximo módulo do fone@RNP. Em outras palavras, define regras de reescrita. Ø Ø Ø Ø Ø

Descrição: id/nome da regra sendo criada; Prefixo: definido de acordo com a regra Expressão: expressão regular que case com a discagem feita pelo usuário; Strip: quantidade de dígitos à esquerda do número que devem ser removidos na reescrita; Ativo: Ativar/Desativar regra.


218

Capítulo 07

PBX IP

Figura 178: Plano de Discagem

5.3.5 Faixa de Valores Utilizada para geração de faturas e contabilização de custos de ligações, dependendo do tipo e horário. Estas informações são utilizadas também para desconto de créditos de usuários. Devem ser informados para cada tipo de ligação, qual o valor por minuto. Podem ser incluídas faixas de horário diferentes para cada tipo de ligação, caso a tarifação pela operadora seja feita desta forma. Para adicionar outra faixa de horário, basta clicar no ícone configuração, clicar em “Atualizar” no final da página.


. Ao concluir a

219

Capítulo 07

PBX IP

Figura 179: Faixa de Valores

5.3.6 Backup É possível fazer o download/upload de arquivo com as configurações de sistema. Para fazer o download do arquivo de backup, basta clicar em “Backup do arquivo M4”. Para fazer o upload do arquivo, basta clicar em “Selecionar Arquivo”. Em seguida, clicar em “Enviar”.

Figura 180: Backup

5.3.7 Atualização


220

Capítulo 07

PBX IP

Quando estiver na opção sistema e clicar no menu “Atualização” caso haja alguma a ser feita irá aparecer conforme imagem abaixo:

Caso não haja atualizações a fazer, será informado que o sistema já está atualizado.

Figura 181: Atualizações

5.3.8 Acesso Provisionamento Permite cadastrar um par de usuário e senha que serão utilizados pelos telefones IP para se autenticar no servidor de provisionamento e assim ter acesso aos arquivos de configuração.


221

Capítulo 07

PBX IP

Figura 182: Cadastro de Login de Provisionamento


222

Capítulo 07

PBX IP

19. CENTRAL – Gerência de usuários e ramais Após a instalação e configuração do PABX como um dispositivo de rede e com os parâmetros globais de telefonia, é hora de configurar os ramais, departamentos, custos, perfis, usuários, grupos de captura, etc. Enfim, é hora de popular o PABX. A melhor forma de popular seu PABX é começar preenchendo os dados da sua Instituição. Isso é feito na Guia “Organização”, no menu lateral esquerdo. Primeiro preencha os dados das Unidades atendidas por este PABX. Depois, preencha os Departamentos de cada Unidade. Depois, partimos para a configuração dos ramais. Nessa etapa, os ramais ainda não serão associados a uma pessoa. Nesse momento, eles serão associados aos departamentos e unidades. Primeiramente, devemos criar os “prefixos” que serão atendidos por este PABX. Logo depois, devem ser cadastradas as faixas de números DDR de cada prefixo. Você pode dividir sua faixa DDR em sub-faixas para, por exemplo, distribuí-las por diferentes departamentos. Se houver centrais legadas em sua solução, agora é a hora de cadastrar os prefixos e faixas DDR que elas serão responsáveis em atender. Finalmente, no meu “Ramais > Gerenciar”, você poderá cadastrar cada ramal de sua instituição, já sob a estrutura organizada anteriormente. Por fim, é hora de associar usuários aos Ramais cadastrados. Vá em “usuários SIP > Gerenciar” e crie seus usuários de acordo com os funcionários. Nesse momento os usuários serão associados aos números de telefones (ramais) e seus departamentos, são descritos os perfis com permissões de ligação, quantidade de créditos e outros parâmetros ligados à pessoa que utilizará esse recurso. 6.1. Usuários SIP 6.1.1. Gerenciar Neste menu, é possível consultar a lista de usuários cadastrados, bem como cadastrar novos usuários no sistema. Na lista de usuários, a coluna SO (Status Operacional) contém um ícone que fica na cor cinza quando o usuário não está registrado e verde, quando o usuário está registrado. Já a coluna SA (Status Administrativo) indica os seguintes estados de ramal: - Verde: Ativo - Amarelo: Em manutenção - Vermelho: Inativo/Bloqueado

Figura 183: Listagem de Usuários


223

Capítulo 07

PBX IP

Apenas o status ativo (verde) permite que o usuário possa efetuar e receber chamadas. Quando o usuário estiver em manutenção ou bloqueado, não poderá efetuar nem receber chamadas. Para alternar entre os estados do ramal, basta clicar sobre o ícone da coluna SA do usuário desejado, que mudará de cor indicando o novo estado do usuário. É possível exibir toda a lista, bem como fazer buscas específicas por usuários ou por dados de outras colunas, como departamento, local, etc. A ordenação padrão da lista de resultados é feita por ordem alfabética de usuário, mas também pode ser feita clicando sobre o nome da coluna de acordo com a qual os resultados devem ser ordenados. Ao clicar sobre o nome do usuário na lista, uma aba é aberta abaixo do mesmo, indicando algumas informações e dados. É possível ver o número dos ramais associados ao usuário, endereço IP, caso ele esteja registrado, histórico de endereços IP nos quais o usuário já se registrou, versão de firmware, modelo e MAC do telefone IP do usuário, com as respectivas datas e horários

Figura 184: Dados de Usuário

É possível também reiniciar o telefone IP do usuário, utilizando o ícone “Reiniciar” ao lado do último registro de IP ou através de “Reiniciar Telefone”.


224

Capítulo 07

PBX IP

Figura 185: Dados de registro de usuário

6.1.2. Cadastrar Usuário Ao clicar na opção cadastrar usuário, uma nova tela será aberta, conforme a Figura 6:


225

Capítulo 07

PBX IP

Figura 186: Cadastro de Usuário

Neste formulário, as seguintes informações devem ser preenchidas: Ø Nome completo do usuário; Ø Login para registro; Ø Email do usuário: receberá os dados do cadastro, faturas, etc;


226

Capítulo 07

PBX IP

Ø Senha registro: é a senha que será utilizada para registrar o login do usuário. Ao clicar no ícone , é feita a geração automática de uma senha para registro. Por default, a senha de registro não é informada ao usuário. Caso deseje-se enviar a senha para o e-mail cadastrado do usuário, basta clicar no ícone

;

Ø Senha Web: senha para acesso ao Portal do Usuário. Pode ser gerada automaticamente clicando-se no ícone

. Esta senha sempre será enviada para o e-mail cadastrado do

usuário; Ø Local onde o usuário será registrado, bem como sua Unidade e Departamento; Ø Captura direta: permite ao usuário fazer captura de chamadas, quando ativada, diretamente de outro usuário específico. Ø Grupo de captura: informará o id do grupo de captura, caso o usuário seja membro de algum grupo. Ø Permissão IP: Por default o usuário pode ser registrado em qualquer IP. Para limitar o acesso, é possível permitir que o usuário registre-se apenas em IPs da instituição. Para isto, basta selecionar “Limitar” e informar a expressão regular da rede autorizada no campo IP. Ex: ^200\.135\.. ; Ø Sistema de créditos: Permite ligações tarifadas ilimitadas, caso esteja inativo, ou restringe ao valor de créditos do usuário, caso esteja ativo. Ø Créditos (Tipo Recarga): §

Sem substituição: O usuário poderá utilizar apenas o valor de crédito disponível no campo Créditos Atuais, mas não será feita recarga mensal, mesmo que haja valor preenchido no campo Crédito Recarga;

§

Com substituição: O valor no campo Créditos Atuais é substituído mensalmente pelo valor fixo contido no campo Crédito Recarga, independentemente de o valor de Créditos Atuais possuir saldo ou não;

§

Incremental: O valor fixo no campo Crédito Recarga é somado ao saldo do campo Créditos Atuais, que ficará com o valor acumulado de créditos.

Ø Ramais Associados: define quais ramais estão associados ao usuário. É necessário informar pelo menos um ramal. Caso haja mais de um ramal associado a um usuário, é necessário selecionar o ramal que será Default, isto é, o número de telefone que permitirá ao usuário efetuar e receber chamadas. A inclusão/exclusão de ramais associados pode ser feita utilizando os ícones

e

;


227

Capítulo 07

PBX IP

Ø Permissões: indicam os privilégios de ligações que o usuário possui. Ø Ativar sistema de bloqueio: Ao marcar esta opção, deverá ser informada uma senha de 6 números que será solicitada ao usuário toda vez que for realizada uma chamada dos tipos indicados com o ícone do cadeado fechado. Os tipos de permissão que estejam com o ícone do cadeado aberto, indicam que para este tipo de ligação, não será solicitada a senha, mesmo que o sistema de bloqueio esteja ativado. Para abrir/fechar o cadeado, basta clicar sobre o ícone.

Editar Usuário: Para alterar as configurações e os dados de um usuário, basta clicar no ícone

na linha do usuário desejado. Após fazer as modificações desejadas, é necessário clicar em para salvar as novas configurações.

6.2. Ramais 6.2.1. Gerenciar

Figura 187: Listagem de ramais

Nesta seção, é possível ver a lista dos ramais cadastrados, bem como fazer buscas, novos cadastros e editar ramais já cadastrados. É possível gerenciar tanto ramais IP, que são indicados pelo ícone

na coluna “Tipo”, quanto ramais

convencionais (analógicos ou digitais), identificados pelo ícone . A coluna “Usuários” indica quantos IDs de usuários estão associados a cada ramal. É possível fazer busca por número de ramal, ou por dados de localização (unidade, departamento e local), bem como por nome de central telefônica, para ramais convencionais. Para editar dados de ramais já cadastrados, basta clicar no ícone desejadas, clicar em

e, após fazer as alterações

para salvar as novas configurações.


228

Capítulo 07

PBX IP

6.2.2. Cadastrar Ramal Os dados informados no cadastro do ramal são os dados que irão constar na página do catálogo telefônico, independente dos dados de localização cadastrados nos usuários associados. Os seguintes itens devem ser preenchidos no formulário: Ø Tipo de Ramal: Define se o ramal sendo cadastrado. Atualmente somente o cadastro de ramal IP é suportado. Ø Unidade/Departamento/Local: Os dados preenchidos nestes campos são os que serão exibidos no catálogo telefônico; Ø Ramal: número do ramal com 4 dígitos; Ø Prefixo: Tronco/Prefixo com a operadora; Ø Páginas amarelas: define a visibilidade do ramal no catálogo: § Público: será exibido no catálogo disponível para toda a Internet; § Somente Interno: será exibido somente quando a consulta ao catálogo for feita dentro da rede da instituição; § Não exibir: o ramal não será exibido nem dentro nem fora da instituição. Ø Contatos do Ramal: Podem ser incluídos nomes de usuários do ramal, além do responsável, que é o usuário associado. Para incluir mais de um nome, basta clicar no ícone ; Ø Serviços: Serviços disponíveis apenas para ramais IP: § Modo Fax: todas as chamadas recebidas pelo ramal receberão tom de fax; § Modo Fax Temporário: apenas a próxima chamada após a habilitação deste campo receberá tom de fax e as demais serão tratadas como chamadas de voz; § Siga-me contínuo: todas as chamadas serão encaminhadas para o ramal preenchido neste campo; § Correio de voz – Secretária Eletrônica: habilita as chamadas não atendidas a serem enviadas para a caixa postal do ramal, acessível com a senha preenchida neste item; § Correio de voz – Anexar recado para o email: as chamadas encaminhadas para o correio de voz serão enviadas por email para o usuário responsável, no formato de arquivo de áudio; § Correio de voz – Secretária Eletrônica: as chamadas encaminhadas para a caixa postal ficarão disponíveis para acesso apenas através do ramal, sem o envio de email.


229

Capítulo 07

PBX IP

Figura 188: Cadastro de Ramal

6.2.3. Prefixos Definem os troncos com operadora que a instituição possui, indicando os prefixos aos quais serão atribuídos ramais. Para o cadastro de prefixo, deverão ser informados: Ø Código do País (2 dígitos); Ø Código DDD do prefixo (2 dígitos); Ø Prefixo (4 dígitos); Ø Descrição: Informações opcionais.

Figura 189: Cadastro de Prefixo

6.2.4. Faixas Permite definir faixas de ramais para unidades específicas. Ao fazer um cadastro de ramal, após selecionar uma unidade cadastrada com uma faixa de ramais, basta clicar nos ícones


para que

230

Capítulo 07

PBX IP

o sistema selecione automaticamente o primeiro ou o último ramal disponível na faixa reservada para a unidade, respectivamente. Ao fazer o cadastro de uma faixa, é necessário informar: Ø Tipo de Faixa: IP; Ø Prefixo: prefixo dos ramais da faixa; Ø Início/Fim da Faixa: o ramal inicial e final da faixa; Ø Descrição: Informações opcionais Ø Unidade Preferencial: se nenhuma unidade preferencial for escolhida, os ramais pertencentes à faixa poderão ser atribuídos a qualquer unidade. Se uma unidade for selecionada como preferencial, os ramais da faixa somente poderão ser atribuídos à esta unidade.

Figura 190: Cadastro de Faixa

6.3. Provisionamento No provisionamento é feita a configuração de telefones IP com ramais/usuários cadastrados no ambiente, bem como fazer o controle patrimonial dos aparelhos de telefone IP. É possível consultar MACs de telefones IP cadastrados, códigos de tombamento patrimonial, modelos de telefones IP, e usuários, bem como alterar o arquivo .cfg com configurações dos telefones Polycom. Para edição do arquivo .cfg, basta clicar no ícone ao lado do aparelho desejado. Para edição dos mapeamentos entre telefone IP x usuário, basta clicar no ícone . É possível ainda exportar a listagem dos dados dos telefones IP para um arquivo .xls clicando no ícone .

Figura 191: Listagem de Provisionamento


231

Capítulo 07

PBX IP

6.3.1. Cadastrar Configuração Para fazer o provisionamento de um telefone IP, devem ser preenchidas as seguintes informações: Ø Número do Patrimônio: código de tombamento patrimonial do aparelho; Ø Número de Série/Endereço MAC: o endereço completo deve ser preenchido, pois este dado será utilizado para fazer a configuração do aparelho quando o mesmo for conectado à rede; Ø Modelo do Telefone: Ao selecionar o modelo, são mostrados os campos de usuário/ramal, de acordo com a quantidade de linhas suportada por cada modelo; Ø Usuário: deverá ser preenchido com o login de usuário previamente cadastrado. Ø Telefone: após o preenchimento do usuário, serão mostrados os ramais associados a ele. Deverá ser selecionado no combo, o ramal que deseja utilizar para o usuário neste telefone IP sendo configurado. Ø Nome/Email do Responsável: Após preencher o usuário e telefone, basta clicar no ícone para preencher automaticamente estes campos com os dados do usuário.

Figura 192: Cadastro de Provisionamento

6.3.2. Telefones Esta opção permite cadastrar e consultar os modelos e características dos telefones IP que serão utilizados no ambiente.


232

Capítulo 07

PBX IP

Figura 193: Listagem de modelos de telefone IP

Para cadastrar um telefone IP, devem ser informados: § Fabricante; § Modelo; § Quantidade de linhas suportadas; § Se há ou não suporte a PoE.

Figura 194: Cadastro de telefone IP

6.3.3. Fabricantes Os nomes de fabricantes cadastrados nesta opção serão utilizados para o posterior cadastro de telefones.

Figura 195: Cadastro de Fabricante

6.3.4. Histórico Permite consultar informações de data/hora de cadastro e alteração de provisionamento.


233

Capítulo 07

PBX IP

É um registro histórico de cada telefone IP, indicando quais usuários já foram configurados em um dado aparelho e quando as alterações foram feitas.

Figura 196: Histórico de Provisionamento

6.4. Serviços São funcionalidades adicionais para os ramais da instituição. Estão disponíveis os serviços de gravação de mensagem para informar sobre mudanças de número de ramal, bem como captura de ligações entre grupos pré-definidos. 6.4.1. Troca de Número Quando um ramal é desativado e substituído por outro, é possível criar uma mensagem informando o novo número quando houver ligações para o número antigo. Esta opção apenas faz a gravação da mensagem, sendo necessário configurar o funcionamento do serviço e a rota no SRL. Ao cadastrar o número novo e o antigo, é necessário que eles estejam no formato Cód.País + DDD + Prefixo + número (Ex: 554837210000).

Figura 197: Cadastro de troca de número

6.4.2. Captura A captura de chamadas entre ramais IP gerenciados pelo ambiente foi testada e homologada para telefones IP Polycom. Para fazer a captura de chamadas, basta teclar Menu 1 8 no aparelho que deseja “puxar” uma ligação de outro. Para que possa ser feita a captura, é necessário cadastrar um grupo, no qual deverá ser informado: Ø Um ID para o grupo (geralmente o número de um dos ramais pertencentes ao grupo); Ø Descrição/Nome;


234

Capítulo 07

PBX IP

Ø Login dos usuários pertencentes ao grupo. Para adicionar mais usuários, basta utilizar o ícone

Figura 198: Cadastro de grupo de captura

6.5. Organização Esta opção permite o cadastro de informações administrativas de localização dos ramais instalados.

6.5.1. Unidades Como Unidades, geralmente são cadastrados centros de ensino e pró-reitorias, por exemplo. Para o cadastro de Unidades devem ser preenchidas as seguintes informações: Ø Nome: identificador único para cada unidade; Ø Descrição: informações opcionais; Ø Créditos Padrão: caso deseje que todos os ramais vinculados a uma unidade, que utilizem o sistema de créditos, recebam inicialmente o mesmo valor, deverá ser informado neste campo o valor desejado; Ø Responsável/E-mail: informações utilizadas apenas para fins de geração de relatórios; Ø Permissões Padrão: caso deseje que todos os usuários vinculados a uma unidade, sejam inicialmente autorizados para os mesmos tipos de ligação, deverão ser marcadas as permissões desejadas. É possível selecionar configurações diferentes para unidades diferentes.


235

Capítulo 07

PBX IP

Figura 199: Cadastro de Unidade

6.5.2. Departamentos Para o cadastro de departamentos, devem ser utilizados nomes únicos. Cada departamento é vinculado a apenas uma unidade.

Figura 200: Cadastro de Departamento

6.6. Painel de Controle 6.6.1. Console Esta opção visa facilitar o debug e acompanhamento de logs. É possível filtrar logs de ligações, de erros, de acesso ao boot Server, entre outros. O log é atualizado no intervalo de tempo definido, sendo que é possível pausar a atualização para verificação.


236

Capítulo 07

PBX IP

Figura 201: Console de logs

6.7. Status 6.7.1. Visão Geral Neste menu, é possível verificar: - Status dos serviços; - Estatísticas da central; - Status do ambiente; - Status de replicação do banco de dados; - Status administrativo e operacional dos servidores Master e Slave.


237

Capítulo 07

PBX IP

Figura 202: Visão geral do sistema

6.7.2. Ligações É possível acompanhar as ligações ativas em tempo real, observando origem, destino e duração da chamada até o momento. Para atualizar o registro das ligações, basta clicar no ícone canto inferior direito.

Figura 203: Ligações ativas

no

6.8. Contabilização 6.8.1. Completadas Disponibiliza a listagem das chamadas completadas pelos ramais do ambiente, tanto chamadas feitas, quanto recebidas, informando origem, destino, data e hora, duração e usuário associado.


238

Capítulo 07

PBX IP

É possível aplicar filtros para consulta por data, origem, destino, prefixo do tronco e usuário associado. Há três botões de atalho rápido para filtro por data, para pesquisar chamadas completadas nos sete dias anteriores, nos 30 dias anteriores, ou no mês atual.

Figura 204: Chamadas Completadas

6.8.2. Não Completadas Disponibiliza a listagem das chamadas não completadas pelos ramais do ambiente, tanto chamadas feitas, quanto recebidas, informando origem, destino, data e hora, código de erro e usuário associado. É possível aplicar filtros para consulta por data, origem, destino, prefixo do tronco e usuário associado. Há três botões de atalho rápido para filtro por data, para pesquisar chamadas não completadas nos sete dias anteriores, nos 30 dias anteriores, ou no mês atual.

Figura 205: Chamadas não completadas


239

Capítulo 07

PBX IP


240

Capítulo 08

PBX IP Acadêmico



Capítulo 8 – PBX IP Acadêmico


241

Capítulo 08

PBX IP Acadêmico

MÓDULO PBX-IP ACADÊMICA Guia de Instalação, Configuração e Operação

FONE@RNP DISTRIBUIÇÃO 2012 HISTÓRICO DO DOCUMENTO VERSÃO

DATA

RESPONSÁVEL

1.0

20/01/2014

1.1 1.2 1.3

28/01/2014 05/02/2014 13/02/2014

1.4

11/09/2014

Guilherme Eliseu Rhoden (PoP-SC) Estefania Borm Paulo Brandtner Edison Tadeu Lopes Melo (PoP-SC/UFSC) Murilo Vetter

1.5 1.6

06/01/2015 14/09/2015

Estefania Borm Estefania Borm

OBSERVAÇÃO Elaboração da documentação Revisão Descrição do WebService Revisão Adicionado link do disco da VM para deploy em outros virtualizadores Revisão Atualização e Revisão

Autores do Documento: - Guilherme Eliseu Rhoden - Estefania Borm

Equipe de Desenvolvimento: - Murilo Vetter (PoP-SC) - Guilherme Rhoden (PoP-SC) - Paulo Brandtner (PoP-SC) - Luis Cordeiro (PoP-SC)

Testes e Homologações - Estefania Borm

Coordenação Projeto: - Edison Melo (PoP-SC/UFSC) - Hélder Vitorino (RNP) - Alex Galhano (RNP)


242

Capítulo 08

PBX IP Acadêmico

ÍNDICE HISTÓRICO DO DOCUMENTO ................................................................................................................................... 242 1. INTRODUÇÃO .................................................................................................................................................. 245 2. PRÉ-REQUISITOS ........................................................................................................................................... 248 2.1. Configuração de DNS para a PBX-IP Acadêmica ............................................................................................. 249 3. GUIA DE INSTALAÇÃO .................................................................................................................................. 251 4. GUIA DE ACESSO INICIAL DA PBX-IP ACADÊMICA .............................................................................. 259 4.1. Configurando uma estação de trabalho para acessar a PBX-IP Acadêmica ....................................... 259 5. GUIA DE CONFIGURAÇÃO ............................................................................................................................ 262 5.2. Módulo Central - Status .............................................................................................................................................. 264 5.2. Módulo Sistema - Firewall ......................................................................................................................................... 266 5.3. Configurações - Sistema .............................................................................................................................................. 268 a) Aba Instituição ............................................................................................................................................................... 268 b) Aba Sistema ..................................................................................................................................................................... 269 c) Aba Gerência ................................................................................................................................................................... 270 d) Aba Proxy SIP ................................................................................................................................................................. 272 e) Aba CAFe ........................................................................................................................................................................... 273 f) Aba TDM ............................................................................................................................................................................ 274 g) Aba Serviços .................................................................................................................................................................... 275 h) Aba Aplicar ...................................................................................................................................................................... 275 5.4. Configurações - Atualização ..................................................................................................................................... 276 5.5. Configurações - Backup .............................................................................................................................................. 277 5.6. Administradores - Gerenciar ..................................................................................................................................... 278 5.7. Logs - Visualizar ............................................................................................................................................................. 279 5.8. Configurações - Permissões de Discagem ............................................................................................................ 280 5.9. Configurações - Plano de Discagem ....................................................................................................................... 281 6. GUIA DE OPERAÇÃO ...................................................................................................................................... 282 6.1. Organização - Classes .......................................................................................................................................................... 282 6.2 Ramais - Prefixos ..................................................................................................................................................................... 284 6.3 Ramais - Faixas ........................................................................................................................................................................ 285 6.4. Portal do Usuário ................................................................................................................................................................... 286 6.5. Usuários SIP ............................................................................................................................................................................. 293 6.6. Ramais - Gerenciar ................................................................................................................................................................ 295 6.7. Registro de Usuário em Sofphone para Teste ............................................................................................................ 297 6.8. Painel de Controle - Console .............................................................................................................................................. 298 6.9. Ligações ..................................................................................................................................................................................... 298 6.10. Contabilização ...................................................................................................................................................................... 299 6.10.1 Completadas ........................................................................................................................................................... 299 6.10.2. Não Completadas ................................................................................................................................................. 300 7. INTEGRAÇÃO DE SISTEMAS - WEB SERVICE ......................................................................................... 302 7.1 createRamal .............................................................................................................................................................................. 302 7.1.1 Parâmetros de Entrada ........................................................................................................................................ 302 7.1.2 Parâmetros de Saída .............................................................................................................................................. 302 7.2 alterarSenha ............................................................................................................................................................................. 303 7.2.1 Parâmetros de Entrada ........................................................................................................................................ 303


243

Capítulo 08

PBX IP Acadêmico

7.2.2 Parâmetros de Saída .............................................................................................................................................. 303 7.3 buscaInfoRamais ..................................................................................................................................................................... 303 7.3.1 Parâmetros de Entrada ........................................................................................................................................ 303 7.3.2 Parâmetros de Saída .............................................................................................................................................. 303 7.4 excluirUsuario .......................................................................................................................................................................... 304 7.4.1 Parâmetros de Entrada ........................................................................................................................................ 304 7.4.2 Parâmetros de Saída .............................................................................................................................................. 304

ÍNDICE DE FIGURAS Figura 1: Login cliente VMware vSphere. ......................................................................................................... 251 Figura 2: Deploy OVF Template........................................................................................................................ 253 Figura 3: Deploy from a file or URL. ................................................................................................................ 253 Figura 4: Importar VM - Continuar. .................................................................................................................. 254 Figura 5: Definir nome da VM. .......................................................................................................................... 254 Figura 6: Escolher Resource Pool. ..................................................................................................................... 255 Figura 7: Escolher Disco. .................................................................................................................................... 255 Figura 8: Escolher Formato de Disco................................................................................................................ 256 Figura 9: Selecionar a rede. .................................................................................................................................. 257 Figura 10: Finalizar importação da VM. ............................................................................................................ 257 Figura 11: Central de Rede e Compartilhamento............................................................................................. 259 Figura 12: Conexões de Rede. ............................................................................................................................. 259 Figura 13: Conexão Local. ................................................................................................................................... 260 Figura 14: IP Manual. ........................................................................................................................................... 260 Figura 15: Iniciar - CMD. .................................................................................................................................... 261 Figura 16: Prompt de Comando. ........................................................................................................................ 261 Figura 17: Avançado. ............................................................................................................................................ 262 Figura 18: Confirmar Exceção. ........................................................................................................................... 262 Figura 19: Catálogo Telefônico. .......................................................................................................................... 263 Figura 20: Tela de Login da PBX-IP Acadêmica. ............................................................................................ 264 Figura 21: Tela de Status - Visão Geral da PBX-IP Acadêmica. ................................................................... 265 Figura 22: Tela de Configuração do Firewall. ................................................................................................... 267 Figura 23: Salvar e Aplicar Firewall. ................................................................................................................... 268 Figura 24: Sistema - Instituição. .......................................................................................................................... 269 Figura 25: Sistema - Sistema. ............................................................................................................................... 269 Figura 26: Sistema - Gerência. ............................................................................................................................ 271 Figura 27: Sistema - Acesso Web. ...................................................................................................................... 272 Figura 28: Configuração Proxy SIP. ................................................................................................................... 272 Figura 29: Sistema - CAFe. .................................................................................................................................. 273 Figura 30: Sistema - TDM. .................................................................................................................................. 274 Figura 31: Sistema - Serviços. .............................................................................................................................. 275 Figura 32: Aplicar configurações. ....................................................................................................................... 275


244

Capítulo 08

PBX IP Acadêmico

Figura 33: Atualizar Aplicações. ......................................................................................................................... 276 Figura 34: Aplicar Atualizações. ......................................................................................................................... 277 Figura 35: Atualização completa. ........................................................................................................................ 277 Figura 36: Backup. ................................................................................................................................................ 278 Figura 37: Listagem de usuários administradores. ........................................................................................... 278 Figura 38: Cadastro de administradores. ........................................................................................................... 278 Figura 39: Cadastro de administradores do ambiente. .................................................................................... 279 Figura 40: Filtro de logs. ...................................................................................................................................... 279 Figura 41: Visualização de logs. .......................................................................................................................... 279 Figura 42: Detalhes de log de uma ação. ........................................................................................................... 280 Figura 43: Permissões de Discagem. .................................................................................................................. 281 Figura 44: Plano de Discagem............................................................................................................................. 281 Figura 45: Classes de Afiliação EduPerson ....................................................................................................... 283 Figura 46: Cadastro de classe. ............................................................................................................................. 284 Figura 47: Ramais - Prefixos................................................................................................................................ 284 Figura 48: Cadastro de Prefixo. .......................................................................................................................... 285 Figura 49: Ramais -Faixas. ................................................................................................................................... 285 Figura 50: Cadastro de Faixa. .............................................................................................................................. 286 Figura 51: Login Portal do Usuário. ................................................................................................................... 287 Figura 52: Selecionar Vínculo. ............................................................................................................................ 288 Figura 53: Selecionar Ramal. ............................................................................................................................... 289 Figura 54: Tela Inicial - Portal do Usuário. ....................................................................................................... 290 Figura 55: E-mail de confirmação de criação de conta. .................................................................................. 291 Figura 56: Alteração do status após ativação. ................................................................................................... 292 Figura 57: Portal do Usuário - Configurações. ................................................................................................. 292 Figura 58:Lista de contatos. ................................................................................................................................. 293 Figura 59: Usuários SIP -Gerenciar. .................................................................................................................. 293 Figura 60: Detalhes do usuário. .......................................................................................................................... 294 Figura 61: Detalhes de histórico de registro do usuário. ................................................................................ 294 Figura 62: Editar Usuário..................................................................................................................................... 295 Figura 63: Ramais - Gerenciar............................................................................................................................. 296 Figura 64: Cadastro de Ramal. ............................................................................................................................ 296 Figura 65: Painel de Controle - Console ........................................................................................................... 298 Figura 66: Status - Ligações. ................................................................................................................................ 299 Figura 67:Contabilização. ..................................................................................................................................... 299 Figura 68: Chamadas completadas. .................................................................................................................... 300 Figura 69: Chamadas Não Completadas. .......................................................................................................... 300

1 Sobre o PBX IP Acadêmico O PBX IP Acadêmico é uma implementação especial de um PABX tradicional, desenvolvido para o fone@RNP, que procura atender às demandas comuns do serviço de telefonia de uma


245

Capítulo 08

PBX IP Acadêmico

grande universidade brasileira. Foi desenvolvido primeiramente pela Universidade Federal de Santa Catarina (UFSC), para atender às necessidades da UFSC. Quando da solicitação de incorporação dessa solução ao fone@RNP, foi modificado para se integrar ao serviço e melhor atender a todos os clientes do fone.

É muito importante ressaltar que a RNP não atuará como mantenedora do PABX das instituições, mesmo se elas optarem por instalar o PABX do fone@RNP. Nós desenvolvemos a solução e estamos oferecendo-a para uso nas instituições em conjunto com os outros módulos do serviço fone@RNP. Mas, exatamente como quando uma instituição escolhe utilizar qualquer outro PABX, seja ele Siemens, Avaya, Cisco, Leucotron, Intelbrás, Asterisk, Elastix, SNEP ou qualquer outro fabricante, é necessário que a instituição contrate uma empresa (ou possua o conhecimento internamente) para manter seu PABX funcionando corretamente. Atualmente, no momento da escrita desse livro, para realizar o trabalho de mantenedor do PABX IP do fone@RNP, a RNP conta com a equipe do PoP-SC, que desenvolveu o PABX, e com a CAM Tecnologia, que nos dá suporte no fone@RNP. O PBX IP foi desenhado para funcionar com outros módulos do fone, tendo como pré-requisito, a instalação de um SRL. Além disso, a terminação de ligações na RTFC deve ser feita por um gateway (idealmente o GWT) configurado como um peer do SRL que controla este domínio. O PBX IP deve receber INVITES apenas do SRL diretamente acima. Todas as chamadas feitas a partir de um PBX IP devem ser encaminhadas para o SRL. Conexões de áudio e vídeo podem seguir entre o PBX e o SRL e o PBX e outros dispositivos deste domínio. Como visto nos parágrafos anteriores, o SRL fica responsável por indicar a rota correta para o número de telefone desejado. Esta versão do PBX IP se chama acadêmica porque foi desenhada para atender aos alunos das universidades. Ela possui integração com o serviço de Identidade Digital da RNP, a CAFe, Comunidade Acadêmica Federada. Essa integração permite a implementação de uma função de autoatendimento, onde o aluno é capaz de solicitar seu próprio ramal IP em uma página web, sem a intervenção de qualquer funcionário. Uma característica única no PABX IP desenvolvido para a comunidade acadêmica brasileira.

O PBX IP também é preferivelmente implementado como uma Máquina Virtual. A RNP utiliza VMWare, mas é possível implementar em qualquer outro fabricante ou tecnologia de virtualização, embora a RNP não dê suporte para outras VMs. O PBX IP é implementado SEMPRE em duplas, para garantir a Alta Disponibilidade do serviço. Se um servidor parar de responder por qualquer motivo, o outro deve assumir e o serviço de telefonia não deve parar. Por isso, escolha servidores de virtualização diferentes para instalar os SRLs, de preferência, distantes geograficamente.

AVISO


246

Capítulo 08

PBX IP Acadêmico

O serviço fone@RNP, baseado na tecnologia de Telefonia sobre Internet Protocol (IP), é uma aplicação que utiliza a infraestrutura de redes IP para encaminhar ligações telefônicas. Por isso mesmo, está sujeita às vantagens e desvantagens do IP. A implantação e manutenção de um serviço de telefonia IP não é trivial, e requer profissionais qualificados para exercer tais tarefas. É necessário que o profissional, responsável técnico pelo serviço na instituição, conheça os riscos da implantação deste serviço. É necessário que ele promova e coordene o diálogo entre as equipes de redes, segurança de redes e de telefonia (ou equivalentes). A RNP se preocupa com a segurança do sistema e a qualidade das ligações. O fone@RNP é dotado de uma série de funções e subsistemas que tratam essas questões de forma mais eficiente possível. Entretanto, não pode garantir que o sistema nunca será invadido, nunca terá mau uso, ou nunca sofrerá por consequência de parâmetros Qualidade de Serviço (QoS) inadequados. A Rede Nacional de Ensino e Pesquisa, RNP, possui o dever de informar que não é responsável por quaisquer danos ou prejuízos causados pelo uso do serviço fone@RNP, principalmente relacionados à qualidade das chamadas e à segurança do sistema contra invasões e mau uso.


247

Capítulo 08

PBX IP Acadêmico

20.

INTRODUÇÃO

A PBX-IP Acadêmica foi concebida para prover um ambiente gráfico de gerência de acesso à telefonia IP para alunos e funcionários de uma instituição. Este guia descreve uma visão geral da PBX-IP Acadêmica, contemplando todos os passos necessários para a instalação, configuração e operação do ambiente, incluindo a integração com a federação CAFe e com aplicações da instituição via WEB Service. A PBX-IP Acadêmica possui duas formas de integração com os sistemas da instituição: • Através do LDAP da Federação CAFe; • Através do WebService da PBX-IP. A PBX-IP Acadêmica disponibiliza para a instituição: • Catálogo Telefônico: listagem pública para consulta de ramais e usuários; • Portal do Usuário: interface de auto-serviço, para acesso individual de cada usuário à criação e configurações do seu próprio ramal; • Área administrativa - Módulo Sistema: para configuração de parâmetros da própria máquina, firewall, etc, através de uma interface web; • Área administrativa - Módulo Central: para gerência (cadastros, consultas e alterações) de ramais, usuários e permissões de discagem; • WebService: para integração com sistemas de gerenciamento de identidade e vinculo com a instituição, consultando os alunos e funcionários com vínculo ativo/regular, permitindo então o uso de ramal da PBX-IP Acadêmica. Este guia foi elaborado com suporte as seguintes versões: • •

Web: 2.0.158 - 01/04/2015 Core: 2.0.28- 05/06/2015

21.PRÉ-REQUISITOS


248

Capítulo 08

PBX IP Acadêmico

Os requisitos mínimos para o funcionamento da máquina são os seguintes: ü Memória: 2GB RAM; ü Armazenamento: 50 GB; ü VMware 5.0 e VMware-Tools instalado.

Além disso, os seguintes requisitos também devem ser atendidos para a implantação da PBX-IP Acadêmica: Ø Já possuir o SIP Router Local (SRL) instalado e em produção na instituição; Ø Já possuir implantado o serviço da Comunidade Acadêmica Federada (CAFe) da RNP; Ø Ter um endereço IP público disponível para ser alocado à PBX-IP; Ø Fazer a configuração hostname/IP no DNS da rede da instituição; Ø Ter faixa de ramais para alocação TDM ou números privados do fone@RNP; Antes de iniciar a configuração da PBX-IP Acadêmica, tenha em mãos os seguintes dados: S Informação Descrição Exemplo 1

IP SRL-M1

Endereço IP do SIP Router Local Máquina 1

200.0.2.11

2

IP SRL-M2

Endereço IP do SIP Router Local Máquina 2

200.0.50.22

3

Realm

4

voip.instituicao.br ou acad.voip.instituicao.br 200.0.20.33

5

IP para a PBX-IP Acadêmica LDAP CAFe

6

Faixa TDM

Domínio que será utilizado para registro dos usuários Endereço IP Público que será utilizado pela PBX-IP Acadêmica Informações do LDAP da CAFe como: hostname/IP, DN Prefixo e faixa de ramais TDM e/ou fone@RNP

ldap.pop-sc.rnp.br ou=people,dc=ufsc,dc=br 48 1234-1000 a 48 1234-1999

21.1.

Configuração de DNS para a PBX-IP Acadêmica


249

Capítulo 08

PBX IP Acadêmico

Para o registro de ramal dos usuários da PBX-IP Acadêmica será necessário fazer a configuração de um Realm para a máquina. Para isso, deve-se fazer a configuração de Realm/Porta no DNS-SRV da instituição, isto é, incluir no DNS o registro SRV do Realm que será utilizado. Siga os exemplos a seguir para fazer a configuração no DNS da sua instituição: •

Exemplo 1: Realm direto no nome da instituição.

Realm: instituicao.edu.br Catálogo/Acesso usuários: acad.instituicao.edu.br Porta SIP: 5080 instituicao.edu.br ... pbxip-acad IN A 200.0.20.33 acad CNAME pbxip-acad.instituicao.edu.br. _sip._udp SRV 5 10 5080 pbxip-acad.instituicao.edu.br. •

Exemplo 2: Realm em um subdomínio da instituição.

Realm: voip.instituicao.edu.br Catálogo/Acesso usuários: acad.voip.instituicao.edu.br Porta SIP: 5080 voip.instituicao.edu.br ... @A 200.0.20.33 pbxip-acad IN A 200.0.20.33 acad CNAME pbxip-acad.voip.instituicao.edu.br. _sip._udp SRV 5 10 5080 pbxip-acad.voip.instituicao.edu.br.


250

Capítulo 08

PBX IP Acadêmico

22.

GUIA DE INSTALAÇÃO

A PBX-IP Acadêmica deve ser instalada através de imagem para VMware. Caso tenha outro tipo de sistema de virtualização, pode-se baixar o disco do VMware através do seguinte link: http://repositorio-fone.rnp.br/fone2012/PBX-IP-ACAD/VM/1.0/stable/FoneRNP-PBXIP-ACADdisk1.vmdk

Importante: Para que você consiga fazer o deploy da URL, você deve antes solicitar à RNP a liberação do IP do seu servidor de VM junto ao repositório. Para consultar a chave SHA1 para validação das imagens, utilize o seguinte link: http://repositorio-fone.rnp.br/fone2012/PBX-IP-ACAD/VM/1.0/stable/FoneRNP-PBXIP-ACAD.mf Para realizar a instalação via imagem do VMware, acesse o servidor de VMs através do VMware vSphere Client. Siga os passos descritos, conforme exemplos a seguir, para fazer a importação da VM, a partir do OVF Template, disponibilizado no repositório do fone@RNP.

Figura 206: Login cliente VMware vSphere.


251

Capítulo 08

PBX IP Acadêmico


252

Capítulo 08

PBX IP Acadêmico

Clique em “File >Deploy OVF Template...”

Figura 207: Deploy OVF Template.

No campo “Deploy from a file or URL”, informar a URL para download do arquivo a partir do repositório da RNP: http://repositorio-fone.rnp.br/fone2012/PBX-IP-ACAD/VM/1.0/stable/FoneRNP-PBXIP-ACAD.ovf

Figura 208: Deploy from a file or URL.


253

Capítulo 08

PBX IP Acadêmico

Figura 209: Importar VM - Continuar.

Informe um nome para a máquina.

Figura 210: Definir nome da VM.


254

Capítulo 08

PBX IP Acadêmico

Escolha um "Resource Pool" para colocar a máquina.

Figura 211: Escolher Resource Pool.

Escolha o disco a ser utilizado.

Figura 212: Escolher Disco.


255

Capítulo 08

PBX IP Acadêmico

Escolha o formato do disco: “Thick Provision Lazy Zeroed”.

Figura 213: Escolher Formato de Disco.

Escolha a rede (Vlan) a ser alocada para a PBX-IP Acadêmica.


256

Capítulo 08

PBX IP Acadêmico

Figura 214: Selecionar a rede.

Finalize a importação da VM.

Figura 215: Finalizar importação da VM.


257

Capítulo 08

PBX IP Acadêmico

Após concluído o processo de importação da VM, ligue a máquina para poder acessá-la e iniciar a configuração.


258

Capítulo 08

PBX IP Acadêmico

23.

GUIA DE ACESSO INICIAL DA PBX-IP ACADÊMICA

23.1. Configurando uma estação de trabalho para acessar a PBX-IP Acadêmica Para ilustrar este guia, foi utilizado o sistema operacional Windows 7. Caso você esteja utilizando outra versão do Windows ou mesmo outro sistema operacional será necessário adequar as instruções à sua estação de trabalho. A PBX-IP Acadêmica está configurada com o endereço IP 10.255.255.30/24. Para acessar a PBX-IP Acadêmica a partir de outra máquina da rede da instituição, coloque-a no mesmo segmento de rede do servidor. Em seguida, altere o IP da máquina, por exemplo: 10.255.255.5. Para isso, clique no botão “Iniciar”, depois em “Painel de Controle”, “Central de Rede e Compartilhamento” e do lado esquerdo escolha, “Alterar as configurações do adaptador”.

Figura 216: Central de Rede e Compartilhamento.

Clique com o botão direito na placa de rede do computador, e escolha a opção “Propriedades”.

Figura 217: Conexões de Rede.


259

Capítulo 08

PBX IP Acadêmico

Dê um clique duplo em “Protocolo TCP/IP Versão 4”.

Figura 218: Conexão Local.

Selecione a opção “Usar o seguinte endereço IP” e digite o IP exemplo: 10.255.255.5. Clique em OK.

Figura 219: IP Manual.


260

Capítulo 08

PBX IP Acadêmico

Para testar, utilize o prompt de comando. Clique no botão “Iniciar”. No campo destinado a “Pesquisar programas e arquivos”, digite CMD e tecle Enter.

Figura 220: Iniciar - CMD.

Na tela do prompt digite: “ping 10.255.255.30”, tecle enter e o resultado deve ser semelhante ao da Figura 16.

Figura 221: Prompt de Comando.

Feche a tela do prompt de comando e abra o navegador de sua preferência (para este guia, utilizamos o Chrome). Na barra de endereços, digite: https://10.255.255.30 e clique em "Avançado" .


261

Capítulo 08

PBX IP Acadêmico

Figura 222: Avançado.

Em seguida, clique em “Ir para 10.255.255.30" para proceder à tela de login do sistema.

Figura 223: Confirmar Exceção.

Os componentes do fone@RNP utilizam certificados auto-assinados para não deixar que informações de administração e configuração trafeguem em texto plano pela rede. Para poder acessar, basta aceitar o certificado auto-assinado, adicionando a exceção.

24.

GUIA DE CONFIGURAÇÃO

Seguindo os passos anteriores, aparecerá a página do catálogo telefônico:


262

Capítulo 08

PBX IP Acadêmico

Figura 224: Catálogo Telefônico.

O catálogo telefônico é uma página pública, para consulta de ramais e usuários, na qual é possível listar e buscar ramais por número, local, responsável, etc. Os ramais e usuários irão aparecer nesta página conforme forem sendo cadastrados, futuramente, na área administrativa da PBX-IP Acadêmica. No momento do cadastro do ramal/usuário, é possível escolher se este deverá ser exibido para consulta pública no catálogo ou não. Para fazer o acesso inicial à área administrativa da PBX-IP Acadêmica, para fazer as configurações do sistema, basta alterar a URL para: https://10.255.255.30/PBX-IP. Você será direcionado à tela inicial de login.


263

Capítulo 08

PBX IP Acadêmico

Figura 225: Tela de Login da PBX-IP Acadêmica.

Digite os seguintes dados para o acesso: Usuário: admin Password: pbxip.admin Após o primeiro acesso, troque a senha de administrador imediatamente!! No canto superior direito, clique em “Sistema”, depois em “Administradores”. Edite o administrador padrão e certifique-se de utilizar uma senha forte! OBS: Após alterar a configuração da máquina para IP público válido, você deverá acessar a área administrativa utilizando o IP da Máquina/PBX-IP ou hostname configurado no DNS da instituição/PBX-IP, isto é, https://IPdaMáquina/PBX-IP ou https://NomeDNSdaMáquina/PBX-IP.

5.2.

Módulo Central - Status

Após fazer o login, será exibida uma tela inicial de visão geral da máquina e da aplicação, na qual é possível observar diversas informações, como status de recursos da máquina, serviços, estatísticas, entre outras.


264

Capítulo 08

PBX IP Acadêmico

Figura 226: Tela de Status - Visão Geral da PBX-IP Acadêmica.

Ø Status dos Serviços: lista os principais serviços utilizados pela PBXIP, informando se estão rodando (ícone verde) ou não (ícone amarelo ou vermelho); Ø Estatísticas da Central: estatísticas de ramais e chamadas da PBXIP; Ø Status Administrativo: endereço IP alocado para a PBX-IP; Ø Número de CPUs e Porcentagem de Utilização: lista de CPUs da máquina, assim como seu modelo e velocidade, contendo ao lado o percentual de utilização de cada uma; Ø Memória Efetiva, Memória Utilizada e Swap: memória efetiva é a memória efetivamente sendo usada pelo sistema. Memória Serviço fone@RNP v.2012 Manual do serviço de telefonia IP da RNP

265

Capítulo 08

PBX IP Acadêmico

utilizada é o total de memória utilizada contando a memória em cache, e swap é o total de memória utilizada como swap; Ø Carga média do sistema: carga média da PBX-IP no último minuto, nos últimos 5 minutos e na última hora; Ø Número de processos: número de processos rodando na PBX-IP; Ø

Partições: lista de partições utilizadas pela máquina, contendo respectivamente suas porcentagens de utilização.

CENTRAL / SISTEMA: são os módulos de configuração e operação da PBX-IP, os quais podem ser alternados, clicando no canto superior direito da tela inicial, conforme Figura 21. § No módulo central, é feita a operação da PBX-IP, isto é, a gerência de ramais e usuários, contabilização de chamadas, etc. §

No módulo sistema, é feita a configuração da máquina e da aplicação, isto é, são feitas configuração de rede, firewall, TDM, etc.

5.2.

Módulo Sistema - Firewall

Iniciaremos a configuração da PBX-IP Acadêmica pelo Firewall, de modo a evitar a perda de acesso após alterar as configurações de rede da máquina. Para isso, clique em "Sistema", no canto superior direito da tela inicial. Em seguida, abra o menu lateral "Firewall". Nesta tela, é possível liberar diversos tipos de acesso à máquina.


266

Capítulo 08

PBX IP Acadêmico

Figura 227: Tela de Configuração do Firewall.

Inicialmente, na opção "Rede de Gerência" clique no botão

para adicionar uma nova linha.

Preencha o IP/máscara da rede da instituição a partir da qual serão feitos acessos futuros para operação da PBX-IP, quando for alterado para IP válido . Além disso, você deverá liberar os IPs de NTP e DNS que serão utilizados pela máquina. Também é possível liberar acesso a portas específicas através do item "Ações", conforme exemplo da Figura 23.


267

Capítulo 08

PBX IP Acadêmico

Figura 228: Salvar e Aplicar Firewall.

Por default, a porta padrão 5060 não é aberta, a fim de evitar acessos não autorizados. Caso queira que a porta fique aberta, basta incluir no item "Portas Abertas", mas não é recomendado, por ser uma porta comumente explorada em tentativas de SIP scan. A porta SIP local padrão para operação do ambiente é a 5080, mas poderá ser alterada na opção "Portas Abertas". Esta porta será utilizada pelos usuários para registro de ramal na PBX-IP e deve ser a mesma porta configurada no DNS da instituição. Sempre após fazer alterações na configuração do firewall, clique em "Salvar" e em seguida em "Aplicar ". É necessário aplicar para que as configurações do firewall tenham efeito.

5.3. Configurações - Sistema Após fazer a liberação de firewall, faremos a configuração da máquina e da aplicação. Para isto, acesse o menu lateral "Sistema" e preencha nas abas, as informações pertinentes da instituição e as principais configurações da aplicação e da máquina.

a) Aba Instituição


268

Capítulo 08

PBX IP Acadêmico

Aba que contém as informações da instituição e do responsável pela administração da PBX-IP Acadêmica. Clique na guia "Instituição" e preencha com os dados cadastrais solicitados, conforme exemplo da Figura 24. Ao concluir, clique em “Salvar”.

Figura 229: Sistema - Instituição.

b) Aba Sistema

Nesta aba serão preenchidas as configurações básicas da máquina, como rede, DNS, NTP, etc.

Figura 230: Sistema - Sistema.

Ø IP: IP válido que será atribuído à máquina. ESTE IP DEVE SER PÚBLICO.


269

Capítulo 08

PBX IP Acadêmico

Ø Máscara: Máscara de rede do IP; Ø Gateway: Gateway da rede à qual pertence o IP da máquina; Ø MTU: Tamanho máximo da MTU no segmento LAN, padrão: 1500; Ø Hostname: Nome do servidor no domínio de rede da instituição; Importante: No “Hostname” a padronização adotada é “PBXIP-Acad-Sigla da Instituição”. Ex: A UFSC terá o seguinte hostname: PBXIP-Acad-UFSC. OBS: Não utilizar: “_” “;” “.” ou outro caractere que possa quebrar na formação do FDQN( Fully Qualified Domain Name). Ø NTP1 e NTP2: Endereços dos servidores de NTP que serão utilizados pela máquina. Lembre de liberar estes endereços no firewall; Ø DNS Resolver 1 e DNS Resolver 2: Caso a instituição possua servidor de DNS, ou tenha algum que deseje apontar, inserir nesses campos e liberar no firewall. Esses DNS´s devem ser capazes de resolver zonas de ENUM. Caso não possua DNS capaz de resolver DNS ENUM, utilize os mesmos endereços IP dos SRLs. Estes endereços também devem ser liberados no firewall; Ø Domínio : Domínio de rede ao qual pertence o IP da máquina; Ø Time zone: Fuso horário que a máquina irá utilizar.

c) Aba Gerência

Na aba Gerência, é possível configurar comunidades de monitoramento SNMP, desviar os logs para um servidor externo, configurar o SMTP para envio de emails automáticos e configurar permissão acesso para determinadas redes à interface de gerência da PBX-IP (IPdaPBX/PBX-IP).


270

Capítulo 08

PBX IP Acadêmico

Figura 231: Sistema - Gerência.

Ø SNMP: § Comunidade: Comunidade SNMP somente leitura; § Rede de Gerência: Rede de gerência da comunidade SNMP; Ø SYSLOG: § IP: Endereço IP do servidor syslog de sua instituição. Para desativar o desvio a um servidor externo, preencher com 127.0.0.1; § Porta: Porta onde o servidor estará escutando (Padrão: 514). § Protocolo: Protocolo de transporte, atualmente suportado TCP e UDP (Padrão: UDP). Ø SMTP: § Servidor SMTP: nome ou IP do servidor SMTP responsável por encaminhar os e-mails automáticos de saída da PBX-IP. Quando é feito cadastro ou alteração de dados de usuário, as alterações são informadas através de um email automático enviado para o endereço de email cadastrado no usuário; § Porta do servidor SMTP: Porta do servidor SMTP. Ex: 465. § E-mail de origem: e-mail de remetente utilizado para compor as mensagens, utilizado para receber respostas de usuários; § Autenticação SMTP: Marcar o checkbox caso o serviço de e-mail requeira autenticação e informar o usuário e senha para tal. Ø Acesso WEB: Define as redes a partir das quais é autorizado o acesso a interface de gerência da PBXIP: § WWW [1 – 5]: IP/Máscara das redes que poderão acessar a interface de gerência da PBX-IP; § WebService: IP dos servidores que se comunicarão com o WebService da PBX-IP para criação de ramais. Preencher os IP separados por um espaço em branco. Ex: IP do servidor de sistema de identidade ou gerência de usuários da instituição;


271

Capítulo 08

PBX IP Acadêmico

Importante: Ø Acesso WWW: Liberar somente para a rede de gerência da instituição e equipe de suporte RNP. Ø Acesso Web Service: O método atual de autenticação é através do IP de origem. Somente liberar para o IP de sua aplicação, caso deseje interagir com a PBX-IP. Para desabilitar, deixar em branco.

Figura 232: Sistema - Acesso Web.

d) Aba Proxy SIP Define as configurações dos proxys para comunicação com a PBX-IP.

Figura 233: Configuração Proxy SIP.


272

Capítulo 08

PBX IP Acadêmico

Ø PBX - VoIP Realm: Realm que será utilizado para responder ao serviço VoIP, isto é, o nome definido para o IP da máquina no DNS da instituição. Ex: acad.voip.instituicao.br; Ø OpenSIPs - Porta: Porta onde o SIPProxy (OpenSIPS) irá atender requisições. Padrão: 5080; Ø OpenSIPs - Nível de Debug: Nível de log que será gerado pelo OpenSIPs. Escolha entre 0 até 7. Recomenda-se utilizar 1. Ø Midia Server - Porta: Porta UDP onde o asterisk responsável por executar funções de servidor de mídia irá atender requisições (padrão: 5071). Não pode ser a mesma do OpenSIPs. O acesso dessa porta somente será realizado pelo OpenSIPs; Ø Sip Router Local - IP Master: IP do Sip Router Local (SRL) master de sua instituição (Máquina 1); Ø Sip Router Local - Porta Master: Porta do SRL master ( Máquina 1). Padrão: 5060; Ø Sip Router Local - IP Slave: IP do Sip Router Local (SRL) slave de sua instituição (Máquina 2); Ø Sip Router Local - Porta Slave: Porta do SRL slave (Máquina 2). Padrão: 5060; Observações: - A PBX-IP somente aceita INVITES de chamadas de peers válidos (SIP Routers Locais) ou usuários autenticados. Invites não autenticados ou de fontes desconhecidas são negados. - Para que o Realm funcione será necessário criar as entradas DNS-SRV apontando para a PBX-IP, informando em qual porta o proxy irá trabalhar (padrão 5080).

e) Aba CAFe Contém os parâmetros do LDAP de acesso para realizar a integração da PBX-IP com a Federação CAFe.

Figura 234: Sistema - CAFe.

Ø CAFe LDAP Host: IP ou hostname do servidor LDAP da CAFe de sua instituição; Ø DN: Ponto de acesso DN (Nome distinto) do diretório LDAP da instituição;


273

Capítulo 08

PBX IP Acadêmico

Ø Modo: Modo de Conexão: default ou SSL. Padrão: default; Ø Porta: Porta para realizar conexão. Padrão: 389 ou 636 (LDAP sobre SSL); Ø Autenticação Por: informar o modo de autenticação: UID ou CN.

f) Aba TDM Nesta aba serão configurados os parâmetros de TDM, isto é, numeração de telefonia que será utilizada pela PBX-IP.

Figura 235: Sistema - TDM.

Ø Telefonia convencional: Faixa de numeração válida, fornecida pela operadora à instituição, que será utilizada pela PBX-IP: • Código de País: Código de nação. Ex: Brasil = 55; • DDD: Código DDD da faixa de numeração do prefixo TDM; • Prefixo: Prefixo TDM , isto é, prefixo da faixa de numeração fornecida pela operadora e que será utilizada pela PBX-IP; • Código da Operadora: Código de operadora utilizado para originar chamadas de longa distância. Ex: Embratel 21; • Linha Externa: Código extra para acesso a linha externa. Ex: 0; • Ramal PBXIP Inicial: Ramal inicial do prefixo TDM que será atendido por essa PBX-IP; • Ramal PBXIP Final: Ramal final do prefixo TDM que será atendido por essa PBX-IP; • Ramal Padrão de Saída: Ramal do prefixo TDM utilizado para completar ligações através da URA da PBX-IP. Ø VoIP: Numeração interna do Fone@RNP: • Prefixo: Prefixo fornecido pela RNP para uso interno da instituição. Ex: 1XXX; • Ramal Inicial: Ramal inicial no prefixo VoIP que será atendido por essa PBX-IP; • Ramal Final: Ramal final no prefixo VoIP que será atendido por essa PBX-IP.


274

Capítulo 08

PBX IP Acadêmico

g) Aba Serviços Os serviços disponíveis nesta opção podem ser habilitados/desabilitados clicando sobre o serviço desejado, em cancelar/selecionar.

Figura 236: Sistema - Serviços.

h) Aba Aplicar Modificações feitas na configuração do sistema devem ser aplicadas para ter efeito. Selecione os itens onde as configurações devem ser aplicadas. Normalmente, seleciona-se os três itens: Sistema, OpenSips e Asterisk. Em seguida, clicar em "Aplicar configurações" e aguardar sua conclusão.

Figura 237: Aplicar configurações.


275

Capítulo 08

PBX IP Acadêmico

Após aplicar as configurações, o IP da máquina será alterado. Será necessário voltar à configuração original de IP na máquina de acesso. Pode ser necessário também alterar a configuração de vlan da máquina virtual no ambiente WMWare, caso tenha utilizado uma vlan diferenciada para a configuração. Em seguida acesse novamente a o PBX IP Acadêmico, agora utilizado o IP válido que foi configurado.

5.4. Configurações - Atualização Após acessar a máquina através do IP válido, com saída para a Internet, o primeiro passo é verificar se há atualizações disponíveis. Para isso, acesse o menu "Atualização". Se houver atualização disponível, será exibido conforme figura 33:

Figura 238: Atualizar Aplicações.

Clique em "Atualizar Aplicações". Após concluir a atualização, será exibido o log conforme exemplo da Figura 34. Na caixa de texto destacada em verde, clique em "Configurações de Ambiente". Você será redirecionado a tela do menu sistema, onde deverá aplicar as configurações para que as alterações tenham efeito, conforme descrito na seção 5.3.h.


276

Capítulo 08

PBX IP Acadêmico

Figura 239: Aplicar Atualizações.

Caso não tenha nenhuma atualização disponível, será exibida a mensagem conforme Figura 35. Caso informe "Erro ao buscar atualizações", solicite à RNP permissão para fazer atualização do componente junto ao repositório.

Figura 240: Atualização completa.

5.5. Configurações - Backup

É possível guardar um arquivo de backup das configurações atualizadas de sistema e firewall da PBX-IP, caso ocorra algum problema com a máquina e seja necessário fazer uma reinstalação futuramente. Para fazer o download do arquivo de backup, basta acessar o menu "Backup" e clicar em “Backup do arquivo M4”. Será gerado um arquivo de texto com os principais parâmetros e variáveis do sistema. Recomenda-se fazer o download do arquivo e armazená-lo para uso futuro, caso seja necessário.


277

Capítulo 08

PBX IP Acadêmico

Para fazer o upload do arquivo M4 (restauração de backup), basta clicar em “Selecionar Arquivo”. Em seguida, clicar em “Enviar”.

Figura 241: Backup.

5.6. Administradores - Gerenciar

Após concluir a configuração e atualização, recomenda-se alterar a senha do admin, a fim de evitar acessos não autorizados. Para isso, acesse o menu "Gerenciar", na guia "Administradores". Será exibida a listagem dos usuários administrativos cadastrados no sistema, onde é possível editar as informações de um usuário clicando no ícone

. Edite o usuário admin e altere a senha.

Figura 242: Listagem de usuários administradores.

Caso queira cadastrar outros usuários para acessar a área administrativa da PBX-IP, clique em "Cadastrar Administrador".

Figura 243: Cadastro de administradores.

Será exibida uma tela para preenchimento das informações do usuário, bem como as permissões de acesso que serão concedidas a ele. Caso deseje que o usuário tenha acesso somente leitura a algum módulo específico, basta marcar a opção "Somente Leitura" ao lado da permissão. Caso deseje que o usuário não tenha acesso a um determinado módulo, basta deixá-lo desmarcado.


278

Capítulo 08

PBX IP Acadêmico

Figura 244: Cadastro de administradores do ambiente.

5.7. Logs - Visualizar Os usuários cadastrados para acesso a área administrativa da PBX-IP terão suas ações registradas através do menu logs, desde tentativas de login, cadastro de usuários, alteração de privilégios, dentre outras. Ao acessar o menu "Visualizar", serão listadas as ações do arquivo de logs, onde é possível realizar filtragem por data, usuário, ações, endereço IP e/ou alguma descrição. Estes parâmetros podem ser visualizados conforme Figura 40, tendo seu resultado exibido conforme Figura 41.

Figura 245: Filtro de logs.

Figura 246: Visualização de logs.


279

Capítulo 08

PBX IP Acadêmico

Para obter maiores detalhes sobre uma determinada ação, basta clicar sobre a linha, conforme exemplificado na Figura 42.

Figura 247: Detalhes de log de uma ação.

5.8. Configurações - Permissões de Discagem O próximo passo de configuração antes de poder iniciar a operação da PBX-IP Acadêmica é a configuração dos tipos de chamadas que poderão ser realizados pelos usuários, bem como as regras de formatação de número para encaminhamento ao SRL. Os tipos de chamadas permitidas pelo ambiente são mapeados através de expressões regulares, definidas nesta seção. Quando um usuário fizer uma chamada, o número destino será comparado com as expressões regulares definidas nesta seção, para identificar qual o tipo de destino que está sendo discado (Ramal, fixo/celular local, DDD, etc). Em seguida, será verificado se o usuário possui permissão para este tipo de chamada, para então fazer o encaminhamento ou recusar a chamada. Além disso, a combinação das chamadas efetuadas com as expressões definidas é utilizada para geração de relatórios e contabilização de custos (para chamadas tarifadas). Por exemplo, se o número discado por um usuário casar com a linha "Chamadas locais de PSTN para Fixo", conforme Figura 43, será em seguida verificado se este usuário possui permissão para fazer chamadas para fixo local PSTN. Se possuir, a chamada será encaminhada e o tipo de chamada será marcado na contabilização como sendo do tipo "Fixo local PSTN". Nesta seção, devem basicamente ser alterados nas expressões regulares o DDD, código de operadora, prefixo da instituição e faixa de ramais. Existe um campo para teste de número destino, no qual é possível testar as regras alteradas, inserindo um número e verificando se casa com alguma regra.


280

Capítulo 08

PBX IP Acadêmico

Figura 248: Permissões de Discagem.

5.9. Configurações - Plano de Discagem Após definir os tipos de chamadas permitidos no ambiente, é necessário definir os planos de discagem (dialplan) contendo as regras alteração de numeração/ reescrita para fazer o encaminhamento destas chamadas ao SRL. Através dos planos de discagem é possível alterar o formato do número discado pelo usuário antes de encaminhar ao SRL. Por ex, a instituição pode definir que os usuários disquem 0+DDD+8 números para chamadas interurbanas, e o plano de discagem pode incluir o código de operadora automaticamente antes de encaminhar a chamada ao SRL.

Figura 249: Plano de Discagem.

Ø Descrição: id/nome da regra sendo criada; Ø Expressão: expressão regular que case com a discagem feita pelo usuário;


281

Capítulo 08

PBX IP Acadêmico

Ø Strip: quantidade de dígitos à esquerda do número destino que devem ser removidos na reescrita; Ø Prefixo: dígitos/caracteres que devem ser inseridos à esquerda do número destino, depois que os dígitos do strip foram removidos; Ø Ativo: Ativar/Desativar regra. OBS: Uma chamada somente será encaminhada ao SRL depois de casar com pelo menos um plano de discagem, mesmo que este não altere o número. Caso haja planos de discagem conflitantes, será casado com o que aparecer primeiro na lista.

Neste ponto, a configuração da PBX-IP está concluída e a máquina já está pronta para operação. Para isto, será detalhado a seguir os procedimentos de operação do módulo Central.

25.

GUIA DE OPERAÇÃO

O módulo Central permite ao administrador fazer a operação do ambiente, oferecendo acesso ao status da PBX-IP, painel de controle, gerência de usuários, definição de informações de ramais, mapeamento de grupos da entidade EDUPERSON para os privilégios de interesse, informações de contabilização, entre outras funções.

6.1. Organização - Classes Inicialmente, é necessário cadastrar as classes de usuários (alunos, funcionários,etc) referentes ao esquema BR Eduperson, presentes na Federação CAFe, que serão utilizadas para o mapeamento no momento do auto-serviço de cadastro. Por padrão, a PBX-IP já possui três classes cadastradas conforme tipo de afiliação do Eduperson, as quais você deverá editar e definir os parâmetros de permissões e créditos.


282

Capítulo 08

PBX IP Acadêmico

Figura 250: Classes de Afiliação EduPerson

É possível editar uma classe, clicando no ícone

na linha da classe desejada. Também é possível fazer

cadastro de novas classes clicando em "Cadastrar Classe". Tanto para cadastro quanto edição de classe, os seguintes campos ficam disponíveis para preenchimento: Ø Nome: identificador único para cada classe; Ø Descrição: informações opcionais; Ø Tipo de Afiliação: tipo de afiliação (classe) ao Eduperson; Ø Créditos Padrão: todos os ramais de usuários vinculados a uma classe, que utilizem o sistema de créditos, receberão inicialmente o mesmo valor de créditos, definido nesta tela, e será feita uma recarga automática mensal no mesmo valor; Ø Permissões Padrão: caso deseje que todos os usuários vinculados a uma classe, sejam inicialmente autorizados para os mesmos tipos de ligação, deverão ser marcados as permissões de ligação desejadas.


283

Capítulo 08

PBX IP Acadêmico

Figura 251: Cadastro de classe.

6.2 Ramais - Prefixos Após definir as classes de usuários, é necessário definir os prefixos e as faixas TDM de ramais que serão atribuídas à cada uma, pela PBX-IP. Para isso, acesse o menu Ramais > Prefixos, e cadastre os prefixos de numeração que serão utilizados pela PBX-IP, conforme cadastrado anteriormente na aba TDM, das configurações do sistema.

Figura 252: Ramais - Prefixos.


284

Capítulo 08

PBX IP Acadêmico

Para o cadastro de prefixo, deverão ser informados os parâmetros, conforme exemplo da Figura 48: Ø Código do País (2 dígitos). Ex: 55; Ø Código DDD do prefixo (2 dígitos). Ex: 48; Ø Prefixo (4 dígitos). Ex: 1050; Ø Descrição: Informações opcionais. Ex: Prefixo Fone@RNP.

Figura 253: Cadastro de Prefixo.

6.3 Ramais - Faixas Após cadastrar os prefixos que serão utilizados, é necessário definir as faixas de ramais do prefixo, fazendo a divisão para cada classe, isto é, será definido o pool de ramais para cada classe Eduperson.

Figura 254: Ramais -Faixas.

Para fazer o cadastro de uma faixa, é necessário informar: Ø Prefixo: prefixo dos ramais da faixa; Ø Início/Fim da Faixa: o ramal inicial e final da faixa; Ø Descrição: informações opcionais;


285

Capítulo 08

PBX IP Acadêmico

Ø Classe Preferencial: deve ser informada uma classe, previamente cadastrada, à qual a faixa de ramais será atribuída.

Figura 255: Cadastro de Faixa.

OBS: Quando for cadastrado um usuário, será automaticamente atribuído o próximo ramal disponível da faixa associada a sua classe.

6.4. Portal do Usuário

Após a configuração dos prefixos e faixas, é possível iniciar o cadastro de usuários. O cadastro de usuários não pode ser feito de forma manual na interface administrativa da PBX-IP Acadêmica. Está interface, permite apenas a gerência, consulta e edição de alguns dados dos usuários. Para o cadastro de usuários, deverá ser utilizado sistema próprio da instituição, integrado à PBX-IP via web service, ou poderá ser cadastrado via interface de auto-serviço do Portal do Usuário. Para acessar o Portal do Usuário, digite no navegador web o endereço: https://IPdaMáquina/usuario ou

https://NomeDNSdaMáquina/usuario.


286

Capítulo 08

PBX IP Acadêmico

Figura 256: Login Portal do Usuário.

Para acessar o portal, o usuário deve utilizar suas credenciais da CAFe junto ao LDAP da instituição: Usuário: usuário da CAFe. Ex: nome.sobrenome; Senha: senha do usuário da CAFe.

Após a autenticação, a PBX-IP Acadêmica busca os vínculos do usuário e, caso possua mais de um vínculo (ex: funcionário e aluno), ficará a cargo do usuário definir qual vínculo ele utilizará na criação de sua conta.


287

Capítulo 08

PBX IP Acadêmico

Figura 257: Selecionar Vínculo.

Após selecionar a afiliação, será solicitado o e-mail do usuário para confirmação do cadastro. É necessário informar um email válido, bem como a configuração de SMTP da PBX-IP deve ser válida. Como o campo email não é obrigatório na CAFe, caso seja encontrado o email do usuário no LDAP, o mesmo será resgatado e caso não encontre o usuário poderá fornecer outro email. Após a escolha do email, será solicitado uma senha que o usuário irá utilizar para fazer o registro do seu ramal. Por questões de segurança optou-se por não forçar a utilização da mesma senha da CAFe, pois ficará salva na configuração do softfone e somente servirá para registro do usuário SIP. Além disso, o usuário deve selecionar um dos ramais disponíveis no combo. Feito isto, deve-se clicar em "Selecionar Ramal".


288

Capítulo 08

PBX IP Acadêmico

Figura 258: Selecionar Ramal.

Com isso, o cadastro do usuário está concluído e este será redirecionado para a tela inicial do Portal do Usuário, onde constam alguns dados da conta.


289

Capítulo 08

PBX IP Acadêmico

Figura 259: Tela Inicial - Portal do Usuário.

Além disso, o usuário receberá uma mensagem no email cadastrado, com as informações de registro do seu usuário, e com um link para fazer a ativação da conta. O ramal ficará bloqueado e não poderá ser utilizado enquanto o usuário não clicar no link enviado no email para fazer a ativação. Caso ainda não tenha confirmado a ativação da conta, o usuário não conseguirá logar seu softfone e aparecerá na tela inicial do portal a mensagem de status: “Para ativar seu ramal utilize o link enviado no seu e-mail”.


290

Capítulo 08

PBX IP Acadêmico

Figura 260: E-mail de confirmação de criação de conta.

Após a ativação, o status do ramal na página inicial do Portal do Usuário, deverá aparecer como “Ativo”.


291

Capítulo 08

PBX IP Acadêmico

Figura 261: Alteração do status após ativação.

Após a ativação do ramal, o usuário poderá realizar pequenos ajustes em suas configurações, através do portal do usuário, como alterar o e-mail e a senha, ativar serviço de correio de voz ou até mesmo realizar um redirecionamento contínuo (siga-me) para outro número, desde que possua privilégios para isso.

Figura 262: Portal do Usuário - Configurações.

O Portal do Usuário dispõe ainda de uma agenda onde o usuário pode cadastrar seus contatos.


292

Capítulo 08

PBX IP Acadêmico

Figura 263:Lista de contatos.

6.5. Usuários SIP Após concluir o cadastro através do Portal do Usuário, os ramais/usuários são inseridos na interface administrativa da PBX-IP. No menu "Usuários SIP", é possível consultar a lista de usuários cadastrados. Na lista de usuários (Figura 264), a coluna SO (Status Operacional) contém um ícone que fica na cor cinza quando o usuário não está registrado, e verde, quando o usuário está registrado. Já a coluna SA (Status Administrativo) indica os seguintes estados de ramal: Ø Verde: usuário ativado; Ø Vermelho: usuário aguardando ativação.

Figura 264: Usuários SIP - Gerenciar.

Apenas o SA ativo (verde) permite que o usuário possa se registrar e efetuar/receber chamadas. Para fazer a ativação manual de um usuário, sem clicar no link do email, basta clicar sobre o ícone da coluna SA do usuário desejado, passando de vermelho para verde. É possível exibir toda a lista, bem como fazer buscas específicas por usuários ou por dados de outras colunas, local, responsável, etc. A ordenação default da lista de resultados é feita por ordem de usuário, mas


293

Capítulo 08

PBX IP Acadêmico

também pode ser feita clicando sobre o nome da coluna de acordo com a qual os resultados devem ser ordenados. Ao clicar sobre o nome do usuário na lista, uma aba é aberta abaixo do mesmo, indicando algumas informações e dados. É possível ver o número dos ramais associados ao usuário, endereço IP, caso ele esteja registrado, histórico de endereços IP nos quais o usuário já se registrou, com as respectivas datas e horários, conforme pode ser observado na Figura 60 e Figura 61.

Figura 265: Detalhes do usuário.

Figura 266: Detalhes de histórico de registro do usuário.


294

Capítulo 08

PBX IP Acadêmico

Também é possível editar um usuário e alterar manualmente algumas informações, semelhante ao que é feito através do Portal do Usuário. Para isto, basta clicar no ícone

ao lado do usuário que se deseja

editar. Ao fazer alterações no usuário, não deve ser alterado dados de nome, login e documento, pois são dados automaticamente preenchidos pelo LDAP da CAFe. Podem ser alterados o email, habilitar/desabilitar sistema de créditos, inserir mais créditos, alterar o ramal, deixar o ramal como público ou não exibir no catálogo e alterar as permissões de discagem. Após fazer as alterações desejadas, clique em "Alterar".

Figura 267: Editar Usuário.

6.6. Ramais - Gerenciar Embora seja permitido cadastrar um ramal manualmente, essa ação não é necessária pois no momento do cadastro do usuário SIP, também é automaticamente cadastrado o ramal escolhido pelo usuário no Portal. Nesta seção, é possível ver a lista dos ramais cadastrados, bem os usuários associados, fazer buscas, cadastrar novos ramais ou editar ramais já cadastrados. Pode-se fazer buscas por número de ramal, ou outros dados do ramal. Ao clicar na linha do ramal, é aberta uma extensão abaixo do ramal, onde são detalhadas algumas informações do ramal selecionado.


295

Capítulo 08

PBX IP Acadêmico

Figura 268: Ramais - Gerenciar.

Para cadastrar um novo ramal, basta clicar em "Cadastrar Ramal" e preencher os dados solicitados. Para editar dados de ramais já cadastrados, basta clicar no ícone em

e, após fazer as alterações desejadas, clicar

para salvar as novas configurações.

Figura 269: Cadastro de Ramal.

Os seguintes campos estão disponíveis na tela de cadastro/edição de ramal:


296

Capítulo 08

PBX IP Acadêmico

Ø Classe: classe de afiliação, definida no cadastro da faixa que inclui o ramal; Ø Prefixo: prefixo da faixa do ramal; Ø Ramal: número do ramal (dígitos); Ø Local: informação de local a ser exibida no catálogo telefônico. Ø Páginas Amarelas: visibilidade do ramal no catálogo telefônico: público, somente rede interna da instituição ou não ser exibido; Ø Contatos do Ramal: caso um ramal tenha mais de um usuário; Ø Serviços - Correio de Voz: para habilitar a secretária eletrônica. É necessário definir uma senha de 6 números, para acesso a partir do dispositivo onde o ramal estiver registrado (Telefone IP ou Softfone); Ø Hora e Data Certa: serviço que fala a data e hora certa; Ø Teste de Eco: realiza teste de latência de áudio permitindo o usuário perceber a qualidade da chamada; Ø Sigame: permite de realizar um desvio contínuo para outro ramal ou número externo. O usuário poderá alterar essa função através do Portal do Usuário. O número a ser preenchido neste campo deve obedecer as regras de discagem. Caso o siga-me seja para um número externo, o usuário deve ter permissão para fazer este tipo de chamada.

6.7. Registro de Usuário em Sofphone para Teste Neste ponto, a PBX-IP já está com a configuração finalizada e possui um usuário/ramal cadastrado. Para testar as configurações da PBX-IP e o registro e realização de chamadas do usuário vamos fazer o registro do usuário SIP. Para isso, utilize qualquer softfone de sua preferência ou Telefone IP, com os seguintes dados para o registro: Ø Domínio: Realm da PBX-IP, conforme configurado no DNS da instituição e na configuração de sistema de máquina; Ø Porta SIP Local: 5080; Ø Username: usuário da CAFe/LDAP. Ex. nome.sobrenome; Ø Password: senha configurada no momento do cadastro do usuário no Portal; Ø Authentication Username: usuário da CAFe/LDAP. Ex. nome.sobrenome; Ø Caller ID: nome do usuário ou número do ramal. Você pode acompanhar o registro do ramal na interface de gerência de usuários SIP. Quando o usuário SIP estiver registrado na PBX-IP, o ícone do telefone, na coluna SO, da linha do usuário, ficará verde. Após o usuário registrar, já é possível realizar chamadas.


297

Capítulo 08

PBX IP Acadêmico

OBS: Para que a PBX-IP Acadêmica possa realizar e receber chamadas, é necessário que esteja cadastrada como um peer no SRL da instituição, e que tenha como rotas as faixas de ramais por ela atendidas. Também é necessário que esteja liberado o acesso da PBX-IP Acadêmica no firewall do SRL.

6.8. Painel de Controle - Console Você pode acompanhar o log das chamadas de um usuário através do menu "Console". Esta opção visa facilitar o debug e acompanhamento de logs quase em tempo real. É possível filtrar logs de ligações do OpenSIPS, de erros, Fail2Ban, entre outros. O log é atualizado no intervalo de tempo definido, sendo que é possível pausar a atualização para verificação.

Figura 270: Painel de Controle - Console

OBS: Você pode também acompanhar os logs das chamadas externas geradas/recebidas pela PBX-IP Acadêmica, através da tela de console do SRL da instituição. Assim, é possível identificar se está ocorrendo corretamente a comunicação entre a PBX-IP e o SRL para o encaminhamento de chamadas

6.9. Ligações


298

Capítulo 08

PBX IP Acadêmico

Através deste menu, também é possível acompanhar informações das ligações ativas em tempo real, observando de forma resumida origem, destino e duração da chamada até o momento. Para atualizar o registro das ligações, basta clicar no ícone

no canto inferior direito.

Figura 271: Status - Ligações.

6.10. Contabilização A PBX-IP gera um relatório interno de chamadas completadas e não completadas.

Figura 272:Contabilização.

6.10.1 Completadas Disponibiliza a listagem das chamadas completadas pelos ramais do ambiente, tanto chamadas realizadas, quanto recebidas, informando origem, destino, data e hora, duração e usuário associado. É possível aplicar filtros para consulta por data, origem, destino, prefixo do tronco e usuário associado. Há três botões de atalho rápido pra filtro por data, para pesquisar chamadas completadas nos sete dias anteriores, nos 30 dias anteriores, ou no mês atual. Um exemplo desta tela pode ser visualizado na Error!

Reference source not found..


299

Capítulo 08

PBX IP Acadêmico

Figura 273: Chamadas completadas.

6.10.2. Não Completadas Disponibiliza a listagem das chamadas não completadas pelos ramais do ambiente, tanto chamadas realizadas, quanto recebidas, informando origem, destino, data e hora, código SIP e usuário associado. As opções de filtragem são semelhantes as chamadas completadas, com acréscimo do código SIP. Os códigos SIP mais comuns são de erros associados a clientes e alguns do serviço ou servidor: Ø 401/403: Não permitido ou sem privilégio; Ø 404: Usuário/Ramal/Rota não encontrado; Ø 480: Temporariamente não disponível; Ø 486: Ocupado (provavelmente em ligação); Ø 487: Geralmente o usuário não atendeu a ligação).

Figura 274: Chamadas Não Completadas.


300

Capítulo 08

PBX IP Acadêmico


301

Capítulo 08

PBX IP Acadêmico

26.

INTEGRAÇÃO DE SISTEMAS - WEB SERVICE

O Web Service provê uma interface para comunicação da PBX-IP Acadêmica com outros sistemas da instituição. A instituição poderá optar por utilizar o auto-serviço da PBX-IP integrado a CAFe (Portal do Usuário) ou incorporar em sua plataforma de serviços a gerência das contas SIP. Para ambos os casos, o endereço de acesso é: https://IP_DO_SERVIDOR/webservice/webservice.php?wsdl. Os parâmetros de saída(retorno das chamadas dos métodos) são devolvidos na forma de string codificada em JSON que pode ser interpretada e utilizada para mostrar as informações solicitadas, possíveis erros ou mensagem de sucesso na chamada do método. Exemplos de mensagem de retorno:

string(61) "{"status":"success","msg":"Usuário criado com sucesso."}". string(86) "{"status":"error","msg":"Erro no banco de dados. A operação foi cancelada!"}”. INFORMAÇÃO: O acesso ao WS é restrito para o IP/rede configurado em: Sistema à Configurações Sistema à Gerência àWebService Os seguintes métodos estão disponíveis para utilização:

7.1 createRamal Recebe como parâmetros o UID do usuário na instituição, o tipo de afiliação, a senha e o e-mail. Os quatro campos são obrigatórios e através do UID consultam-se as outras informações na CAFe, como nome, número de documento, etc. Levando-se em consideração o tipo de afiliação (student, employee, staff) o primeiro ramal disponível para a respectiva classe é criado e associado ao usuário. É feito um hash com a senha e outras informações que depois são confrontadas durante o registro do usuário em um cliente SIP (softphone).

7.1.1 Parâmetros de Entrada Parâmetro Uid

Tipo String

Obrigatório Sim

affType

String

Sim

senha String mail String 7.1.2 Parâmetros de Saída Parâmetro status msg

Sim Sim

Observações Identificador único do usuário Ex. [email protected] “student”, “employee”, “staff” Senha de registro E-mail do usuário

Observações “success”, “error” Mensagem informativa do resultado


302

Capítulo 08

PBX IP Acadêmico

7.2 alterarSenha Recebe o UID do usuário e a nova senha, recalcula o hash e altera os dados no banco de dados.

7.2.1 Parâmetros de Entrada Parâmetro uid

Tipo String

Obrigatório Sim

senha

String

Sim

7.2.2 Parâmetros de Saída Parâmetro status msg 7.3 buscaInfoRamais

Observações Identificador único do usuário Ex. [email protected] Senha de registro


Recebe o UID do usuário e retorna os dados dele.


Tipo String

Obrigatório Sim

7.3.2 Parâmetros de Saída Parâmetro usuario status

Tipo String String

creditosatual

String

creditosvalorreposicao telefones

String Array de Strings

tempo_total_falado

String

tempo_total_falado_mes

String


Observações Identificador único do usuário Ex. [email protected] Observações nome de usuário (username) -1 = Inativo, 0 = Manutenção, 1 = Ativo “error” = em caso de erro Valor dos créditos atuais do usuário Valor da reposição mensal do créditos Array contendo os telefones associados ao usuário Tempo total de ligações do usuário no formato HH:MM:SS Tempo total de ligações no mês atual do usuário no formato HH:MM:SS 303

Capítulo 08

PBX IP Acadêmico

msg

String

Mensagem de erro (Só retorna no caso de status = “error”)

7.4 excluirUsuario Recebe o UID do usuário e o exclui do banco de dados, excluindo-se também os contatos cadastrados no portal do usuário. Se os ramais só estiverem associados a este usuário, são deletadas também as mensagens do correio de voz do ramal e o próprio correio de voz. Durante o processo de exclusão é armazenado em tabela do banco de dados a atual informação de créditos, que será utilizada em caso de nova criação desse usuário dentro do mesmo mês, evitando abusos por parte do usuário para tentativa de renovação dos créditos de forma indevida.


7.4.2 Parâmetros de Saída Parâmetro status msg

Tipo String

Obrigatório Sim

Observações Identificador único do usuário Ex. [email protected]


O WebService facilita a integração com outros sistemas desenvolvidos em qualquer linguagem. Exemplo de acesso em PHP utilizando a biblioteca SOAP do framework Zend: require_once(dirname(__FILE__) . '/Zend/Soap/Client.php'); $url= 'https://IP_DO_SERVIDOR/webservice/webservice.php?wsdl'; $client = new Zend_Soap_Client($url); try{ $retorno= json_decode($client->excluirUsuario('[email protected]'), true); if($retorno['status'] == "success"){ //Trecho de código em caso de sucesso } else if ($retorno['status'] == "error") { //Exemplo de impressão do erro ocorrido echo"ERRO: ".utf8_decode($retorno['msg']); } }catch (Exception$e) { echo"Ocorreu um erro no WebService: ".$e->getMessage(); }


304

Capítulo 08

PBX IP Acadêmico


305

Capítulo 09

Casos de uso



Capítulo 9 – Casos de uso Neste capítulo, são propostos casos de uso do fone@RNP que vêm sendo encontrado em diversas instituições clientes. Vários são casos reais. A dinâmica se baseia na apresentação do caso. O aluno deve sugerir a solução, descrevendo-a textualmente e através de um esquema de blocos. Idealmente, se houver tempo, deve-se finalizar o estudo no laboratório, com a instalação e configuração das soluções.

Lembrete sobre o uso do SRL nas instituições O único caso em que o SRL é dispensável é quando há apenas um GWT em uso pela instituição cliente. Qualquer outro caso, o uso do SRL é recomendável. Mesmo que pareça trivial a ligação de um dispositivo SIP diretamente ao fone@RNP, é recomendado a instalação de um (par de) SRL na instituição cliente. O SRL isola a rede interna, no domínio do cliente, do ‘core’ do serviço do fone@RNP. Fazendo uma analogia para redes IP, ligar um PABX diretamente ao SRC seria igual a querer conectar uma estação de trabalho diretamente em um roteador do backbone. Além disso, o SRL instalado na rede local da instituição diminui consideravelmente o tempo de resposta das mensagens de controle e, consequentemente, o tempo de conexão das chamadas. O SRL também faz manipulações no número discado, formatando de acordo com a recomendação E.164 para que as pesquisas por rotas sejam padronizadas ou ainda, adequando-o para integração com outros dispositivos do fone@RNP. As mensagens que os dispositivos SIP ligados ao SRL devem esperar como resposta quando uma chamada não pode ser realizada seguem listadas abaixo. ● 404 - Not Found: Sem Rota ● 408 - Request Timeout: O outro lado não responde. Pode estar indisponível. ● 503 - Serviço Indisponível: Enviado pelo GWT quando a E1 apresenta problemas ● 486 - Busy: O número discado está ocupado. ● 487 - Request Terminated: O usuário chamou determinado número e cancelou antes de atender ou chamou até cair.


306

Capítulo 09

Casos de uso

Caso 1 Cenário: A instituição possui um PABX digital, sem interfaces IP, com uma porta E1 para a operadora e diversos ramais internos. Ela pretende apenas integrar seu PABX ao fone@RNP, sem nenhuma pretensão de expandir de seu parque de telefonia.

Solução proposta: Nesse caso, o mais indicado é a instalação do GWT entre seu PABX e a operadora telefônica, ligado diretamente ao SRC.


307

Capítulo 09

Casos de uso

Caso 2 Cenário: A instituição possui um PABX digital, com interfaces SIP disponível, com uma porta E1 para a operadora e diversos ramais internos. Ela pretende apenas integrar seu PABX ao fone@RNP, sem pretensão de expandir de seu parque de telefonia.

Solução proposta: Nesse caso, há duas saídas: 1. Se a instituição não quer ou tem dificuldades em configurar seu PABX, a solução indicada é a mesma do caso 1, a instalação do GWT entre seu PABX e a operadora, ligado diretamente ao SRC. A solução 1 deve ser evitada pois gera custos desnecessários. Além disso, ocupa espaço no datacenter e consome mais energia que uma VM. 2. É possível integrar ao fone@RNP sem a aquisição de nenhum hardware adicional. Devese, então, a. instalar um par de SRLs (máquinas virtuais), b. configurar um tronco SIP em seu PABX IP e c. configurar lá a “transparência”, isto é, chamadas à distância para números fixos devem tentar ser entregues pelo tronco SIP (fone@RNP). i. Se a ligação não puder ser completada, a chamada deve ser transbordada pelo tronco padrão, com a operadora local. d. configurar a entrega de ligações locais, entrantes pelo fone@RNP, com destino à cidade da instituição.

Vamos ilustrar aqui a opção 2, já que a primeira é desaconselhável e idêntica ao primeiro caso.


308

Capítulo 09

Casos de uso

Caso 3 Cenário: A instituição do caso 3 tem um perfil de escritório. Foi crescendo com pouco (ou sem) planejamento do seu serviço de telefonia. Hoje, possui um PABX sem troncos digitais, mas com 25 troncos analógicos com a operadora local e 30 ramais. Está adequando sua rede IP para suportar a implementação do serviço de Telefonia sobre IP.

Solução Proposta: Tendo um perfil aproximado de escritório, com 30 ramais dificilmente a quantidade de ligações durante a HMM irá ocupar os 25 troncos simultaneamente. Assim, não deve haver grande impacto perder alguns troncos. Para confirmar isso, é preciso conseguir relatórios de uso desses recursos. Além disso, ao interligar com o fone@RNP, parte das ligações que utilizariam os troncos analógicos passarão a ser encaminhados pelos troncos SIP, pelo fone@RNP. Também, somos encorajados a indicar a adoção da tecnologia de voz sobre IP porque a instituição mostra interesse em modernizar seu serviço de telefonia e porque a ampliação do serviço baseado em VoIP é relativamente mais fácil e menos custosa do que a ampliação do serviço tradicional. Assim, a sugestão é a substituição do PABX atual pelo GWT Analógico, implementado pelo equipamento CIP850. Apesar dos troncos analógicos serem limitados a 8 canais simultâneos, as ligações à distância para fixos serão encaminhados pelo fone@RNP (gerando economia) e a quantidade de ramais poderá aumentar. Futuramente, se houver a necessidade de aumentar a quantidade de troncos, é possível expandir a solução com relativa facilidade, adicionando módulos do fone@RNP. Para a integração do GWT analógico ao fone@RNP é necessária a instalação do SRL para manipulação dos números e controle das rotas dentro deste domínio.


309

Capítulo 09

Casos de uso

Caso 4 Cenário: A instituição possui um PABX com uma interface digital com a operadora telefônica. Ela precisa expandir sua oferta de ramais, mas tem dificuldades em adquirir novas placas (ou não há mais espaço no aparelho). A rede IP é saudável e há condições de implantação de telefonia IP.

Solução Proposta: Para a integração da rede de telefonia tradicional com a rede IP será necessário um GWT. Para ampliar a oferta de ramais, a sugestão é utilizar o PBX IP do fone@RNP. Sempre que há mais de um dispositivo SIP na instituição, para que eles funcionem juntos será necessária a instalação também do SRL, que controlará as rotas dentro desse domínio.


310

Capítulo 09

Casos de uso

Caso 5 Cenário: A instituição ainda não possui solução de voz. Quer aproveitar 100% do fone@RNP. Mas precisa ter uma interface digital local. A instituição considera acrescentar troncos GSM, para celular. Também considera a contratação de provedor de telefonia IP (ITSP).

Solução Proposta: Como no caso anterior, há mais de um dispositivo SIP a ser controlado neste domínio. Logo, será necessário a instalação de um par de SRLs. Abaixo dele, o PBX IP do fone@RNP porque a instituição manifestou o interesse de utilizar 100% da solução do fone@RNP. Para a interface com a rede digital de telefonia é necessário um GWT, configurado como um peer no SRL. O tronco com o ITSP será configurado como um peer no SRL. O gateway para telefonia celular pode ser de dois tipos diferentes: 1) E1 ⇔ GSM: Ficaria instalado no GWT. 2) SIP ⇔ GSM: Instalado como um peer do SRL, como ilustrado abaixo.


311

Capítulo 09

Casos de uso

Caso 6 Cenário: A instituição é composta por vários sites e já possui um serviço de telefonia IP que interliga seus campi. Toda a lógica de encaminhamento de chamadas é controlada pela rede VoIP pré-existente.

Solução Proposta: Nesse caso, todos os sites interligados pelo serviço de Telefonia IP da instituição se beneficiará quando apenas um ponto se integrar o fone@RNP. Basta instalar um par de SRLs para interligar as duas redes. Assim como no caso 2, o cliente deverá configurar seu serviço para encaminhar chamadas à distância para números fixos pelo tronco do fone@RNP e, se a ligação não for completada, deverá transbordar para sua estratégia padrão de terminação de chamadas. Deverá também aceitar chamadas vindas do fone@RNP para serem entregues na RTFC nas cidades de seus sites.


312

Capítulo 09

Casos de uso

Caso 7 Cenário: A instituição é composta por 3 sites. Cada campus é independente (administrativamente) do outro. Cada um possui um PABX digital com uma interface E1 com a operadora. Não há intenção de expandir o serviço de telefonia a curto prazo para nenhum dos campi.

Solução Proposta: Novamente há mais de um dispositivo SIP no domínio do cliente. Então, há a necessidade de instalar um par de SRLs. Abaixo dele, configurado como peers, devem estar os GWTs, ligados entre o PABX e a RTFC de cada site.


313

Capítulo 09

Casos de uso

Caso 8 Cenário: A instituição, uma universidade, é composta por vários sites. Cada campus tem sua administração independente dos outros e os ambientes são extremamente heterogêneos. Suponha que os campi são equivalentes aos casos 4 (Reitoria), 5 (Site1), 2 (Site2) e 6 (sites {3+4+5+N}). A instituição já possui uma rede IP que interliga seus sites, com condições de implantar o serviço de telefonia IP. Além disso, a universidade também tem interesse em brindar seus alunos com o serviço de telefonia IP, concedendo-lhes ramais IP (não o aparelho, mas números locais) para se comunicarem entre si e com outros alunos e pesquisadores de outras universidades.

Solução Proposta: Como há vários dispositivos SIP a ser controlados, há a necessidade de instalação de um par de SRLs para o domínio da instituição cliente. Para brindar seus alunos com ramais IP, basta instalar o PBX IP Acadêmico, ligado diretamente ao SRL principal do cliente. No primeiro site, equivalente ao caso 4, basta seguir a solução do caso 4: um par de SRLs para este (sub)domínio, um par de PBX IP e um GWT. No próximo site, equivalente ao caso 5, basta seguir a solução do caso 5: um par de SRLs para controlar este (sub)domínio, ou seja, a saída pelo ITSP um (par de) PBX IP, um GWT e um GW GSM. No terceiro site, equivalente ao caso 2, basta aplicar a solução do caso 2: ligar o PABX de 3o no SRL do domínio.*


314

Capítulo 09

Casos de uso

No último site, equivalente ao caso 6, basta aplicar a solução do caso 6: ligar o serviço ToIP da instituição ao SRL do domínio.*

*NOTA: os sites 1 e {3+4+5+N} podem (ou não) precisar de um SRL local (nestes subdomínios), dependendo das características do modelo de negócio do cliente e, eventualmente, do plano de numeração envolvido no cenário.


315

Capítulo 09

Casos de uso


316

Capítulo 10

Estatísticas



Capítulo 10 – Estatísticas

Sobre estatísticas De acordo com o dicionário online Michaelis,

estatística substantivo feminino 1 Ciência que tem por objetivo a coleção, análise e interpretação de dados numéricos a respeito de fenômenos coletivos ou de massa, bem como a indução das leis a que tais fenômenos cabalmente obedecem e, ainda, a representação numérica e comparativa, em tabelas ou gráficos, dos resultados da análise desses fenômenos. 2 Os fatos numéricos pertencentes a um fenômeno coletivo ou de massa.

O fone@RNP possui uma frente de trabalho que se preocupa exatamente com as estatísticas de uso do serviço. Os dados das chamadas realizadas dentro do serviço são coletados e organizados de forma a permitir a análise e interpretação por nós: gerentes, engenheiros, técnicos e analistas responsáveis pelo serviço. Seja do ponto de vista da RNP, o prestador do serviço, ou do ponto de vista das instituições, clientes do serviço, o fone@RNP apresenta relatórios estatísticos ricos e úteis para tomada de decisão. Os relatórios do fone@RNP estão disponíveis online, com 2 tipos de acesso: 1. no portal estatisticasfone.rnp.br, com acesso livre para qualquer pessoa; 2. nos dispositivos do fone, com acesso restrito aos administradores e operadores dos clientes. O primeiro é mais útil para mostrar séries históricas e perfis de uso do sistema. O segundo pode ter um caráter mais voltado para descoberta de problemas, com pesquisas mais pontuais. Mas ambos são muito importantes para tomada de decisão de técnicos e gestores.


317

Capítulo 10

Estatísticas

Relatórios do Sistema de Estatísticas O Sistema de Estatísticas foi elaborado ainda na versão anterior do fone@RNP, a distribuição 2008. Ele foi adequado para exibir também as estatísticas dos dados recolhidos dos dispositivos da distribuição 2012. Seu funcionamento é baseado nas ações de coleta dos Registros de Detalhes das Chamadas (CDRs, na sigla em inglês), processamento dos CDRs, consolidação dos CDRs e apresentação da informação em diversos relatórios diferentes. Cada relatório possui um ponto de vista diferente, resultando em diferentes informações.

Ao acessar o sistema de estatísticas, o usuário irá encontrar uma tela de apresentação com um dashboard contendo um mapa e uma tabela com informações resumidas à esquerda e 4 relatórios.

Uso do Mapa O mapa à esquerda funciona como um filtro rápido, auxiliando a selecionar informações das regiões e estados do Brasil. Conforme se clica no mapa, as estatísticas vão se atualizando.


318

Capítulo 10

Estatísticas

Para voltar a apresentar informações nacionais ou regionais, ou seja, de todas as instituições de uma região ou de todas as regiões do Brasil, basta clicar no botão “REGIONAL” ou “NACIONAL”, que aparecem acima do mapa quando uma região ou estado é selecionado. A tabela exibe as quantidades de CHAMADAS, INSTITUIÇÕES e MINUTOS com base nos filtros aplicados naquele instante.

Para melhorar a visualização dos relatórios, o mapa pode ser omitido clicando na pequena seta, localizada à meia altura na divisória entre a coluna no mapa e os 4 relatórios.

Para voltar a apresentar o mapa, clique na mesma seta, que se reposicionará à extrema esquerda do quadro. Obs.: O único gráfico que não reflete as escolhas do mapa é a MATRIZ DE TRÁFEGO.


319

Capítulo 10

Estatísticas

Uso dos relatórios Os relatórios apresentados no dashboard possuem botões de controle e áreas para informações, independente do tipo de gráfico que está sendo exibido. Repare as marcações na figura abaixo.

As marcações à esquerda são de áreas de informação. Acima, exibe o título do gráfico/relatório, e a marcação de baixo é a legenda. Quando o mouse é colocado sobre esta área a legenda para este relatório é exibida. As marcações à direita são botões de ação e controle deste relatório. Acima, os já assimilados botões de minimizar, expandir e fechar. E abaixo, um botão para exportar o relatório, para comparar com outros relatórios e um botão de detalhes, que tem a mesma função do botão expandir, do conjunto superior de botões. Na área mais interna de cada janela de relatório, além da informação propriamente dita, há também alguns outros botões para controle do que e como deve ser plotado no gráfico. Repare na figura abaixo.


320

Capítulo 10

Estatísticas

A área destacada acima, mostra as possibilidades de se exibir a informação. Se o gráfico deve ser em linhas ou em barras. A área destacada abaixo mostras opções de informações a serem plotadas no gráfico. Neste caso, é possível escolher entre número de chamadas, tempo total das chamadas ou tempo médio das chamadas. Também é possível escolher se o que está sendo plotado são chamadas feitas ou chamadas recebidas.

Exibição de outros relatórios O dashboard só mostra 4 relatórios simultaneamente. Só há espaço para esses 4. Para exibir outros relatórios, primeiro é necessário fechar um ou mais relatórios em exibição. Novos relatórios estão disponíveis na “combo box” localizada na parte superior do portal de estatísticas. O botão “Instituição usuária” pode ser utilizado em conjunto com o “Relatório estatístico”. Ao selecionar uma instituição e um relatório, quando o o botão “Adicionar relatórios” é acionado, o relatório já aparece com o filtro marcado para a instituição escolhida. Obs.: É possível até 8 gráficos abertos, 4 em estado normal e 4 minimizados;


321

Capítulo 10

Estatísticas

Relatório em Detalhes Para apresentar um relatório em detalhes, clique no botão maximizar ou no botão detalhes. Abaixo, note dois relatórios exibidos no modo de detalhes. O primeiro é do tipo série histórica, apresentado em barras, e o segundo é um Ranking, apresentado em forma de “pizza”.


322

Capítulo 10

Estatísticas

Note que no modo maximizado aparecem mais opções e informações: 1. diversos filtros na parte superior da janela do gráfico; 2. uma tabela com informações utilizadas para gerar o gráfico; 3. a escolha do tipo de informação a ser plotada e; 4. um resumo totalizando os dados considerados no filtro aplicado.

Comparação de relatórios Agora que já sabemos retirar e adicionar relatórios no dashboard, é possível comparar relatórios. A função de comparação de relatórios foi pensada para ser utilizada com 2 relatórios por vez. Eles podem ser de mesmo título ou de títulos diferentes e podem assumir qualquer filtro que o usuário deseje configurar. Para comparar 2 relatórios, feche todos os relatórios. Depois escolha os dois gráficos que você deseja comparar. Depois clique no botão “Comparar” do primeiro relatório e, depois, no segundo. Abaixo, a figura exemplifica a comparação das “Chamadas Realizadas e Recebidas”, durante o ano de 2012 pelos clientes RNP-Campinas e CEFET-MG.


323

Capítulo 10

Estatísticas

Note que o modo de comparação exibe os 2 gráficos maximizados, com detalhes. Depois de maximizados, é possível navegar livremente entre os filtros e escolher o tipo de informação a ser plotada para realizar a comparação desejada. Para sair do modo de comparação é necessário clicar no botão “Restaurar”, o botão do meio, nos 3 botões superiores à direita de uma das janelas.


324

Capítulo 10

Estatísticas

Descrição dos filtros Os relatórios podem ser filtrados por PERÍODO e LOCALIDADE: PERÍODO Ano - Pode ser escolhido um único ano ou um range de anos, deslizando os pontos:

Obs.: Os anos que aparecem para os filtros são derivados das coletas. No caso acima existem no banco de dados, coletas de 2009 até 2011. Mês - Pode ser feita a combinação de mês e ano:

Dia - Pode ser feita para um único dia (inicial igual à final) ou um range de datas:

Hora - Pode ser escolhido um período do dia para a exibição do relatório (25/08/2011 de 8h até 18h):

LOCALIDADE Obs. Todos os filtros de localidade estão interligados, assim quando selecionamos uma região ela filtra as UFs, uma UF filtra os DDDs e quando selecionamos um DDD ele filtra as instituições. Todo o filtro tem a opção “Todos”, assim não é preciso limpar todo o filtro para modificação de apenas um item. Região: Norte, Nordeste, Centro-Oeste, Sudeste e Sul UF: Todas as UFs do Brasil, porém se a região Sudeste for selecionada, por exemplo, serão exibidos só os estados desta região, Espírito Santo, Minas Gerais, Rio de Janeiro e São Paulo. DDD: Todos os DDDs do Brasil, porém se o estado do Rio de Janeiro for selecionado, por exemplo, serão exibidos os DDDs deste estado, 21, 22 e 24. Instituição: Todas as instituições participantes do Fone@RNP. Este filtro segue o mesmo padrão dos anteriores.


325

Capítulo 10

Estatísticas

Descrição dos relatórios CHAMADAS COMPLETADAS – REALIZADAS E RECEBIDAS Descrição do gráfico O gráfico CHAMADAS COMPLETADAS mostra quantidade de chamadas que foram feitas entre todas as instituições onde houve atendimento. Também há a opção de exibir a duração das chamadas em minutos. Estão excluídas deste gráfico, por exemplo, as chamadas em que o número chamado estava ocupado, não atendeu ou ainda com destino inexistente. Filtros auxiliares: Totais – Quantidades das chamadas realizadas e das chamadas recebidas Durações – Minutos das chamadas realizadas e das chamadas recebidas Modos de exibição: Barras ou linhas

COMPARAÇÃO DE TIPOS POR DIREÇÃO Descrição do gráfico O gráfico COMPARAÇÃO DE TIPO POR DIREÇÃO mostra a quantidade de ligações feitas de acordo com seu destino ou origem. Também há a opção de exibir a duração das chamadas em minutos. A seleção de origem ou destino é feita na caixa de opções abaixo da legenda. Quando selecionado “Recebidas”, os tipos de chamadas se referem aos destinos. Quando selecionado “Realizadas”, os tipos de chamadas se referem às origens. Os destinos ou origens estão qualificados como: •

RTFC, quando as chamadas são destinadas (RECEBIDAS) ou originadas (REALIZADAS) em telefones na Rede de Telefonia Fixa Comutada, ou seja, telefones na rede pública, fora dos institutos e universidades;

•

PABX, quando as chamadas são destinadas (RECEBIDAS) ou originadas (REALIZADAS) em telefones convencionais dentro das instituições clientes e;

•

VoIP, quando as chamadas são destinadas (RECEBIDAS) ou originadas (REALIZADAS) em telefones IP, sejam eles softphones ou deskphones.

Filtros auxiliares: Totais – Quantidades das chamadas realizadas ou das chamadas recebidas Durações – Minutos das chamadas realizadas ou das chamadas recebidas Modos de exibição: Linhas ou barras


326

Capítulo 10

Estatísticas

CHAMADAS COMPLETADAS POR DIFERENTES TIPOS DE ORIGEM E DESTINO Descrição do gráfico O gráfico CHAMADAS COMPLETADAS POR DIFERENTES TIPOS DE ORIGEM E DESTINO compara as chamadas feitas pelo sistema fone@RNP de acordo com os tipos de origem e destino A qualificação dos tipos de origem e destino é semelhante ao gráfico anterior. •

RTFC, quando as ligações são originadas ou destinadas em telefones da rede pública, ou seja, fora das instituições clientes;

•

PABX, quando as ligações são originadas ou destinadas em telefones convencionais dentro das instituições clientes, e;

•

PABX, quando as ligações são originadas ou destinadas em telefones IP, sejam deskphones ou softphones.

A tabela associada ao gráfico mostra também os valores absolutos da quantidade de chamadas e tempo de duração de cada par origem x destino, separados por tipo. Filtros auxiliares: Totais – Percentuais das chamadas completadas de acordo com o cruzamento dos tipos (origem x destino) possíveis Durações – Percentuais dos minutos das chamadas completadas de acordo com o cruzamento dos tipos (origem x destino) possíveis Modo de exibição: Pizza

RANKING DE USO PARA CHAMADAS COMPLETADAS POR LOCAL Descrição do gráfico O gráfico RANKING DE USO PARA CHAMADAS COMPLETADAS POR LOCAL mostra um comparativo das chamadas realizadas ou recebidas de acordo com a opção selecionada em TIPO DO GRÁFICO. É possível ordenar as ligações pela quantidade de chamadas originadas ou quantidade de chamadas recebidas. Também é possível ordenar de acordo com a quantidade de minutos realizados ou recebidos. A tabela associada ao gráfico mostra também os valores absolutos dos gráficos selecionados. Filtros auxiliares: Fez mais ligações – Percentuais das chamadas completadas Recebeu mais ligações – Percentuais das chamadas completadas Tempo de ligações realizadas – Percentuais dos minutos das chamadas completadas Tempo de ligações recebidas – Percentuais dos minutos das chamadas completadas Modo de exibição: Pizza


327

Capítulo 10

Estatísticas

OCUPAÇÃO DE CANAIS Descrição do gráfico O gráfico OCUPAÇÃO DE CANAIS mostra exatamente o que título propõe. Em sua apresentação padrão, mostra as 24 horas do dia anterior, para todas as instituições. Quando visualizado sem filtro de instituições mostra a quantidade de chamadas simultâneas que o sistema foi capaz de trafegar. Quando filtrado para uma instituição, mostra a quantidade de troncos necessários para atender à demanda de chamadas à distância para números locais desse cliente. Em sua apresentação padrão, mostra as 24 horas do dia anterior, para todas as instituições. Não faz sentido exibir esse gráfico para intervalos além de um dia. Por isso, o filtro de tempo foi limitado para este relatório. Modo de exibição: Linhas ou Barras

RANKING DE ECONOMIA Descrição do gráfico O gráfico RANKING DE ECONOMIA mostra um comparativo das regiões ou instituições que mais economizaram com a utilização do fone@RNP, de acordo com a opção selecionada em TIPO DO GRÁFICO. Antes de visualizar a informação deste relatório é necessário que o usuário estime valores para o custo do minuto de uma chamada à distância e o custo do minuto de uma chamada local. É possível ordenar as ligações pela economia alcançada. Filtros auxiliares: Quem economizou mais no total de ligações – Total de ligações para outros clientes e cidades Quem economizou por ligações não pagas– Ligações para outros clientes do fone Quem economizou mais por ligações pagas – Ligações para cidades onde há clientes do fone@RNP Modo de exibição: Pizza RANKING DE LIGAÇÕES PÚBLICAS Descrição do gráfico O gráfico RANKING DE LIGAÇÕES PÚBLICAS mostra um comparativo das regiões geográficas ou instituições, das chamadas realizadas ou recebidas para RTFC, de acordo com a opção selecionada em TIPO DO GRÁFICO. É possível ordenar as ligações pela quantidade de chamadas originadas ou quantidade de chamadas recebidas. Também é possível ordenar de acordo com a quantidade de minutos realizados ou recebidos. A tabela associada ao gráfico mostra também os valores absolutos dos gráficos selecionados. Filtros auxiliares: Fez mais ligações – Percentuais das chamadas completadas Recebeu mais ligações – Percentuais das chamadas completadas Tempo de ligações realizadas – Percentuais dos minutos das chamadas completadas Tempo de ligações recebidas – Percentuais dos minutos das chamadas completadas Modo de exibição: Pizza


328

Capítulo 10

Estatísticas

MOTIVOS DE NÃO COMPLETAMENTO Descrição do gráfico O gráfico MOTIVOS DE NÃO COMPLETAMENTO mostra um comparativo das mensagens de retorno mais comuns quando as ligações não são completadas. A tabela associada mostra também os valores absolutos e é ordenada pela quantidade de ocorrência. As informações deste gráfico não significam necessariamente um problema com o sistema fone@RNP. Ocorrências como “chamou até cair”, “usuário estava ocupado” e “discagem para número inexistente” estão incluídas aqui. Modo de exibição: Pizza

ESTIMATIVA DE ECONOMIA Descrição do gráfico O gráfico ESTIMATIVA DE ECONOMIA oferece informações para que seja possível estimar a economia feita com as ligações executadas através do fone@RNP. Apresenta valores de quantidade de ligações e de duração total das chamadas. No gráfico são apresentadas duas barras: •

Quantidade de chamadas à distância não pagas são as chamadas realizadas para telefones IP ou para ramais convencionais dentro das instituições clientes. Assim, não foi gerado nenhum custo adicional para nenhuma instituição.

•

Quantidade de chamadas à distância pagas são aquelas terminadas na rede de telefonia pública. Neste caso, alguma instituição no estado destino arcou com o custo desta ligação local.

Filtros auxiliares: Totais – Quantidades das chamadas realizadas Durações – Minutos das chamadas realizadas

Modos de exibição: Barras e Linhas


329

Capítulo 10

Estatísticas

MATRIZ DE TRÁFEGO Descrição do gráfico O gráfico MATRIZ DE TRÁFEGO é oferece uma visão geral das ligações feitas pelo sistema fone@RNP. As células da matriz mostram a quantidade de chamadas e o total de duração das chamadas. A matriz apresenta todos os possíveis fluxos, indicando origem e destino das ligações, agrupado de acordo com o filtro selecionado. Filtros auxiliares: Tráfego – A opção “tráfego” mostra as ligações que foram atendidas. Não tráfego – A opção “não-tráfego” mostra a quantidade de ligações que não foram atendidas, independente do motivo. Filtros: Este relatório tem um sistema de filtros particular. A construção da matriz depende da combinação de Regiões, UFs, DDDs, Instituições (origem e destino) e a escolha do Tipo de Filtro. Exemplos: Criação de uma matriz com os estados da Região Sudeste: 1. Selecione a Região Sudeste na combobox Região; 2. Em Tipo de Filtro, selecione UF; 3. Clique em FILTRAR RELATÓRIO. Criação de uma matriz com alguns estados da Região Nordeste: 1. Selecione a Região Nordeste na combobox Região; 2. Com o botão shift do teclado sendo pressionado, selecione Alagoas, Bahia, Ceará e Maranhão, por exemplo; 3. Em Tipo de Filtro, selecione UF; 4. Clique em FILTRAR RELATÓRIO. Criação de uma matriz com todas as instituições do Rio de Janeiro com DDD 21: 1. 2. 3. 4. 5.

Selecione a Região Sudeste na combobox Região; Selecione Rio de Janeiro na combobox UF; Selecione 21 na combobox DDD; Em Tipo de Filtro, selecione Instituição; Clique em FILTRAR RELATÓRIO.


330

Capítulo 10

Estatísticas

Relatórios dos módulos do fone@RNP Os relatórios embutidos nos módulos do fone@RNP (GWT, SRL e PBX IP) são mais indicados para identificação e auxílio na resolução de problemas locais. Embora, nada impeça que possa ser utilizado para gerar séries históricas de sua instituição ou do domínio que atendem.

Relatórios do GWT Ao acessar a interface gráfica de configuração do GWT, na coluna à esquerda, o módulo de contabilização aparece na segunda posição. O GWT conta com 4 relatórios estatísticos que serão descritos nesse momento.

Estatísticas Esse é um relatório online e interativo. A direita exibe um gráfico com a quantidade de chamadas nos últimos 13 meses. É possível plotar 4 tipos de chamadas: • Completadas VoIP que seguiram pelo fone@RNP • Completadas PSTN que seguiram pela RTFC • Não completadas VoIP que não foram completadas e deveriam seguir pelo fone • Não completadas PSTN que não foram completadas e deveriam seguir pela RTFC Ao clicar na linha ou na legenda de cada tipo de informação é possível habilitar do desabilitar a informação correspondente no gráfico. Abaixo desse gráfico vê-se a estimativa de economia, baseada em informação fornecida quando da configuração do GWT.


331

Capítulo 10

Estatísticas

A esquerda é exibida a informação do número de chamadas completadas ou não desde o início de operação do GWT. Esses números são utilizados para a formação do gráfico à direita. Esta informação também é interativa. Ao se clicar em completadas, por exemplo, os números se desdobram em VoIP ou PSTN, indicando se as ligações foram encaminhadas pelo fone@RNP ou pela RTFC, respectivamente. Novamente, ao se clicar em VoIP, por exemplo, a informação se desdobra nos anos em que o GWT esteve em operação. Por último, ao se clicar em um ano, a informação se desdobra nos meses daquele ano.

Completadas O relatório “Completadas” exibe o detalhamento das chamadas completadas com sucesso. Basicamente, é o CDR.

Na parte superior há uma série de campos onde é possível criar filtros para conseguir a informação desejada com maior precisão.


332

Capítulo 10

Estatísticas

Na parte de baixo do quadro de filtros há botões com filtros de tempo pré-definidos. Logo abaixo é exibida a tabela com os detalhes das chamadas. É possível ordenar a tabela de acordo com a coluna desejada clicando no cabeçalho da referida coluna. As colunas de informação são: Data A data e hora do início da tentativa de chamar o destino Origem O número de origem, exatamente como repassado pelo GWT Destino O número de destino, exatamente como repassado pelo GWT Duração Tempo desde o início da tentativa de estabelecer a chamada Tempo de Bilhetagem Duração a partir do atendimento Entrada Informa se a chamada entrou pelo PABX, RTFC ou fone@RNP Categoria FORA DE USO Terminação Informa se a chamada saiu para o PABX, RTFC ou fone@RNP Não Completadas O relatório “Não Completadas” exibe o detalhamento das chamadas que não foram completadas com sucesso. De forma geral, é um dos primeiros lugares a se visitar quando há suspeita de problemas com as entregas das chamadas. As informações são muito semelhantes ao relatório anterior, incluindo a área de filtros. A única mudança é que as colunas “Duração” e “Tempo de Bilhetagem” são substituídas pela coluna “Motivo”, que informa o motivo pelo qual a chamada não foi completada.

Mais Chamados O relatório “Mais Chamados” exibe os números que mais foram chamados por esse GWT, a partir do PABX.


333

Capítulo 10

Estatísticas

Na parte superior há dois campos onde é possível criar filtros para conseguir a informação desejada com maior precisão. É possível escolher a terminação, ou seja, se a ligação foi encaminhada pelo fone@RNP ou pela RTFC. Também é possível filtrar o número destino. Ainda existem dois filtros pré-definidos. O primeiro botão exibe as chamadas que foram encaminhadas pela RTFC que não possuem rota pelo fone@RNP (um comportamento esperado). O segundo botão exibe chamadas que foram encaminhadas pela RTFC, mas que possuem rotas pelo fone@RNP. Essas, podem ser indício de algum problema. Logo abaixo é exibida a tabela com os detalhes das chamadas. É possível ordenar a tabela de acordo com a coluna desejada clicando no cabeçalho da referida coluna. As colunas de informação são: Número destino Número mais discado Última atualização Última vez que o número foi discado Sucesso VoIP Quantidade de vezes que foi encaminhado pelo fone@RNP Sucesso PSTN Quantidade de vezes que foi encaminhado pela RTFC Próxima ligação Porta pela qual a próxima ligação deve ser encaminhada Detalhe Apenas apresenta o ícone de detalhe

Ao clicar sobre o número mais chamado, na primeira coluna, é apresentada uma nova janela de informações com os detalhes das chamadas para o número em questão.


334

Capítulo 10

Estatísticas

Ao clicar sobre o ícone da lupa, na última coluna, é apresentada uma nova janela de informações com os detalhes das informações tabeladas para o número em questão.


335

Capítulo 10

Estatísticas

Relatórios do SRL O SRL, assim como o SRC, possui 3 tipos de relatórios estatísticos. Todos baseados nos Registros das Chamadas (CDRs) que passam por eles. Eles mostram, basicamente, 1. o próprio detalhamento das chamadas, 2. a matriz de tráfego, com quantidade de chamadas e minutos e, 3. gráficos da matriz de tráfego, com a quantidade de chamadas.

Esta, acima, é a tela da aba de contabilidade do SRC. São apresentados todos os peers cadastrados para escolha da origem e para escolha do destino, um ao lado do outro. Abaixo e à esquerda há um quadro para configuração do filtro de intervalo de tempo. E abaixo e à direita se encontram os 3 botões para os 3 tipos de relatórios diferentes. Os passos para geração de um relatório são bem simples.


336

Capítulo 10

Estatísticas

Na aba “contabilização”, 1. Escolha os peers de origem 2. Escolha os peers de destino 3. Escolha o intervalo de tempo a ser analisado 4. Escolha o tipo de relatório desejado

Acima está um exemplo de relatório do botão “Gerar Tabela” A tabela é o próprio Detalhamento da Chamada, o CDR. As colunas de informação são: Data e hora da chamada Origem Tipo Origem Número Origem Destino Tipo Destino Número Destino Duração

Marca o início da chamada Informa o peer que originou a chamada Informa tipo de telefone que originou a chamada Informa o número “chamador” Informa o peer para onde a chamada foi encaminhada Informa o tipo de telefone onde a chamada foi terminada Informa o número chamado, no formato E.164 Informa a duração da chamada


337

Capítulo 10

Estatísticas

A janela ainda apresenta alguns comandos auxiliares. No canto superior direito encontram-se dois botões: Completadas e Não completadas. Por padrão, o botão “Completadas” está selecionado. Ele exibe as ligações que ocorreram normalmente. Se o usuário escolher o botão “Não Completadas” serão exibidas as tentativas de conexão que não foram bem sucedidas. Observação: As ligações não completadas não significam necessariamente um problema no fone@RNP. Ali podem estar listadas, por exemplo, chamadas feitas para destinos que estavam ocupados na hora da ligação. No canto inferior direito estão botões de navegação nos registros. Sua utilização é bem intuitiva. No canto inferior esquerdo estão botões com opções para exportação dos dados exibidos na tela. É possível exportar os dados para o “clipboard” (memória), para o formato excel (separado por vírgulas), para o formato PDF e para impressora.

Acima está um exemplo de relatório do botão “Gerar Matriz”.


338

Capítulo 10

Estatísticas

O relatório é a própria matriz de tráfego entre os peers selecionados. Não há necessidade de escolher os mesmos peers de origem e destino. Ou seja, a matriz não precisa ser quadrada. Os peers mostrados no início de cada linha são as origens e os peers mostrados no início de cada coluna são os destinos. A informação dentro de cada célula é o número de chamadas e o volume em minutos entre origem e destino. Por exemplo, a matriz mostra que a UFSC fez 249 chamadas, totalizando mais de 15 horas de conversação, para São Paulo, pelo peer PoP-SP. Por outro lado, o PoP-SP não realizou chamadas para nenhum dos peers exibidos. Observação: Neste contexto, o PoP-SP é um peer mantido pela RNP. Sua função é apenas entregar chamadas na cidade de São Paulo para as instituições clientes.

Acima está um exemplo do relatório obtido ao escolher o botão “Gerar Gráfico”. Este relatório exibe em forma de gráfico a informação de quantidade de ligações que ocorreram com sucesso e também as tentativas que não foram completadas.


339

Capítulo 10

Estatísticas

Os gráficos são obtidos com dados da matriz de tráfego equivalente às instituições escolhidas. As abas correspondem aos peers de origem. Todas as abas (origens) exibem um gráfico para cada destino. Por exemplo, de acordo com o gráfico acima, houveram tentativas sem sucesso de ligações da RNP-DF para RNP-RJ em alguns dias. Em outros, houveram quantidades semelhantes de ligações com sucesso. Então, é possível inferir que houve algum problema entre os peers RNP-DF e RNPRJ no início e no meio de fevereiro.


340

Capítulo 10

Estatísticas

Relatórios do PBX IP As estatísticas do PBX IP são bem simples. Podemos encontrar informações estatísticas em 2 lugares. Na primeira página, “Visão Geral” (1º quadro, Status, na coluna da esquerda), há um pequeno resumo da quantidade e da situação dos ramais cadastrados e das ligações.

O outro local onde é possível encontrar informações estatísticas no PBX IP se está no último quadro da coluna esquerda, chamado “Contabilização”. Há dois relatórios nesse módulo: Completadas e Não completadas.


341

Capítulo 10

Estatísticas

Completadas O relatório “Completadas” mostra, basicamente, o CDR das ligações que foram originadas e recebidas pelos ramais do PBX. Na parte superior há uma série de campos onde é possível criar filtros para conseguir a informação desejada com maior precisão. Na parte de baixo do quadro de filtros há botões com filtros de tempo pré-definidos. Logo abaixo é exibida a tabela com os detalhes das chamadas. É possível ordenar a tabela de acordo com a coluna desejada clicando no cabeçalho da referida coluna. As colunas de informação são: Data A data e hora do início da tentativa de chamar o destino Origem O número de origem, no formato E.164 ou como recebido pelo PBX Destino O número de destino, no formato E.164 ou como recebido pelo PBX Duração Intervalo de tempo em que a chamado ocupou recursos no PBX Usuário O nome do usuário no PBX ou o número recebido pelo PBX


342

Capítulo 10

Estatísticas

Não Completadas O relatório “Não Completadas” exibe o detalhamento das chamadas que não foram completadas com sucesso. De forma geral, é um dos primeiros lugares a se visitar quando há suspeita de problemas com as entregas das chamadas. As informações são muito semelhantes ao relatório anterior, incluindo a área de filtros. A única mudança é que a coluna “Duração” é substituída pela coluna “Código”, que informa o código da mensagem SIP com que a chamada foi desligada, indicando o motivo pelo qual a chamada não foi completada.


343

Capítulo 10

Estatísticas


344

ANEXO - Planejamento para instalação do fone@RNP em uma empresa fictícia XPTO Mudança Renovação do serviço de telefonia da XPTO e integração de seus 3 escritórios.

Resumo da mudança O serviço de telefonia atual que utiliza equipamentos tradicionais e é independente em cada escritório será substituído pela solução de telefonia IP desenvolvida para o serviço fone@RNP, distribuição 2012. Também será substituído o serviço fone@RNP na sua versão antiga. Além da substituição de equipamentos (PABX e telefones), também serão incluídas algumas funções extras no serviço de telefonia. ● Chamadas a 4 dígitos entre os escritórios ● Criação de caixas de mensagens para todos os ramais ○ Encaminhamento de recados para email, com arquivo de áudio anexado. ● Para os viajantes, mesmo número na mesa ou no softphone ○ Registro em mais de um telefone IP ao mesmo tempo ○ Softphone herdará todas as características do telefone de mesa ○ Possibilidade de atender ou realizar chamadas na mesa ou no softphone ● Capacidade de FAX para cada ramal

O que será instalado? Instalação do fone@RNP v.2012, com substituição do fone 2008 e do sistema tradicional de telefonia nos 3 escritórios.

Ações previstas A mudança está prevista para ocorrer em 2 fases: Fase1 - Piloto Fase2 - Migração completa A fase1 - Piloto contará com a participação de toda a equipe da Serviços, Colaboradores indicados pela TI, colaboradores indicados de P&D, mais alguns colaboradores-chave. Após a instalação e configuração da fase1, haverá um período de 2 meses de avaliação do Piloto. A fase2 - Migração completa deverá executar a migração dos telefones dos demais colaboradores da XPTO. As seguintes atividades estão previstas: 1. Aprovação do plano de Migração 2. Instalar GWTs em cada escritório. 3. Instalar SRL para XPTO (1o nível) 4. Instalar SRLs em cada escritório (2o nível) 5. Instalar PBX IP em cada escritório 6. Instalar os primeiros ramais IP (Registrar telefones no PBX IP) 6.1. Considerar configuração dos telefones por autoprovisioinamento 7. Configurar encaminhamento padrão pela rota de menor custo 8. Configurar encaminhamento dos DDRs dos telefones antigos para os novos 9. Configurar encaminhamento a 4 dígitos entre sites internos 10. Configurar encaminhamento dos números virtuais (2008) para novos ramais 10.1. automatizar como “siga-me” do número virtual para o novo ramal IP 10.2. Conversar com cada usuário do ramal antigo. 11. Rodar o checklist 12. Revisar e corrigir configurações no serviço fone@RNP e na rede IP de suporte (rotas e firewall) 13. Rodar o checklist sem nenhum erro - - - Período de análise do Piloto do fone@RNP nos escritórios da RNP - - 14. Migrar os outros telefones 15. Rodar o checklist sem nenhum erro 16. Desligamento dos servidores do fone antigo 17. Desligamento dos PABX legados 18. Retirada dos telefones analógicos

Cronograma #

Descrição

Data Início

Data final

1

Aprovação do plano de Migração

14/10

17/10

Observação

2

Instalar GWTs em cada escritório

GWT-S1 ok GWT-S2 ok GWT-S3 ok

GWT-S1 ok GWT-S2 ok GWT-S3 ok

3

Instalar SRL para XPTO (1o nível)

SRL (1n1) ok SRL (1n2) 14/10

SRL (1n1) ok SRL (1n2) 17/10

4

Instalar SRLs em cada escritório (2o nível)

14/10 SRL2n1-S1 SRL2n2-S1

24/10 SRL2n1-S1 SRL2n2-S1

SRL2n1-S2 SRL2n2-S2

SRL2n1-S2 SRL2n2-S2

SRL2n1-S3 SRL2n2-S3

SRL2n1-S3 SRL2n2-S3

14/10 PBX1-S1 PBX2-S1

24/10 PBX1-S1 PBX2-S1

PBX1-S2 PBX2-S2

PBX1-S2 PBX2-S2

PBX1-S3 PBX2-S3

PBX1-S3 PBX2-S3

5

Instalar PBX IP em cada escritório

6

Instalar os primeiros ramais IP 27/10 (Registrar telefones no PBX IP)

31/10

Com auxílio das equipes de suporte locais.

7

Configurar encaminhamento padrão pela rota de menor custo

03/11

07/11

Auxílio de suporte terceirizado

8

Configurar encaminhamento dos DDRs dos telefones antigos para os novos

03/11

07/11


9

Configurar encaminhamento a 4 dígitos entre sites internos

03/11

07/11


10

Configurar encaminhamento dos números virtuais (2008) para novos ramais

03/11

07/11


11

Rodar o checklist

07/11

07/11

12

Revisar e corrigir configurações no serviço fone@RNP e na rede IP de suporte (rotas e firewall)

10/11

12/11

13

Rodar o checklist sem nenhum erro

13/11

13/11

--

Período de análise do Piloto

13/11

15/01

14

Migrar os outros telefones

01/02

01/03

15

Rodar o checklist sem nenhum erro

01/03

01/03

16

Desligamento dos servidores do fone antigo

15/03

15/03

17

Desligamento dos PABX legados

15/03

15/03

18

Retirada dos telefones analógicos

16/03

23/03

Plano de discagem Sempre que possível, deve ser mantida a forma de discar atualmente em vigor na empresa. Para evitar mudança no hábito dos colaboradores, será mantido o primeiro “0”, para “pegar linha externa”, apesar de saber que, tecnicamente, não é mais necessário. Números internos do mesmo escritório: 4 dígitos Números internos de outros escritórios: 4 dígitos ou completo (0+CA+8dígitos) Números locais fixos: 0 + 8 dígitos iniciados por 2-5 Números locais celulares: 0 + 8 dígitos iniciados por 6-7 | 0 + 9 dígitos iniciados por 8-9 Números à distância fixo: 0 + CA + 8 dígitos iniciados por 2-5 Números à distância celular: 0 + CA + 8 dígitos iniciados por 6-7 | 0 + CA + 9 dígitos iniciados por 8-9 Números Internacionais: 0 + 0 + CP + número de 7 a 11 dígitos (incluindo Cód. de Área do país)

Ligações a cobrar local: 0 + 90 + 90 + 8 ou 9 dígitos Ligações a cobrar à distância: 0 + 90 + CA + 8 ou 9 dígitos Serviços especiais: 0 + 0X00 + 8 dígitos 0 + 1XX

Sobre a infraestrutura Lista de dispositivos e DMZs DMZ para serviços externos SRC - Serviço Nacional para clientes da RNP (Já existe! Pertence ao prestador do serviço) SRC-RJ: 200.143.193.54 SRC-DF: 200.130.35.113 Rede Externa SRL-S1 (2o nível) - Serviço local para o escritório (Site1) SRL-S1-2n1: SRL-S1-2n2: PBX-S1 - Serviço local para o escritório (Site1) PBX-S1-1: PBX-S1-2: GWT-S1 - Serviço local para escritório (Site1) GWT-S1: XXX.XXX.XXX.XXX SRL-S2 (2o nível) - Serviço local para o escritório (Site2) SRL-S2-2n1: SRL-S2-2n2: PBX-S2 - Serviço local para o escritório (Site2) PBX-S2-1: PBX-S2-2: GWT-S2 - Serviço local para escritório (Site2) GWT-S2: XXX.XXX.XXX.XXX SRL-S3 (2o nível) - Serviço local para o escritório (Site3) SRL-S3-2n1: SRL-S3-2n2: PBX-S3 - Serviço local para o escritório (Site3) PBX-S3-1: PBX-S3-2: GWT-S3 - Serviço local para escritório (Site3) GWT-S3: XXX.XXX.XXX.XXX

Rede (ou VLAN) de telefonia Telefones IP Site1 - Serviço local para o escritório Rede IP: XXX.XXX.XXX.XXX/24

Telefones IP Site2 - Serviço local para o escritório Rede IP: XXX.XXX.XXX.XXX/24 Telefones IP Site3 - Serviço local para o escritório Rede IP: XXX.XXX.XXX.XXX/24 Observação: Os telefones podem ter endereço IP “não roteável” (RFC-1718), desde que haja rota e não haja NAT entre os demais dispositivos de telefonia.

QoS da camada 2 Recomendável criação de VLAN para telefonia. Ou mesmo a utilização de switch separado. Priorização de quadros nos switches não necessário, mas também pode ser aplicável. QoS da camada 3 Amplamente recomendável a priorização de pacotes de voz (e vídeo). QoS entre escritórios é responsabilidade da equipe de Engenharia. QoS interno a cada escritório não necessário, mas também pode ser aplicado. Alimentação dos telefones DADO: Os telefones IP existentes no estoque são antigos e não suportam PoE. Se houver, nas baias, ponto de energia assegurado por nobreaks, utilizar estes pontos para alimentação dos telefones IP. Novas aquisições de telefones devem considerar PoE e também a compra de Switches PoE.

ANEXO

Configuração de Firewall

Serviço fone@RNP v.2012 O serviço de telefonia IP da RNP

Anexo – Configuração de Firewall


1

ANEXO


CONFIGURAÇÃO DO FIREWALL Este guia apresenta as regras de firewall que devem ser abertas para cada componente do fone 2012. O ambiente é composto por 4 tipos de componentes, sendo: •

SRC – SIP Router Central

•

SRL – SIP Router Local:

•

GWT – Gateway Transparente

•

PBX-IP – Private Branch Exchange-Internet Protocol

1.1. SRC – SIP ROUTER CENTRAL Gerencia a tabela ENUM global dos participantes do Fone@2012. Responsável por rotear as sinalizações SIPs entre os participantes e controle de DNS na zona ENUM. Pode interagir com SRL e GWT, SIP e DNS e outros peerings externos. Ambiente composto por duas (2) máquinas para contingência. IPs do SRC SRC-DF:

200.130.35.113

SRC-RJ:

200.143.193.54

Abaixo exemplo em PSEUDO linguagem de firewall. SRC conectado com SRL e GWT. O SRL já realiza controle de das chamadas permitindo somente sinalização entre peerings autorizados. Para facilitar as regras de firewall, serão liberadas somente as portas de SRL e GWT. Sentido: Internet --> DMZ ;; PERMITIR CONEXÃO TCP ESTABELECIDAS permitir conexoes estabelecidas ;; ;; SIP permitir protocolo UDP origem INTERNET porta 5060,5071 destino SRC-DF,SRC-RJ porta 5060 ;; ;; RTP -- NÃO REALIZA MIDIA PROXY. ;; ;; ZONE-TRANSFER e consultas DNS permitir protocolo UDP,TCP origem INTERNET porta 53,>1024 destino SRC-DF,SRC-RJ ;; ;; NTP permitir protocolo UDP origem IP-NTP1,IP-NTP2 porta 123,>1023 destino SRC-DF,SRCRJ porta 123 ;; GERENCIA do ambiente permitir protocolo TCP origem REDE_GERENCIA destino SRC-DF,SRC-RJporta 22,80,443 ;; GERENCIA do ambiente permitir protocolo udp origem REDE_GERENCIA_NMS destino SRC-DF,SRC-RJ porta 161


2

ANEXO


Sentido: DMZ --> INTERNET alguns ADMs de firewall permitem tudo do SRV --> Internet ;; PERMITIR CONEXÃO TCP ESTABELECIDAS permitir conexoes estabelecidas ;; ;; SIP permitir protocolo UDP origem SRC-DF,SRC-RJ porta 5060 destino INTERNET porta 5060,5071 ;; RTP -- NAO REALIZA ;; DNS-QUERY E ZONE TRANSFER permitir protocolo UDP,TCP origem SRC-DF,SRC-RJ porta 53,>1023 destino INTERNET porta 53,>1023 ;; GERENCIA permitir protocolo UDP origem SRC-DF,SRC-RJ destino IP-SYSLOG porta 514

1.2. SRL – SIP ROUTER LOCAL Gerencia a tabela ENUM local da instituição e recebe cópias das tabelas do serviço central. Responsável por rotear as sinalizações SIPs no âmbito local da instituição, podendo ser integrado com PBX-IP, GWT e outros proxys/Gateways SIP, como (AudioCodes, Asterisk, Central IP, Provedor SIP externo ex: VONO, etc.). Pode realizar Realiza Media-Proxy. Ambiente composto por 2 máquinas para contingência. Ex: em PSEUDO linguagem de firewall. SRC conectado com SRL e GWT. O SRL já realiza controle de das chamadas permitindo somente sinalização entre peerings autorizados. Para facilitar as regras de firewall, será liberado somente as portas de SRL e GWT. Sentido: Internet --> DMZ ;; PERMITIR CONEXÃO TCP ESTABELECIDAS permitir conexoes estabelecidas ;; ;; SIP permitir protocolo UDP origem SRC-DF,SRC-RJ porta 5060 destino SRL1,SRL2 porta 5060 ;; ;; RTP -- SE HABILITADO MEDIA PROXY e sem SUPORTE FIREWALL SIP/RTP permitir protocolo UDP origem INTERNET porta >1024 destino SRL1,SRL2 porta RANGE 50000-60000 ;; ;; ZONE-TRANSFER e consultas DNS permitir protocolo UDP,TCP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp, GWT destino SRL1,SRL2 porta 53 ;; ;; NTP permitir protocolo UDP origem IP-NTP1,IP-NTP2 porta 123,>1023 destino SRL1,SRL2 porta 123 ;; GERENCIA do ambiente permitir protocolo TCP origem REDE_GERENCIA destino SRL1,SRL2 porta 22,80,443 ;; GERENCIA do ambiente permitir protocolo udp origem REDE_GERENCIA_NMS destino SRL1,SRL2 porta 161


3

ANEXO


Sentido: DMZ --> INTERNET ;; alguns ADMs de firewall permitem tudo do SRV --> Internet ;; PERMITIR CONEXÃO TCP ESTABELECIDAS permitir conexoes estabelecidas ;; ;; SIP permitir protocolo UDP origem SRL1,SRL2 porta 5060 destino PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 5060 permitir protocolo UDP origem SRL1,SRL2 porta 5060 destino GWT porta 5071 permitir protocolo UDP origem SRL1,SRL2 porta 5060 destino [CASO EXISTA OUTROS\ PROXYS LOCAIS, ADICONAR AQUI] ;; RTP -- SE HABILITADO MEDIA PROXY e sem SUPORTE FIREWALL SIP/RTP permitir protocolo UDP origem SRL1,SRL2 destino INTERNET porta RANGE 50000-60000 porta >1023 ;; DNS-QUERY E ZONE TRANSFER permitir protocolo UDP,TCP origem SRL1,SRL2 porta 53,>1023 destino PBX-IP-m1, PBXIP-m2, PBX-IP-vrrp, GWT porta 53,>1023 ;; GERENCIA permitir protocolo UDP origem SRL1,SRL2 destino IP-SYSLOG porta 514 Ø IPs do SRL (estes fornecidos pela RNP, após verificação do formulário informado no início do manual, e caso sua instituição tenha o serviço de DNS terceirizado favor consultar o Administrador de Redes da Instituição). IP-SRL1: ________________________________ (DNS Resolver1) IP-SRL2: ________________________________ (DNS Resolver2)

1.3. GWT – GATEWAY TRANSPARENTE O GWT, faz o roteamento de menor custo de forma transparente entre a instituição, FONE@RNP e PSTN local. Esse equipamento também realiza o Media-Proxy. Em um momento pertinente o administrador encontrará os seguintes parâmetros a serem configurados: DNS: Zone Transfer do SIP-Router (Local ou Central), dependendo da configuração. TCP/UDP 53: Realiza o DNS-Forward para os DNS da instituição. SIP: udp: 5071 RTP: udp: 10.000 até 20.000 IP-GWT: Definido pela Instituição IP-DNS_RECURSIVO1: DNS Recursivo da Instituição IP-DNS_RECURSIVO2: DNS Recursivo da Instituição IP-NTP1: Definido pela Instituição: ex: ntp.pop-sc.rnp.br, ntp.cais.rnp.br, ntp.intituição.br IP-NTP2: Definido pela Instituição: ex: ntp.pop-sc.rnp.br, ntp.cais.rnp.br, ntp.intituição.br REDE_GERENCIA: Rede de gerência do ambiente


4

ANEXO


REDE_GERENCIA_NMS: Rede ou IP da estação de gerência SNMP ex: Cacti,Nagios, Dude, WhatsUP, etc.. IP-SYSLOG: Permitir exportar logs do sistema para outra máquina, caso necessário. Exemplo em PSEUDO linguagem de firewall o GWT Conectado ao SRC. Caso o GWT conecte ao SRL, basta trocar os IPs de SRC-DF e SRC-RJ pelos respectivos IPs do SRL. Sentido: Internet --> DMZ ;; PERMITIR CONEXÃO TCP ESTABELECIDAS permitir conexoes estabelecidas ;; ;; SIP permitir protocolo UDP origem SRC-DF,SRC-RJ porta 5060 destino IP-GWT porta 5071 ;; ;; RTP ;; OBS: Caso o firewall possua suporte a SIP/RTP, basta habilitar as regras do SIP, que as demais ;; serão abertas automáticamente permitir protocolo UDP origem INTERNET porta >1023 destino IP-GWT porta RANGE 10.000-20.000 ;; ;; ZONE-TRANSFER e consultas DNS permitir protocolo UDP,TCP origem SRC-DF,SRC-RJ porta 53 destino IP-GWT ;; ;; DNS FORWARD para DNS da instituição, retorno das requisições permitir protocolo UDP,TCP origem IP-DNS_RECURSIVO1,IP-DNS_RECURSIVO2 porta 53 destino IP-GWT ;; ;; NTP permitir protocolo UDP origem IP-NTP1,IP-NTP2 porta 123,>1023 destino IP-GWT porta 123 ;; GERENCIA do ambiente permitir protocolo TCP origem REDE_GERENCIA destino IP-GWT porta 22,80,443 ;; GERENCIA do ambiente permitir protocolo udp origem REDE_GERENCIA_NMS destino IP-GWT porta 161 Sentido: DMZ --> INTERNET ;; alguns ADMs de firewall permitem tudo do SRV --> Internet ;; PERMITIR CONEXÃO TCP ESTABELECIDAS permitir conexoes estabelecidas ;; ;; SIP permitir protocolo UDP origem IP-GWT porta 5071 destino SRC-DF,SRC-RJ porta 5060 ;; RTP ;; OBS: Caso o firewall possua suporte a SIP/RTP, basta habilitar as regras do SIP, que as demais ;; serão abertas automáticamente permitir protocolo UDP origem IP-GWT porta RANGE 10.000-20.000 destino INTERNET porta >1023 ;; ;; DNS FORWARD para DNS da instituição, retorno das requisições


5

ANEXO


permitir protocolo UDP origem IP-GWT destino IP-DNS_RECURSIVO1,IP-DNS_RECURSIVO2 porta 53 ;; NTP permitir protocolo UDP origem IP-GWT destino IP-NTP1,IP-NTP2 porta 123 ;; GERENCIA permitir protocolo UDP origem IP-GWT destino IP-SYSLOG porta 514

1.4. PBX IP PBX IP responsável pelo AAA dos ramais SIP, gerenciamento do aprovisionamento dos Telefones, Catálogo, Relatórios, etc... Para telefones corporativos da Instituição. Ambiente composto por 2 máquinas para contingência, que compartilham um IP Virtual para rápido failover. Esse componente somente pode falar com o SRL. Pode fazer Media-Proxy, se habilitado. Sentido: Internet --> DMZ ;; PERMITIR CONEXÃO TCP ESTABELECIDAS permitir conexoes estabelecidas ;; ;; SIP -- INVITE permitir protocolo UDP origem SRL1,SRL2 porta 5060 destino PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 5060 ;; SIP -- INVITE/REGISTER -- TELEFONES permitir protocolo UDP origem REDE_TELEFONES_IPS_INSTITUICAO destino PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 5060 ;; ;; RTP -- SE HABILITADO MEDIA PROXY e sem SUPORTE FIREWALL SIP/RTP permitir protocolo UDP origem INTERNET porta >1024 PBX-IP-m1, PBX-IP-m2, PBX-IPvrrp porta RANGE 50000-60000 ;; ;; ZONE-TRANSFER e consultas DNS permitir protocolo UDP,TCP origem SRL1,SRL2 porta 53 destino PBX-IP-m1, PBX-IPm2, PBX-IP-vrrp ;; ;; DNS FORWARD para DNS da instituição, retorno das requisições permitir protocolo UDP,TCP origem IP-DNS_RECURSIVO1,IP-DNS_RECURSIVO2 porta 53 destino PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp ;; ;; NTP permitir protocolo UDP origem IP-NTP1,IP-NTP2 porta 123,>1023 destino PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 123 ;; GERENCIA do ambiente permitir protocolo TCP origem REDE_GERENCIA destino PBX-IP-m1, PBX-IP-m2, PBX-IPvrrp porta 22,80,443 ;; GERENCIA do ambiente permitir protocolo udp origem REDE_GERENCIA_NMS destino PBX-IP-m1, PBX-IP-m2, PBXIP-vrrp porta 161 Sentido: DMZ --> INTERNET ;; alguns ADMs de firewall permitem tudo do SRV --> Internet ;; PERMITIR CONEXÃO TCP ESTABELECIDAS permitir conexoes estabelecidas


6

ANEXO


;; ;; SIP permitir protocolo UDP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 5060 destino SRL1,SRL2 porta 5060 permitir protocolo UDP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 5060 destino REDE_TELEFONES_IPS_INSTITUICAO ;; RTP -- SE HABILITADO MEDIA PROXY e sem SUPORTE FIREWALL SIP/RTP permitir protocolo UDP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta RANGE 5000060000 destino INTERNET porta >1023 ;; DNS-QUERY E ZONE TRANSFER permitir protocolo UDP,TCP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 53,>1023 destino SRL1,SRL2 porta 53,>1023 ;; DNS FORWARD para DNS da instituição, retorno das requisições permitir protocolo UDP,TCP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp destino IPDNS_RECURSIVO1,IP-DNS_RECURSIVO2 porta 53 ;; GERENCIA permitir protocolo UDP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp destino IP-SYSLOG porta 514


7

ANEXO

Instalação manual do SRL



ANEXO – Instalação manual do SRL


1

ANEXO


1. INSTALAÇÃO do SRL O SIP Router pode ser instalado via configuração manual ou através de imagem disponível de VMWare. Abaixo é detalhado o procedimento manual.

1.1. INSTALAÇÃO MANUAL Para realizar a instalação manualmente, deve ser informado qual máquina vai ser instalada, 1 ou 2. Quando o componente for operar sem redundância, pode-se informar que está se instalando a máquina 1 e quando solicitado na instalação o IP da máquina vizinha, informar o mesmo IP. A configuração do host e da redundância entre as duas máquinas finais serão aplicadas na interface gráfica.

1.1.1. PARTICIONAMENTO É recomendado o uso de LVM nas partições para facilitar futuras expansões de disco caso sejam necessárias. O particionamento da máquina é recomendado que seja feito utilizando LVM seguindo o modelo abaixo: Filesystem

Size

Used

/dev/mapper/vg--root-lv--root

1.9G

174M

Avail 1.6G

/dev/mapper/vg--root-lv—tmp1.9G

35M

1.8G

2% /tmp

/dev/mapper/vg--root-lv—usr3.7G

495M

3.0G

14% /usr

/dev/mapper/vg--root-lv—var3.7G

104M

3.4G

3% /var

/dev/mapper/vg--root-lv--var--lib 22G

237M

21G

/dev/mapper/vg--root-lv--var--log

15G

180M

14G

Use%

Mounted on

10% /

2% /var/lib 2% /var/log

1.1.2. CONFIGURAÇÃO PACOTES LINUX Adicionar no arquivo /etc/apt/sources.list as seguintes entradas: deb http://debian.pop-sc.rnp.br/debian/ squeeze main deb-src http://debian.pop-sc.rnp.br/debian/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-updates, previously known as 'volatile' deb http://debian.pop-sc.rnp.br/debian/ squeeze-updates main deb-src http://debian.pop-sc.rnp.br/debian/ squeeze-updates main # AG Projects software deb

http://ag-projects.com/debian stable main

deb-src http://ag-projects.com/debian stable main


2

ANEXO


Atualizar a base de pacotes do sistema operacional e instalar a chave para o repositório do Media Proxy e pacotes requeridos para realizar a instalação: apt-get update cd /usr/local/src wget http://download.ag-projects.com/agp-debian-gpg.key apt-key add agp-debian-gpg.key apt-get install rsync vim

1.1.3. SISTEMA CORE E WEB Para realizar a instalação do SRL, executar os seguintes comandos: cd /usr/local/src/ wget http://rep.fone2012.pop-sc.rnp.br/fone2012/SRL/APP/core/SRL-core-last-stable.tar.gz wget http://rep.fone2012.pop-sc.rnp.br/fone2012/SRL/APP/web/SRL-web-last-stable.tar.gz tar zxvf SRL-core-last-stable.tar.gz tar zxvf SRL-web-last-stable.tar.gz cd SRL ./update_scripts.sh

OBS: É esperado ocorrer erro na versão 1.0.0, na cópia do "/var/lib/backup/local-config.m4.ORIGINAL".

1.1.4. OPENSIPS É necessário realizar a compilaçãodo OpenSIPs e inicializar a base de dados. O script de instalação irá baixar as dependências de compilação e uso, solicitando as senhas do MySQL e LDAP. Guarde-as para posterior uso. Tempo estimado: 10 min, dependendo do tempo da rede e processamento do host. Para isso, executar o seguinte procedimento: cd /usr/local/SRL/install ./pacotes_debian_geral.sh

Ao instalar, o postfix deve ser configurado como "local-only", conforme tela abaixo:


3

ANEXO


Figura 1

Após será solicitado o nome do host para o SRL. É importante que esse nome seja FDQN para que o SMTP da instituição possa trabalhar corretamente. A instalação do OpenSIPs para o SRL é disparado através do seguinte comando: cd /usr/local/SRL/install ./install_opensips.sh 0

1.1.5. MEDIA PROXY Para disparar a instalação do Media Proxy, devem ser executados os seguintes comandos: cd /usr/local/SRL/install ./install_mediaproxy.sh

OBS: Aceitar instalar mesmo não autenticado os APT-GET INSTALL.

1.1.6. CONFIGURAÇÃO INICIAL Para realizar a configuração inicial, deve ser executado o procedimento abaixo respondendo as perguntas conforme forem sendo mencionadas. No final, a máquina estará instalada e pronta para ser configurada via interface gráfica: cd /usr/local/SRL/install ./init_sistema.sh


4

ANEXO ____

____

/ ___||


_ _ \| |

\___ \| |_) | | ___) |

_ <| |___

|____/|_| \_\_____| Versao 1.0.0 / 2012/12/18 SRL Install Entre com as informacoes do Host SRL Servidor (1 ou 2): 1 IP da SRL_M1: 10.255.255.10 Digite o IP da SRL_M2 (VIZINHO): 10.255.255.11 Defina o dominio [voip.rnp.br]: fone.rnp.br Defina o LDAP DN [dc=fone,dc=rnp,dc=br]: Inicializar MySQL (S/N):S *** DB:MySQL *** Digite a senha de root do MySQL(Definida na Instalacao do MySQL) MySQL ROOT PW: Crie uma senha para os acessos ao MySQL MySQL USER PW: LDAP Inicializar LDAP (S/N):S *** LDAP *** Crie uma nova senha para o LDAP SENHA LDAP ADMIN: Senha para replicacao- ** LDAP ** Ambas IGUAIS em M1 e M2 LDAP REPLICACAO PW: OPENSSL_CONF: Houve alteracoes md5sum: /var/lib/backup/last/openssl.cnf.tar.gz: No such file or directory Nova versao, arquivar e atualizar last - openssl.cnf Jah Arquivado - local-config.m4 OPENSSL_CONF: Reiniciando.. rm /etc/apache2/apache.pem rm: cannot remove `/etc/apache2/apache.pem': No such file or directory Gerando certificado... Generating a 1024 bit RSA private key .......................................++++++ ...........++++++ writing new private key to '/etc/apache2/apache.pem' ----Enabling module ssl. See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates.


5

ANEXO


Run '/etc/init.d/apache2 restart' to activate new configuration! Enabling module rewrite. Run '/etc/init.d/apache2 restart' to activate new configuration! Inicializando OpenSIPS stty: standard input: Invalid argument stty: standard input: Invalid argument stty: standard input: Invalid argument Inicializando LDAP... Stopping OpenLDAP: slapd. Starting OpenLDAP: slapd. Inicializando LDAP... ldap_add: Already exists (68) update-rc.d: using dependency based boot sequencing FIREWALL: Houve alteracoes md5sum: /var/lib/backup/last/firewall.sh.tar.gz: No such file or directory Nova versao, arquivar e atualizar last - firewall.sh Jah Arquivado - local-config.m4 FIREWALL: Reiniciando.. /etc/init.d/firewall restart Reiniciando Firewall.. . Restarting web server: apache2 ... waiting .

OBS: • • •

Na seleção do campo “SRL Servidor (1 ou 2)”, caso esteja instalando uma segunda máquina para operar de forma redundante, definir como sendo o servidor 2. No campo “IP da SRL_M1”, selecionar o IP que deve ser configurado pela máquina. No campo “IP da SRL_M2 (VIZINHO)”, selecionar o IP que a máquina vai fazer peering.

A partir daqui, retome o manual de instalação e configuração do SRL.


6

ANEXO

Plano de testes



ANEXO – Plano de testes


1

ANEXO

Plano de testes

PLANO DE TESTES Cada instalação do fone@RNP possui um caderno de testes específico. Para evitar várias cópias de documentos similares, vamos apresentar a ideia geral que originou os formulários. Testes de chamadas (Checklist) Antes e após cada instalação de um módulo do fone será necessário testar se todos os tipos de chamadas podem ser realizados normalmente. Tomemos um hipotético Campus A como referência. Todas os tipos e direções de chamadas devem ser testadas, sempre que for cabível, conforme listadas abaixo. Ligações dentro do Campus A

● ● ● ●

Ligações feitas a partir de telefones IP para telefones IP; Ligações feitas a partir de telefones analógicos para telefones analógicos; Ligações feitas a partir de telefones IP para telefones analógicos; Ligações feitas a partir de telefones analógicos para telefones IP.

Ligações “entrantes” no Campus A

● Ligações para dentro do Campus A, com origem na RTFC ○ Para ramais IP; ○ Para ramais analógicos. ● Ligações para dentro do Campus A, com origem em outro Campus da mesma instituição ○ Para ramais IP; ○ Para ramais analógicos. ● Ligações para dentro do Campus A, com origem em outro cliente do fone@RNP ○ Para ramais IP; ○ Para ramais analógicos. Ligações “saintes” do Campus A

● Ligações para fora do Campus A, para outro Campus da mesma instituição ○ A partir de telefones IP; ○ A partir de telefones analógicos. ● Ligações para fora do Campus A, para outra instituição do fone@RNP no mesmo DDD ○ A partir de telefones IP; ○ A partir de telefones analógicos. ● Ligações para fora do Campus A, para outra instituição do fone@RNP em outro DDD ○ A partir de telefones IP; ○ A partir de telefones analógicos. ● Ligações para fora do Campus A, mas dentro da mesma cidade ○ A partir de telefones IP para números locais na RTFC ■ Celulares ■ Fixos ○ A partir de telefones analógicos para números locais na RTFC, celulares ou fixos. ■ Celulares


2

ANEXO

Plano de testes

■ Fixos ○ Ligações para fora do Campus A, para números na RTFC em outro código de área ■ Celulares ■ Fixos ○ A partir de telefones IP para números DDD na RTFC ■ Celulares ■ Fixos ○ A partir de telefones analógicos para números DDD na RTFC ■ Celulares ■ Fixos Ligações para serviços especiais

1XX 1XX XXXX 0X00 XXXXXXX 9090 XXXXXXXX 90CA XXXXXXXX Esses testes devem ser repetidos a cada modificação no serviço de telefonia, em todos os sites dos clientes.


3

LEVANTAMENTO DE DADOS LOCALIDADE: DATA: FONE@RNP DISTRIBUIÇÃO 2012

LEVANTAMENTO DE INFORMAÇÕES PARA INSTALAÇÃO

1.1.1. Dados Cadastrais da Instituição para o Fone@RNP Preencha com todos os campos para facilitar o contato. Instituição Campus Setor Sigla WebSite E-mail CEP Endereço (logradouro, número, completo)

Bairro Cidade Estado CNPJ

1.1.2. Dados Cadastrais dos técnicos da Instituição para o Fone@RNP Preencha com todos os campos para facilitar o contato com a equipe responsável pelo serviço na instituição. Responsável Administrativo Nome Telefone E-mail CPF RG Responsável Técnico 1 Nome Telefone E-mail CPF RG Responsável Técnico 2 Nome Telefone E-mail Contato emergencial (Contato do plantonista ou do setor - lista / grupo) Setor Telefone E-mail

1.1.3. Conexão de rede Existentes na Instituição Preencha com todos os fornecedores de conectividade com a Internet, inclusive a RNP. Indique o(s) link(s) de backup. Fornecedor

Velocidade

FORNECEDOR_1 FORNECEDOR_N (BKP)

Tipo Simétrico/ Full Duplex ADSL

Endereço IP Máscara Gateway Público 255.255.255.255 255.255.255.255 255.255.255.255

1.1.4. Descreva o ambiente virtualização Detalhe a quantidade dos servidores e o sistema de virtualização que sua instituição possui. Caso não possua, escreva "Não possuo ambiente de virtualização".

1.1.5. Equipamentos existentes relativos ao uso de VoIP Preencha indicando que equipamentos de Voz sobre IP sua instituição já possui. Adicione linhas conforme a necessidade.

Equipamento

Não Sim Qtd

Observações / Descrição

Servidor Placa E1 (Digium TE235BF) Kommuter (Khomp) Balluns (para telefonia) Adaptadores Cabos coaxiais para telefonia (G.703) Cabos de rede para telefonia (RJ48) PABX IP Telefone IP Outro equipamento 1 Outro equipamento 2 Outro equipamento 3 Outro equipamento 4

1.1.6. Sobre a central telefônica Convencional Responda às perguntas da tabela abaixo de acordo com o ambiente de telefonia de sua Instituição. Veja manual disponível no endereço: http://portal.rnp.br/web/servicos/forum/-/message_boards/message/1194421 Questão Informe a marca e modelo da PBX PBX possui interface VoIP? Se sim, descreva protocolo (SIP/H.323/IAX), endereço IP e porta Quantos troncos E1 a Instituição possui?

Resposta

Quantos troncos Analógicos a instituição possui? Quantos troncos GSM a instituição possui? Quantos troncos VoIP a instituição possui? Quantos ramais a instituição possui?

1.1.7. Responda as seguintes perguntas caso a instituição possua E1 sem tronco SIP Uso exclusivo para instituição que adere ao serviço com GWT. Questão Resposta A central telefônica está instalada no mesmo prédio do “Centro de Dados”? Qual a distância em metros entre a PBX e o “Centro de Dados”? Tem espaço e local adequado para instalação do GWT no mesmo espaço físico da PBX? Tem espaço e local adequado para instalação do GWT no “Centro de Dados”? Qual a sinalização do tronco E1 entre a PBX e a RTFC (R2 ou ISDN)? Caso apenas um tronco, quantos canais estão configurados nele? Caso mais de um tronco, há diferenciação na direção das chamadas nos troncos? Ex. tronco de entrada e/ou saída de chamadas. Quais os conectores conectados ao tronco E1? Ex. BNC/IEC/Mini-IEC Quais os conectores conectados à central PBX Convencional? Ex. BNC/IEC/Mini-IEC 1.1.8. DDD, prefixos e faixas de números de ramais atendidos pela PBX convencional Preencha com todos os números cedidos pela sua operadora telefônica que atendem à sua Instituição. Adicione todas faixas de forma separada, incluindo assim o quantidade de linhas que forem necessárias. CA

DDD

ABCD

Prefixo

Faixa de ramais MCDU-XYZQ

1.1.9. Linhas analógicas diretas e ramais de PABX Virtual oferecidos pela operadora Preencha com todos os números cedidos pela sua operadora telefônica que atendem à sua Instituição. CA

DDD

Número ABCD-XYZQ

Serviço Linha Direta ou Ramal virtual

1.1.10. Fotos Cole aqui fotos dos conectores da central PBX, dos conectores no modem da operadora e do ambiente (rack, armário, sala) em que estão instalados. PARA PREENCHIMENTO EXCLUSIVO DA RNP

1. Prefixos a serem completados para a RTFC Prefixos dentro do mesmo Código de Área da Instituição cujas chamadas tenham tarifação LOCAL, de acordo com a ANATEL. Informação atualmente alimentada pelo TXT da Anatel. N.º

DDD

Prefixo

Faixa de ramais

2. Lista de equipamentos e Endereços IPs a serem utilizados na instituição Definição do tipo de serviço: ( ) SRL ( ) GWT ( ) PBX - IP ( ) PBX Analógico Caso seja SRL, descreva em que unidades os equipamentos serão instalados: __________________________________________________________ Caso seja GWT, identifique o tipo de placa: ( ) DIGIUM PCI-e ( ) EBS SERVER Equipamento

IP / Máscara

Porta SIP

(

) KHOMP PCI-e Peers

Observação

3. Informações associadas ao Fone@RNP da Instituição Usuária ID FEGEN DDD Padrão Serviço de Monitoramento instalado: Serviço de Estatística instalado:

( (

4. Lista de materiais a serem enviados pela RNP

) SIM ) SIM

( (

) NÃO ) NÃO

ANEXO

Ajuste de temporização do R2



ANEXO – Ajuste de temporização do R2


1

ANEXO


1. PROBLEMA Após a instalação do GWT 2.0 o tempo de comutação de uma ligação da PBX para a PSTN com o kommuter habilitado estiver muito mais elevado que com o kommuter desabilitado.

2. SOLUÇÃO Uma possível solução para este problema é ajustar o comportamento da sinalização R2 que vem por padrão configurada no GWT 2.0. Para tal, entre na configuração das placas acessando a guia Sistema e menu Configurações > Placas (Figura 1). Para acessar o módulo de configuração Khomp, utilize as credenciais: Usuário: config Senha: config

Figura 1

Entrar na aba Configuração, menu Telefonia > Profiles e copiar o Perfil R2, conforme Figura 2.


2

ANEXO


Figura 2

Alterar o nome do perfil para R2_PABX e ajustar os parâmetros Comportamento para fim de número de destino para Enviar I15 e Timeout de recepção de MFC para frente para 1000. Estes parâmetros podem ser ajustados conforme central integrada (Figura 3). Ao finalizar a configuração clique em Concluir.


3

ANEXO


Figura 3

Mapear o perfil recém-criado para a placa da PBX. Para tal, entrar na aba Configuração, menu Telefonia > Links E1. Alterar o parâmetro Sinalização da placa PBX para o perfil R2_PABX e clicar em Aplicar (Figura 4).

Figura 4

Reiniciar o serviço Khomp API Server, através da aba Monitoração, guia Serviços (Figura 5).


4

ANEXO


Figura 5

Para finalizar, entrar na guia Sistema, menu Configurações > Ambiente, aba Serviços Habilitados e reiniciar o serviço Asterisk (Figura 6).

Figura 6


5

ANEXO

Instalação do GWT com servidor + placa



ANEXO – Instalação do GWT com servidor + Placa Digium


1

ANEXO


Roteiro de instalação e configuração do GWT Com servidores + placas Digium

1. PRÉ INSTALAÇÃO Antes de começar, certifique-se de ter disponíveis em sua instituição todas as informações relacionadas abaixo.

1.1. INFORMAÇÕES PRELIMINARES Para iniciar, obtenha e preencha as informações contidas no questionário “Levantamento de informação para Instalação do Gateway Transparente”, item 6.1 do Apêndice, que está localizado no final deste documento, pois as informações nele contidas serão de extrema importância para continuação da instalação.

1.2. RELAÇÃO DE MATERIAIS ü 1 placa TDM Digium modelo TE220 com duas interfaces E1, RJ45, com módulo de cancelamento de eco; ü 1 Servidor homologado e com automático após queda de energia, que a partir deste momento será chamado de Gateway Transparente ou GWT. ü 1 Kommuter 10, modelo RJ45(Figura 1), para alta disponibilidade da conexão com a operadora, com 4 interfaces E1, RJ45 e uma interface USB utilizada para alimentação e comunicação com o driver do Asterisk.

Figura 1

ü 2 Baluns (Figura 2) para balanceamento de impedância, possuindo um conector RJ45 de um lado e 2 conectores BNC no outro lado.

Figura 2

ü 2 cabos coaxiais, duplex, 75 Ohms com 1 ponta BNC e outra (IEC ou BNC), dependendo da interface de conexão com a PSTN, devidamente identificados como C1 e C2.


2

ANEXO


ü 2 cabos coaxiais, duplex, 75 Ohms com 1 ponta BNC e outra (IEC ou BNC), dependendo da interface da PABX, devidamente identificados como C3 e C4 ü 1 Cabo RJ45, de tamanho que atenda a necessidade de seu ambiente, para a conexão entre balun e o Kommuter, devidamente identificado como C5. ü 1 Cabo RJ45, pode ser padrão de 1,5mt ou do tamanho da necessidade de seu ambiente, para a conexão entre balun e o Kommuter, devidamente identificado como C6. ü 1 Cabo USB, devidamente identificado como C7. Na caixa do Kommuter já contém um no tamanho padrão, para conexão Kommuter -> Servidor. ü 2 cabos RJ45, 1,5mt que servirá para a conexão do Kommuter com o Servidor, devidamente identificados como C8 e C9. ü Servidor conectado a rede local.

1.3. INSTALAÇÃO DA PLACA E1 A placa para telefonia digital, utilizada para comunicação do servidor com a rede de telefonia pública convencional (PSTN) e com o PABX, vem configurada de fábrica para o padrão T1. Antes de instalá-la no servidor é necessário configurá-la para o padrão E1. Para isso, antes instalar a placa no GWT será necessário fechar os jumper J1-J2 e J3-J4, no local indicado abaixo, na Figura 3:

Figura 3

Feche os jumpers e insira em um slot PCI do Servidor. Caso a placa já venha instalada fisicamente no GWT, é importante que seja feita a verificação do jumper. Se essa configuração não estiver correta, a ligação com o PABX e com a operadora não funcionará.

1.4. CONEXÃO ENTRE GWT, KOMMUTER, PABX E PSTN Inicialmente é feita a identificação do tipo de conector. Observe na Figura 4 qual o tipo de conector que sua central possui:


3

ANEXO


Figura 4

BNC – Conector tipo BNC, tamanho “grande”, tipo encaixe. Tamanho de 5cm IEC – Conector tipo IEC, tem um tamanho menor que o BNC, sendo uma extremidade de rosca(2cm) com um antiderrapante. Mini-IEC – Conector tipo mini-IEC, em sua extremidade de conexão tem formato de rosca, na extremidade desta roca ele tem formato de uma “porca” (hexagonal), diferente do IEC. Antes de continuar a instalação certifique-se que está de posse de todos os cabos, compatíveis com o seu ambiente de telefonia. Na Figura 5 observa-se o diagrama de como deve ficar a conexão dos cabos entre os equipamentos(Atenção, abaixo está ilustrado um cenário possível, dentre vários outros).

Figura 5


4

ANEXO


O Kommuter é o componente utilizado para prover alta disponibilidade do ambiente, em caso de falha da máquina (ex: Software, hardware e falha elétrica) esse equipamento irá chavear automaticamente da PSTN para a PBX convencional Porta (A) PARA (D). O Kommuter possui LEDs verdes, que quando está aceso indica que as chamadas estrarão passando pelo GWT, e os LEDs vermelhos, que indicam que as chamadas seguem direto entre PABX e a PSTN. A conexão deve seguir o seguinte padrão: Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø

Cabo coaxial 1, identificado como C1 (PSTN-RX -> B1-TX) Cabo coaxial 2, identificado como C2 (PSTN-TX -> B1-RX) Cabo coaxial 3, identificado como C3 (PBX-RX -> B2-RX) Cabo coaxial 4, identificado como C4 (PBX-TX -> B2-TX) Cabo RJ-45, identificado como C5 (B1-RJ45 -> KOMMUTER-PORTA A) Cabo RJ-45, identificado como C6 (B2-RJ45 -> KOMMUTER-PORTA D) Cabo USB, identificado como C7 (KOMMUTER-USB -> Servidor-USB) Cabo RJ45, identificado como C8 (KOMMUTER-PORTA B -> PLACA DIGIUM - PORTA 2) Cabo RJ45, identificado como C9 (KOMMUTER-PORTA C -> PLACA DIGIUM - PORTA 1) Cabo RJ45, identificado como C10 (LAN -> Rede Local)

Faça a identificação dos cabos de acordo com a descrição acima. Lembre-se de identificar os dois lados do cabo, para que posteriormente seja possível o suporte em caso de problemas. Note que após a ligação completa dos cabos conforme descrito acima, o serviço de telefonia deve estar funcionando exatamente como antes da ligação dos cabos. Além disso, mesmo durante a instalação do servidor GWT o serviço de telefonia também não deve sofrer nenhum prejuízo.

1.5. INSTALAÇÃO DO SERVIDOR 1. 2. 3. 4.

Instale o servidor no rack. Conecte o cabo de rede local. Ligue o Servidor. Inicialize o servidor com o DVD de instalação do módulo de Gateway Transparente. (Para obter a imagem de instalação do servidor acesse - http://repositorio-fone.rnp.br/downloads/IMG_FONERNP_2012_20130613.iso e grave um DVD 5. Quando iniciar aparecerá à tela abaixo (Figura 6) e escolha a primeira opção e tecle ENTER. Na próxima tela aguarde a carga completa dos componentes (Figura 7), para prosseguir a instalação:


5

ANEXO


Figura 6

Figura 7

Ø Na Figura 8 um alerta é apresentado, o qual lembra que ao prosseguir com a instalação todos os dados no servidor serão perdidos, pois o mesmo será formatado. Caso queira continuar com a instalação certifique-se que não há dados importantes no servidor. Informa também que por questões de segurança será solicitado que confirme seu desejo de continuar.


6

ANEXO


Figura 8

Ø Tecle ENTER(“EXIT”), para continuar Conforme alertado na tela anterior, a confirmação é solicitada na Figura 9.

Figura 9

Ø Digite GWT e tecle ENTER. Aparecerá um mais um aviso informando sobre a exclusão de dados e lhe perguntando se realmente é esta ação que você quer executar.


7

ANEXO


Figura 10

Ø Tecle ENTER – “YES”, (Figura 10). Quando confirmar, aparecerá à tela de instalação (Figura 11), informando o tempo de instalação, esse tempo pode variar de 40 minutos até 2 horas.

Figura 11

Com o progresso da instalação as próximas telas serão:


8

ANEXO


Figura 12

Figura 13

Figura 14


9

ANEXO


Após o término da instalação a tela ficará como a Figura 15.

Figura 15

Em seguida, o servidor será reiniciado automaticamente, mas em alguns casos, por diferenças de equipamento de hardware, esta ação pode não ser executada. Se ocorrer falha ao reiniciar o servidor, a tela ficará como na Figura 15. Isso significa que a instalação foi concluída, porém não reiniciou automaticamente. Se após o término o GWT não reiniciar e ficar parado no status da Figura 15, desligue e ligue o GWT para que seja concluída a tarefa.


10

ANEXO


Figura 16

Esta é a tela padrão do GWT(Figura 16) – Gateway Transparente. Observe que nela está informado seu nome e domínio ao qual pertence esse GWT, o endereço IP, Versão do Core (núcleo da solução) e do Ambiente Web (Interface gráfica da solução).

2. ACESSANDO E CONFIGURANDO O GWT 2.1. CONFIGURANDO UMA ESTAÇÃO PARA ACESSAR O GWT Como mostrado na Figura 16, o GWT vem pré-configurado com o endereço IP 10.255.255.1. Para ilustrar este guia, foi utilizando o sistema operacional Windows 7. Caso você esteja utilizando outra versão do Windows ou mesmo outro Sistema Operacional será necessário adequar as instruções à sua estação de trabalho. Abaixo seguem os passos a serem executados. Para acessar o servidor em outra máquina coloque-a no mesmo segmento de rede do servidor, por exemplo: 10.255.255.5. Clique no botão “Iniciar”, depois em “Painel de Controle”, depois em “Central de Rede e Compartilhamento” e do lado esquerdo escolha, “Alterar as configurações do adaptador” (Figura 17):


11

ANEXO


Figura 17


Figura 18

Depois clique com o botão direito em cima da placa de rede do computador, e escolha a opção “Propriedades” (Figura 19):


12

ANEXO


Figura 19

Neste momento será feita a inserção do IP da máquina no mesmo segmento de rede do GWT, para ser iniciado o acesso. Dê um clique duplo em “Protocolo TCP/IP Versão 4”, conforme selecionado na Figura 20

Figura 20


13

ANEXO


Selecione a opção “Usar o seguinte endereço IP:” e digite o IP exemplo 10.255.255.5 como de acordo com a Figura 21, e depois clique no botão OK.

Figura 21

Para testar, execute um comando através do prompt de comando. Clique no botão “Iniciar”. No campo destinado a “Pesquisar programas e arquivos” clique e digite CMD e tecle ENTER(Figura 22).


14

ANEXO


Figura 22

Na tela do prompt digite: “Ping 10.255.255.1”, tecle ENTER e o resultado deve ser exatamente o da Figura 23.

Figura 23

Saia da tela cima digitando “EXIT” e tecle ENTER. Abra o navegador de sua preferência e no local do endereço digite o endereço https://10.255.255.1 (Figura24). Para este guia, utilizamos o Google Chrome.


15

ANEXO


Figura 24

E depois clique em “Continuar mesmo assim”.

2.2. CONFIGURAÇÃO PRELIMINAR DO GWT Seguindo os passos anteriores, aparecerá a seguinte tela:


16

ANEXO


Figura 25

Digite os seguintes dados para o acesso: Usuário: Password:

admin gwt.admin

Após logar, a Tela inicial será semelhante à Figura 26. Observe no canto superior direito que o módulo “Gateway” está selecionado. Esta é a tela de monitoramento do GWT, que indica quais serviços estão funcionando ou não, informações do hardware, informações de rede e outros detalhes.

Figura 26


17

ANEXO


Acesse a Tela de Administração do Sistema (Figura 27). Clique no módulo “Sistema”(1) na barra verde na área superior direita do navegador, quando clicar nesta opção irá se expandir do lado esquerdo do navegador a opção “Configurações”(2).

Figura 27

Nesta tela é possível criar um novo usuário, ou editar as informações de um usuário existente. Abaixo a tela de edição do usuário ao sistema. Clique no botão editar Figura 27 (4) e em seguida ALTERE a senha inicial do usuário “Admin”, para uma que você tenha controle (Figura 28).

Figura 28


18

ANEXO


2.2.1. Configurações -> Ambiente Nesta opção, o Administrador poderá inserir ou editar configurações de funcionamento do serviço FONE@RNP. No menu “Configurações” do lado esquerdo da página, na opção “Ambiente” (Figura 29), existem várias guias que serão descritas a seguir.

Figura 29

a) Guia Instituição Guia que contém as informações da Instituição e o responsável pela Administração do serviço Fone@RNP. Clique na guia Instituição e preencha com os dados do solicitados, no campo “Telefone para contato” preferencialmente deve ser o número de telefone móvel. Ao concluir clique em “Salvar Alterações”.

Figura 30

Ø Sigla: Sigla corresponde a instituição que está sendo instalado o GWT Ø Campus: Campus ou Unidade corresponde a instituição que está sendo instalado o GWT


19

ANEXO


Ø Nome da Instituição: Nome completo da instituição. Existe um Bug, que será corrigido (a quantidade de caracteres não deve ser superior a 20). Ø Nome do responsável para contato: Nome da pessoa que ficará responsável pelo serviço na instituição. Ø Telefone para contato: Telefone de contato do responsável, preferencialmente, telefone móvel. Ø E-mail para contato: Correio eletrônico de contato do responsável. b) Guia Sistema Guia responsável pelas configurações do Sistema do GWT, abaixo a descrição de cada campo, conforme mostrado na Figura 31.

Figura 31

Ø Hostname – Nome do servidor no domínio. Importante: No “Hostname” a padronização adotada para o FONE@2012 é “GWT-sigla da instituição”, Ex.: O IFPE Campus de Garanhuns/PE, será, “GWT-IFPEGUS”. Para outro exemplo confira a Figura 31. Ø IP – Aqui é inserido o endereço IP que será destinado ao GWT. ESTE IP DEVE SER PÚBLICO. Ø Máscara – Máscara de Rede do endereço IP. Ø Gateway – É o endereço IP do Gateway da instituição. Ø NTP1 e NTP2 – Utilizar respectivamente os mesmos da imagem (ntp.pop-sc.rnp.br e ntp.cais.rnp.br) Ø DNS Resolver1 e DNS Resolver 2 – Caso a instituição possua servidor de DNS, ou tenha algum que deseje apontar, inserir nesses campos. Esses DNS´s devem ser capazes de resolver zonas de ENUM. Ø Domínio – O endereço ao qual o GWT pertence. Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Configurações”.


20

ANEXO


Neste momento, após efetuado os passos acima, devemos configurar o firewall para que não percamos o acesso ao servidor, já que estamos na rede da configuração inicial e alteramos para o IP público onde foi solicitado.

2.2.1.1.

Configurações -> Firewall

O início da configuração do GWT será feita pelo Firewall, pois vamos precisar inserir o IP da máquina que fará a gerência do GWT. Se fizermos alguma alteração de IP antes de configurarmos a gerência, poderemos perder o acesso ao GWT. No lado esquerdo da tela no menu “Configurações” clique na opção Firewall para acessar suas configurações. Role a página até o final e localize a área que contém “Rede de Gerência” (Figura 33).

Figura 32

Observe na Figura 33, que o IP 10.255.255.0, está cadastrado, e deve permanecer assim até a finalização da configuração, pois ele permitirá acesso a esta rede caso algo saia errado. Você deve removê-la em uma segunda etapa.

Figura 33

Agora inclua as demais redes de onde você poderá realizar manutenção no GWT (Acesso HTTP e HTTPS), clique no botão

depois no campo onde deve digitar o endereço IP, seguindo o exemplo, digite o IP da máquina


21

ANEXO


que fará o acesso ao GWT, concluindo clique no botão “Salvar” e depois em “Aplicar Configurações” (Figura 33). Na área “Ações”, ainda na página do Firewall(Figura 34), é onde serão fornecido os IPs que poderão enviar mensagens SIP ao GWT (no caso SRC ou SRL). Se o ambiente estiver conectado ao SRL, somente esses IPs são necessários. Após Configurar o firewall revisando os parâmetros de sua instituição, clique em Salvar e depois Aplicar.

Figura 34

2.2.1.2.

Configurações -> Aplicar Configurações

Após configurar o ambiente, é necessário aplicar as configurações do sistema, para que todas as alterações surtam efeitos.

Figura 35

Ø Configurações de Sistema: quando selecionada, aplica as configurações que foram feitas no que diz respeito ao sistema, como alterações nas guias, Instituições, Sistema, Gerência. Ø Configurações de Asterisk (TDM, ENUM, Proxy SIP): quando selecionada, aplica as configurações que foram feitas no que diz respeito ao GWT e seus serviços. Marque as duas caixas de opção (“Configurações de Sistema” e “Configurações de Asterisk” e clique no botão “Aplicar configurações selecionadas”. Lembre-se após esse procedimento, você perderá o acesso ao GWT.


22

ANEXO


Para obter novamente o acesso ao GWT, você terá que reconfigurar a rede do seu S.O de acordo com o configurado com os passos anteriores. Neste momento é necessário entrar em contato com o Suporte do FONE@RNP, para que seja liberado o IP do GWT (IP público) nos servidores de atualização do serviço, e assim prosseguir com a instalação.

2.2.1.3.

Atualizando o GWT.

Nesta nova versão do Fone@RNP foi adicionado o recurso de “Atualizações”, onde com apenas alguns cliques é possível atualizar tanto o CORE do GWT quanto a sua interface WEB. Basta ter alguma atualização disponível e executar a rotina e todo o seu GWT estará atualizado.

Figura 36

No menu “Configurações” do lado esquerdo da página, clique na opção “Sistema”, conforme Figura 36, se houver alguma atualização a guia “Atualizações” estará ativa, depois clique em “Atualizar Aplicações”, aguarde. Depois clique na guia “Ações” e clique em “Reiniciar o Servidor”. c) Guia Gerência Nesta tela é possível definir comunidades SNMP de Read-Only para gerência do ambiente, desviar logs para um servidor centralizado e ainda definir um servidor para envio de e-mails. O servidor de e-mail permite realizar relay de forma autenticada. Para desabilitar o relay para um syslog externo, forneça o endereço 127.0.0.1.


23

ANEXO


Figura 37

Normalmente nessa tela apenas o item SMTP é alterado, e inserido o servidor de SMTP caso a instituição possua. d) Guia TDM É uma sigla em inglês de Time Division Multiplexing – TDM é um tipo de multiplexação, que permite transmitir simultaneamente vários sinais dentro do mesmo meio de transmissão, canal de comunicação, possui um tempo próprio e definido de uso da banda para transmissão. Esta é uma das configurações mais importantes, onde serão definidos os prefixos da instituição e como ele realizará seu encaminhamento interno no GWT. Na área “Telefonia convencional”, o técnico deve inserir informações sobre o acesso de telefonia atual da instituição.


24

ANEXO


Figura 38

Ø Código do País: Insira o código de seu país. Não é necessário incluir o sinal ‘+’. Digite 55 para Brasil. Ø DDD: Deve ser preenchido como código de área da localidade da instituição cliente. Ø Prefixo: São os 4 primeiros dígitos do número telefônico da instituição. Por exemplo, a RNP-RJ possui o número 55 21 2102-9660. O prefixo é 2102. Ø Código da Operadora: é o CSP, o Código de Seleção da Prestadora. Ex.: 87 no interior de Pernambuco. Ø Linha Externa: Se existe algum número programado, para ser digitado para acessar a PSTN. Ø Ramal PBX Inicial e Final: Informações da faixa de ramal PABX convencional, onde ele encaminhará as chamadas recebidas para o tronco conectado ao PABX. Na área intitulada “VoIP”, o técnico deve preencher com informações recebidas da RNP e com informações arbitradas pelo próprio cliente quando do planejamento do serviço. Área VoIP Ø Prefixo: São os 4 primeiros dígitos (do total de 8 dígitos) dos números de telefones virtuais. Esses prefixos são informados pela RNP ao cliente durante a adesão e são válidos APENAS dentro do serviço Fone@RNP. Ø Ramal Inicial: São os 4 últimos dígitos (do total de 8 dígitos) que especificam o primeiro ramal do intervalo que o cliente deseja utilizar como números virtuais. Esses números são determinados pelo administrador do VoIP na instituição.


25

ANEXO


Ø Ramal Final: São os 4 últimos dígitos (do total de 8 dígitos) que especificam o primeiro ramal do intervalo que o cliente deseja utilizar como números virtuais. Esses números são determinados pelo administrador do VoIP na instituição. Ø Ramal Padrão de Saída: é o número que será apresentado como origem das chamadas feitas pela instituição. Ø Ramal da URA: É o ramal que deve ser discado para acesso ao sistema de telefonia IP, utilizado no fone versão 2008. Está presente aqui para fins de compatibilidade entre as versões do fone. Área externa Ø Valor do Minuto: Valor estimado do custo do minuto de uma chamada telefônica. Utilizado para cálculo aproximado da economia. Os Botões de período de contabilização são utilizados para definir o intervalo de tempo que se deseja apresentar a estimativa de economia. e) Guia ENUM ENUM significa em inglês Eletronic Number Mapping (Mapeamento Eletrônico de Números). O ENUM conecta um número de telefone a um endereço da Internet (URI) que é publicado no sistema de resolução de nomes, o DNS. O proprietário de um número ENUM pode, portanto, publicar para onde uma chamada deve ser reencaminhada através de uma entrada DNS.

Figura 39

O GWT utiliza mais de uma árvore ENUM em sua lógica interna para encaminhamento das chamadas. Nesta guia, deve-se definir quais tabelas ENUM o GWT irá consultar para verificar se existe rota IP para o numero discado. Caso o GWT esteja conectado ao SRL, deverá ser habilitada a tabela local para ativar a consulta de rotas do SRL criadas pela instituição. Ative todas as tabelas de pesquisa. Clicando em “Selecionar” (Figura 39) em todas as opções. Só ative a tabela ‘Local’ se estiver utilizando o SRL. Em seguida, clique em “Salvar as Alterações” (Figura 40).


26

ANEXO


Figura 40

f)

Guia Proxy Sip Define as informações referentes ao GWT e IPs do SIP-Router (Central ou Local), Figura 41.

Figura 41

Ø Realm VoIP: Colocar o voip realm da instituição: ex: ufsc.br ou voip.ufsc.br Ø IP do Gateway: Endereço IP no qual o GWT irá escutar. Esse endereço deve ser o mesmo fornecido da Guia Sistema, campo IP (Figura 35). Ø Porta do Gateway: Recomenda-se deixar a padrão: 5071 Ø IP SIP Router: Colocar os endereços do SRL ou SRC, de acordo com a topologia escolhida. g) Guia Serviços Habilitados Para, iniciar um serviço basta clicar em “Selecionar” e para parar clique em “Cancelar”.

Figura 42


27

ANEXO


Habilite todos os serviços para verificação das pendências. SÓ NÃO ATIVE O FIREWALL NESTE PONTO DA INSTALAÇÃO, PARA QUE NÃO HAJA A PERDA DE ACESSO AO GWT.

2.2.2. Configurações -> Aplicar Configurações Após configurar o ambiente, é necessário aplicar as configurações do sistema, para que todas as alterações surtam efeitos.

Figura 43

Ø Configurações de Sistema: quando selecionada, aplica as configurações que foram feitas no que se diz respeito ao sistema, como alterações nas guias, Instituições, Sistema, Gerência. Ø Configurações de Asterisk (TDM, ENUM, Proxy SIP): quando selecionada, aplica as configurações que foram feitas no que se diz respeito ao GWT e seus serviços. Marque as duas caixas de opção “Configurações de Sistema” e “Configurações de Asterisk”, e clique no botão “Aplicar configurações selecionadas”.

2.3. CONFIGURAÇÃO COMPLEMENTAR DO GWT 2.3.1. Configuração Das Placas E1 As placas TDM 220-E da Digium possuem duas interfaces digitais. Elas formam o equivalente a 48 linhas, quando configuradas para interfaces T1, ou o equivalente a 60 linhas, quando configuradas para interfaces E1. Desenvolvida para uso com sistemas de comunicações baseados no Asterisk. É uma placa PCI-Express. Há também a possibilidade de utilizar um módulo de cancelamento de eco para fornecer uma melhor qualidade nas chamadas em todos os canais. O fone@RNP adota o uso desse módulo.


28

ANEXO


Figura 44

Para configurar as placas clique do lado esquerdo do menu “Configurações” e clique em “Placas”, como está selecionado na Figura 44. OBS.: Caso o seu o painel de “Placas” em seu ambiente esteja semelhante ao da Figura 44 (Status em Vermelho), pode ser um cabo desconectado, as placas não configuradas corretamente ou o KOMMUTER DESATIVADO, para que saia deste estado e fique como a Figura 45, Status Verde, é necessário que o cabeamento esteja de acordo com o diagrama inicial da Figura 5, que a sinalização das placas estejam corretas e o KOMMUTER esteja ATIVADO.

Figura 45

Ø Após a execução da tarefa anterior, e se sua sinalização for ISDN, será mostrada a Figura 46 para a placa 1 ou Figura 47 caso tenha sido “editar” a placa 2. Os campos mostrados nas imagens seguem abaixo explicados (Os parâmetros dos campos nas imagens são apenas exemplos).


29

ANEXO


Figura 46

Figura 47

Tipo: Sinalização para a qual a placa será configurada, neste caso os parâmetros para ISDN. SwitchType: É o tipo de switch a ser configurado. Normalmente, no Brasil, quando o tipo do enlace é ISDN, utiliza-se o switchtype ‘EuroISDN’. Frame: Identifica o tipo de quadro do enlace, CCS Codificação por Canal Comum, ou CAS, Codificação por Canal Associado. Codificação: Identifica a codificação de linha do enlace. Normalmente, HDB3. CRC4: É o padrão para detecção de erros na transmissão. Esse campo identifica se o enlace utiliza ou não detecção de erros.


30

ANEXO


Sinalização: É o método de sinalização. “User” significa que o GWT está configurado como equipamento da premissa do cliente (CPE). Clock: Identifica a fonte de clock para sincronização do enlace. Cancelamento de eco: Especifica se deve ser utilizado o cancelamento de eco. Canal de controle: Identifica o canal de controle para este enlace. Canais: Identifica os canais de voz desse enlace. Contexto: Identifica o contexto para onde devem ser encaminhadas as ligações que entram por este enlace. From-PBX(Figura 46) e From-PSTN(Figura 47) Após a execução da tarefa anterior e se sua sinalização for MFC/R2, será mostrada a Figura 48 para a placa 1 ou Figura 49 caso tenha sido “editar” a placa 2, os campos mostrados nas imagens seguem abaixo explicados. (Os parâmetros dos campos nas imagens são apenas exemplos).

Figura 48


31

ANEXO


Figura 49

Tipo: Sinalização para a qual a placa será configurada, neste caso os parâmetros para R2-Digital. Frame: Identifica o tipo de quadro do enlace, CCS Codificação por Canal Comum, ou CAS, Codificação por Canal Associado. Codificação: Identifica a codificação de linha do enlace. Normalmente, HDB3. CRC4: É o padrão para detecção de erros na transmissão. Esse campo identifica se o enlace utiliza ou não detecção de erros. Variação: O padrão R2-Digital possui variações que são adotadas diferentemente por diversos países. No Brasil, a variação utilizada é a MFC-5C. Max ANI: Automatic Number Identification - Número máximo de dígitos que identifica o chamador. Max DNIS: Dialed Number Identification Service – Número máximo de dígitos que identifica o número chamado. Get ANI First: Especifica se este PABX espera receber primeiro a informação de ANI. Categoria: Identifica a categoria do assinante. Normalmente, ‘national subscriber’. Skip Category: Identifica se o GWT deve desconsiderar a categoria informada. Normalmente, não. Double Answer: Identifica se o PABX deve fazer atendimento duplo, comum para evitar chamadas a cobrar. Se a instituição deseja receber chamadas à cobrar, escolha ‘não’. Forced Release: Indica que a ligação deve ser forçadamente desconectada, imediatamente após o desligamento.


32

ANEXO


Charge Calls: Usado para informar a outra parte da ligação se deve aceitar ou não chamadas à cobrar. Normalmente é indiferente para as operadoras, mas é útil para alguns PABX mais antigos. Collect Calls: Indica se é permitido receber chamadas à cobrar. Depende de cada instituição. Immediate Accept: Esta função permite desconsiderar o uso dos sinais de grupo B/II e ir diretamente para o estado de ligação aceita para chamadas entrantes. MFBACK Timeout: Valor, em milisegundos, do tempo limite para o sinal MF de resposta. Pulse Timeout: Valor, em milisegundos, para o tempo limite do pulso de medição. Os pulsos de medição são enviados por algumas operadoras para fins de bilhetagem. Entretanto, esse pulso pode ser confundido com o sinal de desligamento (hangup). Idle Bits: Especifica o padrão de bits que representa ‘canal livre’ para determinada linha. Log/Debug: Habilita ou desabilita mensagens de debug para esta interface. Clock: Usado para sincronização da linha. Especifica se o equipamento é a referência de clock ou se segue a referência de clock de seu par, do outro lado do enlace. Cancelamento de eco: Especifica se ativa ou não o uso do hardware de cancelamento de eco. Canal de controle: Especifica o canal de controle do enlace. Canais: Especifica quais são os canais de voz do enlace. Contexto: Indica o contexto para onde serão encaminhadas as ligações que entram por este enlace. FromPBX(Figura 48) e From-PSTN(Figura 49)

Como solicitado anteriormente, observe na Figura 44, que existem duas Interfaces. Para configurar cada interface por vez clique no botão “Editar”, e irá abrir a tela de configuração, conforme Figura 46, se o tipo do sinal for ISDN. Se for sinal MFC/R2 a tela será como a Figura 48. Após cada configuração clique no botão “Salvar” e depois execute todo o procedimento do item 2.2.2 Aplicar Configurações.


33

ANEXO


3. BACKUP/RESTORE No Fone@RNP distribuição 2012, foi desenvolvida uma ferramenta para criação de arquivos de backup, ou seja, será possível após finalizar TODAS as configurações do GWT, criar um arquivo de backup, esta ferramenta está no menu “Configurações” do lado esquerdo da página, na opção “Backup” (Figura 50). Além de criar, é possível restaurar a configuração importando as informações de um arquivo backup. Por que é importante manter uma cópia de segurança (Backup) das configurações? Porque caso aconteça alguma falha de hardware no servidor ou por algum motivo você tenha que troca-lo, os dados de configuração de seu ambiente podem ser facilmente restaurados, otimizando o tempo de instalação e configuração.

Figura 50

Crie um arquivo de backup, clicando no botão “Backup do arquivo M4”, e escolha onde irá guardar o arquivo. Caso seja necessário restaurar as configurações, basta clicar no botão “Escolher arquivo” e apontar onde o arquivo M4 estaria e em seguida clicar no botão “Enviar”.


34

ANEXO


4. MONITORAMENTO Assim como na Figura 26, no início deste documento, foi mostrado na tela com o módulo Gateway (Canto superior direito da página) ativado. Estamos voltando para explicar justamente que é possível monitorar o sistema. Nesta página serão apresentados erros de não conformidade com algum serviço monitorado, que merece atenção e devem ser corrigidos para evitar problemas de disponibilidade ou segurança.

Figura 51

Clique no módulo “Gateway” (canto superior direito da página) para abrir a página de monitoramento (Figura 51). Observe que quando executado a ação anterior, no lado esquerdo da página nas opções do menu “Monitoramento”, podemos escolher “TDM” ou “Canais”. Clique na opção “TDM”


35

ANEXO


Figura 52

Quando clicado na opção “TDM” na Figura 52 mostra que é possível monitorar as interfaces (placa 1 e placa 2) conectadas na PABX e PSTN, informando visualmente um status das interligações. Na Figura 53 mostra como ficará a tela após tudo configurado corretamente, como exemplo utilizamos a página do IFSCLAJES.

Figura 53

Clique no botão “Detalhes”

Ao clicar no botão “Detalhes”, sua página deve ficar semelhante à Figura 54. Onde são exibidos todos os canais de comunicação e seu status.


36

ANEXO


Figura 54

É possível também visualizar o que está sendo trafegado no GWT, no menu “Configurações”, clicando em Canais, depois em “Detalhes”

, e será exibida uma tela semelhante à Figura 55, neste exemplo usamos o

exemplo do IFSC-LAJES onde os canais estão sendo monitorados. Observe que existem duas ligações em andamento.

Figura 55


37

ANEXO


5. CONTABILIZAÇÃO No menu contabilização, existem as opções que nos dão relatórios precisos de como está o comportamento do serviço Fone@RNP no GWT. Neste menu existem as opções: Estatísticas, Chamadas Completadas, Não Completadas e Mais Chamados (Números mais discados).

5.1. ESTATÍSTICAS Nesta opção “Estatísticas” do menu “Contabilização” é possível acompanhar a observar graficamente as estatísticas das ligações do ambiente. Abrange ainda estatística de “Estimativa de Economia” e exibe os valores em moeda corrente, observe a Figura 56.

Figura 56


38

ANEXO


5.2. COMPLETADAS Na opção é mostrado o CDR (Call Detail Record ou Registro de Detalhes da Chamada - registro de uma ligação(conexão) telefônica contendo os detalhes dessa ligação nesta conexão) das chamadas completadas pelo GWT. Esta tela também exibe o tipo de terminal utilizado para fazer essa ligação se foi IP, PSTN ou PaBX, observe a Figura 57.

Figura 57

5.3. NÃO COMPLETADAS Mostra o CDR das chamadas não completadas pelo GWT (Figura 58), informa o motivo por que não completou e com o tipo de terminal utilizado para realizar a chamada IP, PSTN ou PaBX. Lembrando que o “não completar” nem sempre é um problema. Exemplificando, uma ligação para um número ocupado gera um CDR de não completado.


39

ANEXO


Figura 58

5.4. MAIS CHAMADOS Em “Mais Chamados” do menu “Monitoramento” o administrador tem acesso as informações de uma base de reputação do GWT, onde fornece informações sobre os destinos, ela foi desenvolvida, para ajudar a melhorar a experiência do usuário em caso de falhas em alguma entrega através de rede IP (Figura 59).


40

ANEXO


Figura 59


41

Guia de uso do SNMP - Fone@RNP 2014

Documentação de uso do protocolo SNMP nas implementações do FONE (2012 e 2014)

FONE@RNP DISTRIBUIÇÃO 2012/2014

Guia de uso do SNMP - Fone@RNP 2014

HISTÓRICO DO DOCUMENTO VERSÃO 1.0

DATA 12/11/2014

1.0

19/11/2014

1.0

24/11/2014

1.0

25/11/2014

Autores do Documento: - Edison Melo - Estefania Borm - Guilherme Rhoden - Murilo Vetter

Equipe de Desenvolvimento: - Murilo Vetter (PoP-SC) - Guilherme Rhoden (PoP-SC) - Paulo Brandtner(PoP-SC) - Luis Cordeiro(PoP-SC)

Coordenação Projeto: - Edison Melo (PoP-SC/UFSC) - Hélder Vitorino (RNP) - Alex Galhano (RNP)

RESPONSÁVEL Guilherme Eliseu Rhoden (PoP-SC) Guilherme Eliseu Rhoden (PoP-SC) Guilherme Eliseu Rhoden (PoP-SC) Guilherme Eliseu Rhoden (PoP-SC)

OBSERVAÇÃO Elaboração da documentação Elaboração da documentação Elaboração da documentação Versão Final

Guia de uso do SNMP - Fone@RNP 2014 ÍNDICE HISTÓRICO DO DOCUMENTO......................................................................................................................................... 2 1.

Introdução ............................................................................................................................................................. 5

2.

Habilitando na Interface gráfica .................................................................................................................... 5

3.

Testando o acesso ............................................................................................................................................... 6

4.

Informações da MIB-2 ....................................................................................................................................... 6

5.

Informações da SNMP Extend ......................................................................................................................... 7

6.

Informações da MIB Fone@RNP .................................................................................................................... 8

Guia de uso do SNMP - Fone@RNP 2014 ÍNDICE DE FIGURAS Figura 1 - Exemplo de configuração do SNMP para a PBX-IP ........................................................................ 5

Guia de uso do SNMP - Fone@RNP 2014 1. Introdução Este guia descreve as formas de uso do SNMP para os componentes do fone@RNP. Em linhas gerais todos os componentes do fone@RNP implementam suporte a MIB-2 através do daemon Net-SNMP. Alguns componentes possuem variações dessas implementações, como no caso do GWT, que integra o suporte de SNMP presente no Asterisk. Além disso, foi criado para o fone@2012 um agente estendido através do NETSNMP-EXTEND-MIB, que também existe no fone@2014, implementando funções básicas de monitoramento não presentes na MIB-2 que são importantes para o Fone@RNP.

No fone@2014, foi desenvolvida uma MIB para gerenciar com maiores detalhes a aplicação do fone. Disponível até 12/11/2014 para o GWT 2.0, mas está no roadmap de implementação até o final do projeto para os demais componentes.

2. Habilitando na Interface gráfica O Acesso ao SNMP é realizado através de uma comunidade (SNMP COMMUNITY) de somente leitora (RO) que possui restrições de acesso através de um IP ou rede de origem. Para poder utilizar o SNMP, inicialmente é necessário habilitar na interface gráfica módulo de Configurações, menu Gerência, o protocolo SNMP, passando a Comunidade e a Rede de gerência. Todos os componentes (SRC, SRL, PBX-IP Corporativa, PBX-IP Acadêmica, GWT 1.0 e 2.0) possuem uma tela semelhante onde é possível definir qual é a comunidade SNMP e rede para onde o acesso é permitido.

Figura 1 - Exemplo de configuração do SNMP para a PBX-IP

OBS:É possível configurar até três comunidades.

Guia de uso do SNMP - Fone@RNP 2014 OBS:Certifique-se que o firewall da aplicação está liberando o acesso na porta UDP/161 com origem na rede de gerência especificada.

3. Testando o acesso Para validar o acesso SNMP através de um mib browser ou cliente snmp. Neste exemplo será utilizado cliente de linha de comando do Linux para o NETSNMP. snmpget -v2c -c COMUNIDADE ENDEREÇO_IP OID

Exemplo:

snmpget -v2c -c teste 10.255.255.1 1.3.6.1.2.1.1.5.0 Exemplo saída: iso.3.6.1.2.1.1.5.0 = STRING: "gwt1-0"

4. Informações da MIB-2 O NetSNMP fornece a possibilidade de obter diversos dados do sistema operacional. Os principais estão listados abaixo. OID REFERÊNCIA PARA SNMPWALK

Função

.1.3.6.1.4.1.2021.2.1

Monitoramento de Processos do Sistema Operacional Gatilhos de não funcionamento de processos

.1.3.6.1.4.1.2021.2.1.100

do sistema operacional Monitoramento

.1.3.6.1.4.1.2021.9.1

do

sistema

de

Armazenamento (HD) Gatilhos de Espaço utilizado do sistema de

.1.3.6.1.4.1.2021.9.1.100

Armazenamento (HD)

.1.3.6.1.4.1.2021.10.1.3

Carga Média do Sistema

.1.3.6.1.4.1.2021.11

Uso da CPU

.1.3.6.1.4.1.2021.4

Monitoramento da Memória

Exemplo:

snmpwalk -v2c -c teste 10.255.255.1 .1.3.6.1.4.1.2021.2.1 Exemplo saída: iso.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 iso.3.6.1.4.1.2021.2.1.1.2 = INTEGER: 2

[6]

Guia de uso do SNMP - Fone@RNP 2014 iso.3.6.1.4.1.2021.2.1.1.3 = INTEGER: 3 iso.3.6.1.4.1.2021.2.1.1.4 = INTEGER: 4 iso.3.6.1.4.1.2021.2.1.1.5 = INTEGER: 5 iso.3.6.1.4.1.2021.2.1.1.6 = INTEGER: 6 iso.3.6.1.4.1.2021.2.1.2.1 = STRING: "apache2" iso.3.6.1.4.1.2021.2.1.2.2 = STRING: "sshd" iso.3.6.1.4.1.2021.2.1.2.3 = STRING: "syslog-ng" iso.3.6.1.4.1.2021.2.1.2.4 = STRING: "mysqld" iso.3.6.1.4.1.2021.2.1.2.5 = STRING: "master" iso.3.6.1.4.1.2021.2.1.2.6 = STRING: "asterisk" iso.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 iso.3.6.1.4.1.2021.2.1.3.2 = INTEGER: 0 (...)

5. Informações da SNMP Extend O Agente NET-SNMP possibilita a extensão de seu agente de forma fácil através de sua MIB Extendida (NETSNMP-EXTEND-MIB). No Fone@RNP existe a seguinte implementação: OID

Função

Retorno Esperado

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."firewall"

Verificar se o FIREWALL está 0 – Inativo operacional

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."proc-ntpd"

Verificar

se

1 - Ativo o

NTP

está 0 – Inativo

operacional

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."proc-sshd”

Verificar

se

1 - Ativo o

SSH

está 0 – Inativo

operacional

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."proc-bind9”

Verificar

se

1 - Ativo o

BIND

está 0 – Inativo

operacional

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."proc-snmpd”

1 - Ativo

Verificar se o SNMPD está 0 – Inativo operacional

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."proc-mysqld"

1 - Ativo

Verificar se o Banco de Dados 0 – Inativo MySQL está operacional

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."proc-apache2"

1 - Ativo

Verificar se o servidor Web 0 – Inativo Apache sendo executado

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."proc-asterisk"

1 - Ativo

Verificar se processo Asterix 0 – Inativo está sendo executado

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."asterisk-komuter" NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."asterisk-tdm1-pbx"

1 - Ativo

Verificar o estado operacional 0 – Inativo do komuter.

1 - Ativo

Estado da E1 conectada na PBX

0 – Down 1 - UP

[7]

Guia de uso do SNMP - Fone@RNP 2014 NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."asterisk-tdm2-pstn”

Estado da E1 conectada na PBX

0 – Down 1 - UP

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."fone-enum-resolving"

Zona

ENUM

privada

do 0 – Down

Fone@RNPestá operacional

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."asterisk-sip-udp-5071”

Asterisk rodando na porta UDP 0 – Inativo 5071

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."asterisk-calls-processed”

1 - UP

Número

1 - Ativo de

chamadas Número

processadas

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."asterisk-channels-active”

Número de canais ativos

NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."asterisk-

Canais com algum problema Listagem

channelsproblem"

identificado

Número

canais problema

Para poder utilizar o NET-SNMP-EXTEND é necessário colocar referência entre aspas simples, conforme exemplo: snmpget -v2c -c fone-rnplocalhost'NET-SNMP-EXTENDMIB::nsExtendOutput1Line."firewall"' Para validar, é possível testar simplesmente habilitando ou desabilitando o firewall para verificar o resultado em um ambiente de homologação. root@gwt-v12:# /etc/init.d/firewall start root@gwt-v12:# snmpget -v2c -c fone-rnplocalhost 'NET-SNMP-EXTENDMIB::nsExtendOutput1Line."firewall"' NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."firewall" = STRING: 1

root@gwt-v12:# /etc/init.d/firewall stop Parando Firewall.. root@gwt-v12: # snmpget -v2c -c fone-rnplocalhost 'NET-SNMP-EXTENDMIB::nsExtendOutput1Line."firewall"' NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."firewall" = STRING: 0

6. Informações da MIB Fone@RNP No roadmap de desenvolvimento (Esforço 1) está previsto a implantação no GWT 2.0 (Fone 2014). Os demais componentes serão implementados de acordo com o plano de desenvolvimento acordado com a RNP.

[8]

dos com

Guia de uso do SNMP - Fone@RNP 2014 OID

Função

Retorno Esperado

.1.3.6.1.4.1.15996.100

Árvore do Fone@RNP

String

.1.3.6.1.4.1.15996.100.1

Sub-árvore para o SRC

String

.1.3.6.1.4.1.15996.100.2

Sub-árvore para o SRL

String

.1.3.6.1.4.1.15996.100.3

Sub-árvore para o GWT

String

.1.3.6.1.4.1.15996.100.3.1

Versão dos Componentes

String

.1.3.6.1.4.1.15996.100.3.1.1

Versão Core

String

.1.3.6.1.4.1.15996.100.3.1.2

Versão Web

String

.1.3.6.1.4.1.15996.100.3.2

SIP Peers

String

.1.3.6.1.4.1.15996.100.3.2.1

Status Administrativo

String

.1.3.6.1.4.1.15996.100.3.2.1.1

SipRouter1

Inteiro 0 – Inativo 1 - Ativo

.1.3.6.1.4.1.15996.100.3.2.1.2

SipRouter2


.1.3.6.1.4.1.15996.100.3.2.2

Status Operacional

String

.1.3.6.1.4.1.15996.100.3.2.2.1

SipRouter1


.1.3.6.1.4.1.15996.100.3.2.2.2

SipRouter2


.1.3.6.1.4.1.15996.100.3.2.3

SIP Peers Endereço IP

String

.1.3.6.1.4.1.15996.100.3.2.3.1

IP SipRouter1

String

.1.3.6.1.4.1.15996.100.3.2.3.2

IP SipRouter2

String

.1.3.6.1.4.1.15996.100.3.2.4

SipRouter Porta

String

.1.3.6.1.4.1.15996.100.3.2.4.1

IP SipRouter1

Inteiro Padrão 5060

.1.3.6.1.4.1.15996.100.3.2.4.2

IP SipRouter2

[9]

Inteiro

Guia de uso do SNMP - Fone@RNP 2014 Padrão 5060

.1.3.6.1.4.1.15996.100.3.3

Informação sobre interfaces TDM

String

.1.3.6.1.4.1.15996.100.3.3.1

Retorna o descritivo das placas E1

String

.1.3.6.1.4.1.15996.100.3.3.2

Retorna o número de Interfaces E1

Inteiro Padrão 2

.1.3.6.1.4.1.15996.100.3.3.3.1

Informações da E1 – tronco 1

string

.1.3.6.1.4.1.15996.100.3.3.3.1.0

Estado administrativo da E1 – n1


.1.3.6.1.4.1.15996.100.3.3.3.1.1

Estado operacional da E1 – n1


.1.3.6.1.4.1.15996.100.3.3.3.1.2

Contexto de Entrada

String Padrão from-pbx

.1.3.6.1.4.1.15996.100.3.3.3.1.3

Retorna o tipo de sinalização

String R2 ou ISDN

.1.3.6.1.4.1.15996.100.3.3.3.1.4

Fonte de Clock

Inteiro 0 – não gera clock 1 – gera clock

.1.3.6.1.4.1.15996.100.3.3.3.1.5

Informação sobre Canais

String

.1.3.6.1.4.1.15996.100.3.3.3.1.5.1

Número de canais na placa 1

Inteiro Padrão 30

.1.3.6.1.4.1.15996.100.3.3.3.1.5.2

Número de canais em uso na placa 1

Inteiro

.1.3.6.1.4.1.15996.100.3.3.3.2


string

.1.3.6.1.4.1.15996.100.3.3.3.2.0



.1.3.6.1.4.1.15996.100.3.3.3.2.1



[ 10 ]

Guia de uso do SNMP - Fone@RNP 2014 .1.3.6.1.4.1.15996.100.3.3.3.2.2

Contexto de Entrada


.1.3.6.1.4.1.15996.100.3.3.3.2.3

Retorna o tipo de sinalização da E1 – n2

String R2 ou ISDN

.1.3.6.1.4.1.15996.100.3.3.3.2.4

Fonte de Clock


.1.3.6.1.4.1.15996.100.3.3.3.2.5


String

.1.3.6.1.4.1.15996.100.3.3.3.2.5.1


Inteiro Padrão 30

.1.3.6.1.4.1.15996.100.3.3.3.2.5.2


Inteiro

.1.3.6.1.4.1.15996.100.3.3.3.3


string

.1.3.6.1.4.1.15996.100.3.3.3.3.0



.1.3.6.1.4.1.15996.100.3.3.3.3.1



.1.3.6.1.4.1.15996.100.3.3.3.3.2

Contexto de Entrada


.1.3.6.1.4.1.15996.100.3.3.3.3.3


String R2 ou ISDN

.1.3.6.1.4.1.15996.100.3.3.3.3.4

Fonte de Clock


.1.3.6.1.4.1.15996.100.3.3.3.3.5


String

.1.3.6.1.4.1.15996.100.3.3.3.3.5.1


Inteiro Padrão 30

.1.3.6.1.4.1.15996.100.3.3.3.3.5.2


Inteiro

.1.3.6.1.4.1.15996.100.3.3.3.4


string

.1.3.6.1.4.1.15996.100.3.3.3.4.0


Inteiro

[ 11 ]

Guia de uso do SNMP - Fone@RNP 2014 0 – Inativo 1 - Ativo .1.3.6.1.4.1.15996.100.3.3.3.4.1



.1.3.6.1.4.1.15996.100.3.3.3.4.2

Contexto de Entrada


.1.3.6.1.4.1.15996.100.3.3.3.4.3


String R2 ou ISDN

.1.3.6.1.4.1.15996.100.3.3.3.4.4

Fonte de Clock


.1.3.6.1.4.1.15996.100.3.3.3.4.5


String

.1.3.6.1.4.1.15996.100.3.3.3.4.5.1


Inteiro Padrão 30

.1.3.6.1.4.1.15996.100.3.3.3.4.5.2


.1.3.6.1.4.1.15996.100.3.4

KOMMUTER - Informações sobre o String

Inteiro

dispositivo de resiliência nível 1 .1.3.6.1.4.1.15996.100.3.4.1

Instalado


.1.3.6.1.4.1.15996.100.3.4.2

Número Serial

String

.1.3.6.1.4.1.15996.100.3.4.3

Estado Administrativo


.1.3.6.1.4.1.15996.100.3.4.4

Estado Operacional


.1.3.6.1.4.1.15996.100.3.5

Descrição dos Serviços Padrões do String Sistema Operacional

.1.3.6.1.4.1.15996.100.3.5.1

Apache

[ 12 ]

String

Guia de uso do SNMP - Fone@RNP 2014 .1.3.6.1.4.1.15996.100.3.5.2

MySQL

String

.1.3.6.1.4.1.15996.100.3.5.3

NTP

String

.1.3.6.1.4.1.15996.100.3.5.4

Bind/Named

String

.1.3.6.1.4.1.15996.100.3.5.5

Firewall

String

.1.3.6.1.4.1.15996.100.3.5.6

SSH

String

.1.3.6.1.4.1.15996.100.3.5.7

SNMPD

String

.1.3.6.1.4.1.15996.100.3.5.8

Syslog

String

.1.3.6.1.4.1.15996.100.3.6

Estado administrativo dos Processos do String Sistema

.1.3.6.1.4.1.15996.100.3.6.1

Apache


.1.3.6.1.4.1.15996.100.3.6.2

MySQL


.1.3.6.1.4.1.15996.100.3.6.3

NTP


.1.3.6.1.4.1.15996.100.3.6.4

Bind/Named


.1.3.6.1.4.1.15996.100.3.6.5

Firewall


.1.3.6.1.4.1.15996.100.3.6.6

SSH


.1.3.6.1.4.1.15996.100.3.6.7

SNMPD


.1.3.6.1.4.1.15996.100.3.6.8

Syslog

Inteiro 0 – Inativo

[ 13 ]

Guia de uso do SNMP - Fone@RNP 2014 1 - Ativo

.1.3.6.1.4.1.15996.100.3.7

Estado Operacional dos Processos do String Sistema

.1.3.6.1.4.1.15996.100.3.7.1

Apache


.1.3.6.1.4.1.15996.100.3.7.2

MySQL


.1.3.6.1.4.1.15996.100.3.7.3

NTP


.1.3.6.1.4.1.15996.100.3.7.4

Bind/Named


.1.3.6.1.4.1.15996.100.3.7.5

Firewall


.1.3.6.1.4.1.15996.100.3.7.6

SSH


.1.3.6.1.4.1.15996.100.3.7.7

SNMPD


.1.3.6.1.4.1.15996.100.3.7.8

Syslog


.1.3.6.1.4.1.15996.100.3.8

Descrição dos processos Específicos do String Fone@RNP

.1.3.6.1.4.1.15996.100.3.8.1

Asterisk

String

.1.3.6.1.4.1.15996.100.3.8.2

Enum

String

[ 14 ]


Sistema de Reputação

.1.3.6.1.4.1.15996.100.3.9

Serviços Específicos do Fone@RNP – String

String

Status Administrativo .1.3.6.1.4.1.15996.100.3.9.1|gauge|adm

Asterisk

Inteiro

-asterisk

0 – Inativo 1 - Ativo

.1.3.6.1.4.1.15996.100.3.9.2|gauge|adm

Enum

Inteiro

-enum


.1.3.6.1.4.1.15996.100.3.9.3|gauge|adm


Inteiro

-reputacao


.1.3.6.1.4.1.15996.100.3.10

Serviços Específicos do Fone@RNP– String Status Operacional

.1.3.6.1.4.1.15996.100.3.10.1

Asterisk


.1.3.6.1.4.1.15996.100.3.10.2

Enum


.1.3.6.1.4.1.15996.100.3.10.3



.1.3.6.1.4.1.15996.100.3.11

Tabelas

ENUM

Privadas

do String

Fone@RNP– Descrição .1.3.6.1.4.1.15996.100.3.11.1

PBX

String

.1.3.6.1.4.1.15996.100.3.11.2

PSTN

String

.1.3.6.1.4.1.15996.100.3.11.3

FONE

String

.1.3.6.1.4.1.15996.100.3.11.4

LOCAL

String

.1.3.6.1.4.1.15996.100.3.11.5

LOCAL-PBX

String

[ 15 ]

Guia de uso do SNMP - Fone@RNP 2014 .1.3.6.1.4.1.15996.100.3.12

Tabelas

ENUM

Privadas

do String

Fone@RNP– Status Administrativo .1.3.6.1.4.1.15996.100.3.12.1

PBX


.1.3.6.1.4.1.15996.100.3.12.2

PSTN


.1.3.6.1.4.1.15996.100.3.12.3

FONE

1 - Ativo Inteiro 0 – Inativo

.1.3.6.1.4.1.15996.100.3.12.4

LOCAL


.1.3.6.1.4.1.15996.100.3.12.5

LOCAL-PBX


.1.3.6.1.4.1.15996.100.3.12.6

nrenum.net

1 - Ativo Inteiro 0 – Inativo 1 - Ativo

.1.3.6.1.4.1.15996.100.3.12.7

enum.redclara.net


.1.3.6.1.4.1.15996.100.3.13

Status operacional das Tabelas

.1.3.6.1.4.1.15996.100.3.13.1

PBX


.1.3.6.1.4.1.15996.100.3.13.2

PSTN


.1.3.6.1.4.1.15996.100.3.13.3

FONE


[ 16 ]


LOCAL


.1.3.6.1.4.1.15996.100.3.13.5

LOCAL-PBX


.1.3.6.1.4.1.15996.100.3.13.6

nrenum.net


.1.3.6.1.4.1.15996.100.3.13.7

enum.redclara.net


.1.3.6.1.4.1.15996.100.3.14

Versão das Tabelas – (Número Serial)

String

.1.3.6.1.4.1.15996.100.3.14.1

PBX

String

.1.3.6.1.4.1.15996.100.3.14.2

PSTN

String

.1.3.6.1.4.1.15996.100.3.14.3

FONE

String

.1.3.6.1.4.1.15996.100.3.14.4

LOCAL

String

.1.3.6.1.4.1.15996.100.3.14.5

LOCAL-PBX

String

.1.3.6.1.4.1.15996.100.3.14.6

nrenum.net

String

.1.3.6.1.4.1.15996.100.3.14.7

enum.redclara.net

String

.1.3.6.1.4.1.15996.100.3.15

Estatísticas de Chamadas

String

.1.3.6.1.4.1.15996.100.3.15.1

Chamadas Completadas

Inteiro

.1.3.6.1.4.1.15996.100.3.15.1.1

via IP

Inteiro

.1.3.6.1.4.1.15996.100.3.15.1.2

viaPSTN

Inteiro

.1.3.6.1.4.1.15996.100.3.15.2|string|#

Chamadas NãoCompletadas

String

via IP

Inteiro

viaPSTN

Inteiro

NaoCompletadas .1.3.6.1.4.1.15996.100.3.15.2.1|gauge| IP .1.3.6.1.4.1.15996.100.3.15.2.2|gauge| PSTN

.1.3.6.1.4.1.15996.100.3.16

Monitoramento de Rede (Em desenvolvimento previsão final

[ 17 ]

Guia de uso do SNMP - Fone@RNP 2014 2015)

[ 18 ]

Capítulo 10

Estatísticas


345

Instalando e Configurando o PBX-IP Do Fone@RNP

Recommend Documents