IPO500  Versão 5.0

A nova versão do IPO500 amplia a capacidade do equipamento e ressalta uma de suas principais características: Simplicidade. Outro fator ressaltado é a interoperabilidade, que advém do protocolo SIP, que é o padrão da indústria de Telefonia IP.

Na versão 5.0 o IPO500 deixa de ser uma Central IP e transforma-se de fato em uma plataforma de comunicação, um Communications Server, que implementa serviços avançados de comunicação IP, além de ser per si um media gateway de alta capacidade. As características de hibridização harmonizam-se com os serviços de comunicação IP.

Com um MTBF superior a 17 anos, sem partes móveis e capacidade de cooperação entre unidades distintas do IPO500, é possível construir um sistema de alta resiliência formando uma Community Network de Centrais IP. Com escalabilidade de 380 ramais em uma única central e capacidade de 500 usuários em uma rede de centrais, o IPO500 atinge com competência, simplicidade, efetividade e baixo custo de implementação uma extensa faixa de mercado, composto por empresas com 30 a 300 usuários em central única, compreendendo a maior faixa de espectro de mercado nacional.

A apresentação que se segue lista estas novas funcionlidades do IPO500.

Conteúdo

Introdução a Voz Sobre IP (VoIP). 4

Breve Histórico. 4

Alguns fundamentos chave. 5

A Importância das Telecomunicações. 6

O que é VoIP. 6

Como funciona o VoIP ?. 7

A conexão VoIP. 7

A Compressão da VOZ. 7

Protocolo de Transporte. 9

O Protocolo RTP. 9

O cabeçalho RTP. 10

O Protocolo RTCP. 12

FXS & FXO.. 13

Exemplo 1 – Conexão Gateway FXS. 13

Exemplo 2 – Conexão Gateway FXO.. 14

PSTN.. 15

Public switched Telephony Network Rede de Telefonia Publica Comutada. 15

POTS. 15

Plain Old Telephone Service Line. 15

ISDN.. 15

T1 ou E1. 16

Conhecendo as Operadoras. 17

Protocolos de Sinalização e Multimídia. 19

H.323. 19

O Protocolo SIP. 20

Componentes do SIP. 20

Requisições SIP: 20

SDP – Session Description Protocol 21

Respostas SIP: 21

Fluxo SIP. 21

Registro de Usuário (REGISTER). 22

Resposta do Servidor (200 OK). 23

Padrões SIP. 23

Introdução a Voz Sobre IP (VoIP)

Breve Histórico

A história da telefonia e a trajetória de uma tecnologia que atingiu um uso massivo, como nenhuma outra tecnologia é surpreendentemente muito recente quando comparada com a história da humanidade, e isto se apenas considerarmos o período que compreende o advento dos primeiros assentamentos agrícolas até os tempos atuais, o que cobre ao menos 10.000 anos de história. As primeiras tecnologias de voz vieram ao mundo por volta de 1870, embora pareça para nós que sempre tenham existido, sendo muito difícil imaginar o mundo sem o telefone, assim como sem televisão ou computador. Este período da história curiosamente coincide com o ápice dos movimentos nacionalistas e a consolidação das grandes nações, movimento que nos apresentou a guerra em escala industrial. Não devemos ter dúvidas, as tecnologias de comunicação e a telefonia contribuíram muito para as transformações radicais que a humanidade sofreu no último século.

Costuma-se atribuir a invenção do telefone ao escocês Alexander Graham Bell, embora tal paternidade tenha sido sempre contestada ao longo do tempo. Se for controversa a primazia da invenção, que na verdade deveu-se, para sermos justos, como conseqüência dos grandes movimentos inventivos de uma determinada época, graças ao esforço conjunto e competitivo entre diferentes cientistas e inventores, é correto atribuir-lhe a primazia por ter sido o primeiro a patentear a sua invenção. Seria correto também atribuir a Thomas Edison a co-autoria do aparelho e tecnologia que ele então patenteava.

Os primeiros equipamentos de telefonia não possuíam teclas para discagem, e com isto era necessário o operador do outro lado da linha para fazer a conexão, em um processo  que vemos nos filmes mais antigos, onde um operador conectava um  plug entre o chamador e o destinatário daquela ligação. O primeiro “PBX” foi criado em 1889, por Almon B. Strowger, juntamente com o primeiro telefone de discagem. O mais incrível de tudo isto é que, apesar do mais de um século nos separa da criação do telefone, em muitos lugares do Brasil, senão em sua maioria, o aparelho analógico que utilizamos incorpora praticamente os mesmos princípios e tecnologia dos telefones primordiais, o que denota o grande mérito daqueles inventores de outrora.

Recentemente, o maior avanço que experimentamos foi a adoção do tom de discagem digital, substituindo o pulso, possibilitando com isto a adoção dos serviços de Call e Contact Center, através dos quais nos comunicamos com bancos e outros serviços. Ainda assim, e apesar das centrais mais modernas incorporarem algum tipo de inteligência e a comunicação digital entre centrais, em nossos escritórios e residências ainda é bastante comum o uso em larga escala da telefonia analógica tradicional.

O motivo deste sucesso é que a telefonia atingiu um grau de confiabilidade e perfeição que chegou ao padrão de disponibilidade de 99.999%. É curioso observar como causa mortífera indignação o fato de o telefone ficar mudo por algumas horas, ainda que seja por uma única vez em vários anos, a indignação e o sangue subindo à cabeça.

 O fato é que nos acostumamos a entender o telefone como uma peça de tecnologia perfeita que não pode, não deve, e não irá nunca quebrar. Por outro lado, a indisponibilidade de água, ou o corte abrupto de energia elétrica, ou mesmo o atraso de aeronaves, engarrafamentos ou o “bolo” no dentista ou médico não causam a mesma indignação que um telefone mudo. Esta tecnologia atingiu aquilo que chamamos de “estado da arte”, acaba e pronto, e, portanto definitivo. Por isto, o senso comum acostumou-se com a noção de que não haveria nenhum motivo para substituí-la por outra.

Por que substituir uma “tecnologia perfeita” por uma alternativa? Afinal, porque usar o VoIP se estamos falando do “estado da arte em tecnologia” ? Uma tecnologia entrante, como o VoIP não vai, com certeza propiciar o grau de disponibilidade de 99.999% que já era obtido com a tecnologia clássica e mais do que centenária. Então, porque usar o VoIP ?  Há vários motivos, e não é somente devido ao custo. O fato é que vivenciamos uma nova revolução tecnológica, que é aquela representada pela comunicação total, que veio para alterar radicalmente usos e costumes.

Alguns fundamentos chave

É importante entender que freqüências nosso ouvido é capaz de perceber. Teoricamente, uma pessoa dotada de boa capacidade de audição e que não tenha sofrido redução de sua sensibilidade auricular devido à idade ou algum trauma é capaz de perceber os sons na faixa de freqüência que compreende de 20hz a 20KHZ (20.000 Hz). Somos capazes, no entanto, de produzir sons audíveis apenas na faixa de 50hz para cima, ao passo que a maior parte da energia sonora que produzimos através do nosso aparelho vocal está concentrada na faixa de 300 Hz a 3 kHz. Por este motivo, entre outros, determinou-se que a faixa compreendida entre 300hz e 3.4kHz é a que concentra a maior parte da inteligibilidade e informação relativa ao reconhecimento da voz.

Desta forma, os sistemas de telefonia foram projetados para utilizar a faixa entre 300 Hz e 3.4 kHz, o que é o suficiente para manter uma conversação de qualidade e possibilitando o emprego de tecnologia mais eficiente para lidar com esta faixa de freqüência.

A maioria dos telefones analógicos que conhecemos emprega um sistema conhecido como “loop-disconect”, ou “loop start”, conectando o sinal de voz em duas direções, usando dois fios (two-wire), transportando eletricamente a informação correspondente aos dígitos discados e a voltagem de campainha. Uma voltagem de 48 v sobre o par de fios é empregada para alimentar o telefone, e por isto não o ligamos na tomada – o sem fio é outra estória, e monitorar a “tirada do gancho”, “colocação no gancho” e pulsar a atividade de discagem.

Para iniciar uma chamada, o usuário levanta o fone, ação esta que fecha um switch no telefone e faz a corrente elétrica fluir em loop, motivo pelo qual chamamos este sistema de “loop start”. A corrente gerada é detectada na Central e  fornece um tom para a linha, tom este que sinaliza ao usuário que agora ele pode iniciar a discagem.

