VoIP - Voice over IP

Transportando Voz sobre uma Rede de Pacotes

             O mais comum hoje em dia ainda é o sistema analógico que opera sob a tecnologia da comutação de circuitos. Este apresenta diversas vantagens como:

 

 

Mas esse sistema também apresenta sérias desvantagens:

 

 

Um primeiro passo na evolução das redes telefônicas foi o surgimento da rede telefônica digital. Esse sistema tinha como base a digitalização do sinal de voz, o que era feito através de 3 etapas: amostragem, quantização e codificação.

 

A amostragem denota o processo de se considerar determinado sinal apenas em instantes discretos de tempo que seriam múltiplos de um intervalo fixo de tempo. A quantização é considerar a amplitude deste sinal apenas em níveis discretos. Após estes dois processos, o sinal será discreto tanto no tempo quanto na amplitude. Contudo, a seguir, é necessário que se encontre uma forma através da qual este sinal amostrado e quantizado será representado, ou melhor, traduzido, na forma de 0’s e 1’s.

 

Na rede telefônica digital fixa convencional, é usada uma freqüência de amostragem de 8 KHz, 256 níveis para a quantização, representados por 8 bits e a forma de quantização do sinal é através da chamada PCM, ou Pulse Code Modulation. Nesta forma de codificação, como foi mostrado, cada amostra será representada por 8 bits (que denotarão 256 níveis discretos e igualmente espaçados de amplitude) e existirão 8000 amostras em um segundo. A conversão de analógico para digital se dá na primeira central local.

 

Desta forma, era possível se dar mais um passo na evolução da rede telefônica. Neste próximo passo, aquela desvantagem de monopólio de pares de cabos por conexão ativa poderia ser solucionado. Através da Time Division Multiplexing, ou TDM, cada cabo é utilizado por mais de usuário da seguinte forma: abrem-se janelas de tempo, uma para cada usuário, de modo que cada usuário utilize o cabo em questão durante um certo intervalo de tempo. Assim, como esse intervalo de tempo é extremamente reduzido, se tem a impressão que a conversação se dá de forma contínua de maneira que há vários usuários utilizando o mesmo cabo.

 

Com a tecnologia digital, foi possível uma série de melhorias, tais como:

 

 

Uma característica muito importante do sinal de voz típico de que cada participante fala em torno de 35% do tempo. Dessa forma, surge intuitivamente a idéia de se usar uma conexão que já está sendo usada quando o usuário que a estiver usando estiver em silêncio. Isso se chama Multiplexação Estatística. Contudo, tal prática é muito suscetível a introduzir atrasos variáveis. Isso ocorre pelo fato de que certas vezes, o silêncio de um usuário coincide com a fala de outro. Mas quando isso não ocorre, o que acontece é um aumento no atraso introduzido pela rede. Esse atraso variável é denominado jitter. Isso é ilustrado na figura abaixo:

 

 

 


 

 

      

 

 

 

 

De posse de todas essas inovações, pode-se dizer que a próxima geração de rede telefônica possuirá as seguintes características:

 

 

As principais tecnologias que são candidatas a implementar essa próxima geração são:

 

 

Contudo, Voz sobre IP se mostra como sendo a melhor pelas seguintes características:

 

Dentro da tecnologia IP, os roteadores são dispositivos que já funcionam se aproveitando da Multiplexação Estatística e, devido a isso, enfrentam constantemente o problema do jitter.

 

Pelo que foi visto até agora, têm-se claramente dois problemas básicos em relação à transmissão da voz através de uma rede de comutação de pacotes:

 

 

Para resolver o problema da alta taxa de transmissão, deve-se usar uma codificação do sinal de voz que forneça uma baixa taxa de transmissão e, para resolver o problema do jitter, deve-se usar algum tipo de compensador que suavize sua presença.

 

Veremos primeiro a questão da codificação. Para isso, faremos uma análise mais profunda da codificação de sinais. A codificação tem um objetivo básico: diminuir a taxa de transmissão de dados de forma a manter a qualidade a melhor possível.

 

Dentro desta condição, podemos identificar 3 tipos de codificadores: os codificadores de forma de onda, os codificadores de fonte ou paramétricos e os híbridos.

 

