Voz sobre IP- Tecnologia e tendências

44
Voz sobre IP- Tecnologia e tendências Ricardo Balbinot 1 , Jorge Guedes Silveira 1 , Fladhimyr Câmara Castello 2 , Pedro Martins dos Santos 2 , Alexandre da Silva Quadra 1 1 Faculdade de Engenharia– Pontifícia Universidade Católica do Rio Grande do Sul T.: 51-33203500 R: 4056 SR: 223 Pr. 30 Sl. 151 – Av. Ipiranga, 6681 – Porto Alegre – RS – Brasil 2 Programa de Pós-Graduação em Engenharia Elétrica– Pontifícia Universidade Católica do Rio Grande do Sul Pr. 30 Sl. 153 – Av. Ipiranga, 6681 – Porto Alegre – RS – Brasil {ricardob,guedes,castello,psantos,quadra}@ee.pucrs.br 1. Introdução Já na atualidade percebe-se uma forte tendência das pesquisas e mesmo do mercado [14,51] no sentido de possibilitar o desenvolvimento de soluções de voz não tão somente utilizando-se uma infra-estrutura comum de redes de pacotes mas, principalmente, utilizando- se o suite TCP/IP para a execução dessa atividade. Diversas iniciativas têm sido elaboradas nesse sentido e o tema Voz sobre IP tornou-se um tema imperativo como estudo na atualidade. Não obstante, o problema tecnológico da voz sobre IP, embora já bem situado, não pode ser absolutamente considerado como resolvido, mesmo em vista das diversas teses, dissertações e grupos de pesquisa atuantes na área. Sob um ponto de vista histórico, podemos situar o desenvolvimento na área através de alguns eventos significativos: a) experimentos com a transmissão de pacotes de voz através da ARPANET, em 1974, entre USC/ISI e o MIT. Utilizou o chamado Network Voice Protocol (NVT); b) em janeiro de 1976 ocorreu a primeira áudio-conferência, utilizando um novo protocolo (Network Voice Control Protocol); c) em 1983 a Xerox construiu o primeiro Ethernet Phone, d) no início da década de 90 surgem diversas aplicações para transporte de voz via redes de pacotes comutados, devido à proliferação de máquinas capazes de fornecer os recursos necessários para conversações com nível de toll-quality. Entre elas destacam-se o VT e o vat; e) em novembro de 1992 foi desenvolvida a primeira aplicação para o MBONE (nv); f) em 1992 iniciaram-se os trabalho do grupo AVT do IETF, com o propósito de padronizar protocolos para o transporte de informações multimídia; g) em novembro de 1995 o RTP [6] foi publicado como um Proposed Standard;

Transcript of Voz sobre IP- Tecnologia e tendências

Page 1: Voz sobre IP- Tecnologia e tendências

Voz sobre IP- Tecnologia e tendências

Ricardo Balbinot1, Jorge Guedes Silveira1, Fladhimyr Câmara Castello2, Pedro Martins dos Santos2, Alexandre da Silva Quadra1

1Faculdade de Engenharia– Pontifícia Universidade Católica do Rio Grande do Sul T.: 51-33203500 R: 4056 SR: 223 Pr. 30 Sl. 151 – Av. Ipiranga, 6681 – Porto Alegre – RS

– Brasil

2Programa de Pós-Graduação em Engenharia Elétrica– Pontifícia Universidade Católica do Rio Grande do Sul

Pr. 30 Sl. 153 – Av. Ipiranga, 6681 – Porto Alegre – RS – Brasil {ricardob,guedes,castello,psantos,quadra}@ee.pucrs.br

1. Introdução

Já na atualidade percebe-se uma forte tendência das pesquisas e mesmo do mercado [14,51] no sentido de possibilitar o desenvolvimento de soluções de voz não tão somente utilizando-se uma infra-estrutura comum de redes de pacotes mas, principalmente, utilizando-se o suite TCP/IP para a execução dessa atividade. Diversas iniciativas têm sido elaboradas nesse sentido e o tema Voz sobre IP tornou-se um tema imperativo como estudo na atualidade.

Não obstante, o problema tecnológico da voz sobre IP, embora já bem situado, não pode ser absolutamente considerado como resolvido, mesmo em vista das diversas teses, dissertações e grupos de pesquisa atuantes na área.

Sob um ponto de vista histórico, podemos situar o desenvolvimento na área através de alguns eventos significativos:

a) experimentos com a transmissão de pacotes de voz através da ARPANET, em 1974, entre USC/ISI e o MIT. Utilizou o chamado Network Voice Protocol (NVT);

b) em janeiro de 1976 ocorreu a primeira áudio-conferência, utilizando um novo protocolo (Network Voice Control Protocol);

c) em 1983 a Xerox construiu o primeiro Ethernet Phone,

d) no início da década de 90 surgem diversas aplicações para transporte de voz via redes de pacotes comutados, devido à proliferação de máquinas capazes de fornecer os recursos necessários para conversações com nível de toll-quality. Entre elas destacam-se o VT e o vat;

e) em novembro de 1992 foi desenvolvida a primeira aplicação para o MBONE (nv);

f) em 1992 iniciaram-se os trabalho do grupo AVT do IETF, com o propósito de padronizar protocolos para o transporte de informações multimídia;

g) em novembro de 1995 o RTP [6] foi publicado como um Proposed Standard;

Page 2: Voz sobre IP- Tecnologia e tendências

h) o primeiro provedor comercial para telefonia IP foi a Delta Three, em 1996, seguida pela Net2Phone, iBasis e pela Telematrix;

i) o SIP [9] foi publicado como um proposed standard em 1999;

Os cenários mais tradicionais de uso para voz sobre IP são os seguintes:

a) utilização de VoIP como sistemas de trunking telefônico: nessa situação a tecnologia é utilizada com o objetivo de transportar a voz entre dois pontos que utilizam sistemas telefônicos tradicionais. A VoIP seria utilizada, nesse contexto, como um sistema de transporte, substituindo soluções tradicionais (usualmente baseadas em TDMs síncronos);

b) utilização de VoIP como uma solução particular em determinadas localidades e/ou situações: é o caso típico de utilização de VoIP (via provedores apropriados) somente para ligações internacionais ou interurbanas;

c) utilização de VoIP pura, porém baseadas em terminais específicos: é o caso clássico de VoIP (muito embora talvez não o mais usual), onde o usuário passa a dispor de um aparelho telefônico específico, capaz de operar utilizando redes IP (muitas vezes essa solução confunde-se com outros tipos de sistemas, a exemplo de Ethernet Phones);

d) utilização de VoIP pura, baseadas em desktops de usuários: muito embora não muito visada na atualidade, talvez seja a mais comum das utilizações da tecnologia. Nesse contexto é importante salientar que voz sobre IP não é telefonia IP, mas sim um conjunto de técnicas e questões mais amplo, dentro do quais a telefonia IP se situa. VoIP, nessa ótica, refere-se a toda utilização de voz aplicada em redes IP (em sistemas de audioconferência, videoconferência, telefonia IP, entre outros). Essa espécie de solução usualmente se apresenta com problemas de qualidade para o usuário final, muito embora possa atingir os mesmos quesitos apresentados pelas demais modalidades.

O restante do texto do minicurso encontra-se dividido da seguinte maneira: na seção dois discutimos os principais fundamentos de sistemas de voz sobre IP e telefonia IP, apresentando as principais características da tecnologia. Na seção 3, tratamos dos protocolos de transporte utilizados em VoIP, incluindo o RTP [6] e seus profiles específicos para o trabalho com VoIP. São destacados aspectos no tocante a multiplexação da mídia, sequenciamento, translators e mixers, utilização das funções de realimentação providas pelo protocolo. Na quarta seção são abordados os principais sistemas e protocolos de sinalização utilizados no contexto de VoIP, a citar: H.323 [4], SDP [8], SIP [9], MGCP [10] e MEGACO [11]. Também são vistos, com menor ênfase, protocolos e técnicas auxiliares ou relacionados, tais como: SIGTRAN [61], ENUM [58], TRIP [60], CPL [59], entre outros.

Na seção 5 são abordadas as principais técnicas e algoritmos utilizados no tocante a qualidade em voz sobre IP, com ênfase nas técnicas de adaptação e manutenção de qualidade. Alguns dos principais aspectos referem-se a: técnicas de bufferização; técnicas de correção de erros; técnicas de compensação de perdas. Na sexta seção consideramos os principais princípios e técnicas de processamento digital de sinais aplicados ao problema da VoIP, com destaque para as questões de cancelamento de eco e supressão de silêncio. Na

Page 3: Voz sobre IP- Tecnologia e tendências

seção 7 fazemos um breve estudo dos principais critérios que afetam a qualidade perceptível nos sistemas de voz sobre IP. Em seguida, são avaliados os principais métodos existentes para uma avaliação “quantitativa”, com destaque particular as técnicas MOS [55] e PSQM [1].

Na seção 8, são vistos aspectos fundamentais relacionados às redes de telefonia comutadas, com destaque aos sistemas de transporte de voz existentes (PDH e SDH), ambos determinísticos, e, principalmente, aos sistemas de sinalização existentes na atualidade, com ênfase no Sistema de Sinalização número 7 (SS7). Na seção 9 são abordados aspectos de interconexão de sistemas de VoIP com sistemas telefônicos tradicionais.

Por fim, na seção 10 é fornecida uma pequena lista com as principais aplicações (open-source) e grupos de pesquisa atuantes na área.

2. Voz sobre IP e Telefonia IP: fundamentos

O tema Voz sobre IP é, certamente, multidisciplinar em essência: envolve desde aspectos de redes de computadores e telecomunicações (com uma abrangência maior na segunda), até critérios e técnicas de DSP. Pretendemos nesta seção prover uma visão geral ao leitor dos principais tópicos relacionados à tecnologia em questão.

Várias questões podem ser levantadas sobre o problema específico de transmissão de voz em redes IP. Pode-se, contudo, agrupar as mesmas de modo conveniente como segue: problemas referentes à transmissão em si, à confiabilidade e segurança, à qualidade final obtida e aos mecanismos apropriados de sinalização da comunicação em trânsito.

Os propósitos originais da tecnologia IP certamente não comportavam a transmissão de mídias com características de tempo real (conforme vários autores já relataram sob diferentes perspectivas [18,20,43]) e, dessa forma, os protocolos tradicionais da família TCP/IP, como o TCP e o UDP, não se mostraram adequados ao seu transporte. Os pontos vitais de transmissão desse tipo de informação focam os seguintes quesitos: baixa latência origem-destino, baixa variação dessa latência, taxas de perda de pacotes e erros de bit baixas. Particularmente, no caso da voz não comprimida, os três primeiros são de maior importância, conforme se pode observar em diversos estudos correlatos [18,19,20,21,22]. Particularmente a questão da perda não pode ser desprezada, conforme será visto com maiores detalhes posteriormente, em razão das características de congestionamento e descarte de pacotes de redes IP típicas [18,20,51]. Esses estudos afirmam que a Internet possui uma característica forte de perdas em curtos espaços de tempo (usualmente onde se localizam bursts de dados que ocasionam congestionamento na rede). Assim, nesse curto espaço de tempo, o fluxo de transmissão e, conseqüentemente, o fluxo de reprodução da fala é interrompido. A tendência natural da rede é estabilizar-se em seguida e dar o seguimento normal aos pacotes não descartados. Ou seja, mesmo sistemas que não utilizem voz comprimida vão deparar-se com picos de perda bastante elevados que degradam severamente a qualidade da voz. Esse tipo de característica beneficia a adoção de mecanismos de correção de perdas em loop aberto, como é o caso das técnicas FEC (Forward Error Correction) – essas questões serão apropriadamente abordadas ao longo do restante do texto.

Page 4: Voz sobre IP- Tecnologia e tendências

Um dos principais elementos para a atenuação desses problemas é a utilização de buffers de reprodução de fala (também conhecidos como buffers de dejitter). Como um dos principais impactos de um congestionamento da rede, além da eventual perda de pacotes, é a distribuição do pico de tráfego por um período maior, pelo preenchimento dos buffers de roteadores e switches, teremos um conseqüente aumento no atraso origem-destino. Devido ao fato de termos um sistema com taxa de geração de dados (a taxa de amostragem da voz) constante, temos a necessidade de um mecanismo que possua dados para reprodução a uma taxa constante igual a da origem (exceção feita a eventuais variações introduzidas pelo uso de compressores- o problema em si, no entanto, persiste). Ou seja, caso o sistema não receba os pacotes ou frames de voz a tempo, ele perceberá a ausência do mesmo como uma perda [22,42]. Nesse aspecto os buffers de dejitter auxiliam na atenuação da percepção de perda do sistema devido a variações bruscas no atraso (o papel dos mesmo, contudo, não é prover soluções para o problema de atraso em si). O uso desse mecanismo, contudo, não contempla o problema da perda de segmentos de voz em si, mas sim situações de perda de curtos segmentos devido ao jitter. Os buffers em questão também podem ser acoplados a técnicas de compensação de perdas de pacotes, permitindo uma atuação mais efetiva de sistemas de voz sobre IP no sentido de evitar baixas de qualidade devido a perdas eventuais de pacotes ou a variações muito grandes de atraso (jitters maiores que a máxima capacidade do buffer). É importante destacar igualmente que, muito embora o efeito benéfico do buffer de dejitter o mesmo também introduz atraso no sistema e, por essa razão, o problema de seu dimensionamento é bastante significativo.

A questão de erros ao nível bit na transmissão não é considerada vital em sistemas de VoIP visto as características próprias da mídia transportada, conjugado com o fato das redes oferecerem um BER, na maior parte dos casos, extremamente baixo na atualidade, permitirem que erros eventuais sejam aceitos sem detrimento significativo da qualidade da voz (sob esse aspecto é importante notar que o erro por perda é tratado de forma diferenciada no âmbito da VoIP).

Muito embora não resolva os problemas de transmissão descritos, o RTP [6] oferece um mecanismo mais adequado para a transmissão que seus similares. Sua grande vantagem está em seu protocolo irmão, o RTCP, que oferece mecanismos de realimentação acerca da qualidade da sessão em andamento em tempo quase real.