Atualmente o método mais empregado é baseado em DTMF. Neste sistema, cada número é representado por dois tons, associados a um grupo de freqüências alto (1209hz, 1336hz e 1447hz), e a um grupo de freqüências baixas (697hz, 770hz, 852hz e 941hz). Estes tons são transmitidos simultaneamente, por um curto período de tempo, um padrão que é definido pelo ITU-T. Foi a introdução deste sistema que possibilitou a implantação dos sistemas atuais baseados em menu, tais como home banking, serviços de seguros, call centers automatizados, e outros sistemas baseados em reconhecimento de tons.

Relativamente em relação aos Estados Unidos, estas implementações demoraram muito a acontecer no Brasil, mas hoje são de uso corrente e de conhecimento por boa parte da população, o que passou a acontecer graças às reformas tornadas possíveis após a privatização das Teles e da inversão maciça de investimentos que permitiu a disseminação destes sistemas.

A maioria dos sistemas de telefonia baseados em PBX atualmente é digital, embora isto não implique no uso de telefones digitais, necessariamente. Dado o seu elevado custo no mercado brasileiro, é muito comum o uso do telefone analógico, ainda que acoplado a uma central digital. Neste caso, a interface do PBX converte o sinal analógico do aparelho telefônico na codificação PCM (*). O sonho de muitos é possuir uma Central IP de última geração, com o aparelho mais barato da praça, o que nem sempre faz sentido…

A Importância das Telecomunicações

As tecnologias têm evoluído de forma rápida e temos visto o quanto são importantes os sistemas de comunicação, acreditando-se que o foco principal de pesquisas e estudos é garantir a qualidade que hoje temos em sistemas de telecomunicação e aperfeiçoando-as na medida do possível.

Com a utilização das redes IP como solução para sistemas de telecomunicação, fica possível estabelecer redução de custos em telefonia e agregação de serviços, utilizando-se uma única estrutura.

O que é VoIP

O VoIP sigla que deriva do inglês “Voice Over IP”, tecnologia que permite a digitalização e codificação de voz em pacotes IP, utilizando para transmissão a rede de comutação de pacotes[1] IP.

A tecnologia VoIP originou dois segmentos de produtos e serviços complementares:

• VoIP – convergência de voz e dados em rede WAN[2], utilizando o ATM[3], Frame Relay ou mesmo o PPP para a transmissão de voz, com o objetivo à redução dos custos de telecomunicações;

• Telefonia IP – dispositivos para telefonia baseados em IP, operando em rede local (LAN[4]) e visando a facilidade de uso, integração e aumento da produtividade.

Como funciona o VoIP ?

O processo como o VoIP trabalha é extremamente simples, primeiramente, a voz é digitalizada utilizando-se um ADC (Analog to Digital Converter), em seguida, este sinal digital é empacotado e transmitido via os meios já utilizados para trafegar dados (internet por exemplo). Ao chegar à ponta receptora, o processo é feito de forma reversa, agora se utilizando um DAC (Digital to Analog Converter) para converter o sinal digital em analógico.

Em resumo, o VoIP digitaliza a voz em pacotes de dados, transmite e reconverte em voz novamente em seu destino.

A imagem abaixo exemplifica este processo:

A conexão VoIP

Para ter uma comunicação VoIP nós precisamos dos seguintes passos:

1. A voz é convertida em sinais digitais (bits)
2. Os bits são comprimidos no formato ideal para a transmissão (uso de do codecs)
3. Os pacotes de voz são inseridos em pacotes de dados usando o RTP (Real-time Protocol)
4. Utiliza-se um protocolo de sinalização (SIP, H323 ou MGCP, por exemplo)
5. No destino, os pacotes são então desempacotados, os dados são extraídos e convertidos em sinais de voz analógicos novamente.

A Compressão da VOZ

Depois do processo de digitalização da voz em dados, precisamos converter esses pacotes em um formato padrão para que seja rapidamente transmitido, para isto utilizamos os chamados CODECs (Codificador-Decodificador). Os codecs são softwares que tem a capacidade de codificar ou decodificar um sinal ou fluxo de dados digital.

Um dos padrões utilizados é a ITU-T G.711 (PCM – Pulse Code Modulation)

O sinal de voz é amostrado a uma taxa de 8000 vezes por segundo. Esta taxa deriva de uma teoria desenvolvida por Harry Nyquist, que estabelece que a taxa de amostragem deva ser ao menos duas vezes a máxima taxa do sinal amostrado, ou seja, (2 x 3.4KHz).

Representamos cada amostra com 8 bit (pode se ter até 256 valores possíveis)

De acordo com a norma ITU-T G.711, existem dois algoritmos para codificar um sinal que são: U-law e a-law. O algoritmo u-law é usado nos EUA e Japão, já o a-law é usado em quase todos os outros países.

O throughput é 8000 Hz * 8bit = 64 kbit/s, utilizado em linhas telefônicas digitais.

Com base nestas informações, sabemos então que se utilizando um codec como o G.711, terá uma ocupação de 64 kbit/s por canal.

Abaixo seguem outros padrões e seus respectivos valores:

• G.723 (MP-MLQ speech coding at 6,3(5,3) kbit/s rate)
• G.726-16 (ADPCM speech coding at 16 kbit/s rate)
• G.726-32 (ADPCM speech coding at 32 kbit/s rate)
• G.726-24 (ADPCM speech coding at 24 kbit/s rate)
• G.729a (CS-ACELP speech coding at 8 kbit/s rate) (preferred)
• G.711a (PCM audio coding standard, 8 kHz sample rate, 8 bits, 64 kbit/s data rate)
• G.711u (PCM audio coding standard, 8 kHz sample rate, 8 bits, 64 kbit/s data rate)

É importante lembrar que nem todos os codecs são gratuitos, o G.729 e o G.723, por exemplo, devem ser licenciados para a utilização.

O Consumo de banda é um fator que deve ser levado em consideração, pois um codec como o G.729, por exemplo, pode chegar a consumir 30 kbps, isto porque a banda reservada é apenas para o payload (carga de voz), alem deste consumo existe ainda o consumo em relação ao trafego de rede, onde este é encapsulado usando cabeçalhos de rede.

Protocolo de Transporte

Agora vamos ver sobre o protocolo que é encarregado de encapsular e transportar esses pacotes contendo a voz através da pilha TCP/IP.

• Pacotes de Dados Voip
  • RTP
  • UDP
  • IP
  • Camadas 1 e 2

O VoIP não utiliza TCP para trafegar os dados e sim UDP sobre IP.

O UDP por não ser um protocolo orientado à conexões, ele não faz controle sobre a ordem de entrega dos pacotes ou confirmações do mesmo. Estes fatores são importantes para garantir a qualidade da voz. O Protocolo RTP resolve estes problemas permitindo que o receptor coloque os pacotes na ordem correta e não espere muito tempo pelos pacotes que podem ter sido perdidos ou que levem muito tempo à chegar. É importante dizer que não é preciso todo pacote vir um de cada vez, mas sim em fluxo continuo e ordenados.

O Protocolo RTP

O RFC 1889 intitulado “A Transport Protocol for Real-Time Applications” define um protocolo que fornece um serviço de transporte de dados com características de tempo real, de que são exemplos áudio e vídeo interativo.

O serviço inclui identificação do tipo do payload, numeração seqüencial, marcas temporais (timestamping) e monitoração da entrega de dados.

O RTP tem dois componentes:

• O próprio RTP, responsável pela transferência de dados;
• Um protocolo de controle (RTCP – RTP Control Protocol), responsável pela monitoração da Qualidade de Serviço e pelo envio de informação sobre os participantes numa sessão;

O RTP/RTCP corre tipicamente sobre UDP, utilizando as suas capacidades de multiplexagem e checksum; em conjunto fornecem parte da funcionalidade de protocolos de Transporte

O RTP/RTCP é adotado na arquitetura multimídia IETF e na arquitetura H.323 (ITU)

O RTP (transporte de dados) tem as seguintes características:

• É executado fim a fim
• Transporta dado com características de tempo real:
  • Streaming
  • Interativos
  • Não inclui mecanismos que providenciem entrega confiável e com garantias de QoS, ou que permitam reserva de recursos;
  • Inclui as seguintes funções:
    • Timestamping (para compensação do jitter em pacotes do mesmo stream)
    • Numeração seqüencial (para detecção de perdas e reordenação)
    • Identificação do tipo de payload (para descrever o tipo de codificação usado no payload)
    • Identificação da fonte (em sessões multicast)