Codificadores de forma de onda têm uma abordagem no domínio do tempo e são os mais intuitivos de se pensar. Eles têm como objetivo codificar o sinal considerando apenas a sua forma de onda, sem considerar nenhuma outra característica. Esse tipo de codificação se dá do modo como foi explicado anteriormente, isto é, após as etapas de amostragem e quantização. Assim o que é codificado é a seqüência de amostras, isto é, suas amplitudes. Tal codificação pode ser a PCM, como dito acima, DPCM, ou Differential Pulse Code Modulation, onde o que é codificado é a diferença entre as amostras consecutivas, ou ADPCM, que é a versão adaptativa desta última.

 

Codificadores de fonte ou paramétricos têm uma abordagem no domínio da freqüência. Eles têm como objetivo codificar o sinal considerando apenas o modo através do qual este foi gerado, ou seja, sua fonte. No caso da voz, a fonte é o próprio trato vocal da pessoa que fala. O que é feito é parametrizar características da fonte em várias janelas ao longo da produção do sinal em questão. No caso da voz, essas características são: se o som é vozeado (faz as cordas vocais vibrarem), se é não vozeado (não faz as cordas vocais vibrarem), o pitch do sinal e, finalmente, o filtro digital que modela o trato vocal. Esta última característica é obtida através da análise LPC aplicada a uma janela do sinal. Exemplos de codificadores de fonte são o Vocoder LPC, o RELP e o QV.

 

Contudo, codificadores de forma de onda têm uma relação de “qualidade x taxa de transmissão” de quase 1 para 1, ou seja, para a qualidade aumentar, deve-se aumentar igualmente taxa de transmissão. Isso é extremamente ruim, pois, se um sinal deve ser transmitido, deve ser com a menor taxa de transmissão possível. Codificadores de fonte  possuem uma taxa de transmissão muito baixa, mas, por mais que se aumente esta taxa, a qualidade não melhora. Assim, codificadores de forma de onda possuem uma qualidade muito boa, mas uma taxa de transmissão muito alta; e codificadores de fonte possuem uma qualidade muito ruim, mas uma taxa de transmissão muito baixa.

 

Para resolver este problema, o que é utilizado é o codificador híbrido, que junta características de ambos os codificadores citados acima. Dessa maneira, podemos ter uma qualidade muito boa com baixas taxas de transmissão. Um exemplo para esse tipo de codificador é o CELP (Code Excited Linear Prediction).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Os padrões mais recentes para codificadores de voz da ITU são G.728, G.729, G.729A e o G.723.1. Estes diferem pelo custo e pela qualidade, mas a tendência é que todos estes se unifiquem em um único padrão. Devido à menor capacidade das redes, os algoritmos tendem a ser cada vez mais complexos, para gerar uma taxa de transmissão mais baixa, de modo a não aumentar o atraso introduzido.

 

Para compensar esse atraso que foi introduzido, e que, como já sabemos, é variável e é denominado jitter, é usado um conjunto de protocolos. Esse conjunto é o RTP (Real-time Protocol) e RTCP (Real-time Control Protocol). São usados desde as primeiras ferramentas para conferências disponíveis na internet. É a estrutura geral de um protocolo que possibilita o transporte de dados em tempo real sobre IP.

 

O RTP tem como objetivo permitir que os receptores compensem o efeito do jitter e a perda da seqüência de pacotes. Isso é feito através da definição da forma através da qual pacotes IP (que carregam dados assíncronos) serão formatados. Esses dados são: informação sobre o tipo de dado (denominado Payload), timestamp e numeração das seqüências.

 

O RTCP é usado em conjunto com RTP para se obter retorno sobre qualidade do serviço. Esta pode ser medida em função da quantidade de jitter e da perda média de pacotes. Além disso, pode-se obter informação sobre a identidade dos participantes.

 

Apesar do que parece, o RTP/RTCP não possue nenhuma influência sobre o comportamento da rede IP, não podendo controlar a QoS. A compensação do jitter é feita através de controle de buffer e de seqüenciamento apropriado. Assim, permitem a obtenção de informações que permitem a tomada de decisão sobre adoção de medidas corretivas, como redundância e uso de codecs de voz com menor taxa de transmissão.

 