Quando nos referimos à confiabilidade e segurança no transporte das informações, podemos dizer que tratamos de um problema geral da tecnologia TCP/IP, visto que, mesmo em aplicações de dados convencionais, esse é um tópico que gera preocupações e estudos variados. Contudo, é interessante avaliar o problema sob a perspectiva de sistemas em tempo real.

O próprio RTP/RTCP já prevê a adoção de mecanismos de criptografia, embora não especifique nenhum em particular, dentro de sua concepção. A confiabilidade dos dados, por sua vez, pode ser vista sob dois aspectos distintos: a inserção de informações indevidas no fluxo de dados da sessão RTP ou a não entrega de pacotes com informações significativas. O primeiro é um problema abordado pelo RTP, enquanto o segundo permanece como uma questão a ser resolvida por outros mecanismos.

Page 5: Voz sobre IP- Tecnologia e tendências

Todos os problemas de transmissão refletem-se na observação de uma melhor ou pior qualidade da conversação pelo usuário. Tradicionalmente, a avaliação dessa qualidade era feita por mecanismos simples de relação sinal-ruído ou similares, os quais mostraram-se inadequados ao caso específico. O mecanismo de avaliação mais aceito é o MOS [55] – Medium Opinium Score- o qual será abordado posteriormente. O MOS de sistemas tradicionais de telefonia gira em torno de 4,5 ou 5, que é o conceito máximo possível de ser atingido. O uso de compressores já introduz, por si só, perdas no conceito MOS máximo possível de ser atingido.

É importante notar ainda que não somente a compressão, o atraso e a perda de pacotes afetam o coeficiente de qualidade possível de ser atingido, mas igualmente a localização das perdas (e, conseqüentemente, das eventuais informações de redundância repassadas), conforme pode ser visto nos trabalhos [43,44].

Numa lista breve, podem-se citar como mecanismos de adaptação e manutenção de qualidade [42,44,51] os buffers de saída e de reprodução, mecanismos de redundância de pacotes e mecanismos de correção de erros e perdas.

Resolvido o problema da transmissão resta, contudo, ainda a questão da negociação prévia à transmissão, assim como a liberação de recursos alocados pelo terminal e pela rede no transcorrer da comunicação. Essas questões usualmente são abordadas por protocolos de sinalização, os quais são representados em sistemas de VoIP pelo emergente SIP [9], pelo MGCP [10], pelo MEGACO [11] e pelo já tradicional H.323 [4]. Outros protocolos que executam funções de sinalização são os componentes do H.323, em particular o H.245 [3] e H.225.0 [2], além de protocolos adicionais ao MGCP, por exemplo. É importante destacar, contudo, que muito embora apresentando situações redundantes, os protocolos acima só conflitam no tocante do H.323/SIP (com a ressalva que o H.323 é mais amplo que o SIP em vários aspectos) e do MGCP/MEGACO.

De forma geral e simplificada um sistema de VoIP possui os seguintes elementos [17] de modo destacado: os terminais de usuário, gateways e proxies. Outras entidades podem ser inseridas conforme a necessidade ou aplicação específica, mas as três anteriores são certamente as mais comumente verificadas (um caso interessante é a presença de MCUs ou Gatekeepers). Os conceitos abaixo listados serão abordados com mais profundidade ao longo do restante do texto.

O terminal de usuário é a entidade responsável pela interação direta do usuário com o sistema em questão. O mesmo deve prover todas as funcionalidades relacionadas com a aquisição, tratamento e reprodução dos sinais de voz dos interlocutores, assim como funcionalidades relacionadas ao transporte da informação de modo apropriado, sinalização e correção/compensação de erros, entre outras.

O gateway é responsável pela interação do sistema com outras tecnologias, destacando-se, particularmente o papel dos gateways quanto à interconexão com sistemas legados (RPTC – Rede Pública de Telefonia Comutada). Não obstante, também existem gateway específicos quanto a tradução de sinalização, por exemplo, a conversão SIP-H.323 ou SS7-SIP. De forma geral, é costume dividir o gateway em três segmentos particulares: gateways de sinalização, gateways de mídia e controladores de gateway.

Page 6: Voz sobre IP- Tecnologia e tendências

Por fim, os proxies são responsáveis pelo seguimento da sinalização e, em boa parte, pela localização do usuário dentro da rede IP. O proxy tradicional SIP atua apenas

Rede Pública de Telefonia ComutadaRede IP

1 2 34 5 6

7 8 9

* 8 #

Terminal UA

1 2 34 5 6

7 8 9

* 8 #

Terminal UA

1 2 3

4 5 67 8 9

* 8 #

Terminal UA

Proxy+Registrar

Dados de sistema e usuário(localização)

MCU

Call manager/Gatekeeper

1 2 3

4 5 6

7 8 9

* 8 #

Telefone

1 2 34 5 6

7 8 9

* 8 #

Telefone

Gateway IP-RPTC CCC

Figura 1: principais entidades de um sistema de VoIP.

É importante destacar que o problema da voz sobre IP é mais amplo que a questão da telefonia IP (a visão dos autores é que a telefonia IP é uma aplicação de voz sobre IP). Logicamente o problema de telefonia IP tem suas características próprias e é de extrema importância, mas a VoIP pode ser utilizada igualmente no contexto de videoconferências, audioconferências, transmissão de áudio com alta fidelidade, entre outras diversas aplicações.

3. Protocolos de Transporte

Conforme já referido na seção anterior, o RTP [6] é o protocolo mais adequado para o transporte de informações em tempo real sobre IP. O RTP é, na verdade, um protocolo que inclui um sistema de controle em tempo real, denominado RTCP (Real Time Control Protocol), o qual possibilita, além do simples transporte das informações, a verificação das condições de transmissão sendo observadas durante o período de conversação entre os peers RTP. Citando a RFC 1889 [6], temos a definição apropriada:

a) “...o protocolo de transporte em tempo real (RTP), para transmissão de dados que possuam características de tempo real.”;

b) “... o protocolo de controle do RTP (RTCP), para monitorar a qualidade do serviço e para repassar informações sobre participantes numa sessão em andamento. O último aspecto do RTCP pode ser suficiente para sessões simples, onde não exista o controle explícito dos membros assim como de acesso, mas não é a sua intenção necessariamente prover o suporte de todos os requisitos de comunicação de controle de uma aplicação. Essa funcionalidade pode ser plenamente ou parcialmente abordada por um protocolo de controle de sessão separado...”.

O conjunto RTP/RTCP não oferece, contudo, nenhum mecanismo de garantia de qualidade de serviço, nem mesmo garantia de entrega dos pacotes, mas fornece os meios necessários para a entrega de pacotes com mínimo atraso e oferece mecanismos que possibilitam o controle da qualidade observada na rede.

Page 7: Voz sobre IP- Tecnologia e tendências

O RTP é tipicamente transportado em pacotes UDP (User Datagram Protocol), utilizando principalmente os seus métodos de multiplexação. Justamente uma das necessidades que o RTP expressa em relação a serviços que devem ser providos por camadas inferiores é a necessidade de multiplexação das diferentes sessões RTP, uma vez que o protocolo por si só não é capaz de prover esse tipo de facilidade.

Uma discussão sempre levantada relaciona-se com a preferência pela utilização do UDP em detrimento do TCP. Essa questão é simplesmente respondida pelo fato do TCP ser inadequado para o trabalho com sistemas em tempo real, que não possam suportar atrasos elevados (pelas características intrínsecas do protocolo, entre as quais, particularmente, a retransmissão de dados).

O RTP inclui igualmente identificadores do tipo de payload, numeração seqüencial e marcas temporais (timestamping). A identificação de payload permite a óbvia operação de identificação da mídia sendo transportada na sessão RTP, bem como a identificação de eventuais profiles que estendam a operação convencional do protocolo. A numeração seqüencial possibilita que os diferentes pacotes enviados não somente possam ser reordenados da forma correta na recepção, mas também é importante para a operação dos buffers de dejitter, em conjunto com o timestamp. Por fim, o timestamp possibilita uma visão temporal da informação sendo repassada: além do uso óbvio para sincronismo entre diferentes sessões RTP (possivelmente com diferentes mídias sendo transportadas), o mesmo também se aplica a mensuração de algumas grandezas que são monitoradas na sessão, entre as quais se destaca, particularmente, o cálculo do RTT (Round Trip Time) da sessão.

V = 2 P X CC M PT Sequence number

Timestamp

Synchronization source (SSRC) identifiers

Contribuiting source (CSRC) identifiers

Figura 2: Cabeçalho do RTP

O cabeçalho do RTP (figura 1) é formado de 12 bytes com os seguintes campos [6]: a) O campo V (dois bits) indica a versão do protocolo; b) A flag X (um bit) indica a existência de extensões no protocolo entre o cabeçalho e o

payload; c) Se o bit P (padding) estiver acionado, indica que o payload sofreu preenchimento

para fins de alinhamento e o ultimo octeto do payload indica precisamente quantos octetos foram acrescentados ao payload original;

d) O contador CSRC (CC) indica quantos identificadores CSRC vem após o cabeçalho fixo. Esse valor pode ir de zero a 15;

e) O marcador M tem seu uso definido pelo RTP nos seus diversos profiles [52]; f) Tipo de Payload (PT) bits indica o tipo de dados que o pacote RTP está

transportando; g) Sequence Number é o número de seqüência dos pacotes RTP. Inicia a contagem em

um número aleatório e é incrementado a cada pacote RTP (a questão do wrap

Page 8: Voz sobre IP- Tecnologia e tendências

around deve ser considerada nesse caso, inclusive para os cálculos de performance efetuados pelo RTCP);

h) Timestamp utilizado para determinar o interpacket gap; i) Synchonization Source cada participante de uma sessão RTP escolhe, de forma

aleatória, um identificador SSRC que irá identificá-lo dentro da sessão frente aos outros participantes. Esse identificador está diretamente associado não somente a mídia, mas também ao relógio utilizado para geração das informações;

j) Contributing Source identifica as fontes que contribuíram para a formação dos dados contidos no pacote. Essas fontes possuem, cada uma, um identificador de sincronismo (um relógio) próprio, o qual, na formação da mídia composta, é transposto e repassado como uma fonte contribuidora para a fonte de sincronismo atual.

O RTP, dessa forma, fornece apenas os mecanismos básicos que permitam a entrega simplificada das informações, a determinação da fonte das mesmas e da base temporal utilizada para sua geração, além do sequenciamento apropriado das informações (através desse conjunto de dados também é possível estimar se um dado pacote foi ou não perdido).

O RTCP (Real-Time Control Protocol) é responsável por monitorar a qualidade do serviço e por repassar informações sobre participantes numa sessão em andamento. Na realidade a grande flexibilidade do RTP é advinda justamente dessa capacidade, a qual será utilizada por diversos mecanismos a fim de controlar ativamente a qualidade da informação sendo transmitida e recebida. O mesmo possui os seguintes pacotes básicos [6]:

a) Sender Reports(SR): gerado pelo usuário que está transmitindo a mídia. Ele informa a quantidade de dados que foram transmitidos, correlacionando o Timestamping e o tempo absoluto do RTP para a sincronização. O SR fornece um retrato de todo terminal ativo como transmissor, permitindo aos receptores o conhecimento daquilo que foi efetivamente enviado em um dado período de trabalho;

b) Receiver Reports(RR): enviado pelo participante de uma sessão RTP que estão recebendo os dados de mídia (um transmissor também pode atuar como receptor – dessa maneira, ele também pode gerar relatório RR). Cada relatório contém um bloco para cada origem de dados na sessão RTP (ou seja, informações de recepção do receptor quanto a um transmissor em especial). Cada bloco contém informações instantâneas e cumulativas a respeito da taxa de perda e jitter sobre cada origem de dados. O bloco também indica o ultimo timestamp e o tempo transcorrido desde que recebeu o relatório da respectiva origem. Com as informações combinadas sobre o seu último relatório de envio (que o transmissor possui) e os diversos relatórios de recepção, o transmissor pode chegar a conclusões como o atraso médio entre origem-destino, o jitter mensurado, entre outras, que possibilitam que o mesmo se adapte às diferentes condições da rede;

c) Source Description(SDES): esse pacote é utilizado pelo gerente da sessão. Ele transporta o CNAME (Canonical Name), um identificador global com a forma similar a um endereço de e-mail. O CNAME é usado para fornecer um identificador global entre diferentes SSRC associados a um mesmo equipamento (com essa informação é possível proceder, por exemplo, ao sincronismo entre diferentes mídias de uma sessão de videoconferência – áudio, vídeo e texto);

Page 9: Voz sobre IP- Tecnologia e tendências

d) BYE: utilizado quando um usuário de uma determinada sessão RTP deseja sair da sessão. Esse pacote deve transportar o SSRC e, eventualmente, pode transportar também CSRC para identificação;

e) APP: transporta informações específicas da aplicação em questão.

É importante destacar que uma sessão RTP é caracterizada por alguns elementos em particular: o endereço de transporte utilizado para a transmissão e o identificador SSRC. Assim, o término de uma dada sessão não implica no término de toda comunicação associada a um dado CNAME, particularmente no caso onde existam diversas mídias sendo transportadas simultaneamente.

Um terminal que utiliza o protocolo RTP, portanto, emite ao menos um relatório aos demais membros da sessão RTP informando sua visão da recepção dos pacotes de um determinado emissor para todos os membros da sessão (e para todos os emissores dos quais porventura venha a receber algum pacote). Os emissores, por sua vez, enviam pacotes periódicos informando como foram enviados os dados, bem como a sua visão como receptores dos dados de outros emissores. A partir do uso dessas informações e do confronto entre ambas, tanto emissores quanto receptores podem chegar a uma definição do estado da rede a curto e a longo prazo podendo-se identificar problemas que estão ocorrendo ou ainda identificar, através do comportamento da rede, a característica que rede irá assumir a longo prazo, possibilitando a criação de estatísticas que podem realimentar um sistema de controle, possibilitando que o sistema, de forma autônoma, reconfigure os codificadores parâmetros de rede evitando assim problemas que poderiam vir a ocorrer [6,49,50,51].