O cabeçalho RTP

O cabeçalho RTP é exibido abaixo:

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=2|P|X|  CC   |M|     PT      |       sequence number         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ….                              |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Os primeiros doze bytes existem em todo pacote RTP, enquanto que a lista dos identificadores CSRC está presente somente quando inserido por um multiplexador. Os campos têm o seguinte significado [RFC 1889, pg 10]:

• Versão (V): 2 bits: identifica a versão do protocolo RTP;
• Padding (P): 1 bit: se esse bit estiver ligado, o pacote contém um ou mais bytes de enchimento no final que não fazem parte dos dados úteis, devendo ser ignorados. Esses bytes podem ser necessários por alguns algoritmos de criptografia com tamanhos fixos de blocos, ou para enviar muitos pacotes RTP em um protocolo de nível inferior;
• Extensão (X): 1 bit: se esse bit estiver ligado, o cabeçalho terá uma extensão com o mesmo número de bytes, em formato definido na RFC 1889;
• Contador de CSRC (CC): 4 bits: número de identificadores CSRC que seguem o tamanho fixo do cabeçalho;
• Marcador (M): 1 bit: tem o objetivo de permitir eventos significativos, tal como limites de quadro, serem marcados no fluxo de pacotes;
• Payload Type (PT): 7 bits: identifica o formato da carga útil do pacote, de forma que possa ser interpretado pela aplicação. Um exemplo é áudio codificado em PCM ou ADPCM, ou vídeo codificado em MPEG ou H.263, e assim por diante;
• Número de seqüência: 16 bits: incrementa de um a cada pacote RTP transmitido, e pode ser usado pelo receptor para detectar perda de pacotes, bem como para restaurar a seqüência correta do fluxo;
• Timestamp: 32 bits: reflete o instante de amostragem do primeiro byte no pacote de dados do RTP. O instante de amostragem deve derivar de um relógio que incrementa linearmente no tempo a fim de permitir sincronização e cálculo de jitter. A resolução do relógio deve ser suficiente para a precisão de sincronização desejada e medição de jitter;
• SSRC: 32 bits: identifica a origem da sincronização. Esse número é escolhido randomicamente, procurando fazer com que todas as fontes de sincronização tenham identificadores diferentes. Caso haja colisões, o SSRC é modificado de acordo com um algoritmo determinado na RFC 1889;
• CSRC: 32 bits cada identificador: máximo de 15 itens: identifica as fontes que contribuíram para a carga de dados existente no pacote RTP. Esses campos são inseridos por multiplexadores, usando os SSRCs das fontes contribuintes. Assim, por exemplo, para pacotes de áudio de várias fontes que foram multiplexados em pacotes únicos RTP, o receptor utiliza esse campo para colocar de forma correta quem falou o quê.

Um exemplo de uso do RTP é visto na RFC 1889 (pg 5), onde ele é utilizado para efetivação de uma conferência de áudio em multicast. No início são alocados duas portas UDP (uma para dados RTP e outra para controle RTCP) e um endereço IP multicast. Essa informação é transmitida para todos os participantes. A aplicação utilizada pelos participantes envia o áudio em pequenos fragmentos de 20ms de duração, cada um deles com um cabeçalho RTP, que é transmitido via UDP na porta especificada anteriormente.

O cabeçalho RTP indica o tipo de codificação de áudio (PCM, ADPCM, MP3) que está contida no pacote, a fim de que os participantes possam trocar a codificação para permitir a entrada de um novo participante que está conectado através de uma linha lenta.

Para pacotes que chegam em ordem trocada, o número de seqüência ajuda na reorganização da informação. Já para atrasos variáveis na rede, a informação de timestamp vai ajudar o receptor a dimensionar o buffer de recepção, a fim de evitar truncamentos na conversa.

Além disso, o receptor sabe que cada número de seqüência corresponde a 20ms nesse exemplo, permitindo a ele reconstruir o tempo produzido pela fonte.

Para saber quem está participando da conferência e quão bem está recebendo áudio, a aplicação de cada pessoa envia uma mensagem multicast periodicamente para a porta RTCP do grupo, indicando seu nome e a qualidade com que está recebendo a informação.

Para deixar a conferência, a aplicação envia um pacote RTCP BYE, indicando que está saindo.

O Protocolo RTCP

O protocolo RTCP (RTP Control Protocol) tem por objetivo fornecer feedback sobre a qualidade de serviço obtida na distribuição de dados RTP, e consegue isso através de transmissões periódicas de pacotes de controle a todos participantes da sessão RTP, utilizando o mesmo mecanismo de distribuição do RTP (unicast ou multicast), e possuindo uma porta específica de controle na sessão, conforme descrito anteriormente. Suas funções são [RFC 1889, pg 15]:

• Feedback sobre a Qualidade de Serviço
  • Os receptores indicam a qualidade da recepção relativa a cada emissor (número de pacotes perdidos, jitter e round-trip delay)
  • Os emissores podem usar esta informação (no caso de aplicações adaptativas) para ajustar os débitos de codificação e outros parâmetros.
  • Sincronização entre meios
    • Por razões de flexibilidade, pacotes de áudio e vídeo são muitas vezes transportados em streams separados, que necessitam de ser sincronizados no receptor (por exemplo, para garantir lip synch); a informação de sincronização entre fontes (mesmo se em servidores diferentes) é fornecida pelo RTCP;
    • Identificação dos participantes na sessão
      • Nome, endereço eletrônico, número de telefone
      • Controle da sessão
        • Devido ao número de participantes numa sessão serem variável e eventualmente muito elevado, torna-se necessário evitar que o número de pacotes RTCP cresça linearmente com a dimensão do grupo multicast;
        • O período entre pacotes RTCP deve ser ajustado dinamicamente à dimensão do grupo, procurando-se que o tráfego RTCP consuma uma percentagem sensivelmente constante do tráfego total RTCP
        • Emissores (sources) e receptores (sinks) de informação enviam periodicamente pacotes RTCP para o mesmo grupo multicast usado para distribuir pacotes RTP;
        • Cada pacote RTCP contém vários elementos, nomeadamente relatórios enviados pelo emissor ou pelo receptor, seguidos por descritores da fonte
        • Sender Reports – descrevem a quantidade de dados enviados até ao momento e informação que permite a sincronização de vários meios;
        • Receiver Reports – contêm um bloco por cada fonte RTP no grupo, que descreve os valores instantâneos e acumulados da taxa de perdas e o jitter relativo à fonte correspondente; um bloco indica ainda o último timestamp recebido e o atraso desde a recepção do último Sender Report
        • Source Descriptors – são usados para controle de sessões;

Para contribuir com o protocolo RTP o RTCP utiliza os seguintes cinco tipos de pacotes detalhados:

• SR (Sender Report)
  Este pacote contém um relatório de envio e recebimento de pacotes RTP por participantes que são fontes ativas, ou seja, participam ativamente contribuindo para o envio de pacotes.
• RR (Receiver Report)

Este pacote contém um relatório de recebimento de pacotes RTP por participantes que não são fontes ativas, ou seja, não participam ativamente contribuindo para o envio de pacotes.

• SDES (Source Description Items)

Este é um pacote descritivo do participante e inclui a informação do seu CNAME.

• BYE

Indica a saída deste participante da comunicação e precisa conter a SSRC/CSRC para sua identificação

• APP – Contém funções específicas da aplicação

FXS & FXO

Portas FXS (Foreign Exchange Station) conectam telefones analógicos, aparelhos de fax e a linhas de cobre dos troncos de um PBX. As portas FXS, em um Gateway conectado a uma rede de telefonia interna, comportam-se como “ramais”.

Portas FXO (Foreign Exchange Office) conectam-se diretamente a linhas PSTN, da rede de telefonia pública, ou a extensões de ramal dos PBXs, conectando-o à rede IP.

Geralmente as portas FXS são empregadas com maior freqüência, em função da conexão direta aos aparelhos da rede de telefonia, em substituição às portas do PBX. As portas FXO são empregadas em geral para fazer a conexão à rede pública, PSTN, ou para propiciar a ligação das portas de extensão ramal do PBX (que são FXS) à rede IP.

A seguir apresentamos alguns diagramas que apresentam a posição correta, e também a incorreta, de uso em relação às portas FXS e FXO.

Exemplo 1 – Conexão Gateway FXS

Exemplo 2 – Conexão Gateway FXO

PSTN

Public switched Telephony Network
Rede de Telefonia Publica Comutada