Estes protocolos podem ser usados sobre qualquer outro protocolo da rede. Entretanto, são usados principalmente sobre UDP. Isso porque o TCP não é adequado pois este protocolo não é adaptado para retransmissão de dados que só toleram baixa latência. Isso acontece pois, freqüentemente, o TCP requisita retransmissão de pacotes que chegam com grande quantidade de erros. Isso é difícil de se tolerar em transmissões que sejam em tempo real.

 

O número de seqüência e o timestamp definidos pelo protocolo RTP têm como objetivo permitir com que uma aplicação, por exemplo, possa determinar que vai armazenar 100 ms de fala no buffer antes de iniciar sua reprodução. Dessa forma, quando um novo pacote RTP chega, ele é colocado no buffer de acordo com o número de seqüência na posição adequada. O timestamp é formatado segundo o formato NTP.

 

O tipo de payload (payload type ou PT) é o tipo de informação ou dado em tempo real contido em cada pacote . É benéfico saber o tipo de dado pois assim não se gasta tempo averiguando o conteúdo do pacote para saber o formato da informação que carrega.

 

Pode-se definir então a chamada “Sessão RTP” como a associação de participantes que se comunicam no RTP. Cada participante utiliza dois endereços de transporte (no caso de ser uma rede IP, são duas portas UDP na máquina local): um para o fluxo RTP e o outro para as mensagens RTCP. Se for multicast, todos usariam o mesmo par de endereços de transporte multicast. Dessa forma, fluxos de dados da mesma sessão devem compartilhar um canal RTCP comum.

 

Outras definições importantes são sobre SSRC e CSRC. A Fonte Sincronização SSRC é uma fonte de fluxo RTP e é denotada por um campo de 32 bits do cabeçalho do pacote RTP. Pacotes com o mesmo SSRC tem uma mesma referência de tempo e sequenciamento. A Fonte Contribuinte CSRC é um SSRC que faz parte de um grupo de SSRCs que foram combinados por um misturador (mixer) RTP. Este também é um campo do pacote RTP.

 

 

 

Pacote RTP

 

 

            Todos os campos que precedem a lista de CSRC estão sempre presentes em um pacote RTP. A lista CSRC está presente apenas depois de um misturador e, portanto, não estará presente no contexto do H.323.

 

            Descrição do pacote RTP:

 

-         2 bits são reservados para a versão do RTP.

-         Um bit de padding (P) indica se o payload sofreu enchimento para fins de alinhamento. Se tiver havido enchimento (P=1), então o último octeto do campo de payload indica precisamente quantos octetos de enchimento foram acrescentados ao payload original.

-         Um bit de extensão X indica a presença de extensões após eventuais CSRCs do cabeçalho fixo.

-         O contador CSRC (CC) 4 bits informa quantos identificadores CSRC vêm após o cabeçalho fixo. O valor de CC pode ir de zero (o mais usual) a 15.

-         Marcador (M): 1 bit. O seu uso é definido pelo perfil RTP. O H.225.0 informa que, para codificações de áudio que suportam supressão de silêncio, ele deve ser colocado em 1 no primeiro pacote de cada período de fala subseqüente a um período de silêncio.

-         Tipo de payload (PT): 7 bits.

-         Número de seqüência: 16 bits. Começa com um valor aleatório e é incrementado a cada pacote RTP

-         Timestamp: 32 bits. A freqüência do clock é definida de maneira diversa para cada tipo de payload. Por exemplo, o payload no H.261 usa um clock de 90 kHZ para o timestamp. Para a maioria dos codecs de áudio, a freqüência do clock RTP é colocada em 8000 Hz. O clock é sempre inicializado com um vetor aleatório e alimenta um contador de pulsos de clock. Se o payload contiver vídeo, o timestamp desse pacote RTP será o valor da contagem de pulsos de clock no instante em que foi obtido o primeiro quadro de vídeo codificado inserido no payload desse pacote. No caso de áudio, o timestamp RTP é o valor da contagem de pulsos de  clock no momento em que a primeira amostra de áudio contida no payload foi produzida.

 