Um ponto importante é a questão dos relatórios serem ou não em tempo real. Na realidade os relatórios são gerados em conformidade com uma banda agregada máxima determinada para o RTCP, e os relatórios são divididos conforme essa banda. Assim, existe a preferência para o envio de SR sobre RR, sobre SDES, e assim por diante. Não obstante, o padrão especifica a necessidade de envio de pacotes RTCP compostos, onde, minimamente, um terminal deve enviar as seguintes informações: um pacote SR/RR (o pacote SR também pode conter relatórios de recepção), um pacote SDES usando o item CNAME e os demais pacotes conforma a banda disponível. No entanto, é possível também a existência de elementos que participem de uma sessão RTP (particularmente no caso de sessões multicast) e, ainda assim, não gerem nenhum relatório de recepção. Esse é o caso de elementos ditos monitores de sessões RTP, os quais podem ser utilizados para fins de diagnóstico da comunicação em andamento.

O protocolo RTP utiliza o conceito de profiles [6,52], de extensões do protocolo que não envolvem um nível de encapsulamento na pilha em uso em um dado equipamento. Entre os profiles de maior relevância para o tema tratado podemos citar:

a) Profile for Audio and Video Conferences with Minimal Control [52] – Define os mecanismos básicos necessários para uma conferencia utilizando-se das mídias de áudio e vídeo;

b) Payload for Confort Noise (CN) [53] – Define mecanismos para o transporte de informações de ruído de conforto;

Page 10: Voz sobre IP- Tecnologia e tendências

c) Extended RTP Profile for RTCP-based Feedback[50] – Que apresenta mecanismos aprimorados de feedback e perda, possibilitando assim o uso de mecanismos de retransmissão e correção de erros;

d) An RTP Payload for Generic Forward Error Correction [46]: determina formatos genéricos de payload para o transporte de informações FEC agregadas a mídia sendo transportada (mais utilizado no caso de FEC independente da mídia);

e) RTP Payload for DTMF Digits, Telephony Tones and Telephony Signal: especificando mecanismos para o transporte de dígitos DTMF e outros tons e eventos de telefonia em pacotes RTP;

f) RTP payload for redundant audio data [47]: especificando um formato alternative de payload para o caso de FEC dependente da mídia;

Translator

Participante

Participante

Participante

Participante

Participante

Participante

Ambiente Multicast Ambiente Unicast

Figura 3: Translator de ambiente multicast para unicast

A necessidade de interconexão de ambientes multicast com ambientes unicast em uma sessão RTP implica na existência de uma lacuna em um sistema de VoIP que é preenchida por aplicações independentes que se comportam como Tradutores (ou Translators). Essencialmente esses sistemas encaminham os pacotes RTP de um ambiente para o outro mantendo intactas as informações referentes ao campo SSRC. Esses sistemas também podem ser utilizados como transação através de firewalls. Os tradutores também são utilizados para reduzir a banda da rede necessária para a transmissão dos dados, uma vez que o mesmo pode efetuar conversões de formato na mídia transmitida [6,49]. Particularmente, um gateway IP-RPTC pode (e deve) ser considerado, sob o ponto de vista do RTP, como um elemento tradutor.

Outra aplicação intermediaria utilizada para interligação de redes diferentes é denominada de mixer. Essa aplicação recebe os pacotes RTP de uma ou mais origens, combina esses dados e repassa para a outra estrutura um novo pacote RTP. O mixer é responsável por fazer o ajuste de tempo nos pacotes provenientes das diferentes origens. Dessa forma todos os pacotes enviados pelo mixer carregam o seu SSRC e não mais o do usuário que gerou os dados efetivamente. O SSRC de cada usuário que colaborou com o pacote gerado pelo mixer é adicionado no campo CSRC, juntamente com o próprio SSRC do mixer pois o mesmo também colaborou com a composição do pacote [6]. O mixer pode ser visto dentro de um sistema de VoIP como a unidade que permite a realização de audioconferências.

Page 11: Voz sobre IP- Tecnologia e tendências

4. Protocolos de Sinalização

4.1. Sinalização H.323

O padrão H.323 [4] provê uma base para comunicação de dados, vídeo e áudio através de redes de pacotes comutados (onde destaca-se, particularmente, a tecnologia IP). H.323 é uma recomendação guarda-chuva do ITU-T que agrupa padrões para comunicação multimídia sobre redes que não provêm qualidade de serviço (QoS).

O padrão é considerado um protocolo “guarda-chuva” porque define todos os aspectos para transmissão de chamadas, do estabelecimento da chamada a troca de disponibilidade de recursos da rede através de diversos padrões auxiliares. O H.323 por si só apenas provê a concepção de sistema e da forma como sistemas de comunicação multimídia devem trabalhar. Pelo fato de ser o padrão mais antigo na área, o H.323, particularmente no tocante ao modelo de sistema, ainda influencia fortemente na concepção dos sistemas.

O padrão define o protocolo de registro, admissão e status (RAS) para roteamento de chamada, e, através do protocolo H.225.0 [2], os recursos necessários para preparar chamadas e, através do protocolo H.245 [3], os mecanismos necessários para troca de capacidades e negociação de recursos.

O H.323 inclui diversos outros padrões, tais como: H.225.0-RAS, Q.931-H.245, RTP/RTCP e codecs de vídeo, áudio, e dados, tais como os codecs de áudio (G.711, G.723.1, G728, etc), codecs de vídeo (H.261, H.263).

A sinalização, com exceção do RAS, é transportada de forma confiável sobre TCP. Os seguintes protocolos negociam a sinalização:

a) RAS: gerencia registro, admissão e status;

b) Q.931: gerencia estabelecimento e finalização de chamadas;

c) H.245: negocia uso e capacidades dos canais.

Além disso, os seguintes protocolos provêem características opcionais dentro do framework H.323:

a) H.235: segurança e autenticação;

b) H.450.x: serviços suplementares.

O H.323 é baseado no protocolo Q.931, Integrated Services Digital Network (ISDN), que permite fácil operabilidade com as redes de voz legadas como PSTN ou SS7 (e isso pode ser visto como uma vantagem do sistema, já que sua integração com sistemas telefônicos tradicionais fica simplificada – entretanto, a própria complexidade do protocolo impõe limites de escalabilidade que contrapõem essa facilidade).

O padrão especifica um sistema composto por Terminais, Gateways, Gatekeepers, Controladores Multipontos, Processadores Multiponto e Unidades de Controle Multiponto (MCU) (os quais são detalhados a seguir).

Page 12: Voz sobre IP- Tecnologia e tendências

Os pacotes de voz devem ser encapsulados no protocolo RTP e transportados no protocolo UDP (User Data Protocol). Para gerenciar a qualidade de comunicação de voz na rede, utiliza-se o protocolo RTCP (Real Time Control Protocol).

A parte de controle do H.323 também utiliza o UDP como protocolo de transporte para estabelecer conexões entre os terminais H.323 e o Gatekeeper, que é basicamente um servidor de acesso remoto da rede H.323, e o TCP para sinalização de chamada e canal de controle. Os protocolos H.225 e H.245 definem toda a operação de controle da arquitetura H.323.

Detalhamos a seguir os componentes que fazem parte da arquitetura H.323: a) Terminal: é o dispositivo de usuário que provê comunicação bidirecional em

tempo real de voz, vídeo ou dados, com outro terminal H.323. O terminal pode também se comunicar com um Gateway ou MCU;

b) Gateway: é um dispositivo de adaptação utilizado para permitir a comunicação entre terminais H.323 e terminais não-H.323. O objetivo geral do Gateway é a translação de características de um terminal da rede de pacotes para um terminal da rede RPTC (telefone convencional).

c) Gatekeeper: é um elemento opcional nas redes H.323, o qual tem a responsabilidade de administração dos serviços de controle da chamada no sistema VoIP. É uma entidade lógica, ou seja, pode ser implementada em qualquer elemento da rede H.323 e não-H.323. As principais funções do Gatekeeper são: tradução de endereços (uso de apelidos H.323), controle de admissão, controle de largura de faixa, gerenciamento de zona e sinalização de chamadas (papel de um proxy SIP);

d) Multipoint Control Unit (MCU): elemento que suporta conferências multipontos entre três ou mais terminais ou Gateways. Composto de um Controlador Multiponto (MC) e Processadores Multipontos (MP);

e) Controlador Multiponto (MC): suporta a negociação de capacidades entre todos os terminais, para se garantir um nível comum de comunicações;

f) Processador Multiponto (MP): é o elemento responsável por mixar, comutar e processar áudio, vídeo e/ou bits de dados. É o processador central de voz, vídeo e dados para uma conferência multiponto;

4.2. Sinalização SIP

O Session Initiation Protocol (SIP – RFC 2543 [9]) é um protocolo definido pelo IETF SIP Working Group que tem por objetivo a padronização das mensagens para criação, modificação e finalização de sessões multimídia, por exemplo chamadas de voz (é interessante, contudo, denotar que, originalmente, o escopo do SIP era bem mais amplo que o caso da voz – na atualidade, entretanto, o mesmo especializa-se progressivamente para o trabalho com situações de telefonia IP, embora ainda possa ser utilizado para sinalizar sessões em geral).

Page 13: Voz sobre IP- Tecnologia e tendências

O padrão foi desenvolvido como um protocolo multimídia que usa as vantagens das mensagens e arquiteturas encontradas nas aplicações populares da Internet. Pelo uso de uma arquitetura distribuída, com a utilização de universal resource locators (URL) para resolução de nomes e mensagens baseadas em texto, o SIP pretende usar as vantagens do modelo da Internet para construção de aplicações e rede VoIP. O mesmo herda características de dois protocolos muito utilizados na Internet, o hypertext transfer protocol (HTTP) e o simple mail transfer protocol (SMTP). Obviamente, o SIP é um padrão aberto. Como o mesmo se integra de forma natural com outros serviços e aplicações do suite TCP/IP, serviços como DNS, LDAP e outros são naturalmente utilizados para o provimento de características necessárias aos sistemas (ou seja, por exemplo, existem extensões e registros específicos do DNS para o trabalho com o SIP).

Como protocolo, o SIP define apenas como as sessões serão criadas e destruídas. Ele utiliza outros protocolos padrão IETF para definir outros aspectos de sessões multimídia, como, particularmente, o Session Description Protocol (SDP) [8] para descrição das habilidades da sessão.

Embora o IETF esteja na atualidade discutindo e gerando extensões que permitam que redes SIP trabalhem com as redes de voz legadas, a principal motivação do SIP está na criação de um ambiente que suporte a próxima geração de modelos de comunicação que utilizam a Internet e as aplicações da Internet. Assim, enquanto o protocolo SIGTRAN [61] é o protocolo para conexão IP com redes PSTN atuais (no tocante ao transporte de informações), SIP é o protocolo para conexões de aplicações multimídia utilizando IP puro.

Entre as funcionalidades ofertadas pelo SIP encontram se as seguintes: a) Tradução de nomes e localização do usuário: para permitir que a chamada

encontre o destino sem preocupação com a localização do usuário, o SIP endereça os usuários por um endereço URL específico. Esse mecanismo possibilita, inclusive, a criação de sistemas que permitam a mobilidade do usuário sem maiores impactos sobre a solução como um todo. Conjugado com o ENUM [58], esse mecanismo pode prover a total independência numérica e de posição ao usuário;

b) Negociação de atributos: o SIP permite que todas as partes envolvidas com a chamada possam negociar e aceitar os atributos (features) suportados e reconhecidos por todos os participantes da conferencia, através do uso do SDP [8];

c) Gerenciamento dos participantes das chamada: durante a sessão, um participante pode “trazer” outros usuários para dentro da sessão, pode transferir uma chamada ou pode cancelar conexões. Esse tipo de característica permite a criação de serviços avançados associados a sinalização, de modo simples e rápido.

Existem dois componentes básicos no padrão: o SIP user agent (UA) e o SIP network server (NS).O user agent é o componente final (end system) para as chamadas e o SIP network server é o dispositivo de rede que executa a sinalização associada com múltiplas chamadas. Um user agent é composto de duas partes: um user agent client (UAC) que inicia as chamadas, e um user agent Server (UAS) que responde às chamadas. User

Page 14: Voz sobre IP- Tecnologia e tendências

agents comunicam-se diretamente com outros user agents ou através de um ou vários servidores intermediários. Dessa forma é possível realizar chamadas ponto-a-ponto utilizando um protocolo cliente servidor. SIP network servers podem ser encontrados em quatro formas de servidores: SIP statefull proxy Server, SIP stateless Proxy Server, SIP redirect Server e Registrar Server. A principal função dos servidores SIP proxies é prover resolução de nomes e localização de usuários. A principal finalidade do Registrar é prover o registro e identificação do usuário.

O protocolo de sessão provê um mecanismo de transporte próprio, independente das camadas de pacotes. Por esta razão, SIP não requer os serviços do protocolo SCTP [32] do Sigtran.

O mecanismo que permite SIP ser usado para estabelecimento de chamadas entre redes SS7/PSTN e SIP/IP, recebe o nome de SIP-T (SIP for telephones). Referências a esses mecanismos podem ser vistas nos trabalhos [5,28,29,36,39].

Por ser um protocolo novo, ainda em padronização não existe um mecanismo definitivo para realizar a troca de mensagens de sinalização entre as duas redes porém, alguns estudos estabeleceram que SIP-T pode levar as mensagens ISUP no corpo da mensagem e SIP-T também especifica o uso do método SIP INFO [38] para efetuar sinalização ISUP em redes IP.

A figura abaixo demonstra o relacionamento entre os componentes da rede SIP.

SIP GatewayWorkstation

Database

1 2 34 5 6

7 8 9* 8 #

IP Phone

SIP Registrar SIP Proxy

IP

PSTN

Figura 4: topologia típica de um sistema utilizando SIP.

SIP e H.323 definem mecanismos para roteamento de chamadas, sinalização de chamadas, troca de capacidades, controle de mídia e serviços suplementares. SIP é um novo

Page 15: Voz sobre IP- Tecnologia e tendências

protocolo que promete escalabilidade, flexibilidade e fácil implementação quando construído sistemas complexos. H.323 é um protocolo muito usado devido a sua facilidade de gerenciamento, confiabilidade e integração com redes PSTN. Alguns estudos comparativos entre os padrões em questão podem ser vistos em [12,13].

4.3. SIGTRAN