A maioria dos telefones no mundo todo são conectados através desta vasta rede de comunicação por circuito otimizada para a comunicação em tempo real, permitindo que qualquer telefone possa ser encontrado, uns aos outros.

Todos os telefones desta rede são encontrados através da discagem de números, o qual pode incluir código de pais, código de área e o numero telefônico.

Ela é a rede de Serviço Telefônico Fixo Comutado (STFC). Essa rede PSTN praticamente foi toda digitalizada, quando queremos nos referir ao convencional (analógico) de telefonia, é referido como POTS.

A PSTN é implementada por padrões da ITU-T.

POTS

Plain Old Telephone Service Line

Provavelmente a conexão mais comum para PSTN é a linha POTS. Esta é uma linha análoga, provida por um provedor de telefonia. Cada linha POTS pode carregar apenas uma conversa por vez.

Para pequenas instalações, linhas POTS são usualmente as de maior custo-benefício quando conectando diretamente para nosso Provedor Local (Local Exchange Carrier – LEC), um termo usado para referir-se à qualquer companhia provedora de serviço local.

ISDN

Integrated Services Digital Network
Rede Digital de Serviços Integrados

ISDN é uma rede toda digital que tem estado disponível através de décadas. Este tipo de rede é disponível em duas principais versões: Basic rate Interface (BRI) e Primary Rate Interface (PRI).

A ISDN divide a linha em múltiplos canais. Cada canal pode conter ou um pacote (Bearing, ou B-Channel – “Canal de transporte/Canal B”) ou sinalização (Data, ou D-Channel – “Canal de Dados/Canal D”).

Uma interface BRI tem 3 canais: 1 canal D e 2 canais B. Portanto, 2 chamadas telefônicas podem estar em progresso por vez em um único BRI.

Uma interface PRI tem 24 canais: 1 canal D e 23 canais B, resultando em 23 ligações simultâneas.

A ISDN não é limitada apenas à voz. Cada canal pode carregar 64k de dados, isto se configurado com o LEC (Local Exchange Carrier).

T1 ou E1

T1 é uma linha com 24 canais. Cada canal pode conter uma chamada. Portanto, um T1 pode ter uma chamada adicional quando comparada ao PRI. Na Europa, o E1 é mais comum.

[T1]T1 é um método de transmissão digital para multiplexar canais de voz ou de dados em um par de fios. É o método padrão de interconexão de centrais telefônicas nos Estados Unidos e Japão. Nos demais países usa-se o E1.

Usando uma técnica chamada Multiplexação por Divisão do Tempo (TDM), o T1 distribui voz e/ou dados de LAN em subcanais DS0. O benefício primário do T1 é a largura de banda – 1,544 Mbps – disponível em 24 subcanais DS0, facilmente alocados, de 64 Kbps. O T1 envia dados em quadros (frames) compostos de 24 palavras de 8 bits (uma palavra para cada subcanal) e um bit de framing, compondo um total de 193 bits por quadro. Um canal T1 transmite 8 000 quadros por segundo. Os bits de framing em quadros sucessivos seguem o padrão para um formato de superquadro (superframe). O Channel Bank T1 verifica esse padrão para garantir que a sincronização seja mantida.

Comparado com T1, o E1 possui 32 canais.

T1s tem que sinalizar a chamada de qualquer maneira e a maneira com que eles fazem isto é através de “Roubo de sinalização” de bit. Isto quer dizer que um bit é roubado de tempo em tempo como as informações precisam fluir sobre a conexão. Enquanto isto é usualmente imperceptível pro ouvido humano, isto pode ser destrutível na comunicação de dados.

[Multiplexador] – Um multiplexador, mux ou multiplex é um dispositivo que codifica as informações de duas ou mais fontes de dados em um único canal. Eles são utilizados em situações onde o custo de implementação de canais separados para cada fonte de dados é maior que o custo e a inconveniência de utilizar as funções de multiplexação/demultiplexação. Em uma analogia física, consideremos o comportamento de viajantes atravessando uma ponte com largura pequena, para atravessarem, os veículos executarão curvas para que todos passem em fila pela ponte. Ao atingir o fim da ponte eles irão se separar em rotas distintas rumo a seus destinos.

Conhecendo as Operadoras

Existem hoje milhares de Operadoras VoIP, entre estas, existem as que se destacam por suas qualidades e serviços e principalmente por sua licença de Operação.

Sim, hoje em dia pode se dizer que qualquer um “pode” oferecer serviços VoIP, lhe garantir um usuário e integrar seus serviços à uma terminação na rede Publica. Porem, as operadoras de verdade precisam ser devidamente licenciadas e certificadas à prover este tipo de serviço, elas devem receber uma licença SCM da Anatel.

Muitas das operadoras contam já com uma enorme quantidade de POPs (Pontos de Presença), o que traz facilidades para os usuários em relação aos custos de ligação.

Digamos que a operadora que você trabalha possui ponto de presença no estado de São Paulo e Rio de Janeiro, imagine agora que dentro da estrutura de sua operadora, sua ligação de São Paulo irá trafegar através da rede de sua operadora, ou seja, os custos que a operadora teria para contatar uma estrutura local no Rio de Janeiro são convertidos em descontos para você. Para o você o, o usuário, é imperceptível este trafego entre SP e RJ.

Imagine o cenário de uma empresa de matriz em São Paulo e Filiais no Rio de Janeiro e Salvador. Todas as ligações convencionais são realizadas por operadoras locais e quando entram em ligações de longa distancia são necessárias comunicações com outras operadoras locais para terminar as chamadas. Neste meio caminho existe um custo muito alto, algo que hoje pode ser realizados algumas maneiras, mas todas elas utilizando-se o VoIP, incluindo ou não uma Operadora. Vamos tratar dessas maneiras de comunicação mais a frente.

Hoje no Brasil, as principais Operadoras de Serviços VoIP são: Vono e Tellfree.

É através de uma operadora que você pode reduzir seus custos de ligação de longa distancia.

Algo importante no momento de escolher uma operadora, é verificar seus pontos de Presença perante todo território Nacional, além é claro, observar criticas e elogios em relação aos serviços prestados, a disponibilidade dos mesmos e principalmente em relação ao atendimento e suporte.

Essas operadoras geralmente oferecem serviços de ligações gratuitas entre usuários do mesmo serviço.

Uma grande operadora da Europa que oferece este serviço também é o Pulver

Protocolos de Sinalização e Multimídia

H.323

H.323 é uma das recomendações da ITU Telecommunication Standardization Sector (ITU-T) que se encontra na sessão H que define “Sistemas Audiovisuais e Multimídia”. As recomendações do H.323 que definem o protocolo que prove sessões de comunicação audiovisuais em qualquer rede baseada em pacotes. Sua implementação se estende à equipamentos de voz e videoconferência, utilizado com diversas aplicações em tempo real como Netmeeting e Ekiga, é estendido também às empresas e provedores de serviços do mundo todo com seus serviços de voz e vídeo sobre redes IP. Esta é uma parta da ITU-T da serie de protocolos H.32x, qual também endereça comunicações via ISDN, PSTN ou SS7 (Signaling System 7), e rede moveis 3G.

O H.323 foi o primeiro padrão VoIP à adotar os padrões IETF (Internet Engineering Task Force) e RTP para transporte de áudio e vídeo via redes IP;

Outras recomendações estão juntas ao H.323: H.225.0, H.245, H.246, H.283, H.341, H.450 Series, H.460 Series, e H.500 Series

As entidades H.323 podem se comunicar através de conexão ponto-a-ponto, sobre um único segmento de rede, ou em uma internetwork com múltiplos segmentos e topologias complexas.

Estas entidades podem ser interoperaveis com terminais H.310 sobre B-ISDN, H.320 sobre N-ISDN, H.322 com terminais em redes com Qualidade de Serviço garantidas, H.324 em terminais GSTN e redes wireless, V.70 terminais, e ISDN através de Gateways.

Em H.323, pode se utilizar Gatekeepers, que são serviços de tradução de endereços e provem controle de admissão.

Um exemplo de Gatekeeper que pode ser encontrado é o GNUGK, open source e bastante utilizado por muitas organizações.

O Protocolo SIP

SIP (Session Initiation Protocol – Protocolo de Inicio de Sessão) inscrito na RFC 3261 é um protocolo baseado em texto, similar ao HTTP e o SMTP. O SIP é um protocolo da camada de aplicação cujo foi criado para iniciar, modificar e terminar sessões com um ou mais participantes. Suas sessões incluem chamadas telefônicas via internet, distribuição multimídia, e conferencias.