RTCP

 

            O RTCP é usado para transmitir aos participantes, de tempos em tempos, pacotes de controle relativos a uma sessão em particular. Esses pacotes de controle podem incluir informações a respeito dos participantes(nome, endereço, e-mail,etc) e informações sobre o mapeamento dos participantes em suas fontes de fluxo individuais. A informação mais útil no contexto do H.323 é aquela que diz respeito à qualidade de transmissão na rede. Todos os participantes das sessões enviam pacotes RTCP; os transmissores enviam sender reports e os receptores, receiver reports.

 

            Tipos de pacotes RTCP:

-         SR (Sender Reports): contêm informações de transmissão e recepção para transmissores ativos

-         RR (Receiver Reports): contêm informações de recepção para ouvintes que não sejam também transmissores ativos.

-         SDES (Source Description): descrevem vários parâmetros da fonte.

-         BYE: enviado por um participante quando ele abandona a conferência

-         APP: funções específicas de uma aplicação.

 

Os pacotes SDES, BYE e APP não são usados no H.323.

 

           

Pacotes SR(Sender Report) e RR(Receiver Report)

           

           

 

            Cada SR contém três seções obrigatórias.

            A primeira seção contém:

-         o contador de relarórios de recepção(RC), de 5 bits, que é o número de blocos de relatórios incluídos neste SR.

-         o tipo de payload (PT), que é 200 para um SR.

-         o tamanho desse SR, representado em 16 bits, que inclui o cabeçalho e o enchimento e expressa o número de palavras de 32 bits menos1.

-         O SSRC do originador desse SR. Esse SSRC também estará nos pacotes RTP originados a partir dessa estação.

 

A segunda seção contém informações a respeito do fluxo RTP enviado por esse transmissor:

-         o timestamp NTP do instante de tempo que se dá o envio desse relatório. Um transmissor pode fixar o bit de mais alta ordem em 0 se ele não conseguir obter o tempo NTP absoluto e este é apenas um valor NTP relativo ao início da seção. Se um transmissor não conseguir obter o tempo transcorrido, ele poderá fixar o timestamp em 0

-         o timestamp RTP, que representa o mesmo tempo que anteriormente, mas com as mesmas unidades e um offset aleatório, como ocorre nos timestamps dos pacotes RTP.

-         A contagem de pacotes do transmissor (32 bits), do início dessa sessão até esse SR. Ele é reinicializado em zero se o SSRC tiver de mudar (isso pode acontecer em uma conferência  H.323 com diversos participantes, quando o MC ativo especifica número de terminais).

-         A contagem de octetos do payload do transmissor(32 bits), desde o início dessa sessão. Também é reinicializado em zero se o SSRC mudar.

 

 

A terceira seção contém um conjunto de blocos de relatórios de recepção, um para cada fonte da qual esse transmissor teve conhecimento desde o último RR ou SR.

- SSRC_n (identificador da fonte): 32 bits – o SSRC da fonte a respeito

              do qual se está relatando.

           

- fração perdida: 8 bits – pacotes recebidos / pacotes esperados.

             

número cumulativo de pacotes perdidos: 24 bits – desde o início da

  recepção. Pacotes atrasados não são contados como perdidos e

  pacotes duplicados são contados como recebidos.

           

- valor estendido do mais alto número de seqüência recebido: 32 bits –

  os 16 bits mais significativos contêm o número de ciclos de números de

  seqüência e os últimos 16 bits contêm o mais alto número de sequência

  recebido em um pacote RTP proveniente dessa fonte (mesmo SSRC).

 

- jitter entre chegadas: 32 bits – uma estimativa da variância do tempo

  entre chegadas subsequentes de pacotes RTP.

- último timestamp SR (LSR): 32 bits – os 32 bits do meio do timestamp

  NTP do último SR recebido (forma NTP compacta)

           

- atraso desde o último SR recebido (DLSR): 32 bits – expresso na forma

  NTP compacta. Junto com o último timestamp SR, o transmissor desse

  último SR pode usá-lo para calcular o tempo de ida-e-volta (round trip

  time) .

 

            Um RR(Receiver Report)

 se parece com um SR, exceto pelo fato de que o campo PT é agora 201 e a segunda seção (relativa ao transmissor) não está presente. Ele pode ser usado por receptores passivos que geram fluxos RTP.

 