O protocolo SIGTRAN (RFC 2719) [61] especifica os meios pelos quais as mensagens SS7 [16,24,25,26,31] podem ser transportadas de forma confiável sobre redes IP. A arquitetura identifica dois componentes: um protocolo de transporte comum (RFC 2960) para o transporte da camada do protocolo SS7 sendo negociado, e outro um módulo para adaptação para emular camadas mais baixas do protocolo. Como já mencionado o protocolo SIGTRAN provê todas as funcionalidades necessárias para suportar a sinalização SS7 em redes IP, e entre essas funcionalidades destacam-se:

a) fluxo de controle;

b) entrega em seqüência das mensagens de sinalização;

c) identificação dos pontos de origem e destino;

d) identificação dos circuitos de voz;

e) detecção de erro, retransmissão e outros procedimentos de correção de erro;

f) restabelecimento de interrupção dos componentes do caminho de trânsito;

g) controles para evitar congestionamento na Internet;

h) detecção do status das entidades;

i) suporte para mecanismos de segurança para proteger a integridade das informações de sinalização;

Quanto a performance, como as mensagens transportadas sobre redes IP devem obedecer os requerimentos impostos pelo ITU, as redes devem ser construídas visando obedecer as expectativas do usuário. Um exemplo de condição que deve ser seguida se refere ao tempo gasto entre a primeira mensagem (IAM) até o estabelecimento da chamada, o qual, segundo o ITU-T determina, em termos de atraso não pode exceder 20 a 30 segundos após o IAM ser transmitido.

Quanto a segurança, SIGTRAN recomenda o uso do IPSEC (RFC2401) para transmissão de sinalização sobre Internet pois o mesmo, garante autenticação, integridade, confidencialidade e disponibilidade.

O Stream Control Transmission Protocol (SCTP) [32] permite a transferência confiável das mensagens de sinalização entre endpoints na rede IP. De forma resumida, este protocolo é utilizado para transportar as mensagens MTP da rede SS7 sobre as redes IP e foi desenvolvido para resolver uma série de limitações do TCP.

O SIGTRAN não é o único grupo IETF envolvido na definição de novos protocolos para habilitar a integração em rede PSTN e IP. PINT (PSTN and Internet Interworking) e SPIRITS (Service in the PSTN/IN Requesting Internet Service) são duas recomendações

Page 16: Voz sobre IP- Tecnologia e tendências

do IETF que se referem a necessidade de conectar os serviços de telefonia entre PSTN e Internet. De forma resumida, PINT negocia com serviços originados da rede IP, SPIRITS negocia com serviços originados da rede PSTN.

Há também no IETF um grupo especificando um esquema para mapear números de telefone padrão E.164 para endereços IP, usando serviço de nomes da Internet (DNS). Esse esquema é chamado de ENUM [58] (telephone number resolution), permite que qualquer aplicação possa descobrir os recursos associados com um único numero de telefone. O mesmo será abordado com maiores detalhes adiante.

Outro grupo especifica o protocolo TRIP [60] (telephony routing over IP) desenvolvido para permitir que provedores de serviços troquem informações de roteamento, para evitar a duplicação de gateways nas redes. O mesmo será mais detalhado adiante.

4.4. ENUM

O Protocolo E.164 number and DNS (ENUM) [58] especifica como a numeração E.164 pode ser traduzida com o uso de Domain Name Service (DNS) a um ou mais endereços IP em especial. O ENUM foi concebido para auxiliar na convergência da Rede Pública de Telefonia Comutada e da rede IP, isto é, no mapeamento do número de telefones da rede PSTN para serviços da Internet, possibilitando dessa forma desenvolver um grande número de aplicações baseado em números de telefones.

Uma das características interessantes do ENUM é permitir também a criação de um ambiente de “independência” numérica, onde o número de identificação do usuário (não mais simplesmente um número telefônico), passa a ser associado diretamente ao usuário, e não mais a uma dada hierarquia de distribuição e realização de chamadas, como é o caso atual. Assim sendo, o ENUM possibilita a criação de um ambiente competitivo onde o usuário não perde o seu número quando na escolha de um eventual provedor de serviços de telecomunicações (e essa é a razão que está levando diversos países a estudar a adoção do padrão, a fim de estimular a competição entre as operadoras).

O ENUM não muda o plano de numeração e não muda o padrão de numeração dos telefones. O funcionamento é baseado na tradução de um número telefônico em um endereço DNS, por exemplo, o número telefônico +55 51-33203500 passa por um processo de translação ENUM e passa a ser referenciado na rede IP com o DNS 0.0.5.3.0.2.3.3.1.5.5.5.e164.arpa. O número ENUM é referenciado da direita para esquerda pois o DNS localiza o nível mais alto primeiro, passando para o próximo nível. Assim teríamos o nível arpa, e164 e após teríamos o código do país (55), após o código regional (51) e assim por diante. Maiores informações sobre a estrutura podem ser encontradas em RFC for Non-Terminal DNS Name Redirection (http://www.rfc-editor.org/rfc/rfc2672.txt.).

Uma aplicação chave a qual o ENUM está se tornando muito aceito é a habilidade de executar uma chamada entre um PC e um telefone da RPTC.

Outra característica interessante do padrão é permitir que vários serviços sejam associados ao mesmo número E.164 (ultrapassando o escopo de um simples serviço telefônico). Isso é feito pois o registro utilizado no servidor DNS é do tipo NAPR, que

Page 17: Voz sobre IP- Tecnologia e tendências

possibilita a associação recursiva de uma série de aplicações, em ordem de preferência, associadas à tradução do nome.

4.5 TRIP

O TRIP [60] é utilizado para distribuir informações de roteamento entre domínios administrativos de telefonia, não definindo, contudo, um algoritmo específico de escolha de rotas. TRIP é independente dos protocolos de sinalização podendo ser usado com H323 ou SIP. Para evitar fragmentação explicita, retransmissão e sequenciamento, o TRIP é transmitido sobre conexão de protocolos confiáveis.

TRIP é um protocolo de roteamento e localização de gateway inter domínios. A função primária do orador TRIP, chamado de location Server (LS), é a troca de informações com outros LS’s.

A idéia principal do TRIP relaciona-se com o fato da localização do usuário poder ser alterada com o tempo e com a necessidade de mantermos uma forma de encaminhamento de chamadas adequada (ou seja, com a necessidade de verdadeiramente rotearmos uma chamada a seu destino apropriado).

4.6. SDP

O Session Description Protocol (SDP) [8] define características das sessões multimídias para propósitos de anúncio da sessão, convite da sessão e outras formas de inicialização de sessões, além da divulgação das capacidades dos clientes finais (endpoints) para abertura de sessões multimídia. É amplamente utilizado por outros protocolos, devido aos mecanismos de descrição de sessão. SDP é um formato para descrição da sessão, ele não incorpora protocolo de transporte e, pode ser utilizado por diferentes protocolos de transporte.

O SDP não tem a intenção de negociar conteúdo da sessão ou codificadores de mídia, apenas descrever as informações referentes a sessão. Para gerenciamento de sessões multimídias o protocolo SIP [9] é utilizado, sendo as características da sessão negociadas com ambas as partes através do protocolo SDP (em termos de divulgação das informações).

O SDP, na sua especificação atual, inclui os seguintes parâmetros:

a) Nome da sessão e propósito;

b) Hora que a sessão será ativa;

c) Informações da mídia da sessão;

d) Informações de recebimento da mídia (endereços, portas, formatos, etc);

e) Informações da largura de banda a ser utilizada;

f) Informações de contato da pessoa responsável pela sessão;

Conforme a RFC 2327 os parâmetros do SDP são apresentados a seguir com uma curta descrição:

Descrição da sessão:

Page 18: Voz sobre IP- Tecnologia e tendências

a) v= (versão do protocolo)

b) o= (proprietário/criador da sessão)

c) s= (nome da sessão)

d) i=* (informação da sessão)

e) u=* (URI da descrição)

f) e=* (e-mail)

g) p=* (número telefônico)

h) c=* (informações da conexão)

i) b=* (informações da largura de banda)

Uma ou mais descrições de hora (abaixo):

j) z=* (ajustes de time zone)

k) k=* (chave de criptografia)

l) a=* (zero ou mais linhas de atributos da sessão)

Zero ou mais descrições da sessão (abaixo):

Descrição de hora:

m) t= (hora que a sessão é ativa)

n) r=* (zero ou mais tempos de repetição)

Descrição da mídia:

o) m= (nome da mídia e endereço de transporte)

p) i=* (rótulo da mídia)

q) c=* (informações de conexão)

r) b=* (informações de largura de banda)

s) k=* (chave de criptografia)

t) a=* (zero ou mais linhas de atributo da mídia)

4.7. MGCP

O MGCP [10] é um protocolo para controle de gateways de telefonia através de elementos de controle externo chamados media gateways controllers. O mesmo assume a arquitetura de controle da chamada onde a inteligência da chamada está fora do gateway e é executada por elementos de controle externo.

A idéia central do MGCP é prover mecanismos que possibilitem a criação de gateways distribuídos, onde a principal carga da operação (a tradução de padrões e mídias de uma rede para outra) seja executada por diversos elementos distintos, possivelmente localizados em máquina distintas. Não obstante, o MGCP objetiva a criação de um ambiente

Page 19: Voz sobre IP- Tecnologia e tendências

onde, externamente, esses diversos elementos distribuídos possam ser vistos como uma unidade única indivisível.

O MGCP utiliza terminais simples chamados MGs (Media Gateways). No papel de servidor há o MGC (Media Gateway Controller) que provê os serviços. Nos extremos da linha ficam os MGs que possibilitam interação com o usuário, enquanto que o MGC provê o gerenciamento centralizado de onde saem todos os comandos. É importante entender que neste modelo o MG é um terminal simples sem funções inteligentes, todas as funções são executadas no MGC. As mensagens de controle entre servidor/cliente (MGC/MG) são enviadas em UDP/IP e quando se estabelece uma conexão de voz serão utilizados os pacotes RTP.

O modelo centralizado de controle permite a criação de ambientes muito mais eficientes, incluindo, controle de tarifação, call-agents, serviços de mensagens, etc.

Dependendo do equipamento, o servidor MGC pode suportar integrações com aplicações de telefonia usado nos PBXs. e oferece interação com os outros protocolos do IETF como SDP, SAP, RTSP etc.

4.8. MEGACO

Derivado do protocolo de controle de gateway de mídia (MGCP), o Megaco [11] fornece controle centralizado de serviços e comunicação de multimídia sobre redes baseadas em IP. Ele está ganhando aceitação porque permite maior capacidade de ajuste que a permitida pelo H.323 e enfoca os requisitos técnicos e os recursos de conferência multimídia omitidos no MGCP.

Do ponto de vista funcional, o Megaco é um protocolo de sinalização usado entre os elementos de uma arquitetura distribuída que inclui gateways de mídia e controladores de gateways de mídia (geralmente chamados de softswitches ou de agentes de sessão). Ou seja, sua funcionalidade primária é extremamente semelhante ao MGCP.

É importante destacar a diferença entre o MGCP e MEGACO e os demais protocolos de sinalização, em particular o SIP. O objetivo dos dois primeiros é o controle de um elemento em particular (os gateways), enquanto do último é o estabelecimento de sessões entre diversos tipos de elementos distintos. Obviamente, em determinados cenários de utilização (particularmente em situações de trunking via VoIP) o MGCP e MEGACO podem ser utilizados sem o SIP, mas os mesmos não conflitam diretamente em termos de funcionalidades.

4.9. CPL

A Call Processing Language [59] é a linguagem que pode ser utilizada para descrever e controlar serviços de telefonia IP. Ela pode ser implementada em networks servers ou user agent servers. A CPL pretende ser simples, extensível, de fácil programação e independente de sistema operacional. Ela é baseada no Extensible Markup Language (XML), um formato de dados comum para descrição de dados estruturados. Muito embora a CPL não seja um protocolo em si, ou mesmo um sistema de sinalização, incluímos a mesma nessa seção pelo seu relacionamento com os elementos previstos no SIP.

Page 20: Voz sobre IP- Tecnologia e tendências

A CPL é uma linguagem de scripts que permite que os usuários finais especifiquem o comportamento dos agentes de chamada, que executam em seu software de telefonia IP. O agente de chamada é chamado quando o servidor SIP recebe um pedido de chamada. Este agente executa as instruções geradas nesta linguagem, como por exemplo sempre tentar contatar determinada pessoa no seu celular, depois na sua casa e em seguida no escritório pelo menos uma vez.

5. Qualidade e Manutenção de Qualidade

Uma das buscas constantes em sistemas de VoIP consiste na manutenção de um nível aceitável de qualidade e inteligibilidade final observada pelos usuários. Isto é especialmente importante considerando que os usuários dos sistemas tradicionais de telefonia estão acostumados com um alto nível de qualidade de serviço.

Apesar das vantagens da transmissão de voz sobre uma rede de pacotes, algumas dificuldades são inerentes ao sistema de transporte de dados, impondo restrições à operação em tempo real. Pode-se citar entre elas:

a) atraso fim-a-fim: pacotes com atrasos superiores a limites pré-estabelecidos são considerados perdidos em sistemas de VoIP [21,44];

b) variação do atraso (jitter): variações de atraso possuem um efeito bastante significativo na qualidade do sistema de VoIP;

c) perdas e erros de pacotes: redes IP apresentam uma forte característica de perda por curtos intervalos de tempo. Essa perda afeta diretamente a qualidade final observada.

Como são diversos os problemas relacionados à cerca da qualidade de um sistema de VoIP, não existe um único processo e sim processos conjugados para resolver problemas isolados. Pode-se citar de forma não exaustiva ações corretivas: compensação do efeito do atraso fim-a-fim através de buffers de recepção, técnicas de compensação de perdas de pacotes ocasionadas pela rede, técnicas de correção de eventuais perdas.

5.1. Adaptação de Qualidade

A adaptação da qualidade em sistemas de voz sobre IP procura caracterizar a adaptação das taxas efetivas de transmissão em razão de um processo de congestionamento. Contudo, no caso de sistemas de VoIP onde, freqüentemente, temos a utilização de taxas mínimas de transmissão através de uma compressão eficaz da voz digitalizada e do uso de mecanismos de detecção de silêncio, não é possível aceitar a queda da taxa de transmissão como um mecanismo de adaptação.

Em razão da necessidade de prover mecanismos os quais, independentemente das condições da rede, possibilitem a inteligibilidade da voz nos curtos períodos onde se observa uma alta taxa de perdas, é mais adequada, portanto, a utilização do termo manutenção da qualidade.