Os convites SIP usados para criar sessões, carregam descrições que permitem aos participantes estarem de acordo com os tipos compatíveis de mídia. O SIP utiliza elementos chamados Proxy Servers que auxiliam as requisições de roteamento para localizar, autenticar e autorizar serviços aos usuários, implementação de políticas de roteamento de chamadas, e prover funcionalidades aos usuários. O SIP também prove uma função de registro que permite aos usuários enviarem suas localizações por use de um servidor proxy. O protocolo SIP roda no topo de diversos protocolos de transporte.

O Protocolo SIP possui cinco funções para iniciar, estabelecer e terminar comunicações Multimídia:

• Localização de usuário: determinação do endereço a ser usado para a comunicação.
• Disponibilidade do usuário: determinação da disponibilidade do interlocutor de entrar na comunicação;
• Capacidades do usuário: determinação da mídia e parâmetros a ser usados;
• Estabelecimento da chamada (call setup): estabelecimento dos parâmetros de chamada entre participantes (quem faz e quem recebe).
• Gerenciamento de Sessão: inclui transferência e término de chamadas, modificação dos parâmetros da sessão.

Os destinatários no SIP são representados com URI (Uniform Resource Indicators) o qual tem o mesmo formato de um endereço email. Isto implica a utilização de um Domain Name Services (DNS) para mapear nomes de hosts e domínios para endereços IP.

Componentes do SIP

• User Agents
  • Clients – Make requests
  • Servers – Accept requests
  • Server types
    • Redirect Server
    • Proxy Server
    • Registrar Server
    • Location Server
    • Gateways

Requisições SIP:

Há seis requerimentos básicos / tipos de métodos:

INVITE (convidar) = Estabelece uma sessão
ACK (confirmar) = Confirma o comando CONVIDAR
BYE (tchau) = Finaliza uma sessão
CANCEL (cancelar) = Cancela a sessão ainda não respondida
REGISTER (registro) = Informa a localização do usuário (nome do usuário, IP)
OPTIONS (opções) = Informa a capacidade e disponibilidade dos telefones de chamada e recebimento SIP

SDP – Session Description Protocol

O SDP (Protocolo de Descrição de Sessão) é um protocolo que é transportado no corpo de uma mensagem SIP. O SDP é encarregado por descrever as sessões.

Respostas SIP:

Os requerimentos do SIP acionam respostas que constam das 6 classes a seguir:

1xx = respostas de informações, tais como 180, que significa chamando
2xx = respostas de confirmação
3xx = respostas de redirecionamento
4xx = comandos não realizados
5xx = erros do servidor
6xx = erros globais

Fluxo SIP

Exemplo do fluxo SIP em uma chamada:

Descrição

• O Usuário A envia um INVITE (chama o usuário através de seu numero, ramal)
• O Usuário B envia uma mensagem do tipo 180, indicando que o telefone está “chamando”. Em seguida o usuário B envia uma mensagem do tipo 200 OK (estabelecendo a comunicação).
• O Usuário A então envia uma mensagem ACK, confirmando o estabelecimento da sessão.
• Enquanto os usuários falam, mensagens RTP são trafegadas.
• Quando o Usuário A desliga o telefone, ele envia uma mensagem BYE para indicar para o outro lado que está encerrando a sessão.

Registro de Usuário (REGISTER)

Abaixo é exibida uma mensagem de pedido de Registro ao Servidor SIP:

Observe que o usuário “Cacs” é o solicitante para o Servidor “192.168.1.10”:

Note que o pedido foi realizado da estação 192.168.1.12 através da porta 8394:

Mais a fundo, podemos também encontrar qual a plataforma que está sendo utilizada como Agente, neste caso um Softphone:

Resposta do Servidor (200 OK)

Padrões SIP

IETF RFCs

• RFC3261  Core SIP specification – obsoletes RFC2543
• RFC2327  SDP – Session Description Protocol
• RFC1889  RTP – Real-time Transport Protocol
• RFC2326  RTSP – Real-Time Streaming Protocol
• RFC3262  SIP PRACK method – reliability for 1XX messages
• RFC3263  Locating SIP servers – SRV and NAPTR
• RFC3264  Offer/answer model for SDP use with SIP
• RFC3265  SIP event notification – SUBSCRIBE and NOTIFY
• RFC3266  IPv6 support in SDP
• RFC3311  SIP UPDATE method – eg. changing media
• RFC3325  Asserted identity in trusted networks
• RFC3361  Locating outbound SIP proxy with DHCP
• RFC3428  SIP extensions for Instant Messaging
• RFC3515  SIP REFER method – eg. call transfer

O IPO500 é uma Central de Comunicações IP  com características híbridas, que incorpora todas as funções tradicionais de telefonia TDM, incluindo todo o parque legado de aparelhos telefônicos analógicos e telefonia TDM, comportando todo o tipo de troncos PSTN, analógicos e digitais E1/R2. O IPO500 é uma Central IP que suporta telefonia IP, nas suas extensões e troncos, suportando telefones IP Avaya, Softphones e troncos IP (SIP).

O  IPO500 é uma plataforma de comunicação IP, com aplicações avançadas de colaboração e Unified Messaging, Conferência e interatividade Web, suprindo as necessidades dos usuários móveis e remotos. Suas características híbridas permitem tirar proveito da infraestrutura existente assim como da nova estrutura de telefonia IP, que podem conviver em uma mesma plataforma.

O IPO500 possui aplicativos em diferentes escalas de complexidade, possibilitando dotar até mesmos os telefones analógicos mais antiquados de funcionalidade IP, por meio do Phone Manager Lite, que é fornecido para todas as extensões. Opcionalmente é possível dotar os telefones de funções mais avançadas – na tela do computador, por  meio do Phone Manager Professional.

A mensageria da empresa pode ser tratada com diferentes níveis de recursos e complexidade, que vão desde o autoatendimento e URA básicos até o Voice Mail Pro, que permite desenhar fluxos de atendimentos mais complexos. O IPO500 possui as funções mais complexas somente encontradas em sistemas mais sofisticados simultaneamente com a funcionalidade IP. Em ambientes onde o custo de transição da telefonica TDM para uma telefonia totalmente IP pode ser proibitivo, o IPO500 oferece o caminho de transição com a melhor relação custo-benefício do mercado, pois permite aproveitar toda a infraestrutura existente simultaneamente permitindo adotar endpoints IP paulatinamente.

O IPO500 pode funcionar como uma Central totalmente IP, com todos os recursos de telefonia tradicionais, funcionando apenas com aparelhos IP. A versão 5.0 permite adotar telefones SIP do mercado, aumentando a disponibilidade de opções. O IPO500 suporta gravações de todos os ramais inclusive IP, por meio de aplicação própria (Contact Store) ou externa, bem como tarifadores Web.

É possível implementar redes de Centrais (SCN – Small Community Network), com funcionalidade estendida entre as centrais, inclusive a continuidade entre ramais obtida totalmente por IP. O IPO pode ser integrado a Centrais existentes por meio de Q.SIG.

O IPO500 é uma central com elevado MTBF, chegando a 14 anos em uma configuração normal. Por não possuir HD e partes móveis possui elevado grau de confiabilidade, não necessitando de customizações especiais para atender à grande maioria das funções requeridas em uma Central de Comunicação IP, e seu tempo de implantação é extremamente curto.

O gerenciamento do IPO500 é via interface totalmente Web e não requer o conhecimento de sistemas operacionais específicos ou treinamentos em plataformas de S.O. de sistemas de telefonia, sendo totalmente intuitivo. O único conhecimento requerido são os conceitos de telefonia e suas aplicações, bem como conhecimentos de redes LAN/WAN e sua administração.

O aprendizado do IPO500 é extremamente rápido e a assistência de suporte pode ser efetivada remotamente em praticamente todos os casos de forma simples, direta e intuitiva. Tais funcionalidades e facilidades permitem ao departamento de TI assumir rapidamente as funções principais da Central, sem comprometer as operações de telefonia e sua disponibilidade e sem criar dependência de profissionais dotados de conhecimentos específicos, garantindo a continuidade das operações sem criar uma dependência indesejável de profissionais especializados em S.O.´s de telefonia customizáveis.

Todos os padrões relevantes, SIP, H.323, CTI, TAPI, são suportados pela Central, o que permite sua integração plena com os serviços disponíveis e aplicações de terceiros, tais como outros endpoints, provedores de serviços de telefonia VoIP, CRM´s, e provendo interface aberta para desenvolvimento de aplicações de CRM.

