Consumo de uma ligação VoIP

Ao usar um PBX hosted é necessário que se estabeleça um comparativo entre as opções que este tipo de serviço prove a quem o procura.
As limitações estão normalmente na quantidade de chamadas que podem ser executadas simultaneamente, na quantidade de minutos que será usado mensalmente e nos serviços que estarão a disposição do usuário.

Todas as limitações variam de acordo com a opção de serviço escolhida pelo interessado, mas nesse artigo de hoje o quero mostrar é a quantidade de megabytes que um minuto de chamada VoIP consome, dessa forma o usuário poderá estabelecer seus critérios tanto para a compra de um serviço PBX hosted quanto para a compra de um pacote de transmissão de dados através do uso de um celular 3G por exemplo.

Com os dados será possível realizar o calculo de custo da chamada, que será composto pelo custo do pacote minutos e mais o custo do minuto VoIP, tendo os dados do pacote você fará a seguinte conta, pega-se quanto de trafego ele permite e divide-se pelo consumo de um minuto de ligação e depois pega-se a quantia de minutos possíveis e o preço fazendo a divisão de um pelo outro teremos o custo do minuto falado e a esse valor adiciona-se o valor do minuto VoIP ai teremos quanto custa uma ligação VoIP usando-se um 3G.

O serviço de ramais mais popular entre os brasileiros é o PBXES este serviço de PBX hosted com ramais VoIP tem a seguinte característica quando se trata de consumo, um minuto de voz transmitida é igual a 2mb.

É muito importante o usuário estar ciente de determinadas questões e o consumo é uma dessas questões. O que tenho visto é que os usuários e técnicos de VoIP tem uma grande falta de interesse em se ater as questões pertinentes a funcionamento e muito aprofundamento na questão do preço do minuto VoIP e no tipo de pacote que o provedor VoIP esta oferecendo, muitas vezes esses pacotes contém uma proposta que na realidade é inviável e o usuário por falta de conhecimento acaba se iludindo. Caso prático desses pacotes é o VoIP Ilimitado, onde a palavra ilimitada ganha vários números, o mais comum são 3000 minutos, mas na realidade ao se comprar uma conta ilimitada muitas vezes não se pensa que para uma residência 3000 é uma quantia de minutos que nunca se usa e também que um serviço VoIP onde se tem um canal nunca atingirá essa marca.

A partir dessas observações me pego pensando que as pessoas têm muito tempo livre, ou que o tempo não tem custo, acredito que o bom uso e o conhecimento dos recursos levam fatalmente a uma maior economia a médio longo prazo do que a simples batalha pelo serviço com preços ridiculamente baixo, que nunca é tão baixo assim.

Eu vou descrever aqui como funciona o consumo de uma chamada Voip para que todos possam avaliar.

O codec G711 usa em média 90kbps e o G729 usa em média 30kbps, a formula usada para o calculo de consumo é:

MB per hour used =kbps *3600 (seconds in an hour) = kilobits per hour kilobits per hour /1024 (convert into megabits)=megabits per hour megabits per hour /8 (8 bits in a byte) = Megabytes (MB) per hour.

Complicado? Então vai mastigado

G711 = (90x3600) /1024 /8 = em torno de 40MB por hora.
G729 = (30x3600) /1024 /8 = em torno de 13MB por hora.

Lembrando que esse consumo é um consumo com base a um lado da chamada, e que para uma ligação ha dois lados o consumo deve ser dobrado.
Para minorar a situação existe a supressão do silencio que é um assunto que vamos deixar para uma próxima vez. (VAD)

Consumo de Banda:

Bandwidth
* GIPS Family - 13.3 Kbps and up
* GSM - 13 Kbps (full rate), 20ms frame size
* iLBC - 15Kbps,20ms frame size: 13.3 Kbps, 30ms frame size
* ITU G.711 - 64 Kbps, sample-based Also known as alaw/ulaw
* ITU G.722 - 48/56/64 Kbps ADPCM 7Khz audio bandwidth
* ITU G.722.1 - 24/32 Kbps 7Khz audio bandwidth (based on Polycom's SIREN codec)
* ITU G.722.1C - 32 Kbps, a Polycom extension, 14Khz audio bandwidth
* ITU G.722.2 - 6.6Kbps to 23.85Kbps. Also known as AMR-WB. CELP 7Khz audio bandwidth
* ITU G.723.1 - 5.3/6.3 Kbps, 30ms frame size
* ITU G.726 - 16/24/32/40 Kbps
* ITU G.728 - 16 Kbps
* ITU G.729 - 8 Kbps, 10ms frame size
* Speex - 2.15 to 44.2 Kbps
* LPC10 - 2.5 Kbps
* DoD CELP - 4.8 Kbps

Abaixo temos uma parte do artigo em inglês, porque não ha motivo para a tradução, uma vez que o que mais importa é a relação do consumo por tipos de rede e isso pode ser identificado no texto com facilidade.

With circuit-switched voice networks, all voice calls use 64 Kbps fixed-bandwidth links regardless of how much of the conversation is speech and how much is silence. With VoIP networks, all conversation and silence is packetized. Using Voice Activity Detection (VAD), packets of silence can be suppressed.

A G.711 call on a Frame Relay connection without IP/RTP header compression or VAD should take about 82.4 kbps. The formula I'm using for this is:
{(64,000 / 50) + 320 + 48} * 50
The 320 is for the IP, UDP, and RTP headers (in bits) and the 48 is for Frame Relay headers (also in bits).

I came up with the 50 by assuming a rate of one packet every 20ms, which is the default. 64,000 is obviously the bandwidth used by G.711. For G.729, the formula is the same just use 8,000 instead.

For Ethernet, instead use 112 bits (14 bytes) for the Layer 2 overhead and you'll come up with:
{(64,000 / 50) + 320 + 112} * 50 = 85.6 kbps

For an IPSec VPN, overhead is roughly 4X as much (estimate 480 bits). So you get:
{(64,000 / 50) + 320 + 480} * 50 = 100.4 kbps

If you've enabled IP/RTP header compression the overhead goes from 320 bits to 16-32 bits. This doesn't make a huge difference with G.711, but with G.729 the bandwidth savings are quite significant (as much as over 50%)

G.729 on Frame Relay without IP/RTP header compression:
{(8,000 / 50) + 320 + 48} * 50 = 26.4 kbps

Same but with IP/RTP header compression:
{(8,000 / 50) + 32 + 48} * 50 = 12.0 kbps

VoIP qualidade e confiabilidade

Dois dos maiores desafios da tecnologia de transmissão de voz através de uma rede IP são a confiabilidade e a qualidade da transmissão.

A confiabilidade esta ligada ao fato de que a chamada tem que chegar ate o destino e a qualidade tem relação com a forma como esta chamada irá chegar. Para atingir minimamente estes desafios será necessário que tenhamos certeza que ao realizar uma chamada o outro lado irá receber e recebendo tenha condições de entender o que esta sendo dito na chamada.

Estes desafios são frutos de questões simples, mas a primeira delas é que a chamada VoIP ira sair de uma rede local onde pode haver controle de tráfego e qualidade e irá trafegar por um período de tempo em uma rede onde não há a menor chance de ter-se um controle ainda que mínimo, pois a chamada ao entrar na rede Internet não nos permite prever os acontecimentos que irão ocorrer no momento da transmissão.

Todos esperamos que as empresas ligadas ao serviço de Internet estejam fazendo sua lição de casa e que com isso nossa chamada possa chegar ao seu destino, e ai teremos a primeira etapa, após esta teremos que ter certeza que os envolvidos estejam comprometidos com a qualidade das transmissões e dessa forma nossa chamada chegará audível e na ordem correta.

Temos na cadeia de fatores que estão diretamente ligados a confiabilidade e qualidade de uma transmissão de voz através da rede os seguintes interventores: NAT Transversal, ICE e STUN e vou colocar um pouco de cada um neste artigo e para os que quiserem se aprofundar é só usar o Google escrevendo : VoIP realibility and quality ou então associando o termo VoIP com cada um dos termos citados.

NAT acrônimo do inglês Network Address Translation, ou seja, o responsável pela tradução dos endereços IP. Em muitos casos essa tradução não é necessária, mas em outras ocasiões sim, por exemplo, quando usa-se uma rede particular com endereço privado e as estações desta rede irão acessar acessem a Internet. Dessa forma, se a estação 10.1.1.2 necessita acessar um servidor na internet, então será necessário traduzir o endereço 10.1.1.2 para um endereço conhecido. O principal protocolo usado para tramissão na Internet é o TCP e no caso do VoIP o UDP, estes protocolos se utilizamd do conceito de multiplexação através de portas de origem e destino, nos permitinod utilizar somente um endereço IP público para traduzir vários endereços privados (NAT masquerade ou NAT Hide), com a utilização de portas diferentes e armazenando todas estas informações em uma tabela de conexões.

O NAT Traversal verifica se os equipamentos envolvidos no estabelecimento da conexão possuem suporte para NAT Traversal, a seguir os equipamentos devem detectar se existe ou não a tradução de endereços. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados.
Este recurso pode ser utilizado com conexões VPN do tipo gateway-to-gateway ou client-to-gateway e deve ser verificado na documentação do equipamento se o mesmo suporta NAT Traversal ou UDP Encapsulation (expressão também utilizada por alguns fabricantes).

STUN acrônimo de Simple Traversal of UDP através de NATs (Network Address Translation) é um protocolo para auxiliar os dispositivos que se encontrem atrás de um NAT firewall ou mesmo de um roteador. A RFC 5389 esta redefinindo o termo STUN como 'Session Traversal Utilities for NAT'. Um servidor STUN ((Simple Traversal of User Datagram Protocol [UDP], por meio da Network Address Translators [NATs]), é um servidor que permite que clientes NAT (ex.: computadores protegidos por firewall) realizem chamadas telefônicas a um provedor VoIP que se encontre fora da rede local.

O servidor STUN permite que os clientes descubram seu endereço público, o tipo de NAT utilizado, e o lado da porta da Internet associada à NAT com uma porta local específica. Essas informações são usadas para permitir a comunicação UDP entre o cliente e o provedor VoIP, e então, estabelecer a chamada. O protocolo STUN é definido pela RFC 3489 e a porta comumente usada por um servidor STUN é a porta UDP 3478.

ICE ancronismo de Interactive Connectivity Establishment, ICE não é um novo protocolo, mas uma metodologia que faz uso de protocolos existentes, tais como o STUN Simple Traversal of UDP Through NAT (STUN), o Traversal Using Relay NAT (TURN) inclusive usa o Real Specific IP (RSIP).
O ICE funciona através de uma cooperação mútua de ambos os parâmetros finais de um diálogo SIP.

Com o trabalho em conjunto de endpoints NAT Traversal, uma série de propriedades importantes são obtidas. O ICE sempre funciona, independente do tipo ou número de NATs, e sempre representa a solução mais barata para transporte de um “Carrier”. Este método cria uma latência mínima em voz sobre IP, e pode ser usado sem aumentar o delay de uma chamada. O ICE é bem mais robusto que o STUN, sendo que o ICE também facilita a transição da Internet do IPv4 para o IPv6, dando suporte para as chamadas entre dual-stack e clientes IPV6 atrás de um NAT. Em algumas condições o STUN pode ser usado em conjunto com o ICE, para garantir que o telefone nunca toque a menos que os utilizadores possam tanto ouvir e ver uns aos outros.

Existem muitas teorias que estão em estudo e muitos trabalhos que estão sendo realizados e em fase de implantação para garantir a qualidade e a confiabilidade do trafego na Internet e estas ações irão em um futuro muito próximo aumentar a qualidade e a confiabilidade das transmissões de voz através da rede IP e consequentemente melhorar sobremaneira o VoIP.