5.2. Bufferização

O principal mecanismo para a atenuação dos efeitos dos dois últimos itens apresentados anteriormente é a utilização de buffers de reprodução da fala ou buffers de dejitter (playout adaptation buffers). Primordialmente, a bufferização dos frames de voz

Page 21: Voz sobre IP- Tecnologia e tendências

procura a eliminação do efeito causado pelo jitter na transmissão (inserção de intervalos ou falhas na reprodução do áudio). Devido ao fato de termos um sistema que possui dados para reprodução a uma taxa constante, temos a necessidade de um sistema que possua dados para reprodução a uma taxa constante igual à da origem. Ou seja, caso o sistema não receba os pacotes de voz a tempo, ele perceberá a ausência do mesmo como uma perda[44]. Neste caso, os buffers de dejitter auxiliam a atenuação da percepção da perda de pacotes devido a variações bruscas no atraso. Porém, o uso desse mecanismo não compensa a perda da fala, e mecanismos de compensação de perdas devem ser utilizados em conjunto para atender um objetivo de perda nula ou com valor determinado, com atrasos máximos estabelecidos na forma do correto dimensionamento do buffer.

O dimensionamento do buffer para a compensação do jitter e para a eliminação da percepção de perda de pacotes está diretamente relacionado aos atrasos observados comumente em redes IP. Entre os diversos mecanismos existentes para o correto dimensionamento do buffer, são de particular interesse todos aqueles que possibilitem um redimensionamento dinâmico em razão das condições da rede.

5.3. Mecanismos de Correção de Perdas de Pacotes

5.3.1 Forward Error Correction (FEC)

O uso de FEC é dos mecanismos mais visados na atualidade para a manutenção da qualidade de sistemas VoIP. Os métodos FEC adicionam redundância de dados para permitir a correção dos dados perdidos durante a transmissão. Por este motivo, incorrem numa utilização desnecessária dos recursos de rede nos casos em que as condições estejam normalizadas e já não apresentem perdas significativas de pacote, assim sendo, deve haver uma relação de compromisso entre a adição de redundância e o congestionamento da rede, se considerar que a perda em grande parte pode ser devido a um congestionamento, o aumento do fluxo de dados pode tornar ainda pior a situação.

O termo FEC referencia mecanismos de correção dependentes e independentes da mídia sendo utilizada[21].

5.3.1.1. Independente da Mídia

Neste caso temos uso de códigos sintáticos, como o Reed Solomon, ou de códigos de correção mais elementares, baseados em códigos XOR, para produzir pacotes adicionais que ajudam na reconstrução dos pacotes perdidos. Um pacote de guarda é gerado e enviado a cada n-1 pacotes de dados provendo a recuperação de n pacotes de dados. Os mecanismos FEC independentes da mídia apresentam a vantagem de poderem ser utilizados sem o prévio conhecimento da mídia sendo transmitida, constituindo um caso genérico para a solução de problemas de erros e perdas. Contudo, isso implica na introdução de um atraso, pois pressupõe o conhecimento dos dados a serem trabalhados, para construção do pacote de guarda (esse atraso, contudo, é introduzido na etapa de recepção, através dos buffers de dejitter).

Page 22: Voz sobre IP- Tecnologia e tendências

Figura 5: reconstrução de frames perdidos de voz por utilização de FEC independente de mídia

[21]

5.3.1.2. Dependente da Mídia

Os mecanismos dependentes da mídia, por sua vez, possibilitam a criação de códigos de proteção sem a introdução significativa de atraso, com eficiência superior, mas não reconstruindo plenamente as unidades perdidas, além de apresentarem a necessidade de serem construídos em concordância com a mídia a ser trabalhada.

Este método consiste em transmitir o pacote a ser protegido anexado em pacotes posteriores transmitidos. O emissor pode escolher enviar o frame de voz anexado no mesmo padrão de qualidade, estando, contudo, usualmente comprimido em qualidade inferior. Além disso, os dados de redundância podem ser transmitidos em um fluxo isolado de informações, a exemplo do que define o profile do RTP em [46] ou juntamente ao fluxo normal de dados, conforme o profile em [47].

Figura 6: reconstrução de frames de voz perdidos através do uso de FEC dependente de mídia

[21].

Esse mecanismo também é conhecido pelo nome de multiplicidade ou piggybacking[42].

5.3.2. Interleaving

Para discutirmos este mecanismo é importante diferenciarmos unidade e pacote, uma unidade de áudio é um intervalo de fala, um pacote pode conter uma ou mais unidades de áudio.

As unidades são reordenadas, isto é o mesmo segmento de sinal é transmitido em pacotes diferentes, e retornam para a ordem original no receptor, procurando dessa forma

Page 23: Voz sobre IP- Tecnologia e tendências

evitar que unidades contíguas de voz sejam perdidas devido a um congestionamento da rede. Em relação a esse fato, é interessante ressaltar que a característica de perdas de pacotes pode ser modelada conforme uma cadeia simplificada de Marcov (modelo de Gilbert) e se dá usualmente em picos de perdas, com poucos pacotes consecutivos.Assim a perda de um pacote resultará em pequenas lacunas em um segmento, ao invés de uma grande lacuna. Combinada com técnicas de compensação de perdas pode-se obter um nível aceitável de qualidade para taxas não muito elevadas de perda.

Figura 7: Interleaving - unidades reordenadas em múltiplos pacotes[21]

5.3.3. Retransmissão

Uma técnica comum para a correção de perda de pacotes é retransmitir o pacote perdido. Para que a retransmissão tenha sucesso o pacote retransmitido deve chegar ao receptor a tempo de ser reproduzido.

A retransmissão de pacotes, muito embora seja uma técnica evitada, pode ser considerada em casos específicos conforme o trabalho de [41]. Para esse tipo de situação, contudo, é importante considerar que só é possível o uso em redes com alta disponibilidade. A vantagem da utilização desses mecanismos é o baixo impacto que os mesmos oferecem sobre a rede, visto que, somente é retransmitido um pacote caso seja detectado a necessidade de correção de alguma perda. Existe um profile RTP específico para essa situação[45].

5.4. Mecanismos de Compensação de Perdas de Pacotes

Os mecanismos de compensação de perdas são implantados do lado do receptor, a fim de corrigir eventuais situações que realmente sejam observadas como a perda do pacote.

Existem basicamente três classes de compensação que podem ser utilizadas: técnicas de inserção, de interpolação ou de regeneração dos pacotes.

As técnicas de inserção prevêem a substituição do pacote perdido por silêncio, ou de ruído, ou repetição do último pacote recebido. No caso do silêncio sua eficiência esta relacionada diretamente com o tamanho da unidade perdida, uma vez que a falha se torna mais perceptível para o ouvido humano quando o tamanho do pacote perdido é maior. A técnica de inserção de ruído se mostra mais eficiente que o método anterior uma vez que o

Page 24: Voz sobre IP- Tecnologia e tendências

cérebro humano tem mais capacidade, dessa forma, de inconscientemente reparar a falta de um segmento de fala, conforme [40]. Além disso, a técnica de geração de ruído pode usar informações enviadas pelo emissor para gerar o ruído de conforto quando o sistema utilizar algoritmos de detecção de silêncio. A repetição do último pacote recebido explora as características de redundância da voz e tem baixa complexidade computacional e performance aceitável, necessitando apenas de um buffer com o último pacote recebido.

As técnicas de interpolação procuram recriar uma versão similar do pacote perdido através da interpolação entre pacotes adjacentes ao mesmo. Para isso é criado um buffer de amostras. Alternativamente pode-se usar amostras posteriores a perda, para se alcançar um resultado melhor. Apesar de apresentar resultados superiores as técnicas de inserção, o processamento despendido nessa situação é muito maior. A técnica mais conhecida deste grupo é o Waveform Substitution.

A técnica de regeneração estende o conceito da interpolação procurando agregar conceitos relativos ao codec utilizado na voz. Para isso usa as informações relativas ao algoritmo de compressão para recriar o áudio perdido. Esta técnica é necessariamente dependente da mídia e demanda muito processamento. Temos como exemplo, as técnicas Interpolation of Transmitted State e Model-based Recovery.

6. Fundamentos de Processamento Digital da Voz Aplicado à VoIP

Certamente o processamento de voz é essencial em qualquer sistema digital que objetive um correto tratamento da voz (a priori envolvendo desde os primórdios da digitalização da voz). Contudo, podemos destacar duas técnicas de particular importância para a área de VoIP: técnicas de detecção e supressão de silêncio e técnicas de cancelamento de eco (o problema em particular da codificação da voz – certamente DSP – é tão importante que deve ser considerado a parte – abordamos brevemente os mesmos aqui).

Antes de iniciarmos a discussão a respeito das técnicas citadas é preciso, contudo, considerar os princípios relacionados a própria codificação análogo-digital do sinal. Como o tópico em questão é bastante conhecido, elaboramos apenas uma breve discussão a respeito e recomendamos ao leitor buscar maiores informações acerca do assunto em livros da área de comunicação de dados.

A digitalização de um sinal consiste essencialmente em quatro etapas distintas que devem ser apropriadamente executadas: a filtragem do sinal analógico de entrada, a amostragem do mesmo conforme critérios bem conhecidos, a quantização do sinal e a codificação apropriada do mesmo. A filtragem do sinal relaciona-se diretamente com a etapa de amostragem, procurando garantir condições adequadas para o atendimento do teorema de Shanon-Nyquist, que estabelece a necessidade de uma freqüência de amostragem mínima igual ou superior a duas vezes a máxima freqüência do sinal (em casos de sinais banda-base). A freqüência máxima considerada usualmente para sinais de voz é de 4KHz (na realidade 3400Hz, mas podemos adotar 4KHz para efeitos de simplificação). Essa freqüência implica que a amostragem deva ser realizada minimamente a 8KHz. Após a etapa de amostragem a saída consiste em um sinal discreto temporalmente, o qual passa a se tornar digital após a quantização. A quantização irá discretizar o sinal em termos de amplitude. No caso da consideração de um conversor PCM linear, os níveis de quantização são distribuídos

Page 25: Voz sobre IP- Tecnologia e tendências

igualmente ao longo da faixa dinâmica de amplitude do sinal. O nível quantizado é então codificado de forma apropriada. A saída do conversor AD, para o caso de uso do PCM com 8 bits por amostra é de 64Kbps. Considerando-se o PCM linear (que não é utilizado para voz ? as versões utilizadas são as de lei-A e lei-µ), a relação dinâmica provida por uma quantização com 8 bits é da ordem de 48,16 dB. Considerando-se o PCM lei-A, é de aproximadamente 72dB, suficiente para o ouvido humano perceber com clareza as variações de nível na voz do interlocutor.

Após a etapa de conversão do sinal, poderíamos proceder à compressão do mesmo (em muitos casos é possível executar as duas operações concomitantemente). Os principais codificadores considerados para trabalho com sinais de voz são o PCM (Pulse Code Modulation), o ADPCM (Adaptative Differential Pulse Code Modulation), os codificadores LPC (Linear Prediction Code), o ACELP, CELP e CS-ACELP.

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. 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á por meio simplesmente das operações de amostragem e quantização. A codificação pode ser a PCM, a 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. É feita uma parametrização das 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” quase unitária, ou seja, para a qualidade aumentar, deve-se aumentar igualmente a taxa de transmissão. Obviamente, isso não é desejável em sistemas de voz sobre IP. Codificadores de fonte, por sua vez, possuem taxas de transmissão muito baixas, mas, por mais que a mesma seja ampliada, a qualidade não melhora significativamente. 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 ruim, mas uma taxa de transmissão muito baixa.

Para resolver este problema, são utilizados os codificadores híbridos, que reúnem características de ambos os codificadores citados. 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

Page 26: Voz sobre IP- Tecnologia e tendências

codificadores de voz da ITU são os G.728(LD-CELP), G.729, G.729A(CS-ACELP) e o G.723.1(ACELP). 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 complexo, para gerar taxas de transmissão mais baixas.

Apesar de as tecnologias de Vocoding serem as mais adequadas para emprego em VoIP, a técnica de ADPCM ainda é muito utilizada por vários fabricantes, sendo inclusive a técnica empregada na transmissão de voz sobre ATM. A mesma consiste de um algoritmo adaptativo que pode ser otimizado com 5, 4, 3 ou 2 bits por amostra, resultando respectivamente em taxas de 40, 32, 24 ou 16kbps. A codificação das diferenças, entre amostras consecutivas, da voz, com 4 bits, resultando em uma taxa de 32 kbps, é a mais conhecida e utilizada. Na comparação com as técnicas de Vocoding, entretanto, esta técnica tende a perder espaço, pois exige mais taxa de transmissão para a mesma qualidade, apesar de apresentar a vantagem de exigir um processamento menor de dados.

Os fatores que devem ser levados em conta, quando comparamos diferentes técnicas de Vocoding, ou Vocoders, são:

a) taxa de bits (Bit Rate): na tecnologia VoIP, o meio de transmissão é compartilhado entre os dados e a voz, porém muitos Vocoders ainda operam com taxas fixas de transmissão, independente do sinal de voz que é transmitido, quando a idéia é evoluir-se para o uso de taxas variáveis de transmissão;

b) atraso: os atrasos se devem, basicamente, a dois componentes importantes que são o atraso de quadro, onde é preciso esperar o número de bits do quadro para poder processá-lo, e o atraso de processamento da voz, que se deve ao tempo necessário para codificação e decodificação;

c) complexidade do algoritmo: geralmente medida em termos da velocidade de computação da quantidade de RAM e ROM que são exigidos. Uma complexidade maior do algoritmo resulta em custo maior de processamento e de consumo de energia (importante em aplicações portáteis);

d) qualidade: medida relativa da qualidade com que soa a voz sob condições ideais, ou seja, voz clara, sem erros de transmissão e com somente um processamento de codificação.

Tabela 1: comparação entre as principais técnicas de codificação de voz

Algoritmo G.723.1 G.729

G.729A

G.728 G.727

Taxa em kbps 5,3 a 6,3 8 16 32

Qualidade Boa Boa Boa Boa

Complexidade Maior Alta Baixa Alta