Dentre as funcionalidades tradicionais suportadas relacionamos algumas das principais, relacionamos algumas:

• Caller ID
• Hold
• Toggle Calls
• Hold on Call Waiting
• Hold Music
• Park
• Automatic Callback
• DID/DDI
• Transfer Blind Transfer
• Distinctive Ring
• Presonalized Ring
• Visual Voice
• Tons
• Call ID
• Call Tagging
• Hunt Group
• Paging
• Dial Plan
• Intrude
• Inclusion
• Private Call
• Hot Desking
• Remote Hot Desking
• Pickup
• Call Recording
• Telecommuter Mode
• Twinning
• TAPI
• CTI
• Account Codes
• Call Barring
• Alternate Route Selection (ARS)
• Maximum Call Length
• PIN Restricted Calling
• Forward on Busy
• Forward on No Answer
• Forward Unconditional
• Forward Hunt Group
• Follow Me
• Incoming Call Routing
• Hunt Groups
• Night Service
• Time Profiles
• Queuing
• Hunt Group

 O 3CX é um PBX IP baseado em Windows que implementa as funções de um SIP Server em plataforma Windows. O PBX IP da 3CX é portanto um aplicativo de software e não possui hardware associado.  O 3CX implementa por software todas as funções de um sistema de telefonia, com aplicações avançadas de Comunicações Unificadas e integração com Outlook. Sua concepção prevê o uso do sistema com Softphones e Telefones IP ao invés de telefones analógicos como ramais. A ligação com o mundo externo prevê o uso de um link de dados e interligação com uma Operadora IP, realizando a função de troncos IP.

A integração com o mundo da telefonia legado, seja por meio de troncos analógicos, seja por troncos digitais do tipo E1 é sempre feita por gateways. Não há suporte no Brasil para placas da Sangoma, internas ao micro, e que apenas suportam ISDN, ao passo que o padrão normalmente utilizado e prático é o E1/R2. Desta forma, utilizam-se gateways externos para interligar o PBX IP 3CX com a Operadora tradicional, como o Epygi E1/R2 ou AudioCodes/Mediatrix para troncos analógicos.

No caso do Brasil, é importante salientar que nem todos os gateways e configurações padrão são suportados, o que significa que Gateways de determinados fabricantes não funcionarão no Brasil e poderão não funcionar adequadamente com a configuração padrão, mesmo que o sript tenha sido gerado pela 3CX e que seja suportado “lá fora”.

Não é recomendado utilizar gateways FXS para dotar o 3CX de ramais analógicos que, embora teoricamente possível, pode acarretar perda de funcionalidade. Gateways de vários fabricantes presentes no Brasil não são suportados pela 3CX e não é suficiente o suporte ao padrão SIP, pois determinados Gateways implementam apenas parte do protocolo, omitindo funções importantes, notadamente funções de ramais. Determinadas implementações podem levar a problemas de registro e transferência de chamadas, entre outras funções.

É preciso sempre ter em mente que o 3CX não foi concebido para dotar o sistema de telefonia de ramais analógicos. Desta forma o emprego de Gateways FXS para prover ramais ao sistema contraria a concepção original que é a de usar ramais softphones ou telefones IP, não tendo sido concebido para criar bancos de ramais analógicos empregando gateways. Mesmo nos casos de gateways FXS homologados pela 3CX, é provável que ocorra perda de funcionalidade de ramal, pois a especificação SIP para ramal não está hoje inteiramente definida, ao contrário do lado tronco (operadora). A sinalização para ramal é bem mais complexa e existem incompatibilidades diversas entre diversos fabricantes. Por este motivo, não recomendamos a adoção de  gateways externos para prover ramal analógico, criando bancos de ramais, a menos que as funcionalidades tenham sido claramente atestadas pelos fabricantes.

Equipamentos homologados: pode ser constatado que os gateways empregados em soluções onde não foi observado que os mesmos foram de fato homologados pela 3CX, ou pelo fabricante, ou testados em ambiente real para uso conjunto em função de ramal, resultaram em mau funcionamento. Em geral os gateways implementam um subconjunto de funções que permitem o seu uso com operadoras externas (Vono, Tmais, Tellfree, etc). Não é recomendável emular função de ramal usando gateways FXS, podendo haver perda de funcionalidade.

Suporte do fabricante: toda solução adotada deve ser validada e reconhecida pelos fabricantes.  Quando a solução não é reconhecida pelos fabricantes perde-se o direito ao suporte a qualquer um dos dois, pois nem a 3CX, neste caso, nem o fabricante do Gateway, atestarão este funcionamento em qualquer documentação ou consulta existente. Desta forma, na prática, perde-se o direito ao suporte. Nestes casos ficamos restritos às funcionalidades que sejam possíveis de obter nos testes em campo. É provável, com grande grau de certeza, que certas funções não possam ser reconhecidas pelo 3CX e o fabricante não homologado quando operando em conjunto.

Problemas de concepção: Deve-se submeter a solução a uma prova de conceito para o projeto, e também haver pesquisa de compatibilidade plena. Quando isto não ocorre, na prática, isto torna impossível ou inviável, debugar o sistema. É provável  que a conclusão final de um projeto não devidamente validado determine a inviabilidade do uso de equipamentos que não funcionarão adequadamente em conjunto, o que levaria à necessidade de aquisição de outros, devidamente homologados, a um custo relativamente elevado. O software 3CX foi idealizado para empregar softphones e telefones IP (homologados). Para troncos de saída esta homologação é menos importante, pois as funções de tronco são mais simples.

Tronco E1: no caso do 3CX, a única forma de empregar um tronco E1 é via gateway externo. A questão da compatibilidade é mais importante do lado da operadora, ou seja, é necessário que o equipamento proposto seja compatível com a sinalização da operadora, e que o mesmo atenda ao padrão de sinalização R2 brasileiro. Isto somente é possível quando o fabricante do Gateway de fato fez os ajustes necessários às condições de operação no Brasil. Além disto, o produto deve ser  homologado pela Anatel. Sem estas condições, a Operadora que entrega o link E1 pode se recusar a prestar suporte ou mesmo ativar aquele link, pois ela sempre poderá argumentar que todo e qualquer problema “é do equipamento”.

Comparativo com a Microsoft: o sistema 3CX pode ser uma excelente opção para o ambiente Windows, e um preparativo para o OCS, que é muito mais complexo e dispendioso. Para ambientes de porte pequeno e médio, ou distribuídos e onde haja a correta aplicação dos conceitos, com o emprego de Softphones e telefones IP e uso do link de dados para efeito de tronco SIP, o 3CX pode se revelar uma opção muito interessante e bem integrada ao Windows, destacando a sua fácil utilização, versatilidade e usabilidade.

Por outro lado, cabe observar que a qualidade do link contratado é crucial para um bom desempenho, o que não será obtido com links de banda larga ordinários e que não possuem um QoS ou SLA apropriado para uso com Voz sobre IP. Se o sistema requerido necessitar de alto grau de hibridização,  o 3CX pode não ser recomendado.

Desta forma, o sistema 3CX para telefonia IP sob Windows é um PBX IP baseado em software que substitui o hardware tradicional proprietário característico dos PBX/PABX´s. O software 3CX foi desenvolvido especialmente para o Microsoft Windows e é baseado no padrão SIP, o que permite uma maior compatibilidade com Operadoras de telefonia IP e com aparelhos telefônicos IP que obedeçam ao padrão SIP.

Principais características do 3CX:

• Não requer um cabeamento separado de telefonia – os telefones usam uma rede de computadores.   
• Facilidade de instalar e gerenciar via configurador baseado em interface web.
• Mobilidade entre escritórios. 
• Possibilidade de escolha entre vários fornecedores de telefones de hardware baseados em software SIP, evitando a vinculação estrita a um único fornecedor.
• Possibilidade de usar a rede tradicional de telefonia (POTS ou PSTN) usando gateways VoIP (*)
• Possibilidade de economizar com ligações usando Provedores de telefonia IP (**).

 (**) Por exemplo, a Tellfree

Principais Aplicações:

O sistema 3CX é idealmente utilizado quando se pretende utilizar uma telefonia completamente IP, o seja, os ramais IP (seja por softpfone, seja por telefone IP) e entroncamento com Operadora de telefonia IP (SIP trunk). A interligação com o mundo da telefonia tradicional pode ser feita com o uso de gateways FXO (*), ou gateways E1 (***).