Padrões de VoIP

 

            Os principais padrões de VoIP são o H.323, o SIP(Session Initialization Protocol) e o MGCP(Media Gateway Controller Protocol). Mas, de fato, apenas o H323 e o SIP podem ser vistos como concorrentes diretos: ambos almejam ser implementados por estações multimídia ‘inteligentes’, e H.323 é considerado mais complexo que o SIP, pois ele usa uma configuração binária ASN.1, o que não é nenhum obstáculo para qualquer programador. O MGCP é mais um esforço de criar um leve, com base em estímulos, para gateways e outros dispositivos e que possa ser usado em conjunto tanto com o H.323 quanto com o SIP.

 

O padrão H.323

 

            O H.323 é uma especificação guarda-chuva que descreve de maneira completa a arquitetura e a operação de um sistema de videoconferências sobre uma rede de pacotes. O H.323 não é específico para IP, pode ser usado sobre IPX/SPX ou ATM (Asyncronous Transfer Mode). A estrutura do H.323 é completa e inclui a especificação de:

 

-         terminais de videoconferência

-         gateways entre uma rede H.323 e outras redes de voz e vídeo

-         gatekeepers, que são a parte inteligente da rede H.323, realizando o registro de terminais, admissão de chamadas e muito mais

-         blocos funcionais MCU(Multipoint Control Unit), MC (Multipoint Controller) e MP(Multipoint Processor) usados para conferências com diversos participantes.

 

O H.323 descreve também como vários protocolos de comunicação são usados entre estas unidades:

 

-         o ‘canal de sinalização de chamadas’, usado durante as fases de estabelecimento e de terminação da chamada e que parecerá familiar para qualquer um que tenha estudado redes ISDN; de fato, ele usa o formato de mensagens do Q.931 e o estende usando o elemento de informação de usuário para usuário. Esse canal de sinalização de chamadas é descrito em detalhes no H.225.0.

-    o canal de RAS (Registration Admission Status)

-         o canal de controle H.245, que é aberto no início no início da chamada ara negociar um conjunto comum de codecs e permanece em uso durante toda a chamada para transportar algumas mensagens de controle.

 

pilha de protocolos do H.323

 

Procedimento para estabelecimento de uma chamada H.323 fim-a-fim:

 

-

através do canal RAS o terminal chamador envia um “Admission

Request” ao gatekeeper e este se aceitar o pedido retorna  uma

uma mensagem “Adimission Confirm” caso contrário retorna

“Admission Reject”.

- a conexão TCP inicial pelo canal de sinalização de chamadas (Q.931)

é feita do terminal chamador para uma porta conhecida do terminal

chamado.

- após o recebimento da chamada, o terminal chamado espera por uma

segunda conexão TCP em uma porta dinâmica e o número dessa porta

é informado por uma mensagem de aceitação de chamada.

- terminal chamador estabelece o canal de controle de chamadas H.245

            com essa porta.

- O H.245 é usado para sinalizar abertura de canais lógicos para áudio e

vídeo, ou seja, sessões RTP são criados para os diversos fluxos de mídia.

 

O H.323 e o SIP

 

            Principais observações a se fazer ao compararmos o H.323 e o SIP:

 

- O SIP apresenta maior simplicidade implicando em maior velocidade.

- O SIP foi projetado para funcionar em backbones com capacidade para

  multicast, não apenas para fluxos de multimídia, como o H.323, mas também

              para mensagens de sinalização.

-          

            - O H.323 faz uma distinção clara entre os tipos de mídia que podem ser enviados

  ou recebidos.

- No SIP não há nenhum procedimento para abrir uma conexão de mídia em

             separado do ato de efetivamente enviar a mídia.

           

 

- O H.323 possui recursos poderosos para controle de conferências.

 

 

Futuro da Multimídia sobre IP

 

Em breve, as redes de transporte SDH e SONET transportarão mais dados do que voz e , quando isso ocorrer, a utilização de voz em pacotes será uma escolha bastante provável. A seguir apresenta-se o gráfico que mostra o crescimento do tráfego de dados e de voz.

           

           

 

            Se projetarmos alguns anos à frente, com as linhas xDSL conectadas a backbones multigigabit, telefones IP em hardware com canceladores de eco de última geração e um novo codificador de banda larga, teremos uma qualidade de som e vídeo melhor que a das redes ISDN.