O funcionamento básico de um Vocoder do tipo CELP é mostrado a seguir. Com base em códigos previamente armazenados, o algoritmo trabalha num laço efetuando

Page 27: Voz sobre IP- Tecnologia e tendências

continuamente o cálculo do erro entre o valor estimado (predição) e o valor real do sinal de entrada (voz), para uma determinada freqüência. Para reduzir o erro, são alterados os parâmetros do filtro LPC (linear predictive coding), o valor do ganho (G) e os parâmetros do filtro de predição de tom (pitch prediction filter). Após feita a variação destes parâmetros, calcula-se quais parâmetros minimizam o erro.

Estes parâmetros (filtro LPC, ganho e filtro de predição de tom) são então codificados e transmitidos.

Figura 8: funcionamento básico de um Vocoder CELP

As técnicas de cancelamento de eco objetivam solucionar um dos principais incômodos introduzidos pelo atraso em sistemas de voz sobre IP [14]: a existência de eco acústico e eco introduzido pela passagem de sistemas de quatro fios para sistemas de dois fios (o qual, para todos efeitos, é considerado como um eco acústico).

O eco acústico é devido a própria realimentação acústica observada no ponto receptor de um sinal: a reprodução do sinal com a conseqüente captura do mesmo (possivelmente através de fone e microfones) provoca o re-envio do sinal para o transmissor e assim sucessivamente. Isso é bastante natural e o efeito torna-se visível apenas quando o atraso origem-destino é significativo (pelas normas do ITU-T atrasos superiores a 150ms entre origem e destino devem levar à consideração da adoção de canceladores de eco nos sistemas envolvidos ? na prática esse limite é um pouco mais elástico). Obviamente, o eco em questão consiste na realimentação do sistema. Usualmente a realimentação não é positiva e o usuário/desenvolvedor não se preocupa com a eliminação desse sinal (é possível contudo, devido a etapas intermediárias de amplificação, que a realimentação seja positiva ? nessa situação o sistema deverá tratar obrigatoriamente o problema com um cancelador de eco apropriado). A preocupação surge a partir do momento em que o eco se torna desconfortável para o usuário final. O eco acústico pode ser bastante minimizado através da utilização de fones e microfones direcionais, que eliminam quase totalmente o efeito da realimentação.

Não obstante, o eco decorrido da adaptação de sistemas de quatro fios para sistemas de dois fios está presente e não pode ser minimizado de forma simples (somente através da adoção de canceladores de eco). A terminologia quatro fios e dois fios referem-se, obviamente, ao caso de telefonia tradicional. Sistemas telefônicos tradicionais utilizam, no chamado local-loop (i.e., na conexão do terminal com a dita central office), dois fios para a

Page 28: Voz sobre IP- Tecnologia e tendências

transmissão dos dados. Isso implica a mistura dos sinais para a transmissão apropriada pelo meio. Essa mistura é efetuada por um elemento conhecido como híbrida e ocorre, basicamente, em dois momentos: no próprio terminal telefônico (na adaptação do sinal advindo do microfone e do sinal dirigido ao fone) e na conexão do meio do terminal à própria central office (devido a presença de redes digitais na conexão entre centrais telefônicas, é necessário adaptar o fluxo unitário provido por um interlocutor ao fluxo fornecido pelo outro usuário – digitalmente existem dois fluxos distintos de informação, i.e., um sistema a quatro fios). Pelas características próprias da híbrida, a mesma introduz um certo grau de realimentação do sistema a dois fios para o sistema a quatro fios, e isso irá causar o efeito de eco. Infelizmente a híbrida está presente virtualmente em todo o sistema telefônico tradicional e qualquer operação que envolva a interconexão com a RPTC deve, portanto, tratar essa questão.

Como as híbridas e o próprio eco acústico podem variar em intensidade de um sistema para outro e ao longo do tempo, os canceladores de eco são filtros adaptativos, que objetivam subtrair do sinal a ser transmitido uma versão atrasada e filtrada da onda anteriormente recebida (isso também pode ocorrer ao contrário).

Figura 9: exemplo de um sistema sofrendo eco acústico com a adição de um

cancelador de eco no receptor.

A chave para a operação dos canceladores de eco relaciona-se com o fato da chamada em loop fechado poder ser modelada matematicamente. Supondo que um interlocutor B não esteja falando, é possível modelar o interlocutor A como um bloco, uma caixa preta, onde a entrada de voz do interlocutor resulta numa saída particular. A resposta impulsiva dessa caixa preta pode ser vista como a função de transferência do sistema, H(t), e o sinal de saída dessa caixa pode ser denominado como y(t). O cancelador armazena uma estimativa da resposta impulsiva, denominada H1(t). O cancelador de eco tem acesso ao sinal x(t) originado do interlocutor A. Passando esse sinal pela filtro H1(t), o mesmo passa a ter uma estimativa do eco, denominada y1(t). Esse eco virtual é subtraído do eco real, resultando num sinal de erro e(t), o qual, idealmente, é zero. A obtenção da função H1(t) é feita através de um gradiente de coeficientes de um filtro adaptativo de resposta impulsiva finita (FIR).

A mensuração do eco pode ser feita através do uso das seguintes alternativas:

a) Echo return loss (ERL): a redução do nível de eco produzido pelo circuito de comunicação sem o uso de um cancelador de eco. Ou seja, se um sinal entra no receptor com um nível de X dB, o eco injetado na rede será X-ERL dB;

Page 29: Voz sobre IP- Tecnologia e tendências

b) Echo return loss enhancement (ERLE): a redução adicional no nível de eco fornecida pelo cancelador de eco. O cancelador não é perfeito, logo ele apenas é capaz de atenuar o efeito do eco. Essa quantia expressa a atenuação propiciada pelo elemento cancelador entre o sinal com eco recebido em sua entrada e o sinal atenuado em sua saída;

c) Acombined (ACOM): a atenuação total provida pelo ERL e ERLE.

A detecção e supressão de silêncio, por sua vez, justifica sua necessidade por simples questões de otimização do sistema. É bastante simples explicar essa necessidade: em uma conversação existem, minimamente, dois fluxos disjuntos de informações (exceto pelo efeito de realimentação introduzido): o fluxo do usuário A para o usuário B e do usuário B para o usuário A (ou seja, um sistema a quatro fios). Nas redes telefônicas tradicionais, determinísticas, a alocação dos circuitos para transmissão é feita e, independentemente dos usuários estarem utilizando os circuitos, os mesmos são mantidos durante todo o período da chamada. Obviamente (na maior parte dos casos), quando A está falando B encontra-se escutando e, provavelmente, em silêncio. Não há nexo, portanto, em transmitir dados que não carregam nenhuma informação útil de B para A (exceto o próprio silêncio). Quando utilizamos redes de pacotes, de alocação dinâmica, para essa transmissão, podemos proceder, minimamente, a eliminação desse fluxo de dados inútil. Para isso é necessário justamente lançarmos mão das técnicas de detecção e supressão de silêncio.

Figura 10: principais medidas aferidas acerca de elementos canceladores de

eco.

A parte da razão expressa acima, também é claro que na fala de um interlocutor existem vários períodos de pausa que podem ser eliminados sem detrimento da qualidade final observada pelos usuários. Ou seja, é possível também utilizar técnicas de VAD (Voice Activity Detection) para eliminar as pausas existentes na própria fala.

Os algoritmos de VAD dividem-se, essencialmente, nas seguintes categorias [48]:

a) técnicas de detecção baseadas na energia do frame de voz: baseado na estimativa da energia contida num frame de voz, é razoável considerar se o frame é ativo ou inativo. Essencialmente, a regra de classificação é bastante simples: se Ej>kEn, então o frame é ativo, senão é considerado inativo. Ej expressa a energia do frame, Em a energia de um frame apenas com ruído e k é um fator maior que um. Ou seja, kEn é o limite de alteração entre o estado ativo e inativo. Algumas técnicas que se encontram nessa categoria são: LEP (Linear Energy-Based

Page 30: Voz sobre IP- Tecnologia e tendências

Detector); ALED (Adaptative Linear Energy-Based Detector) e WFD (Weak Fricatives Detector);

b) técnicas de detecção baseada no domínio freqüência: essas técnicas levam em consideração as características em freqüência do sinal de voz. Alguns algoritmos que se situam nessa categoria são: LSED (Linear Sub-Band Energy Detector) o qual se baseia numa comparação da energia do frame de voz no domínio freqüência em quatro sub-bandas a parte; SFD (Spectral Flatness Detector), o qual avalia a atividade de voz através da análise da variância do sinal no domínio freqüência; CVAD (Comprehensive VAD), o qual é uma conjunção das técnicas anteriores.

Um outro aspecto importante a ser considerado acerca dos supressores de silêncio é o chamado fator de holdover, o qual consiste essencialmente em uma histerese para os algoritmos de detecção de silêncio, evitando que a consideração de atividade ou inatividade varie bruscamente, causando impacto na operação do sistema.

Figura 11: fluxo de decisão do detector CVAD

Outras técnicas auxiliares também podem ser utilizadas para complementar sistemas de VoIP. Entre elas podemos citar a existência de geradores de ruído, utilizados com dois propósitos: a inserção do chamado ruído de conforto quando da existência de períodos de silêncio e a inserção do ruído como substituição a eventuais pacotes perdidos e não recuperados através de outras técnicas de correção e compensação. O ruído de conforto usualmente é gerado como um ruído gausiano, a fim de simular o efeito do conhecido ruído branco, presente nos sistemas de comunicação tradicionais. O ruído de conforto é importante, como o próprio nome diz, para possibilitar que o interlocutor perceba a comunicação como “ativa”, evitando a sensação desagradável de imaginar a conexão como quebrada [51].

7. Avaliação de Qualidade

A percepção da qualidade da voz pelo usuário é determinante na avaliação no desempenho de um sistema de VoIP. Conforme já visto, os principais problemas afetam a qualidade da voz fim-a-fim dos sistemas de Voz sobre IP são, essencialmente, o atraso fim-a-fim, a variação desse atraso (jitter), a perda de pacotes e a existência de erros nos pacotes. Via de regra os erros presentes em um pacote não são determinantes, já que as redes atuais caracterizam-se por taxas de erros de bit (BER) suficientemente baixas para este problema ser desprezado, na maior parte dos casos (não obstante é importante considerar o mesmo

Page 31: Voz sobre IP- Tecnologia e tendências

quando da utilização de links sujeitos a erros – caso particular de enlaces de rádio ou redes wireless que não possuam por si só mecanismos que garantam uma BER suficientemente baixa).

Dos problemas acima apresentados acima o atraso é, sem dúvida, o mais significativo de todos, já que é usualmente uma quantia fora do controle do usuário (a menos da utilização de redes e protocolos que sejam capazes de priorizar a entrega de pacotes). Conseqüentemente, essa é uma variável que deve ser considerada não só na construção de sistemas de voz sobre IP como igualmente nas técnicas de avaliação da qualidade (e o atraso é determinante na forma como o usuário avalia a qualidade do sistema como um todo).

Conjugado ao atraso, o jitter pode introduzir uma série de problemas, particularmente sendo interessante o fato do mesmo introduzir a necessidade de utilização de buffers de dejitter (os quais contribuem justamente para o aumento do atraso fim-a-fim em qualquer sistema de voz sobre IP). O jitter pode ser percebido, na pior situação, como um problema de perda de pacotes [51].

Muito embora a perda de pacotes possa ser até mesmo desprezada, na maior parte dos casos, quando da utilização de VoIP em redes privadas, ainda assim é importante destacar que a mesma é mais significativa quanto maior for a eficiência do compressor utilizado (obviamente, nos casos da voz codificada simplesmente com o uso de técnicas PCM, a correlação existente entre frames contíguos é tão grande que a perda de uma única unidade não é tão significativa). Não obstante, quando da utilização de sistemas de VoIP através da Internet, essa questão passa a ser bastante significativa. Nessa situação devemos considerar os estudos que procuram modelar e caracterizar a perda observada na Internet, como nos trabalhos de Bolot et al. [18] e Hardman et al. [20]. As técnicas de manutenção e adaptação de qualidade observadas anteriormente passam a ser de vital importância em tal ambiente.

Figura 12: distribuição da perda de pacotes consecutivos [18]

Duas técnicas se destacam a esse respeito: a técnica MOS [55] e PSQM [1] ou PSQM+ .

A avaliação MOS (Medium Opinium Score) é a mais comumente utilizada para avaliação qualitativa da voz frente aos usuários. A mesma consiste, essencialmente, numa

Page 32: Voz sobre IP- Tecnologia e tendências

avaliação junto aos usuários do sistema, através de uma grade de valores de qualidade subjetivos, encontrados no método ACR – Absolute Category Rating, do ITU-T P.800. Um problema fundamental com essa aproximação, contudo, é que é difícil e demorado conduzir experimentos controlados com pessoas a fim de obter-se dados empíricos que permitam o desenvolvimento de funções aceitáveis que mapeiem condições diversas de qualidade de serviço e tipos de codecs para a qualidade subjetiva de voz que é percebida pelos usuários.

Abaixo podemos visualizar valores MOS típicos para os codificadores mais comumente utilizados.

Tabela 2: valores MOS típicos para codificadores mais comumente utilizados.

Codificador Largura de banda [kbps] Qualidade (MOS)

µLaw 64 4.2

ADPCM 32 4.1

GSM 13.2 3.6

G.723.1 5.3/6.3 3.5/4

LPC 2.4-5.6 2.4-3

Uma alternativa ao modelo oferecido pelo MOS é o uso de dispositivos de envio e recepção de voz a fim de monitorar a qualidade fim-a-fim (utilizando para tanto segmentos de fala pré-gravados ou sinais artificiais baseados na especificação ITU-T P.50 [56]) que permitam automaticamente determinar a qualidade dos sinais recebidos aplicando métodos objetivos para a medição da qualidade da voz. Essas alternativas são trabalhadas pelas técnicas ITU-T P.861 PSQM [1], pela sua versão melhorada para voz em redes de pacotes, a PSQM+, ou mesmo através da técnica mais recente a ITU-T P.862 PESQ [57].

As técnicas em questão comparam o sinal de voz recebido com o sinal de voz enviado a fim de possibilitar um mapeamento para o MOS [54].