O  3CX é portanto indicado para ser empregado com telefonia plenamente IP, ou com entroncamento misto, quando se usa Operadora SIP e Operadora tradicional, para o que podem ser utilizados gateways analógicos, porém com todos os ramais IP, seja pelo uso de softfones, seja pelo uso de telefones IP.

• O 3CX não é indicado para uso de telefonia híbrida, quando se deseja usar ramais analógicos com misto de ramais IP e entroncamento analógico. Embora seja perfeitamente e tecnicamente possível criar um PBX IP híbrido usando o 3CX conjugado com gateways, tal prática revela-se economicamente pouco atraente.

Desta forma, quando se pensa em um PBX IP com facilidades Windows e um sistema puramente IP, o 3CX pode ser uma excelente opção. De outra forma, quando se deseja conjugar telefonia tradicional com telefonia IP o 3CX não apresenta a mesma vantagem econômica, podendo se revelar bem mais caro do que a solução híbrida.

Requisitos Mínimos:

Em termos gerais, um computador do tipo Pentium Dual Core, Windows XP SP4, 2003 ou 2007, ou Vista, com 2GB de memória e 120GB de HD, de boa procedência e qualidade, deverá ser suficiente, lembrando que o MTBF de sua telefonia será equivalente ao MTBF do PC servidor de telefonia. Suporte a virtualização (**).

(*) AudioCodes. Requer configuração especial.

(**) Requer consulta técnica e estudo de viabilidade.

(***) Quadro E1 Gateway com 1 x E1/R2.

Suporta Gateways FXS da Mediatrix.

Projetando um sistema de Vigilância IP e Comparando com o CFTV

Quando se fala em sistemas de vigilância que empregam câmeras IP é inevitável a  comparação direta com sistemas CFTV analógicos, o que tem suscitado acaloradas discussões que sempre envolvem estes dois tipos de sistemas, levando a um confronto de tecnologias baseado em abordagens  baseadas em informações distorcidas. A comparação entre os sistemas na maioria das vezes é incompleta e pouco parcial, o que leva a uma incompreensão da empregabilidade de cada sistema.

 Em geral a defesa dos sistemas de CFTV soa algo “apaixonada” e torna-se mesmo uma discussão anacrônica e reativa contra a progressiva e inexorável predominância dos sistemas de vigilância IP sobre os analógicos. Apesar das resistências enfrentadas, a prevalência futura dos sistemas nativos IP sobre os demais sistemas é de indiscutível previsibilidade, tal e qual como aconteceu com a tecnologia de câmeras digitais, que acabaram suplantando e soterrando suas antecessoras.

Para compreender melhor a aplicabilidade destas tecnologias, faz-se necessário rever o histórico que envolve a evolução das tecnologias de vigilância por câmeras. A maioria absoluta dos sistemas de vigilância hoje existente no Brasil é composta por sistemas de CFTV analógicos, sendo suportado por uma grande rede de instaladores e prestadores de serviços que obtêm a maior parte de suas receitas com a instalação deste tipo de sistema. O grande problema para a maioria destes instaladores é que este corpo técnico não tem capacitação hoje para lidar com sistemas baseados em vigilância IP, motivo pelo qual defendem a superioridade da solução analógica sobre aquela baseada em IP.

 Poderíamos até mesmo traçar uma analogia entre os sistemas de de vigilância baseados em CFTV versus Vigilância IP e o confronto entre a telefonia analógica e a telefonia IP. Esta miríade de suportadores da tecnologia tem, até certo ponto, inibido a penetração dos sistemas de vigilância IP com maior intensidade.

Esta analogia ajuda a compreender a distinção que existe entre os dois sistemas. No Brasil, principalmente, a cultura voltada para a adoção de novas tecnologias, ao contrário do pensamento corrente, é extremamente conservadora. O Brasil tem sido sempre um dos últimos países a adotar novas tecnologias, especialmente pela grande dificuldade de adaptação das pessoas e empresas com as mudanças recorrentes. Não foi por outro motivo que o Brasil foi um dos últimos, senão o último país do mundo, a manter fábricas de máquinas de escrever operacionais, anos depois de terem sido varridas do mercado dos países mais desenvolvidos.

A cultura da vigilância no Brasil ainda está fortemente arraigada no conceito da televisão com vários quadrantes, localizada na “salinha do vigilante”, ou na portaria. É muito comum que os sistemas de vigilância fiquem a cargo da “equipe de segurança”, que geralmente possui pouco conhecimento tecnológico para lidar com outra coisa que não seja um DVR, ainda considerado um expoente tecnológico.

A maioria dos sistemas ditos digitais de vigilância no Brasil é na verdade composta por sistemas analógicos que foram “digitalizados”. Desta forma o sistema dito digitalizado na verdade requer a conversão da imagem nativa analógica em digital, normalmente à custa de grande perda de qualidade. Eventualmente, por serem digitalizados, tornam-se “IP”, e por isto podem ser manipulados por softwares de gerência. Tal digitalização, contudo, tem um custo elevado, com conversores analógico-digitais, sistemas de armazenamento e software que podem contribuir para elevar demasiadamente o custo, com um resultado apenas razoável e de difícil gerenciamento. Por outro lado, pode ser a melhor opção quando se dispõe de um sistema já implantado e com câmeras analógicas de qualidade superior.

Para melhor entender as diferenças entre um sistema baseado em vigilância IP e um outro baseado em sistema analógico, temos que compreender melhor o “porquê do IP” aplicado a este tipo de tecnologia. Muitas vezes nos esquecemos do principal antes de avaliarmos as diferenças entre os sistemas de mundos diferentes.

Na verdade, é disto que se trata. Estamos saindo da era do mundo analógico, tal como ocorre com a telefonia, para o mundo IP. Não será isto um simples modismo ? Na verdade, temos que entender que a principal questão aqui é conceitual. Estamos entrando na era da convergência, onde todas as aplicações se comunicam através da mesma infraestrutura, no caso, da rede IP, e passam a ser administradas pela mesma gerência,  de TI.

É disto que se trata. A área de segurança, tal qual a telefonia, sai do cantinho da “portaria”, ou da “salinha de segurança” e passa a ser administrada pela área de TI. Afinal de contas, a TI já se preocupa com outros tipos de invasão, como a invasão dos sistemas da empresa ? Qual é a diferença em se rastrear a invasão física ?

A partir do uso do IP a gerência passa a ser unificada e potencializa-se os recursos existentes na própria TI, descartando-se outros. Além disto, a utilização de câmeras IP possibilita agregar inteligência na própria câmera, que é por si um FTP e Web Server. Cada câmera é um servidor inteligente  de imagens que pode ser monitorado individualmente e responder a diversos comandos e programações, agindo de forma bidirecional, respondendo a ativação de dispositivos, alarmando por si e até mesmo enviando e-mails e SMS.

Cada câmera pode ser acessada individualmente a partir de qualquer localidade, parametrizadas todas as restrições de acesso, é claro. Mas não paramos por aí. A qualidade da imagem de uma câmera IP, que grava a imagem digitalmente nativa é muito superior ao da imagem analógica digitalizada. Nem sempre isto pode ser notado no “filme em movimento”, porém tal fator de qualidade ficará patente na recuperação da imagem congelada.

 Alguns fatores contribuem para esta perda de qualidade por parte das câmeras analógicas. Um deles diz respeito ao comprimento do cabo de CFTV, até chegar naquela “salinha de segurança”,  pois ocorre degradação de imagem em função da distância percorrida. Outro fator é que a imagem analógica digitalizada raramente gera uma definição superior a 0.4Mpixel. Câmeras IP de melhor qualidade registram 1.3 Mpixel ou mais, porém sem degradação alguma em função da distância, por já terem sido digitalizadas na origem.

Outro fator muito importante,  e que muitas vezes somente é notado quando se quer recuperar determinado evento é o efeito provocado pelo entrelaçamento de imagem na câmera analógica, ao passo que câmeras IP de qualidade superior fazem uso do progressive scan. Novamente, tal fator passará despercebido quando se vê a imagem em movimento, mas não quando recuperamos o still da imagem, ou seja, o exato instante em que queremos congelar a imagem do evento. No modo entrelaçado ocorre uma varredura entre linhas pares e ímpares no quadro de imagem, com um retardo de  17 a 20ms entre as duas varreduras. É o suficiente para gerar o efeito “borrão”.  No progressive scan a imagem é literalmente scaneada por inteiro, quadro a quadro.