Uma técnica adicional para avaliação da qualidade, bastante interessante, é descrita no trabalho de Janssen et al. [19]. A mesma é baseada no bem conhecido modelo-E, o qual possibilita o estudo dos efeitos do atraso e perdas típicos em VoIP sobre a avaliação da qualidade. O aspecto interessante é que o trabalho em questão permite a adição de um fator (fator A) que permite avaliar igualmente a expectativa do usuário em relação ao sistema. O resultado é estimado através de um resultado variando entre 0 (pior qualidade) até 100 (melhor qualidade). O ITU-T considera em suas considerações que valores inferiores a 50 são inaceitáveis para ambientes de telecomunicações. O valor considerado como toll-quality é 70. Abaixo podemos ver uma tabela exibindo os valores típicos para diversos codificadores, desconsiderando o fator de expectativa A (numa condição onde a atenuação introduzida por um cancelador de eco seria perfeita).

Page 33: Voz sobre IP- Tecnologia e tendências

Tabela 3: qualidade mensurada dos principais codecs a partir do trabalho de Janssen et al. [19].

Origem Padrão Tipo Taxa [kbps] Qualidade (R)

G.711 PCM 64 94.3

16 44.3

24 69.3

32 87.3 G.726, G.727 ADPCM

40 92.3

12.8 74.3 G.728 LD-CELP

16 87.3

G.729 (A) CS-ACELP 8 84.3

ITU-T

G.723.1 ACELP 5.3 75.3

GSM-FR RPE-LTP 13 74.3

GSM-HR VSELP 5.6 71.3 ETSI

GSM-EFR ACELP 12.2 89.3

Considerando-se o mesmo modelo, podemos dimensionar a máxima taxa de perdas aceitável, para um atraso fim-a-fim menor que 150ms e uso com toll-quality.

Tabela 4: máxima taxa de perdas aceitável em sistemas considerando: TC- técnicas de compensação sendo utilizadas; VAD- técnicas de detecção e

supressão de silêncio (Janssen et al. [19]).

Origem Padrão Taxa Limite de perda (%)

G.711 sem TC 64 1

G.711 com TC 64 10

G.729(A) + VAD 8 3.4 ITU-T

G.723 +VAD 6.3 2.1

ETSI GSM-EFR 12.2 2.7

8. Sistemas Legados: fundamentos

O termo sinalização, em telefonia, se refere à troca de informações entre componentes de comunicação para prover e manter o serviço de comunicação.

A sinalização telefônica, que consiste na forma de comunicação entre as centrais telefônicas, foi inicialmente implementada utilizando os próprios canais de voz para transportar informações na forma de tons e pulsos elétricos rudimentares. Assim, os primeiros sistemas de sinalização utilizados nas centrais automatizadas se basearam totalmente na codificação de

Page 34: Voz sobre IP- Tecnologia e tendências

informações simples em sinais elétricos (pulsos) - sinalização E&M - e, posteriormente, em combinações de tons audíveis - sinalização MFC - transportados pelo próprio canal de voz, ou seja, pelo mesmo canal de conversação. Essa sinalização era denominada a sinalização de canal associado, e possuía uma série de desvantagens que levaram a adoção de outros esquemas de sinalização.

Para se obter melhores performances, foram definidos canais de sinalização exclusivos para esse fim, deixando os canais de voz somente para voz e os canais de sinalização somente para sinalização. Essa medida foi possível já na introdução do sistema PDH [15], através do uso do chamado canal comum para o transporte das informações de sinalização.

8.1. Sinalização SS7

O Signaling System 7 (SS7) é uma arquitetura para execução de sinalização out-of-band (utiliza um canal próprio para sinalização- usualmente o canal comum) no suporte a estabelecimento de chamada, tarifação, roteamento e funções de troca de informações na rede pública de telefonia comutada (RPTC, Public Switched Telephone Network - PSTN). Identifica as funções e os procedimentos a serem executados pela rede de sinalização para seu funcionamento. O mesmo é um meio pelos quais elementos da rede telefônica trocam informações. Essas são transportadas sob a forma de mensagens.

O objetivo do Sistema de Sinalização por Canal Comum nº7 (SSCC7 ou SS7), especificado e padronizado pelo International Telecommunication Union - Telecommunication Standardization Sector (ITU-TSS) é, fazer com que as informações de sinalização e controle não transitem no próprio canal de voz correspondente, e sim através de uma rede de dados independente. Dessa forma há uma maior disponibilidade dos canais de voz, visto que esses não serão utilizados para transmissão de sinalização.

Sinalização out-of-band é a sinalização que não ocorre no mesmo canal da conversação, ou seja, estabelece um canal digital separado para a troca de informações de sinalização. Este canal bidirecional é chamado de enlace de sinalização (signaling links). Signaling links trafegam informações a taxas de 56 ou 64 kbps (a depender do sistema de transporte sendo utilizado – no caso do sistema americano e japonês pode-se enfrentar o problema do robbed bit, o qual reduz a taxa máxima possível para 56 kbps). É interessante destacar que essa é a banda ocupada por um canal de voz digitalizado, a qual encontra sua justificativa nos princípios de processamento de sinais já abordados no texto.

Dentre as vantagens em se usar uma sinalização out-of-band temos a possibilidade de realizar sinalização a qualquer hora durante toda a conversação e não apenas no início e possibilita a sinalização de elementos da rede que não possuem uma conexão direta.

8.2. Fundamentos da rede de sinalização SS7

Visto que a sinalização é transportada em um caminho diferente da voz, a arquitetura mais simples seria alocar um dos caminhos entre cada comutador conectado para tráfego de mensagens de sinalização. Para realizar sinalização entre nodos que não estão conectados diretamente sinalização associada torna-se muito complexa, devido a isso surgiu a arquitetura North American SS7.

Page 35: Voz sobre IP- Tecnologia e tendências

A arquitetura de sinalização North American define novas e separadas redes de sinalização. Para construção das redes são considerados alguns componentes essenciais que de forma geral, são chamados de Ponto de Sinalização (PS, Signaling Point). Os mesmos são identificados por um código de endereçamento único, conhecido como point code. Esses componentes são apresentados abaixo:

a) SSP: Signal Switching Point, um PS que provê acesso local à rede de sinalização (end offices ou tandems). Geralmente originam, terminam ou comutam chamadas. É o ponto final das redes SS7, assim como o telefone é o ponto final na rede PSTN;

b) STP: Signal Transfer Point, ponto de sinalização com função de transferência, isto é, encaminha para outros PS as mensagens recebidas. São os comutadores de pacotes da rede SS7. Eles executam funções de roteamento especializados. De forma mais clara, o trabalho do STP é examinar o destino das mensagens que ele recebe, consultar a tabela de roteamento e enviar as mensagens pelo caminho usando os links que foram selecionados da tabela de roteamento;

c) SCP: Signal Control Points, são bancos de dados que provêm informações necessárias para realização de processamento de algumas chamadas, por exemplo 0800.

É importante destacar que se usa o termo enlace de sinalização ou apenas enlace para designar a conexão entre dois pontos de sinalização a nível lógico (funcional) e o termo enlace de dados de sinalização para se referir à conexão física por onde passa o enlace.

Os enlaces são dispostos em conjuntos que interconectam diretamente dois PS, chamados conjunto de enlace (linksets).

Um grupo de enlaces dentro de um mesmo conjunto de enlaces que tem características idênticas é chamado grupo de enlaces.

Além dos linksets, um PS deve definir rotas. A rota, nesse contexto em particular, é uma seqüência de linksets usada para atingir um determinado destino. Um linkset pode pertencer a mais de uma rota.

Devido a criticidade do processamento de chamadas, a disponibilidade da rede SS7 é considerada crítica. A menos que um SSP realize trocas de informações de sinalização, ele não poderá completar chamadas entre comutadores. Assim sendo, as redes SS7 são construídas com grande grau de redundância.

Os protocolos da rede SS7 são organizados em níveis, de maneira análoga às camadas do modelo de transporte de dados OSI (Open Systems Interconections) para redes de computadores [23]. São 4 os níveis no SS7; os três níveis de menor hierarquia compõem o Subsistema de Transferência de Mensagens (Message Transfer Part – MTP) e correspondem aos três primeiros níveis do modelo OSI. No nível 4 do SS7, que corresponde à camada de aplicação do modelo OSI, podemos ter vários subsistemas de usuários (user parts), como Telephone User Part (TUP) e o ISDN User Part (ISUP).

Page 36: Voz sobre IP- Tecnologia e tendências

presentation

application

session

transport

network

data link

physical MTP level 1

MTP level 2

MTP level 3

TUP

TCAPI

SUP

SCCP

Figura 13: Modelo OSI e pilha SS7

O Subsistema de Transferência de Mensagens (Message Transfer Part – MTP) é o protocolo de transporte usado pelos outros protocolos de nível superior no SS7. O MTP provê às demais camadas do SS7 os seguintes serviços:

a) transmissão de dados nodo-a-nodo;

b) esquema de detecção e correção de erros básicos;

c) sequenciamento de mensagens;

d) roteamento de mensagens;

e) discriminação de mensagens (a discriminação de mensagens determina a quem a mensagem é endereçada);

f) funções de distribuição de mensagens.

O MTP é subdividido em três camadas: nível 1, 2 e 3, que correspondem respectivamente aos níveis físico, enlace e rede do modelo OSI.

a) o nível físico do MTP (MTP1) é o responsável pela conversão de dados digitais em uma seqüência de bits para transmissão através da rede. Links de sinalização utilizam canais DS0 e levam dados de sinalização a taxas de 56 ou 64 Kbps;

b) o nível 2 (MTP2) provê funcionalidades da camada de enlace. Ele garante que dois signaling end points possam trocar mensagens de sinalização. Provêem capacidades de detecção e correção de erros e sequenciamento de todos os pacotes de mensagens do SS7;

c) o nível 3 (MTP3) estende as funcionalidades providas pelo MTP2 para prover funcionalidades da camada de rede. Ele garante que as mensagens possam ser

Page 37: Voz sobre IP- Tecnologia e tendências

trocadas entre signaling end points mesmo se não há uma conexão direta entre eles.

Outros níveis existentes são: a) Signaling Connection Control Part (SCCP): provê as duas maiores funções

que estão faltando no MTP. A primeira é a capacidade de endereçar aplicações dentro de um ponto de sinalização. A segunda função é a habilidade de executar roteamento incremental, usando global title translation (GTT). O GTT funciona semelhante a uma balanceador de carga;

b) ISDN User Part (ISUP): define o protocolo e as mensagens usado para estabelecer e terminar (tear down) as chamadas de voz e dados sobre a rede publica de telefonia comutada. Chamadas que originam e terminam no mesmo switch não utilizam sinalização ISUP;

c) Transaction Capabilities Application Part (TCAP): define o protocolo usado para comunicação entre aplicações nos nodos. Em vista das mensagens TCAP deverem ser entregues para aplicações individuais dentro dos nodos que eles endereçam, ele usa SCCP para transporte;

d) Operations, Maintenance and Administration Part (OMAP): define o protocolo designado para auxiliar os administradores das redes SS7.

A especificação mundial SS7 está na série Q.700 de recomendações da ITU Telecommunication Standardization Sector (ITU-), órgão permanente da International Telecommunication Union (ITU).

As principais recomendações da ITU-T de especificação da rede SS7 e seus componentes estão relacionados abaixo:

Assunto Recomendações ITU-T

Introdução ao Sistema de Sinalização N° 7 (SS7) Q.700

Message Transfer Part (MTP)

Descrição funcional do MTP do SS7

Enlace de dados de sinalização (MTP1)

Enlace de sinalização (MTP2)

Funções e mensagens da rede de sinalização (MTP3)

Q.701-Q704, Q.706 e Q.707

Q.701

Q.702

Q.703

Q.704

Telephone User Part (TUP) Q.721-Q.725

Data User Part (DUP) Q.741

ISDN User Part (ISUP) Q.761-Q.764, Q.766-Q.768

Serviços suplementares do ISDN Série Q.73x

Signaling Connection Control Part (SCCP) Q.711-Q.714, Q.716

Transaction Capabilities (TC/TCAP) Q.771-Q.775

Page 38: Voz sobre IP- Tecnologia e tendências

Gerenciamento da rede SS7 (OMAP, ASE) Q.750-Q755

Para detalhamento de outros aspectos mais específicos têm-se as seguintes recomendações ITU:

Assunto Recomendações ITU-T

Estrutura da rede de sinalização Q.705

Numeração de point codes de sinalização internacionais Q.708

Hypothetical signaling reference connection Q.709

MTP Simplificado para pequenos sistemas (aplicação PABX)

Q.710

Especificação de teste para os diversos componentes do SS7

Série Q.78x

9. Interconexão com sistemas legados

As redes de VoIP fazem melhor uso da largura de banda disponível que as soluções tradicionais da PSTN. Por exemplo na PSTN um circuito de 64 Kbps é alocado para cada chamada e por toda a chamada. Em redes VoIP, os dados de voz são digitalizados, comprimidos e transportados em pacotes sobre a rede IP. Usando a mesma largura de banda, redes VoIP podem transportar muitas chamadas de voz como na PSTN e com melhor qualidade.

Para conectar as duas redes, PSTN e IP é necessário que os dados de voz e os dados de sinalização sejam trocados entre ambas as redes. Como visto anteriormente, informações de sinalização são utilizadas para iniciar, terminar, comutar e gerir chamadas de voz.

As operadoras de telefonia fixa e móvel estão desenhando suas redes para uma arquitetura IP, pois os benefícios de usar redes IP em comparação as redes legadas time division multiplex (TDM) são:

a) fácil distribuição: melhoramentos futuros são transparentes;

b) equipamentos de baixo custo: elementos de sinalização legada são muito caros;

c) melhor eficiência: uso de novas tecnologias como IP sobre SDH e IP sobre fibra pode atingir um throughput maior. Limitação do padrão SS7;

d) alta largura de banda.

9.1. Sinalização SS7 em redes VoIP

Para que redes VoIP trafeguem sinalização SS7 sobre IP o IETF definiu um grupo chamado Signaling Transport, o qual produziu o já abordado SIGTRAN [61]. Este protocolo suporta os requerimentos da sinalização SS7 definidos pelo ITU.

Em redes de telefonia IP, definiu-se basicamente três componentes para troca das informações de sinalização, os quais já foram abordados ao longo do texto:

Page 39: Voz sobre IP- Tecnologia e tendências

a) Media Gateway: o media gateway termina as chamadas de voz com a rede PSTN, comprime e empacota os dados de voz e, entrega pacotes de voz comprimidos na rede IP;

b) Media Gateway Controller – executa o registro e gerenciamento dos recursos do media gateway. Um media gateway controller troca mensagens ISUP com o comutador central-office através do signaling gateway. Às vezes o media gateway controller é chamado de softwitch;

c) Signaling Gateway – provê conexão transparente de sinalização entre redes IP e redes comutadas;

Um media gateway, signaling gateway ou media gateway controller podem ser dispositivos físicos separados ou integrados no mesmo equipamento.

9.2. Sinalização SIP em redes VoIP

Devido ao fato de SIP ser um protocolo ainda em padronização não existe um mecanismo definitivo para a conexão e funcionamento de redes PSTN e IP.

Existem diversos trabalhos que propõem mecanismos para conexão das duas redes, dentre esses trabalhos estão:

a) en bloc – que se baseava na criação de um tempo T10 para aguardo de recebimento de um novo dígito. Foi apresentado e rejeitado no 47th IETF SIP Working Group, um encontro de pesquisadores que tratam do funcionamento da sinalização de redes PSTN com IP. Rejeitado pois impunha uma delay não aceitável no estabelecimento da chamada;

b) INFO – se baseia no envio de uma mensagem INFO para cada novo digito da rede PSTN (mensagem SAM). Gera um problema que é uma resposta de endereço inválido para a primeira mensagem;

c) Múltiplos INVITEs - propõe o envio de INVITEs completo a cada vez que uma mensagem SAM for recebida pelo ingress gateway, cada vez com um dígito a mais. Uma questão importante é o tratamento que os servidores proxies podem dar para as mensagens, ou seja, o servidor Proxy pode enviar a mensagem para mais de um egress gateway gerando mais de uma sessão de sinalização com a rede PSTN. Entretanto, existe a possibilidade de se enviar o método BYE ou CANCEL para finalizar uma chamada pendente.

Nos dias atuais a proposta que está sendo considerada para a conexão das redes IP e PSTN tem sido o envio de múltiplos INVITEs, levando a mensagem ISUP dentro do corpo da mensagem SIP. Esta é recebida pelo gateway que retira a mensagem ISUP e encaminha para o respectivo elemento da rede PSTN. Dessa forma o gateway de sinalização é responsável por fazer o empacotamento/desempacotamento das mensagens de sinalização da rede PSTN.

Page 40: Voz sobre IP- Tecnologia e tendências

Um gateway entre PSTN e redes IP baseadas em sinalização SIP deve implementar todas as funcionalidades de um user agent client SIP.Este gateway pode ser subdivido, logicamente, em:

a) Signaling Gateway – este gateway é responsável por terminar as chamadas associadas à sinalização SS7 (ISUP). Ou seja, executar a interface dos troncos PSTN que são controlados pelo ISUP. Este gateway se comunica com o media gateway através do protocolo MGCP. Provê interconexão transparente de sinalização entre as duas redes;

b) Media Gateway – este é muito similar ao proposto no framework de arquitetura SS7. Este gateway realizará a interconexão, ao nível de mídia, entre o circuito PSTN e o fluxo RTP;

c) Cliente SIP – responsável por executar toda a sinalização do lado IP;

d) Cliente RTP – responsável por executar o fluxo RTP;

e) Media Gateway Control – responsável pelo controle da mídia. Executa o registro e gerenciamento dos recursos dos media gateway. Pode controlar o caminho da voz, pois interage com o media gateway que possui interface E1/T1 (voz da PSTN) e interface IP (VoIP).

Como citado antes, existem diversos trabalhos que pesquisam como interconectar as duas redes de telefonia existente, entre estes trabalhos tem-se destaque ao trabalho de Camarillo [30,39] que visa mapear as mensagens ISUP dentro do corpo das mensagens SIP. Este trabalho ainda está em vias de padronização pelo IETF.

Esse trabalho gerou outros, entre eles a definição de novos tipos de valor MIME, chamado message/sip, message/sipfrag, para permitir que as mensagens sejam trafegadas no corpo da mensagem SIP. Já que as mensagens ISUPs são binárias definiu-se outro tipo MIME [33,34], chamado application/isup para trafegar mensagens ISUP em aplicações IP.

10. Grupos de pesquisa atuantes

Abaixo apresentamos uma pequena lista apresentando alguns grupos de pesquisa e projetos na área de VoIP (acadêmicos ou open source).

1) Metropoa-PUCRS: desenvolve atividades na área de VoIP desde 1999. O grupo consiste de dois professores coordenadores, 6 mestrandos na área e mais 10 bolsistas pesquisadores. O objetivo principal do grupo é o desenvolvimento de soluções de VoIP fim-a-fim, incluindo as técnicas de manutenção e adaptação de qualidade. Site: http://nmedia.metropoa.tche.br

2) UFRJ: Laboratório de voz sobre IP da Universidade Federal do Rio de Janeiro, desenvolve a alguns anos pesquisa e desenvolvimento de projetos focando nas áreas Ambientes Heterogêneos de Telefonia IP, Medidas de VoIP em Redes de Pacotes, Voz e Telefonia sobre ATM. Site: http://www.voip.nce.ufrj.br/

3) Vovida: Comunidade que desenvolve soluções open source, na área de telecomunicações criada com a finalidade de manter um ambiente onde informações e softwares de

Page 41: Voz sobre IP- Tecnologia e tendências

comunicações possam ser facilmente acessados, encontrados e compartilhados. Site: http://www.vovida.org

4) SpeakFreely: Sistema open source que implementa uma série de funcionalidades encriptação, compressores selecionáveis. Porém, não apresenta nenhum mecanismo de compensação ou correção. Site: http://www.speakfreely.org

5) RAT: Robust Audio Tool, é uma ferramenta open source atualmente em desenvolvimento na área de voz sobre IP. É destina essencialmente para conferências de áudio, entre dois ou mais participantes. Site: http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/

6) FreePhone: É uma ferramenta desenvolvida pelo Inria/Grenoble, sendo freeware mas não open source. Seu desenvolvimento foi descontinuado.

7) IRT Laboratory: O Internet Real-Time Lab (IRT) da Columbia University, mantém pesquisas nas áreas de voz sobre IP, protocolos de tempo real e qualidade de serviço, coordenadas pelo Prof. Henning Schulzrinne.

http://www1.cs.columbia.edu/~hgs/research/IRT/

8) Open H.323: Projeto com o objetivo de desenvolver uma implementação interoperacional com descrição total das características do H.323 do ITU. Site: http://www.openh323.org/

9) Open SS7: Projeto open source de desenvolvimento da pilha SS7 e SIGRAN, para plataformas Unix/Linux. Site: http://www.openss7.org/

12. Referências

[1] ITU-T Recommendation P.861 “Objective Quality Measurement of Telephone Band (300-3400 Hz) speech codecs”

[2] ITU-T Recommendation H.225.0 (1998) “Call signaling protocols and media stream packetizations for packet-based multimedia communication systems”

[3] ITU-T Recommendation H.245 (1998) “Control protocol for multimedia communication”

[4] ITU-T Recommendation H.323 (1998) “Packet-based multimedia communication systems”

[5] IETF Draft (draft-ietf-sip-isup-02.txt) “ISUP to SIP mapping”

[6] IETF RFC 1889 “RTP: A Transport Protocol for Real Time Applications”

[7] IETF RFC 1890 “RTP Profile for Audio and Video Conferences with Minimal Control”

[8] IETF RFC 2327 “SDP: Session Description Protocol”

[9] IETF RFC 2534 “SIP: Session Initiation Protocol”

[10] IETF RFC 2705 “Media Gateway Control Protocol (MGCP) version 1.0”

[11] IETF RFC 3015 “Megaco protocol version 1.0”

[12] SCHULZRINNE, H., ROSENBERG, J. Signaling for Internet Telephony.

[13] SCHULZRINNE, H. A comparison of SIP and H.323 for Internet Telephony.

Page 42: Voz sobre IP- Tecnologia e tendências

[14] DOUSKALIS, B. IP Telephony: The Integration of Robust VoIP Services, Prentice-Hall.

[15] BLACK, U. Sonet & T1: Architectures for Digital Transport Networks, Prentice-Hall.

[16] RUSSEL, T. Signaling System #7, McGraw-Hill

[17] BERGMARK, D.; KESHAK, S. Building blocks for IP telephony, IEEE Communications Magazine, p. 88-94, 2000.

[18] BOLOT, J. Analysis of audio packet loss in the Internet, NOSSDAV, p. 163-174, 1995.

[19] JANSSEN, J. Delay and distortion bounds for packetized voice calls of traditional PSTN quality, IPTel 2000.

[20] HARDMAN, V. Reliable audio for use over the Internet, INET’95.

[21] PERKINS, C. A survey of packet-loss recovery techniques for streaming audio, 1998.

[22] ROSENBERG, J. Distributed algorithms and protocols for scalable internet telephony, Columbia University, 2001.

[23] TANENBAUN, A. S., Redes de computadores, 2° Ed, Ed. Campus, 1994.

[24] HENRIQUE, M. C., Introdução ao sistema de sinalização por canal comum n7 e à central Batik ELCOM 4KT. Relatório técnico DCC028/96. Setembro, 1996.

[25] Illuminet. Signaling System 7 (SS7). Retirado de The Internacional Engineering Consortium, <www.iec.org>. Acessado em Julho, 2002.

[26] SS7 Tutorial – Network Arquitecture, retirado de <www.ss8.org>. Acessado em Julho, 2002.

[27] DONOVAN, S.; CANNON, M. A function description of a SIP-PSTN Gateway, draft-donavan-sip-gw-client-00.

[28] CAMARILLO, G. SIP/ISUP interconnection. Trabalho apresentado no Fall’99 VON, Atlanta. Setembro, 1999.

[29] CAMARILLO, G.; ROACH, A. BCP for SIP to ISUP mapping. Trabalho apresentado no 47th IETF SIP WG Meeting, Março, 2000.

[30] CAMARILLO, G. Overlap signalling handling. Trabalho apresentado no 50th IETF SIP WG Meeting, Março, 2002.

[31] American National Standards Union, Signaling System No 7; ISDN User Part Signalling procedures. ITU-T Q764, Setembro, 1997.

[32] STEWART, R. Stream Control Transmission Protocol. RFC 2960. Outubro, 2000.

[33] MARK, W. MIME type for ISUP messages. Draft-watson-sip-isup-mime-00.txt. Outubro, 1999.

[34] ZIMMERER, E.; VEMURI, A. .The SIP ISUP/MIME type. Draft-zimmerer-mmusic-sip-isup-mime-00. Janeiro, 2000.

Page 43: Voz sobre IP- Tecnologia e tendências

[35] CAMARILLO, G.; ROACH, A., Ong, L. Mapping of ISUP Overlap Signalling to SIP. Draft-ietf-sipping-overlap-00. Julho, 2002.

[36] MILLER, F.. Carrying ISUP in SIP Messages (SIP-ISUP-ANNEX). Draft-miller-sip-isup-annex-00.

[37] SPARKS, R.. Internet Media Type message/sipfrag. Draft-sparks-sip-mimetypes-03. Abril, 2002.

[38] DONOVAN, S.. The SIP INFO Method. RFC2976. Outubro, 2000.

[39] CAMARILLO, G.; ROACH, A., PETERSON, J.. ISUP to SIP Mapping. Draft-ietf-sipping-isup-01. Fevereiro, 2002.

[40] WASEN, O. J.. The effect of waveform substitution on the quality of PCM packet communications, 1988.

[41] PAPADOPOULOS, C; PARULKAR, G. Retransmission-based error control for continuous media applications. In: NOSSDAV, 1996.

[42] PERKINS, C.; HODSON, O. Options for repair of streaming media. IETF, RFC 2354, 1998.

[43] ROSENBERG, J.; QIU, L.; SCHULZRINE, H. Integrating packet FEC into adaptive voice playout buffer algorithms on the Internet. IEEE Infocom, Março, 2000.

[44] SANNECK, H.; Packet loss recovery and control for voice transmission over the Internet, 2000.

[45] MYIAZAKI, A. et al. RTP Payload formats to enable multiple selective retransmissions. IETF, draft-ietf-avt-rtp-selret-03.txt.

[46] ROSENBERG, J.; SCHULZRINE, H. An RTP payload format for generic forward error corretion. IETF, RFC 2733.

[47] PERKINS, C. et al. RTP payload for redundant audio data. IETF, RFC 2198.

[48] PRASAD, R. V. et al. Comparison of voice activity detection algorithms for VoIP. Anais do ISCC’02. p. 530 -535.

[49] RUELA, J. Arquitecturas Multimédia – FEUP/DEEC/RBL – 2002/03.

[50] SCHULZRINNE, H; ROSENBERG J. Internet Telephony: Architecture and Protocols na IETF Perspective – July 2, 1998

[51] BALBINOT, R. Modelagem e Prototipagem de Sistemas de Voz sobre IP Com Mecanismos de Transmissão Robusta – Março/2002

[52] SCHULZRINNE, H. RTP Profile for Audio and Video Conferences with Minimal Control.

[53] ZOPF, R. Real-Time Transport Protocol (RTP) Payload for Comfort Noise (CN).

[54] CONWAY, A. E. A passive method for monitoring voice-over-IP call quality with ITU-T objective speech quality measurement methods. ICC 2002, vol. 4, p. 2583 –2586.

Page 44: Voz sobre IP- Tecnologia e tendências

[55] ITU-T Recommendation P.800, “Methods for subjective determination of transmission quality”, 1996.

[56] ITU-T Recommendation P.50, “Artificial Voices”, 1999.

[57] ITU-T Recommendation P.862, “Perceptual evaluation of speech quality (PESQ), an objetive method for end-to-end speech quality assessment of narrowband telephone networks and speech codecs”, 2001.

[58] IETF RFC 2916, “E.164 number and DNS”

[59] IETF RFC 2824, “Call Processing Language Framework and Requirements”

[60] IETF RFC 3219, “Telephony Routing over IP (TRIP)”

[61] IETF RFC 2719, “ Framework Architecture for Signaling Transport”