É  por isto que vemos um borrão na tela quando recuperamos a imagem em Still (congelada), obtida pelo método analógico. Estas diferenças de qualidade e precisão são determinantes no momento crucial que envolve a recuperação de imagens.

E tais diferenças podem mesmo ser dramáticas. É comum vermos na televisão a recuperação de imagens referentes a roubos e acidentes, onde a imagem do perpetrador não passa de um borrão na tela. Infelizmente, em termos forenses tais imagens são inúteis. Por este motivo é que se diz em vigilância IP: “não basta saber que houve o roubo, posto que isto já o sabemos, mas sim recuperar a imagem do evento com a máxima precisão possível”.

Tal precisão será tão mais crítica quanto o valor do prejuízo que se deseja recuperar. Tais fatores envolvem também a celeridade na investigação, assim como precisão da imagem. O trabalho de determinar o instante do roubo, sinistro ou evento,  pode demandar tempo e esforço, diretamente proporcionais ao rudimento da tecnologia empregada. No caso de sistemas de armazenagem, mesmo os digitais, e que sejam  desprovidos de inteligência de software para cercar o evento, no extremo oposto da tecnologia, muitas horas poderão ser dispendidas para recuperar um borrão e constatar o óbvio, que é, de fato, que houve um roubo… Isto pode representar a diferença entre muitas horas de investigação e alguns poucos minutos, e a recuperação de uma evidência útil contra uma prova imprestável.

 Os softwares de gerenciamento são igualmente importantes e permitem delimitar o perímetro de investigação na tela, por meio de janelas, tornando muito mais fácil localizar um evento. Desta forma, precisão, qualidade, inteligência de software são fatores diretamente associados à qualidade, eficiência e precisão da prova colhida, podendo representar a diferença entre um sistema de vigiância do tipo “faz de conta” e um sistema confiável e eficiente.

Outros fatores

Zoom, Pan, Tilt, ou PTZ, denomina aquelas câmeras motorizadas capazes de realizar rotações longitudinais e latitudinais. Novamente aqui, a qualidade do movimento está associada ao “motor de passo”. Uma câmera PTZ de qualidade superior apresentará maior durabilidade e fineza nos movimentos. Com relação ao Zoom, tanto no ótico, como no digital, há que se tomar cuidado. Aqui fala mais alta a qualidade das lentes e do processador de imagem. Estes fatores irão determinar o alcance da câmera e a perscrutação de detalhes, bem como o campo de visão e agilidade.

Câmeras Externas x Câmeras Internas

As câmeras externas devem suportar a maior intensidade de luz solar e estar protegidas por domos apropriados, aderentes ao padrão IP66. Por estarem expostas a intempéries e grande irradiação solar, é necessário que tais câmeras sejam capazes de compensar as condições de iluminação, o que pressupõe a existência de auto-íris. Câmeras não apropriadas para uso externo podem sofrer danos com o passar do tempo, como a destruição do CCD. Desta forma, câmeras para uso externo devem ser fabricadas espcificamente para este fim, e estar protegidas por domos apropriados. Além disto, devem funcionar tão bem durante o dia como à noite, com baixa iluminação. Aqui os fatores sensibilidade efetiva (lux), qualidade da imagem durante o dia e à noite são fatores determinantes.

Por outro lado, câmeras de uso interno podem ser de foco fixo e apropriadas para uma menor variação de intensidade de luz. No entanto, cabe ressaltar que dependendo do ambiente a câmera deve ser capaz de compensar a luz de fundo de um objeto o pessoa, visto que uma intensidade de luz de fundo elevada pode escurecer demasiadamente o objeto foco de observação. Desta forma, é necessário fazer medições reais a fim de mensurar as condições reais de utilização.

Um outro cuidado a tomar é quanto à sensibilidade (lux)  apregoada por certas câmeras. O fato de a câmera ser sensível a pouca luminosidade (lux reduzido), não necessariamente significa que ela é capaz de captar a imagem com boa qualidade sob condições de baixa iluminação. A câmera pode de fato ser bastante sensível e oferecer uma péssima qualidade de imagem.

Como todo equipamento de rede, toda câmera IP é interligada à Rede local, através de uma porta de switch. É possível adaptar AP´s para projetar a imagem em uma rede Wireless. Algumas câmeras possuem Wireless embutido. Tal facilidade pode reduzir substancialmente o gasto com infraestrutura nova.

Uma câmera IP pode ser publicada na Internet e ser acessada de qualquer localidade. A câmera fica posicionada na rede interna e o acesso à mesma somente é possível por meio usuário e senha. Em termos gerais, toda câmera IP é um servidor de imagens na Net. Devemos atentar também para os níveis de segurança que tais câmeras podem oferecer quanto ao acesso não autorizado.

Quando se escolhe uma câmera IP, outros fatores principais a serem observados são:

• Tipo de Sensor
• Sensibilidade (lux)
• Suporte a Dia/Noite 
• Tipo de lente (varifocal, foco fixo, auto-iris, auto-foco, zoom ótico e digital)
• Fixa ou PTZ
• Resolução Pixels
• Deteção de Movimento, áudio,
• Tipo de comunicação, se é bidirecional
• Compressão de video suportada (MJPEG, MPEG4, H.264)
• Amplitude de Pan e Tilt

 A escolha da câmera
 

 A escolha da câmera apropriada diz respeito, evidentemente, à real necessidade verificada, dado que o custo de uma câmera de concepção mais simples é substancialmente menor do que o topo de linha. Desta forma, o tipo de câmera escolhido deve estar alinhado com o orçamento e o desempenho pretendido. Em diversas ocasições a câmera de foco fixo e menor sensibilidade (em lux) será perfeitamente apropriada. Em outras situações seu desempenho poderia comprometer o sistema de vigilância e apresentar um resultado bastante insatisfatório.

Os fabricantes de câmeras costumam oferecer sistemas de gerenciamento próprios para controle e gerenciamento de câmeras. Contudo, quando se deseja controlar múltiplas câmeras, sistemas desenvolvidos por parceiros dos fabricantes costumam apresentar um desempenho bastante superior aos sistemas próprios dos fabricantes.

Por fim, devemos sempre levar em conta os valores que serão vigiados, o perímetro de vigilância e a criticidade em função do risco. Portanto, para locais de baixo risco e baixo valor envolvido, onde se pretende apenas acompanhar o que está acontecendo, um sistema de baixo custo seria mandatório, tomando-se o cuidado mínimo necessário com a qualidade da imagem coletada. Para locais onde os valores e riscos envolvidos são elevados, podemos entender a câmera como um componente do “seguro contra risco”, que possibilita reduzir a vulnerabilidade e os riscos de perda material mais elevados. Entendo-se o custo da câmera como uma proporção dos valores envolvidos, materiais e imateriais, poderemos ter uma melhor idéia do orçamento mais apropriado. Abaixo a ilustração mostra a diferença entre o vídeo entrelaçado e o progressive scan.

Progressive Scan                                                                  Entrelaçado

 As figuras abaixo ilustram a diferença entre uma imagem congelada obtida a partir do Progressive Scan e outra obtida através do modo entrelaçado.

Progressive Scan                                                                   Entrelaçado

Fonte: Axis Project Guide

Muitas vezes a teoria encontra-se divorciada e até mesmo em conflito com a prática, o que nos leva a encarar situações insólitas, onde o bom-senso é a primeira vítima de um processo de implantação. É como se ao iniciar um projeto todo o aprendizado teórico e formal fosse esquecido sob  soleira de alguma porta. Reunimos informação e experiência de mais de 20 anos com projetos com as mais diversas complexidades, mas seguimos no Brasil lutando por inserir a boa prática de projetos no dia-a-dia de nossos interlocutores. Pregamos que a boa prática e a teoria tem lugar no nosso dia-a-dia e a cultura brasileira do jeitinho e do funcionar de “qualquer jeito” não tem mais lugar no mundo de hoje.

O aprendizado faz-se com erros e acertos e aprendemos muito com nossos erros e os erros dos clientes, o que subsidiará informação suficiente para que, pelo menos, não reeditemos estes erros, o que tem sido, por incrível que pareça, recorrente. Atribuímos tudo isto à cultura muito peculiar do brasileiro, como pretendemos mostrar com os “causos” que contaremos. Por uma questão ética autoevidente, e embora tratem-se de casos reais, devidamente comprovados e testemunhados, omitiremos todo e qualquer nome de pessoa ou cliente das narrativas aqui versadas.