Curso de VoIP

HJ Treinamento e Consultoria
Curitiba Julho de 2001

1
 UNIDADE 1

Índice Remissivo

UNIDADE 1........................................................................................................................................................2
ÍNDICE REMISSIVO...........................................................................................................................................2
UNIDADE 2........................................................................................................................................................4
INTRODUÇÃO....................................................................................................................................................4
1. Telefonia Básica, a Integração de Redes, Voz Sobre Redes de Pacotes, Características das
Tecnologias de Voz Sobre Pacotes..............................................................................................................4
UNIDADE 3......................................................................................................................................................12
TELEFONIA IP.................................................................................................................................................12
1. Voz sobre IP....................................................................................................................................12
2. Pequenas Centrais de Telefonia IP com SS7..................................................................................14
3. Grandes Centrais de Telefonia IP com SS7....................................................................................15
4. Telefonia IP Distribuída com SS7...................................................................................................17
5. A Rede de Telefonia IP Distribuída................................................................................................19
6. Futuro da telefonia IP.....................................................................................................................20
UNIDADE 4......................................................................................................................................................22
PADRÃO H.323...............................................................................................................................................22
1. Visão Geral da recomendação H.323.............................................................................................22
2. Terminais.........................................................................................................................................25
3. Gateways.........................................................................................................................................26
4. Unidades de Controle Multiponto...................................................................................................28
5. Codecs.............................................................................................................................................31
6. Gatekeepers....................................................................................................................................33
7. Como o H.323 Trabalha.................................................................................................................35
8. Glossário de Termos H.323............................................................................................................39
UNIDADE 5......................................................................................................................................................42

2
 SIP – SESION INITIALIZATION PROTOCOL......................................................................................................42
UNIDADE 6......................................................................................................................................................55
RTP E RTCP...................................................................................................................................................55
1. Introdução:......................................................................................................................................55
2. O Transporte do Tráfego em Tempo Real.......................................................................................56
3. Características de Tráfego em Tempo Real....................................................................................58
4. Requerimentos para Comunicação em Tempo Real.......................................................................58
5. Aplicações Hard versus Soft Real Time..........................................................................................59
6. Arquitetura do Protocolo RTP........................................................................................................60
7. RTCP (RTP Control Protocol)........................................................................................................65
UNIDADE 7......................................................................................................................................................69
MGCP – MEDIA GATEWAY CONTROL PROTOCOL.........................................................................................69
1. Introdução.......................................................................................................................................69
2. Relação entre o MGCP e o H.323..................................................................................................71
3. Comandos MGCP...........................................................................................................................73
4. Parâmetros do MGCP....................................................................................................................75
5. Comandos da API e os Parâmetros Associados.............................................................................77
6. Mensagens MGCP e Parâmetros Associados.................................................................................82
7. Mensagens e Parâmetros MGCP....................................................................................................84
8. Exemplo de Operação do MGCP...................................................................................................87
UNIDADE 8......................................................................................................................................................92
TÉCNICAS DE COMPRESSÃO DE VOZ E CONTROLE DE TRÁFEGO MULTIMÍDIA..............................................92
1. Propriedades do Sinal de Voz.........................................................................................................92
2. Recomendação G.711.....................................................................................................................95
3. Recomendação G.726.....................................................................................................................95
4. Recomendação G.723.1..................................................................................................................97
5. Recomendação G.729 e G.729/A....................................................................................................98
UNIDADE 9....................................................................................................................................................101
QUALIDADE DA VOZ EM REDES DE PACOTES..............................................................................................101
1. Latência em Telefonia IP..............................................................................................................101

3
 UNIDADE 2

Introdução

1. Telefonia Básica, a Integração de Redes, Voz Sobre Redes de

Pacotes, Características das Tecnologias de Voz Sobre Pacotes.

Quando os primeiros engenheiros de telecomunicações se depararam com o problema de

criação da planta de telefonia, o método que prevaleceu devido à sua simplicidade e
robustez (disponibilidade e qualidade) foi o de comutação de circuitos (na época ainda
analógicos). Este método prevalece até hoje, constituindo-se como a planta de
comunicações de maior pulverização disponível no mundo. Porém um marco veio a mudar
isto e abrir novas perspectivas de mercado e de funcionamento da rede. O evento da
comunicação de dados.

Quando os primeiros computadores foram criados surgiu a necessidade de pulverizar o

acesso às aplicações, e assim surgiu o mercado de interligação (primeiramente com aluguel
de circuitos e mais tarde com redes dedicadas) dos sistemas computacionais distribuídos.
Devido ao caráter dessa nova forma de comunicação, o método escolhido foi o de
comunicação de pacotes que era mais adequado para a aplicação de dados.

Não alheio à isso o ITU-T (antigo CCITT) propôs uma rede que através de comutação de
circuitos seria capaz de integrar todos os serviços de telecomunicações (telefonia, telex,
dados, videotexto, internet, etc...). Esta rede se chamou RDSI (Redes Digital de Serviços
Integrados) e lançou a infra-estrutura na qual as plantas de telecomunicações hoje se
baseiam (inclusive a Internet).

4
Uma coisa bastante importante nessa época é que estavam sendo lançados os alicerces da
atual planta de telecomunicações, e por volta de 1984 o processo de normalização da RDSI
estava terminando, então o ITU-T levou um estudo em que mostrava que o grau de
importância do serviço de comunicação de dados tradicional (baseado em comutação de
pacotes) estava seguindo uma tendência de crescimento exponencial (ver figura 1). Além
disso as arquiteturas abertas de interconexão eram uma verdade (TCP/IP, OSI, Netware, e
Banyan-Vines), e elas tinham sido produzidas seguindo uma filosofia capaz de integrar
qualquer tipo de serviço.

Figura 1 – Tendências de Crescimento dos Serviços de Telecomunicações

Crescimento
da Planta

Telefonia

Dados com
Comutação de
Pacotes

tempo

Desse estudo a principal conclusão era de que haveria a necessidade de se desenvolver uma
planta de transporte de informação baseado em técnicas de pacotes capaz de levar qualquer
tipo de serviço (ficou conhecida na época como RDSI-FL – RDSI de faixa larga), cuja
tecnologia do núcleo seria o ATM (Asynchronous Transfer Mode).

As vantagens dessa nova técnica são:

- Multiplexação Estatística

- QoS garantido por prioridades

- Maior flexibilidade por implementação das aplicações ficar à cargo do usuário

- Independência do Serviço (segue princípios do modelo OSI)

- Maior fator de utilização (pois podemos adaptar mais facilmente compressão e

compactação).

- Infra-estrutura comum leva a melhor utilização sazonal da rede e divide custos

(portanto serviços tendem a baratear).

5
 Esses conceitos de rede integrada do ITU não se tornaram sucessos comerciais, mas foram
o suporte tecnológico de toda a rede que hoje conhecemos, seja a Rede Digital de Telefonia,
a rede SDH, a rede de acesso ADSL e HDSL, bem como as redes WAN (Wide Area
Network) para roteadores.

Paralelamente à isso tudo, e aproveitando toda essa infra-estrutura tecnológica que a RDSI
estava implantando, a Internet vinha crescendo vertiginosamente, principalmente devido a
facilidade de implementação de serviços que se tornaram Killer Applications (tais como e-
mail, Home Pages, FTP).

Assim as redes de pacotes chegaram atualmente nas empresas ao status de telefone (é bem
provável que haja mais computadores hoje nas corporações do que ramais de telefone),
todos eles interligados por uma infra-estrutura de rede local e as localidades interligadas
por roteadores, bridges ou switches, formando uma grande rede corporativa. Isso é o que as
estatísticas do ITU-T apontavam com um crescimento exponencial das linhas de dados.

O mais interessante é que essas linhas de dados eram alugadas (na maior parte das vezes)
assim uma baixa utilização poderia levar à um custo muito elevado para se ter os serviços
anteriormente citados disponíveis para os funcionários.

A solução seria o de colocar serviços agregados nestas linhas de dados, que viessem a
diminuir os custos ou mesmo subsidiá-las. Começaram então as primeiras tentativas de se
integrar voz na linha de dados, conforme veremos com detalhes abaixo:

(A) Primeira Fase – Compactação de Voz em Linhas Dedicadas

Nesta fase o principal objetivo era o de aproveitar que as linhas de dados estavam presentes
no CPD e poderíamos colocar os PABX das empresas interligados (Tie Line) através de
algumas linhas de dados especializadas (normalmente estruturadas).

A figura 2 mostra esta fase, em duas topologias típicas nas quais o usuário poderia
aproveitar o seu Hardware (PABX) implantando nele uma placa ou um bastidor que
compactava as linhas tronco formado de canais de 64kbps, normalmente em ADPCM de
32kbps ou 16kbps, multiplicando assim o número de canais servidos (em 2:1 ou 4:1).

6
 Figura 2 – Topologias Típicas da 1ª Fase

Dispositivo
de
Compactação

PABX

Modem Acesso à Rede de Dados

MUX

Roteador (a) Redes Pequenas com Modem Mux

PABX

Dispositivos Acesso à Rede de Dados

Mux
de Flexível
Compactação

Roteador (b) Redes Grandes com Mux Flexível

Não se pode deixar de falar que além dos canais de voz compactados havia a necessidade
de se trocar sinalização entre os PABX, para tanto um canal era normalmente usado para
este fim. Este canal poderia ser carregado como um canal de dados independente ou ainda
poderia ser carregado pelo roteador (aqueles que possuíam a capacidade de tal serviço).

7
(B) Segunda Fase – Voz sobre Frame Relay
Paulatinamente, com o intuito de deixar mais flexível e baratear o custo do serviço de
dados, começou a ser largamente implantada redes baseadas na tecnologia Frame Relay.
Que se assemelha em performance as linha dedicadas, porém promove uma multiplexação
estatística em nível 2 OSI, de tal forma que pode servir de acesso múltiplo em uma só linha
de dados.

Os circuitos dedicados passaram a ter seu equivalente em circuitos virtuais permanentes

(CVPs). Esta tecnologia já mostra o potencial do qual falamos ao iniciar o texto, o aumento
da eficiência devido à multiplexação estatística e a independência dos serviços devido à
obediência ao modelo OSI.

O crescimento das linhas de dados em Frame Relay passa a ser explosivo, devido à
necessidade do usuário de simplificar o seu acesso e de poder diminuir o seu Hardware
(principalmente no que diz respeito à interfaces).

Nada mais natural do que tentarmos adicionar ao serviço de dados com comutação de
pacotes em Frame Relay o de carregar voz. Este padrão passou a se chamar VoFR (Voice
over Frame Relay) e se tornou um padrão de fato.

Neste caso, para ser o mais simples possível, vamos simular em redes de pacotes (com
multiplexação estatística) o mesmo que foi feito em Redes Determinísticas. A figura 3
mostra melhor o funcionamento dessa rede.

Figura 3 – VoFR

Router
Phone

VFRAD
FrameRelay

PBX

FAX

8
 O usuário nesta fase passou a sentir a vantagem de ter uma única rede capaz de carregar
vários serviços de telecomunicações, condição esta que deveria ter sido sentida com a
RDSI, porém foi adiada por questões de mercado.

(C) Terceira Fase – IP Trunking

Esta é a fase que vivemos atualmente, onde usamos o IP para levar o tráfego multimídia,
porém com elementos de rede capazes de fazer a transcodificação (Gateways), e através de
arquiteturas como H.323 ou SIP podemos fazer ligações ponto-a-ponto, como se
estivéssemos em uma planta telefônica.

Porém, continuamos dependente da rede corporativa para atingir o objetivo de comunicar, e

a flexibilidade da arquitetura formada ainda se restringe ao ambiente corporativo. A grande
vantagem é que o modelo TCP/IP, diferente dos outros modelos citados anteriormente
possuem protocolos de aplicação desenvolvidos e testados, permitindo que o usuário possa
interagir em níveis mais altos, e conseguir assim melhores resultados quanto à flexibilidade,
diversidade, independência da infra-estrutura, Interação, Escalabilidade, etc...

Além disso, começa a existir equipamentos no ambiente das operadoras de

telecomunicações, que fazendo uso do Backbone IP, procuram baratear o custo dos
entroncamentos interurbanos. A figura 4 mostra melhor esta fase:

Figura 4 – IP Trunking

H.323 H.323
Gatekeeper

H.323
Gateway
Proxy

Internet
PABX
H.323

PSTN

(a) Ambiente Corporativo

9
 (b) Ambiente da Operadora de Telefonia

(D) Quarta Fase – VoIP

Voz sobre IP não é uma rede de voz ou multimídia sobre uma rede de pacotes, mas sim uma
rede digital de serviços integrados, como a RDSI se propôs a fazer, onde os elementos de
todas as fases anteriores, bem como a PSTN se integram em um único Backbone IP.

O objetivo do Curso é ver com detalhes os elementos que constituem a arquitetura VoIP,
mas a figura 5 mostra um pouco do que se espera da nova Plataforma de Serviços.

As principais vantagens deste tipo de rede se assemelham às da RDSI, porém com algumas
ressalvas:

 Devido à QoS não ser garantida, ela mais se parece num primeiro instante como um
serviço novo ou um valor agregado.

 Independência de infra-estrutura quanto à aplicação

 Desenvolvimento de novas aplicações só dependem da existência do backbone e da sua

abrangência e capacidade.

10
 Extrema pulverização de Hosts TCP/IP, principalmente no ambiente corporativo.

 Maior liberdade para o desenvolvimento de software (principalmente com a arquitetura

SIP.

 Mobilidade garantida por servidores específicos.

Figura 5 - VoIP

11
 UNIDADE 3

Telefonia IP

1. Voz sobre IP

Com o crescimento explosivo da Internet nos últimos tempos (principalmente depois da

criação da World Wide Web (WWW), a tem transformado em uma rede global usada para
pesquisa, negócios e uso pessoal. O resultado disso é que o IP (Internet Protocol) se
transformou em um padrão de fato para comunicação de dados. Como era de se esperar em
qualquer rede que atingisse essa capilaridade, ela começa agora a se expandir a sua área de
atuação, de forma a absorver outros serviços que tipicamente eram fornecidos por outras
redes. No caso da telefonia (o maior filão do mercado de telecomunicações do mundo), o
grande "boom" tem sido o conceito de Telefonia sobre IP. Diferentemente da PSTN (Public
Switch Telephony Network – Rede Pública Comutada de Telefonia) que possui arquitetura
comutada à circuito, as redes IP são comutadas à pacotes (datagramas). As máquinas (Hosts
e Gateways) na rede estão todos conectados por conexões permanentes, com a banda
passante compartilhada com todos os usuários ativos (por multiplexação estatística).
Quando a rede é muito solicitada (gerando congestionamento) todos os usuários
permanecem conectados, porém experimentam uma degradação da performance do
sistema.

Apesar das redes PSTN e IP serem fundamentalmente diferentes, em termos de roteamento

e performance, é possível que estas duas redes sejam conectadas trocando tráfego de voz e
dados. A figura 1 mostra a primeira geração tecnológica para atingir esta integração.

12
 Figura 1 – Integração das Redes IP e PSTN

Se um usuário conectado em um SSP (Service Switching Point – Ponto de Serviço de

Comutação), pode fazer uma chamada diretamente sobre a PSTN para qualquer outro
usuário ligado à outra SSP. O tráfego de voz será roteado através de outros SSP
intermediários (se houver), podem haver várias centrais envolvidas no roteamento de uma
ligação fim-a-fim. A sinalização SS7 (Sinalização Canal Comum n 7), é roteada através de
infra-estrutura própria através de vários STPs (Signalling Transfer Point – Ponto de
Transferência de Sinalização). Na figura 1 vemos um exemplo simples usando apenas uma
central intermediária e um par de STPs. Neste exemplo, o telefonema é interurbano, e a
chamada será tarifada conforme as regras normais de telefonia.

A tecnologia de Voz sobre IP (VoIP – Voice over IP) oferece uma rota alternativa. Uma
ligação local é colocada em um Comutador de Telefonia IP, que digitaliza e comprime o
tráfego de voz e a coloca em pacotes de dados que serão mandados sobre uma rede IP. Os
Comutadores de Telefonia em ambas as pontas se comunicam com os respectivos SSPs à
que estão ligados através de sinalização SS7 disponível da planta de telefonia, e o
entroncamento de voz/dados é feito com linhas RDSI. Neste esquema as ligações podem
ser iniciadas e terminadas por qualquer rede (PSTN ou IP). Para usuários ligados à rede IP
com computadores providos de recursos de multimídia, com um software se transformam
em um terminal de telefonia IP, e podem trafegar voz e dados normalmente, e se interfacear
com qualquer outro telefone na PSTN.

Na rede IP, os dispositivos de Voz sobre IP se comunicam usando tanto protocolos

proprietários, como algum dos padrões emergentes tais como o H.323 ou MGCP. Por causa
da falta de padrões completamente definidos, a primeira geração de produtos de VoIP
requerem gateways de um mesmo fabricante nas pontas da rede IP. Em meados de 1998,

13
 surgiram os primeiros gateways baseados em H.323, para interoperabilidade com
fabricantes diferentes. Mais tarde voltaremos a abordar este assunto.

A sinalização usada na primeira geração de produtos VoIP de primeira geração, é limitada

em sua funcionalidade. Estabelecimento e desligamento de chamadas básicas são possíveis,
mas serviços da IN (Inteligent Network – Rede Inteligente), não podem ser acessados. Estes
serviços requerem a habilidade de uso da camada TCAP (Transactions Capability –
Capacitação de Transações), da pilha SS7, para acessar as bases de dados que existem na
PSTN.

2. Pequenas Centrais de Telefonia IP com SS7

Reconhecendo a importância do protocolo SS7, alguns fabricantes de Centrais de Telefonia

IP começaram a anunciar o suporte à sinalização SS7. Os primeiros produtos desse tipo
foram pequenas Centrais de Telefonia IP (menos que 1000 portas suportadas), com a pilha
SS7 configurada como um nó final SSP. Uma topologia de rede mostrando a integração
entre as redes IP e IN, usando esse tipo de centrais é mostrada na figura 2.

Figura 2 – Pequenas Centrais de Telefonia IP com SS7.

Esta arquitetura é conceitualmente simples. Cada Comutador de Telefonia IP é conectado

diretamente a um par de STPs usando links SS7, habilitando o suporte dos serviços da IN
(Rede Inteligente). Porque os Comutadores de Telefonia IP são muito pequenos, o resultado
é uma rede VoIP altamente distribuída (pulverizada), o que diminui a possibilidade de
congestionamento local do entroncamento com os SSPs. Também, a arquitetura distribuída
é inerentemente mais confiável, sem nós que possam potencialmente causar falha geral de
sistema.

14
 No entanto existem vários problemas críticos com esta topologia. A primeira dificuldade
com a arquitetura mostrada na figura 2 é que é extremamente cara. Os enlaces de
sinalização SS7 são dedicados, com banda passante garantida e full-duplex. Cada enlace
desses está ligado à um grande custo operacional, incluindo taxas de manutenção do enlace,
taxa de conectividade (devido à distância), e taxa pelo uso (demanda). Cada link SS7 tem a
capacidade de controlar um número muito maior de portas que esses Comutadores de
telefonia IP podem suportar. Assim os enlaces SS7 são ineficientemente usados, e o custo
total da rede se torna excessivo.

Outra característica com estas configuração de rede é que esses pequenos Comutadores de
Telefonia IP, devem possuir um código, que os identifiquem na planta de sinalização
tradicional SS7, para que possam ser roteadas as suas informações. Usuários são forçados à
discar códigos de acesso diferentes quando se movem de uma central para outra.

Talvez a maior desvantagem do uso desta arquitetura baseada em Pequenos Comutadores

de Telefonia IP, é a necessidade de um número muito grande de códigos identificadores do
ponto de sinalização. Cada nó na rede SS7 requer um identificador único, chamado código
de ponto de sinalização, Existe um número limitado desses códigos disponíveis. E isto é
particularmente verdade se usarmos a versão do ITU (International Telecommunications
Union) de SS7, que é mais severamente limitado do que a versão da ANSI (American
National Standards Institute). Por causa disso é simplesmente impraticável adotar uma
arquitetura como a da figura 2, quando a rede crescer tanto que o número de pontos de VoIP
se tornar muito grande. Portanto esta solução só deve ser usada para redes que estejam
iniciando ou para pequenos provedores de serviço de VoIP.

3. Grandes Centrais de Telefonia IP com SS7

O próximo passo lógico para os fabricantes de equipamentos para VoIP, é criar Grandes
Comutadores para Telefonia IP (maiores que 1000 portas). Esta arquitetura é mostrada na
figura 3, e resolve a maior parte dos problemas relacionados com o uso dos Pequenos
Comutadores de Telefonia IP.

15
 Figura 3 - Grandes Centrais de Telefonia IP com SS7.

Uma melhor relação custo efetiva é atingida à medida que mais portas são controladas para
cada enlace SS7. Um ISP (Internet Service Provider – Provedor de Acesso Internet), pode
prover serviços de VoIP para um número grande de usuários usando uma único Comutador
e um número simples de telefone. Um número menor de códigos de ponto de sinalização
são necessários. No entanto, esta configuração de rede possui uma desvantagem
particularmente severa. Um usuário que use a telefonia IP, para ligar para outro usuário que
está ligado no mesmo Comutador de Telefonia IP, deve usar uma linha tronco para se ligar à
PSTN, que irá comutar para outra linha tronco de volta para o mesmo Comutador IP,
fazendo com que prendamos para esta conexão 2 troncos. Como os troncos são recursos
caros, com banda passante dedicada sob demanda, este tipo de operação é extremamente
prejudicial, além do que pode ser causa para congestionamento do acesso local. O ideal
seria que os Comutadores de Telefonia IP pudessem comutar localmente evitando o uso da
PSTN.

Outro problema parecido ocorre quando dois usuários de telefonia IP (já ligados à Internet),
mesmo de Comutadores IP diferentes querem se comunicar temos que fazer uso dos troncos
para os SSP locais. Isso deve ser resolvido logo fazendo com que os Comutadores IP,
fazendo uso da Internet apenas possam comutar livremente sem a necessidade do uso de
recursos da PSTN para isso.

Outro problema ainda com a arquitetura mostrada na figura 3, é que a disponibilidade do

serviço é baixa. Todo o tráfego de VoIP flui sobre um único comutador, se ele se tornar
inativo por qualquer motivo, todo o serviço de VoIP é perdido.

16
4. Telefonia IP Distribuída com SS7.

Uma Central de Telefonia IP Distribuída oferece um bom meio termo entre Comutadores de
Telefonia IP Pequenos e Grandes. A Figura 4 mostra de forma explodida uma Central de
Telefonia IP Distribuída. Estas centrais incluem todas as funções dos exemplos anteriores,
mas os módulos funcionais estão separados logicamente. Os processos podem rodar numa
mesma central pública, em uma mesma máquina, ou distribuída sobre uma rede IP em
máquinas múltiplas. A plataforma de computadores em que os processos podem rodar
podem variar desde pequenos PCs até grandes servidores configurado para alta tolerância à
falhas, para alta disponibilidade, em configuração redundante.

Figura 4 - Centrais de Telefonia IP Distribuída com SS7.

Como na rede mostrada na figura 2, esta topologia usa múltiplos grupos, relativamente
pequenos, de troncos. Estes podem ser colocados fisicamente perto dos SSPs, minimizando
o transporte de informação dos troncos PSTN, que são relativamente caros. Retirando o
tráfego entre usuários de telefonia IP nativos da PSTN, podemos aumentar a
disponibilidade dos troncos. Esta configuração também pode evitar grupos de troncos
congestionados, o que aumenta a qualidade final do sistema.

Nesta arquitetura enquanto os Gateways de Interfaces (Media Gateways) estão distribuídos

ao longo da rede, o Gateway SS7/IP é centralizado, conectado à rede SS7 em um local
convenientemente próximo de um STP existente. Apesar da natureza distribuída desta
configuração, a configuração inteira dos blocos é vista como um único Comutador para a
rede SS7. Ele possui um único código de ponto de sinalização, que é usado para gerenciar
todos os Gateway de Interface. Isto é mais custo-efetivo que a configuração com pequenos
comutadores, e evita o congestionamento causado pela configuração de grandes
comutadores.

Com a utilização de aplicações de base de dados nas Centrais de Telefonia IP Distribuída,

um SSP pode perguntar para a rede SS7 qual o mais eficiente Gateway de Interface para

17
rotear uma chamada solicitada. Além disso, total funcionalidade com a Rede Inteligente
pode ser suportada de ambos os lados, PSTN e na rede IP.

O Gateway SS7/IP comunica-se com os Gateways de Interface e com os outros módulos

usando a rede IP (ver figura 5. Se cada um dos módulos entende um formato consistente de
pacote de dados, então as informações de sinalização podem ser trocadas. Se o Gateway
SS7/IP for suficientemente sofisticado, os outros módulos na central podem ser duplicados,
para aumentar a disponibilidade. Se qualquer módulo ficar indisponível por qualquer razão,
o Gateway SS7/IP pode rotear o tráfego para um módulo redundante remanescente, até o
problema ser resolvido.

O único módulo dentro da Central de telefonia IP Distribuída, mostrada na figura 5, que

não é duplicada para aumentar a disponibilidade é o Gateway SS7/IP. Isso porque a rede
SS7 irá rotear todas as mensagens direcionadas para o código de ponto de sinalização, para
um único dispositivo.

Figura 5 – Comunicação Inter-processos em uma Central de Telefonia IP Distribuída

18
5. A Rede de Telefonia IP Distribuída

A integração de comunicação de sinalização ideal entre a rede IP e a rede PSTN, coloca a

Central de Telefonia IP distribuída um passo `a frente. O Gateway SS7/IP suportar
múltiplas Centrais de Telefonia IP Distribuídas ao invés de ser um Gateway desses para
cada Central Distribuída, esta arquitetura que é mostrada na figura 6, provê pontos bem
definidos de interface de sinalização entre as duas redes.

Figura 6 – Arquitetura de Rede de Telefonia IP Distribuída

Assim como em todos os casos anteriormente descritos, o Gateway SS7/IP se conecta à um

STP com um par de links na PSTN. Nesta configuração, no entanto, o Gateway SS7/IP foi
arranjado como um par casado, eliminando o problema de simples ponto de falha das
centrais de Telefonia IP Distribuídas. Os dois Gateways SS7/IP dividem um único código
de ponto de sinalização aparecendo para a rede SS7 como uma única Central. Os Gateways
SS7/IP são tipicamente alocados em locais geograficamente separados, para aumentar a
disponibilidade da rede como um todo, mantendo a sincronização em todo o tempo. Na
PSTN o protocolo SS7 inclui mecanismos de re-roteamento e retransmissão do tráfego de
mensagens no caso de falhas de qualquer Gateway SS7/IP. Na Rede IP, o Gateway SS7/IP
aumenta o seu nível disponibilidade. São permitidas as configurações de Gateway para
trabalhar em regime Primário/Secundário ou trabalhar Alternadamente.

O Módulo Centralizado de Gerência de Rede usa protocolos como Simple Network

Management Protocol (SNMP) e Common Object Request Broker Architeture (CORBA),
para gerenciar os vários processos ao longo da rede, incluindo o Gateway SS7/IP.

19
6. Futuro da telefonia IP

A comunicação de rede do futuro incluem ambos, a tradicional PSTN baseada na tecnologia

comutada à circuito e a tecnologia de pacotes de dados das redes IP. A convergência dessas
duas arquiteturas de rede diferentes criou capacitações que nenhuma dessas redes consegue
suportar sozinha. O progresso inevitável dessa convergência depende de uma série de
fatores, mas dois são particularmente significantes, a padronização de protocolos e a
definição de uma política de tarifação interrede.

Se a convergência mostrada na figura 7 for atingida em seu potencial completo, a industria

terá de admitir usar protocolos padrão para serem usados na rede IP. Estes protocolos
devem cobrir todos os aspectos de comunicação, incluindo compressão de voz, transmissão
multimídia e sinalização. A adoção desses padrões irá habilitar equipamentos de múltiplos
fabricantes coexistirem e interoperar na rede. Muitos padrões diferentes estão atualmente
em desenvolvimento por organismos de padronização e consórcios de indústrias, ver tabela
1.
Tabela 1 – Padrões Industriais Aceitos na Telefonia IP

Standard References
H.323 ITU-T, Recommendation H.323, "Visual
Telephone System and Equipment for Local
Area Networks that Provide a Nonguaranteed
Quality of Service"
ITU-T, Recommendation H.225, "Call
Signaling Protocols and Media Stream
Packetization for Packet-Based Multimedia
Communications Systems"
ITU-T, Recommendation H.245, "Line
Transmission of Nontelephone Signals"
Media Gateway Control Protocol (MGCP) MGCP Specification from Telcordia
Technologies (www.telcordia.com)
Session Interface Protocol (SIP) www.cs.columbia.edu/~hgs/sip/sip.html

20
 Figura 7 – Convergência da Telefonia IP e PSTN

Um único padrão está tomando força no momento (H.323), em que alguns fabricantes estão
disponibilizando ou estendendo as suas facilidades para os seus próprios protocolos
proprietários. Muito há para se fazer nesta área mas já temos o consenso de que os
fabricantes estão conscientes de que o futuro desta tecnologia passa pela adoção de
protocolos de consenso.

Os operadores da rede telefônica, os ISPs e as agências regulamentadoras, tem começado à

discutir o assunto de tarifação do serviço de Telefonia IP. Até agora as conversas pouco
surtiram de efeitos positivos. O problema é que as redes telefônicas emergiram de um
mercado altamente regulamentado e com políticas de tarifação projetadas para criar
competição. A Internet por outro lado cresceu de um mercado sem nenhuma
regulamentação. Existem muitas questões não técnicas que devem ser resolvidas para que
essas redes convirjam, e as políticas adotadas agora terão efeitos profundos no futuro da
telefonia IP.

21
 UNIDADE 4

Padrão H.323

1. Visão Geral da recomendação H.323

Os computadores pessoais estão rapidamente se transformando em um dispositivo chave

para comunicação para milhões de usuários. E isto tem se acelerado com a explosão da
Internet. Enquanto o serviço de correio eletrônico é ainda a forma predominante de
comunicação através de computadores, o conferenciamento eletrônico, através de conexões
de voz e de vídeo, tem se tornado atrativo para um grupo crescente de usuários ávidos por
estes serviços. O principal desafio para esta comunicação entre computadores está no
desenvolvimento de padrões que consigam prover conectividade – para controlar a
chamada (procurar o destino, ringing, etc...) para serviços de voz e de vídeo. A maior parte
dos fabricantes acredita que os padrões de comunicação multimídia baseados na
recomendação H.323 apresentam a melhor característica de compatibilidade e
escalabilidade.

O conjunto completo de documentos de especificação e informações correlatas ao padrão

H.323 é apresentado no site http://www.itca.org/ sob o subtítulo Teleconferencing
Standards.

22
A recomendação do ITU-T H.323, descreve os requisitos técnicos para serviços de
comunicação multimídia em redes comutada de pacotes. As Redes Comutadas de Pacotes
incluem LANs, WANs, a Internet, conexões ponto-a-ponto (dial-up ou permanentes) sobre
PPP, ou qualquer outro protocolo de comutação de pacotes. No escopo da H.323 não estão
incluídas as interfaces de rede, ou os protocolos de transporte e acima.

Os principais benefícios da implementação deste padrão são:

 Um padrão relativamente simples que permite que equipamentos de Telefonia

Internet interoperar.

 Padrão de interoperação com redes heterogêneas, como RDSI, PSTN, etc...

 Flexibilidade para suportar diferentes softwares, e implementações de redes com

capacidades diferentes.

A implementação desta recomendação já está na versão 4 (aprovada em Novembro de

2000), porém a maior parte dos fabricantes implementam a versão 2, mas esperasse uma
migração muito importante para a versão 4, bypassando a versão 3.

Podemos dizer que a implementação H.323 é a mais importante arquitetura (a mais aceita
no âmbito da Telefonia IP, de fato, hoje em dia as redes H.323 implementadas já somam
centenas de milhões de minutos de comunicação multimídia à cada mês, e isso foi
alcançado devido à sua alta escalabilidade e flexibilidade, bem como a facilidade de reuso
da infra-estrutura existente.

Devido à essas características esta é uma solução atrativa tanto para operadoras e
provedores de serviço como para as corporações. Acredita-se que logo o padrão H.323 será
implementado em telefones celulares através do desenvolvimento de chips específicos
baseados no hardware de videoconferência.

A H.323 especifica cinco componentes principais, os Terminais, os Gateways, os

Gatekeepers os Proxies e as Unidades de Controle Multiponto (Multipoint Control
Units - MCU). Os Terminais, Gateways e as MCUs são classificadas como pontos finais –
dispositivos que podem iniciar ou receber ligações. Outra tecnologia chave associada a
recomendação H.323 são os codecs que são usados para codificar e decodificar os sinais de
áudio e vídeo transmitidos.

A figura 1 mostra os elementos da arquitetura H.323, como dito anteriormente, esta

arquitetura permite que dois ou mais clientes rodem aplicações multimídia usando o
protocolo H.323. Assim, qualquer combinação de dados de voz, vídeo ou dados podem ser
trocadas entre os pontos finais.

23
 Figura 1 – Elementos da Arquitetura H.323

H.323 H.323
Gatekeeper

H.323
Gateway
Proxy H.320
sobre
ISDN

Internet H.324
sobre
PSTN e/ou PSTN
ISDN
H.323

A recomendação H.323 cobre os requisitos técnicos para serviços de comunicação de áudio

e vídeo em LANs e Internets que não provêm Qualidade de Serviço (QoS). A

24
 recomendação H.323 referencia-se na recomendação T.120 para conferência o que inclui a
capacitação de enlaces de dados. No escopo da recomendação H.323 não se incluem as
especificações da LAN em si nem os protocolos de transporte na Internet. Apenas os
elementos para a interação com as Redes de Circuito Comutado (SCN) são definidos.

2. Terminais

Os terminais H.323 são pontos finais clientes que provêem uma comunicação bidirecional à
tempo real. A Figura 2 descreve os componentes de um terminal H.323. Todo terminal deve
prover comunicação de áudio à tempo real. Também eles podem prover serviços de vídeo
ou videoconferência de modo opcional. A H.323 especifica os modos de operação
requeridos por diferentes terminais de dados, vídeo e voz a fim de interoperarem.
Conferência de dados provê a capacidade de transmitir texto, compartilhar um white
boarding e transmitir dados, esse serviço deve estar de acordo com a recomendação ITU
T.120.

Todo terminal H.323 também suporta H.245, que é usado para negociar capacitação e uso
dos canais. São requeridos três outros componentes: Q.931 para sinalização controle de
chamada, um componentes chamado Registration/Admission/Status (RAS), que é o
protocolo usado para comunicar com o Gatekeeper, e o suporte para RTP/RTPC para
sequenciamento de pacotes de áudio e vídeo.

Outros componentes opcionais em um terminal H.323 são: Codecs de Vídeo, protocolo de

conferência de dados T.120, e capacitação de serviço MCU.

Os terminais podem ser implementados como software baseado em PC ou em dispositivos

específicos tais como videofones ou Internet fones. Atualmente a imensa maioria dos
terminais é baseado em softwares rodando em PCs. Apesar de não ser especificamente
tratado pela recomendação H.323, terminais baseados em PCs tipicamente usam uma placa
de som, microfones e alto-falantes (ou handset). Ainda à uma variedade de fabricantes que
disponibilizam cartões para PC que oferecem uma interface para ser colocado um telefone.

25
 Figura 2 – Terminal H.323

3. Gateways

Um Gateway H.323 é um ponto final que provê uma comunicação bidirecional, em tempo
real entre terminais H.323 e outros terminais ITU (como telefones por exemplo), ou com
outro Gateway H.323. Eles fazem a translação dos procedimentos de controles de chamada
(H.245 e H.242) e do formato de transmissão (H.225.0 e H.221) necessário para converter
uma chamada no formato de comutação de pacotes (H.323) para comutado à circuito (por
exemplo PSTN) e vice versa. Além disso os Gateways fazem a translação entre os formatos
dos sinais codificados de áudio e de vídeo, bem como executam as funções de controle de
chamada tanto do lado da LAN como do lado da rede comutada a circuito. Os gateways são
componentes opcionais na rede, eles só são necessários para interoperar redes com
características diferentes. A figura 3 mostra um Gateway H.323/PSTN. Os terminais H.323
se comunicam com os Gateways usando os protocolos H.245 e Q.931.

26
De modo geral o propósito do Gateway é refletir as características de um ponto final de
uma LAN para um ponto final em uma SCN (Switched Circuit Network) e vice-versa. As
aplicações diretas do Gateway são listadas abaixo:

 Estabelecimento de enlaces com terminais analógicos PSTN.

 Estabelecimento de enlaces com terminais H.320 sobre uma rede RDSI.

 Estabelecimento de enlaces com terminais H.324 sobre redes PSTN.

Com transcodificadores apropriados, os Gateways podem suportar enlaces com terminais

H.310, H.321, H.322 e V.70.

Muitas funções dos Gateways são deixadas para o fabricante. Por exemplo, o número de
terminais suportados através de um Gateway não é objeto de padronização. Suporte a
funções de conexões multiponto, suporte a conexões de áudio/vídeo/dados, são também
deixadas para os fabricantes.

Um uso bastante comum dos gateways é transportar ligações de longa distância sobre uma
rede IP. Empresas podem reduzir os custos de suas ligações telefônicas usando gateways
para transportar o tráfego de voz, entre seus escritórios, sobre uma rede de dados existente.
Há um número cada vez maior de companhias que estão implantando redes de gateways
para prover ligações de longa distância e até mesmo internacionais. Neste tipo de aplicação
o chamador disca um número local para se conectar ao gateway, e então disca o número
destino. O gateway local faz uma conexão IP para outro Gateway localizado no destino. O
gateway destino completa a chamada discando o número local que representa o destino. A
Figura 4 ilustra uma ligação gateway-a-gateway.

Figura 3 - Gateway

27
 Figura 4 – Chamada Gateway-a-Gateway

Os Gateways são também usados para prover uma interface entre clientes H.323, como um
PC rodando o Microsoft NetMeeting™, e a PSTN, como mostrado abaixo.

Figura 5 – Chamada Terminal-para-Gateway

4. Unidades de Controle Multiponto

A Unidade de Controle Multiponto (MCU) é um ponto final H.323 que provê os serviços
necessários para que três ou mais pontos finais participem de uma conferência Multiponto
(por exemplo Teleconferência). Um MCU consiste de um Controlador Multiponto (MC)
que é obrigatório, e Processadores Multiponto (MP) (opcional). O MC provê a
funcionalidade de controle de chamada requerida para a conferência multiponto (H.245),
incluindo a negociação de capacitações comuns dos pontos finais, como processamento de
voz e vídeo, os MCs também controlam os recursos de conferência para determinar para
quem os fluxos de áudio e vídeo serão enviados em multicast. O MP, se presente, provê o
processamento (comutação e multiplexação) dos feixes do meio (áudio, vídeo, e/ou dados).
As funções do MC e MP podem ser incorporadas dentro de outras entidades H.323 –
Terminais, Gateways, ou Gatekeepers.

Os MCs não interagem diretamente com os fluxos de áudio, vídeo e/ou dados, isso é
deixado para os MPs se estiverem presentes. A Figura abaixo mostra a funcionalidade das
MCUs.

28
 Figura 6 - MCUs

(A) Conferências Multiponto

A capacitação de conferências multiponto são conseguidas de diversas maneiras e

configurações segundo a H.323. A recomendação usa os conceitos de conferências
centralizadas e descentralizadas como descrito na figura 6.

Conferências Centralizadas Multiponto requerem a existência de uma MCU como

facilitador. Todos os terminais mandam os seus fluxos de dados, voz, vídeo e controles para
a MCU de modo ponto-a-ponto. A MC gerencia centralizadamente a conferência usando as
funções de controle H.245 que também definem as capacitações de cada terminal. O MP
faz a mixagem de voz, a distribuição de dados, as funções de seleção/mixagem de vídeo,
que tipicamente ocorrem em conferencias multiponto e mandam os fluxos resultantes para
os terminais participantes. O MP pode também prover a conversão entre diferentes codecs e
taxas de bit e pode usar multicast para distribuir vídeo processado. Uma MCU típica que
suporta conferências centralizadas multiponto consiste de uma MC e uma MP para dados,
voz e imagem.

Conferência Descentralizadas Multiponto podem usar a tecnologia de multicast. Neste caso

os terminais H.323 participantes transmitem voz e vídeo entre si em multicast sem
mandarem dados para uma MCU. Observar na figura 6 que os dados e continuam

29
controlados centralizadamente pela MCU, e as informações dos Canais de Controle H.245
continuam sendo transmitidos ponto-a-ponto à uma MC.

Terminais Receptores são responsáveis pelo processamento de múltiplos fluxos de

informações de áudio e vídeo. Os terminais usam os canais de controle H.245 para indicar
para uma MC quantos fluxos de áudio e vídeo simultâneos eles podem decodificar. Esse
número não é o limitante de fluxos pertencentes à uma conferência, é uma variável apenas
local. O MP pode prover também seleção de vídeo e multiplexação de áudio em uma
conferência descentralizada multiponto.

Conferências Multiponto Híbridas usam uma combinação de funções centralizadas e

descentralizadas. Sinais H.245 e também fluxos de áudio e vídeo são processados através
de mensagens ponto-a-ponto para a MCU. O sinal remanescente (áudio ou vídeo) é
transmitido aos terminais H.323 participantes através de multicast.

Uma vantagem de conferência centralizada é que todos os terminais H.323 suportam

comunicações ponto-a-ponto. A MCU pode gerar múltiplos conexões unicast para a
conferência dos participantes e nenhuma capacitação de rede especial é requerida.
Alternativamente, a MCU pode receber múltiplos unicasts, mixar áudio e comutar vídeo, e
alternativamente gerar fluxos multicast, conservando a banda passante da rede.

O H.323 também suporta conferências mistas multiponto, onde alguns terminais estão em
conferência centralizada, outros em conferência descentralizada, e uma MCU provê o
serviço de bridge entre esses dois tipos. O terminal não sabe a natureza da conferência que
está em progresso, apenas o modo de conferência que está pronto para mandar e receber os
fluxos de informação.

Pelo fato de suportar tanto broadcast como unicast, a H.323 está preparada para trabalhar
tanto nas tecnologias atuais como nas tecnologias futuras de rede. Multicast faz melhor uso
da banda disponível da rede, mas exige maior esforço computacional nos terminais, que
deve mixar e comutar/selecionar seus próprios feixes de áudio e vídeo. E no caso de
roteadores e switches serem empregados na rede, o serviço multicast deve ser suportado.

A MC pode ser localizado dentro de um Gatekeeper, Gateway ou Terminal ou ainda em

uma MCU. A Figura 7 mostra as configurações descentralizada e híbrida.

30
 Figura 7 – Configuração Descentralizada e Híbrida

Considere um exemplo simples onde uma conferência multiponto é setada entre três
clientes (figura 7). Um terminal cliente (Cliente B) incorpora a função MC. Todos os
terminais usam multicast para participar da conferência descentralizada. Uma função MP
em cada nó irá mixar e apresentar o áudio entrante e os sinais de vídeo para o usuário. Esta
configuração minimiza a necessidade de recursos especializados. No entanto, a rede deve
ser setada para suportar multicast.

Uma MCU separada pode ser usada para manipular apenas as funções de controle, dados e
áudio. Nesta configuração o vídeo pode continuar em multicast que conserva a banda
passante. Esta MCU poderia ser um sistema dedicado ou um terminal mais poderoso.

Quando as conferências envolvem terminais espalhados na LAN e fora desta temos uma
vantagem em fazer as funções de MCU integradas com o Gateway.

5. Codecs

Os pontos finais H.323 usam codecs (também chamados de codificadores) para digitalizar e
comprimir os sinais de áudio e vídeo. Os codecs diferem por uma série de características,
incluindo qualidade de voz ou imagem, banda passante requerida para transmissão do sinal
e utilização da CPU.

De acordo com a H.323, todos os pontos finais devem suportar o padrão G.711 para
codificação de voz. Muitos devem suportar o codificador de voz para pequena banda
G.723.1. A capacitação para vídeo é opcional na H.323, e se existir os pontos finais devem
suportar o codec H.261. O suporte à outros codecs de áudio e vídeo são opcionais.

31
A tabela 1 mostra as recomendações associadas aos padrões H.32x do ITU-T, incluindo os
codecs.

Tabela 1 – Recomendações dos Padrões H.32x

H.320 H.321 H.322 H.323 H.324

V1/V2
Approval Date 1990 1995 1995 1996/1998 1996
Network Narrow- Broadband Guar- Non-guar- PSTN or
band ISDN ATM anteed anteed POTS, the
switched LAN band-width band-width analog
digital packet packet phone
ISDN switched switched system
networks networks,
(Ethernet)
Video H.261 H.261 H.263 H.261 H.261 H.261
H.263 H.263 H.263 H.263
Audio G.711 G.711 G.722 G.711 G.711 G.723
G.722 G.728 G.722 G.722
G.728 G.728 G.728
G.723
G.729
Multiplexing H.221 H.221 H.221 H.225.0 H.223
Control H.230 H.242 H.242 H.245 H.245
H.242 H.230
Multipoint H.231 H.231 H.243 H.231 H.323
H.243 H.243
Data T.120 T.120 T.120 T.120 T.120
Comm. Interface I.400 AAL I.363 I.400& TCP/IP V.34
AJM I.361 TCP/IP Modem
PHY I.400

32
6. Gatekeepers

O gatekeeper é um componente opcional na H.323. Ele provê uma série de serviços

importantes e provavelmente serão incluídos na maioria das redes H.323. A Figura abaixo
mostra a função do Gatekeeper no gerenciamento de sua Zona de atuação. Os gatekeepers
provêm serviços de controle de chamadas entre os pontos finais registrados em sua zona.
De muitos modos os Gatekeepers atuam como Comutadores Virtuais.

Figura 8 - Gatekeeper

Os serviços provisionados pelos gatekeepers estão descritos à seguir:

 Controle de Zona – Os Gatekeepers introduzem o conceito de zona. Uma zona é uma

coleção de todos os pontos finais gerenciados por um único gatekeeper. Em uma zona
está incluído pelo menos um terminal, e pode ou não incluir gateways ou MCUs. Isto é
independente da topologia de rede e pode incluir múltiplos segmentos de LAN. Os
gatekeepers provêem os serviços listados abaixo para todos os pontos finais dentro da
sua zona.

 Controle de Admissão – O gatekeeper permite ou rejeita a admissão para os pontos

finais H.323 da sua zona. Isto segue critérios baseados na banda disponível, ou algum
outro critério definido pelo administrador da rede.

 Controle de Banda – O gatekeeper também trata todas as requisições de mudança de

banda. Isto pode ser baseado na saturação da zona, em algum outro critério específico
definido pelo administrador da rede.

 Translação de Endereço – O gatekeeper mantém uma base de dados com os pontos

finais que fazem parte da sua zona. Mediante requisição dos pontos finais, ele pode
traduzir aliases (nome do host, endereço e-mail, etc.) para endereços da rede (e.g.
endereços IP) e Traduz endereços externos (e.g. formato de número de telefone E.164)
para endereços de rede.

33
Os Gatekeepers também são responsáveis por esses serviços adicionais:

 Autorização de Chamada – O gatekeeper pode aceitar ou rejeitar chamadas de um

ponto final mediante um processo de autorização (e.g. Você pode escolher não receber
chamadas de terminais H.323 de um concorrente).

 Gerenciamento de Banda – O gatekeeper pode limitar o número de pontos finais

fazendo acesso simultâneo, para preservar a banda disponível.

 Gerenciamento de Chamadas – O gatekeeper mantém uma base de dados de todas as

chamadas H.323 em andamento em sua zona. Esta informação é usada para seguir o
estado dos pontos finais para uma série de propósitos, como gerenciamento de banda e
identificação do chamador.

 Sinalização de Controle de Chamada – O gatekeeper pode suportar dois tipos de

controle de chamada, direto e roteado. As chamadas roteadas são tipicamente usadas em
sistemas onde é necessário monitorar mais de perto o estado das chamadas.

No modo direto de chamada , o ponto final chamador (A) manda uma

requisição de admissão na zona (ARQ) para o gatekeeper. Todo o controle
da chamada é então passado para os pontos finais.

Figure 3 – Modo de Chamada Direta

No modo de chamada roteada o ponto final chamador (A) manda da mesma forma um

pedido de admissão na zona para o gatekeeper. No entanto, neste caso todo o controle de
admissão e de conexão será roteado através do gatekeeper. Isto permite ao gatekeeper
conhecer mais de perto todas as conexões em andamento na sua zona.

Figure 4 – Modo de Chamada Roteada

34
7. Como o H.323 Trabalha

Abaixo mostramos um diagrama com uma chamada H.323 ponto-a-ponto. Foi focado a
parte relativa a mensagens de interesse para o Proxy, e excluímos os detalhes do esquema
relativo à negociação de áudio e vídeo.

Em todos os exemplos, usaremos os personagens Alice e Bob. Quando falarmos de

firewalls, consideraremos Alice como um usuário externo e Bob um usuário protegido pelo
firewall.

Vamos começar pelo entendimento dos conceitos básicos de uma chamada ponto-a-ponto.
A chamada é gerenciada em três diferentes níveis. Começaremos com Alice fazendo uma
conexão TCP para a Well Known Port do H.323 (porta 1720).

Bob e Alice mandam pacotes Q.931 por esta conexão. Como parte desta troca de
mensagens, Bob e Alice negociam uma porta efêmera (porta dinamicamente aberta e maior
que 1024) à ser usada pela conexãoH.245. De acordo com o padrão, uma vez a conexão
H.245 é estabelecida, a conexão Q.931 pode ser desligada sem a necessidade da mensagem
Release Complete e sem afetar o resto da chamada H.323. Na prática, a conexão Q.931 é
simplesmente abandonada.

A conexão H.245 é feita pela origem (chamador) sobre a porta efêmera negociada pelo
fluxo Q.931. O H.245 manipula toda a parte de negociação de parâmetros de chamada, tais
como tipo de codecs à serem usados. O H.245 também tem comandos que geram
“conexões” UDP. Essencialmente, uma vez que os codecs de áudio e vídeo e os parâmetros
tenham sido negociados, a sessão H.245 executa uma seqüência OpenLogicalChannel.
Esta seqüência troca endereços e números de porta de RTCP dos transmissores assim como
os endereços e números de porta de RTP e RTCP dos receptores, para um fluxo de mídia
(voz ou imagem ou dados) em particular. Deve ser notado que no H.323, cada canal lógico
é considerado unidirecional, dessa forma, para que duas pessoas troquem informações de
áudio, duas conexões lógicas devem ser abertas, uma de Alice para Bob e outra de Bob para
Alice. Além disso o RTCP requer uma conexão bidirecional para o fluxo de dados que
controlam o RTP (status, timestamp, etc.). Os fluxos RTP e RTCP devem ser abertos
adjacentes (enquanto a porta RTP é um valor par à do RTCP é uma valor ímpar
imediatamente superior).

35
 Figura 5 – Diagrama de uma Conexão H.323 Ponto-a-Ponto

(A) Adicionando um Proxy

O diagrama abaixo mostra como as mensagens são manipuladas quando um proxy é
inserido no meio do fluxo. Lembrando que isso é requerido apenas para funções de firewall
e as funções proxy (filtragem de pacotes e circuitos, filtragem de endereços), e operam
apenas no nível IP, e são transparentes para os parceiros (Alice e Bob).

Quando um proxy é inserido, a fase Q.931 é modificada para o esquema abaixo:

36
 Figura 6 – Q.931 com um Proxy

Abaixo mostramos as conexões proxy para a sessão H.245. Para ajudar a compreender a
complexidade, mostramos exemplos de números de porta. Observe que selecionamos
números de porta pequenos para fins didáticos, na realidade estas portas são efêmeras e
sempre maiores que 1024.

37
 Figura 7 – Mensagens H.245 com o Proxy

38
8. Glossário de Termos H.323

Call (Chamada): Comunicação Multimídia ponto-a-ponto entre dois pontos finais H.323.

Call Signaling Channel (Canal de Sinalização de Chamada): Canal usado para

transportar as mensagens de sinalização de acordo com a Q.931.

Centralized Multipoint Conference (Conferência Centralizada Multiponto): Uma

chamada em que todos os terminais participantes se comunicam através de uma conexão
ponto-a-ponto com uma MCU.

Common Intermediate Format (CIF – Formato Intermediário Comum): Formato de

Imagem para H.263, representado por 352 pixels/linha por 288 linhas/imagem.

Decentralized Multipoint Conference (Conferência Descentralizada Multiponto): Uma

conferência onde os terminais participantes fazem multicast para todos os outros
participantes sem usarem a MCU.

E.164: Formato de endereçamento para redes RDSI. Ver ITU Recommendation E.164
(1991).

Endpoint (Ponto Final): Um Terminal, Gateway ou MCU.

Gatekeeper (GK): Uma entidade H.323 que provê translação de endereços, controle de
acesso, e às vezes gerenciamento de banda de uma LAN para uso dos Terminais H.323,
Gateways e MCUs.

Gateway (GW): Uma entidade H.323 que provê comunicação em tempo real entre
terminais H.323 em uma LAN e outros terminais ITU em uma WAN ou um outro Gateway
H.323.

H.323 Entity (Entidade H.323): Qualquer componente H.323, incluem os Terminais,

Gateways, Gatekeepers, MCs e MCUs.

H.245 Logical Channel (Canal Lógico H.245): Um canal carregando fluxos de

informação entre dois pontos finais H.323.

IP: Internet Protocol

Local Area Network (LAN): Um meio físico compartilhado, para comunicação peer-to-
peer, que pode incluir elementos de interconexão de redes tais como bridges, switches ou
roteadores.

39
Multicast: Processo de transmitir à partir de uma fonte para muitos destinos. O mecanismo
seguido depende da tecnologia de LAN envolvida.

Multipoint Conference (Conferência Multiponto): Uma conferencia entre três ou mais

terminais, que podem pertencer à LAN ou à uma rede comutada de circuito (CSN).

Multipoint Control Unit (Unidade de Controle Multiponto - MCU): Um ponto final na

LAN que habilita três ou mais terminais e/ou gateways à participarem de uma conferência.
A MCU incluem obrigatoriamente s MC (Multipoint Controller) e opcionalmente os MP
(Multipoint Processors).

Multipoint Controller (Controlador Multiponto - MC): Uma entidade que provê o

controle de três ou mais terminais em uma conferência multiponto.

Multipoint Processor (Processador Multiponto - MP): Uma entidade que provê o

processamento de áudio, vídeo e fluxos de dados em uma conferência multiponto. Os MP
provêm a mixagem, comutação/seleção, ou outro processamento de fluxos de mídia sob o
controle da MC.

Quality of Service (Qualidade de Serviço - QoS): Garantia de banda e disponibilidade da

rede para as aplicações.

Q.931: Protocolo de sinalização de chamada para abrir, conservar e terminar chamadas.

RAS Channel (Canal RAS): Um canal não orientado à conexão usado para prover
mensagens de Registro, Admissão e Status (Registration, Admission and Status - RAS)
além de mudanças de banda entre duas entidades H.323.

Reliable Transmission (Transmissão Conectada): Transmissão de dados orientado à

conexão que garante seqüência, controle de erros, e controle de fluxo na transmissão e
recepção das mensagens.

Resource Reservation Protocol (RSVP): Especificação do IETF que permite a requisição

de uma banda passante.

Real-Time Protocol/Real-Time Control Protocol (RTP/RTCP): Especificação do IETF

para gerenciamento de sinais de áudio e vídeo. Permite às aplicações sincronizar e difundir
informações de áudio e vídeo.

Switched Circuit Network (Rede Comutada à Circuito - SCN): Uma rede de

telecomunicações comutada à circuito pública ou privada, tais como PSTN e RDSI.

TCP: Transmission Control Protocol. Camada orientada a conexão acima do IP.

Terminal: Um ponto final que provê uma comunicação em tempo real com outro terminal,
gateway ou MCU. Um terminal deve prover áudio e pode também prover vídeo e/ou dados.

40
UDP: User Datagram Protocol. Protocolo de Transporte não orientado à conexão que
trabalha de maneira não confiável, usado para aplicações em tempo real.

Transmissão não orientada à conexão: Transmissão que provê entrega com maior esforço
dos pacotes de dados. As mensagens podem ser duplicadas, invertidas ou perdidas (não
confiável).

Zona: A coleção de todos os Terminais, Gateways e MCUs gerenciados por um único

Gatekeeper. Uma zona inclui no mínimo um Terminal e pode incluir segmentos de LAN
conectados por Roteadores.

41
 UNIDADE 5

SIP – Sesion Initialization Protocol

Session Initialization Protocol

 SIP é um protocolo de sinalização fim a fim do tipo
cliente-servidor:
 Primariamente o SIP provê presença e mobilidade,
 Primitivas do protocolo: estabelecimento de sessão,
terminação e mudanças.
 Serviços arbitrários implementados sobre o SIP:
 Redirecionamento de chamadas de origem não conhecida
para a secretária,
 Responder com uma Web page se indisponível,
 Mandar um JPEG ou convite.

42
Session Initialization Protocol

 Funcionalidade:
 Codificação Textual (compatível com TELNET,
TCPDUMP, etc...)
 Programabilidade ampliada

Session Initialization Protocol

 SIP não é limitado à Telefonia Internet:
 SIP primeiramente estabelece a presença do usuário,
 As mensagens SIP podem conter o payload de sinalização
arbitrário: descrição de sessão, mensagens instantâneas,
JPEGs, e qualquer tipo MIME.
 Muito útil para aplicações contendo noção de sessão:
 sistemas de realidade virtual distribuída,
 Games em rede (implementações de Quake II e III),
 Vídeo-conferência, etc...

Session Initialization Protocol

 Aplicações podem influenciar a infra-

estrutura SIP (Processamento de
Chamada, Localização de Usuário,
Autenticação):
 Mensagens Instantâneas e Presença,
 SIP para aparelhos.

43
 Lembrar que SIP não é...

 Um protocolo de transporte
 Um protocolo de reserva de QoS
 Um protocolo de controle de Gateways

 Além disso não dita...

 As funções dos produtos e serviços,
 A configuração da Rede.

Histórico
 Primeiros trabalhos em 1995 no mmusic WG do IETF
 02/96: draft-ietf-mmusic-sip-00: 15 pag. texto ASCII, 1 tipo
descrito
 12/96: -01: 30 pag. texto ASCII, 2 tipo descrito
 01/99: -12: 149 pag. Texto ASCII, 6 métodos
 03/99: RFC 2543, 153 pag. Texto ASCII, 6 métodos
 11/99: Formação do SIP WG
 11/2000: draft-ietf-sip-rfc2543bis-02, 171 pag. Texto ASCII, 6
métodos
 12/2000: é reconhecido que há muito trabalho para um só WG; 1
RFC, 18 I-D’s na agenda do WG
 04/2001: proposta de divisão do SIP WG em SIP e SIPPING
 2001: Implementações SIP altamente disponíveis
 http://www.cs.columbia.edu/~hgs/sip/implementations.htm
 http://www.pulver.com/sip/products.html

Equipamentos Terminais SIP

 User Agent (User Application)

 UA Client (originam chamadas)
 UA Server (escutam para
chamadas entrantes)

44
Cavalos de Batalha do SIP

 Servidor Proxy SIP

 retransmite sinalização de chamada, i.e. atua
como ambos cliente e servidor
 opera de uma forma transacional, não guarda
nenhum estado da sessão
 Servidor de Redirecionamento SIP (Redirect
Server)
 redireciona chamadores para outros servidores

Cavalos de Batalha do SIP

 SIP Registrar
 aceita requisições de registro de usuários
 mantém localização (whereabouts) no
servidor de Localização (Location Server) -
como no GSM HLR.

Endereços SIP

 SIP garante um endereço globalmente alcançável.

 Usuários anexam ao seu endereço usando o método de
registro SIP
 Chamadores usam este endereço para estabelecer uma
sessão de tempo real com os usuários.
 URLs usadas com formato de endereços de dados,
exemplos:
 sip:jiri@iptel.org
 sip:voicemail@iptel.org?subject=callme
 sip:sales@hotel.xy;geo.position:=48.54_-123.84_120

45
 Endereços SIP

 Devem incluir Host, podem incluir user

name, port number, parâmetros (por
exemplo, transporte), etc.
 Pode ser incluído em webpages,
assinaturas de e-mails, impresso em seu
cartão de apresentação, etc.
 Capacidade de endereçamento infinita
 URLs não SIP podem ser usadas da
mesma maneira (mailto: , http: , ftp: ).

Exemplo de Registro

Operação com Proxy

46
Funcionalidade dos Servidores
Proxy
 Serve como um intermediário através do qual todos
os usuários podem ser alcançados.
 Executa funções de roteamento: i.e. para quem (UA,
proxy, redirect) a mensagem de sinalização deve ser
enviada.
 Permite que as funções de roteamento sejam
programadas; Lógicas arbitrárias podem ser
desenvolvidas sobre o protocolo:
 preferências de sinalização de usuário
 AAA
 controle de firewall, etc.

Funcionalidade dos Servidores

Proxy

 Chamadas para diversos destinos, podem

ser tratadas seqüencialmente ou em
paralelo.

Cadeia Proxy

 Há casos onde o proxy local se envolve

com a decisão do destino:
 provimento de importante lógica de
processamento de chamada (identificação do
911 mais próximo, etc.)
 gerenciamento de firewall
 os telefones internet devem possuir o
endereço do proxy: podem ser programados
manualmente ou com protocolos de
configuração (TFTP, DHCP, etc.)

47
 Cadeia Proxy

 Em geral os servidores podem ser

arbitrariamente encadeados.
 Um servidor corporativo central pode
distribuir para os servidores departamentais,
 Um usuário pode querer redirecionar as suas
chamadas entrantes para o seu telefone
celular.
 Os servidores devem poder evitar loops e
reconhecer espirais.

Exemplo de encadeamento de
proxy

Nota: a sinalização pode tomar um caminho completamente

diferente do sinal

Proxy sem lembrança de estados

orientado à transações
 Se um proxy é sem estados, então
ele captura o estado de uma
transação e completamente o
esquece em seguida.
 O proxy SIP não é consciente do
estado das chamadas
 A não ser que a função de gravação
de rotas esteja habilitada, o BYE
pode tomar um caminho
completamente diferente (por isso
não pode ser esperado)
 Teoricamente podem haver estados
também, porém isso deverá ser
implementado de forma consciente
para não limitar o crescimento em
escala das aplicações.

48
As Transações Subsequentes
Bypassam o Proxy

 Apesar da gravação
da rota ser uma
prática comum, BYE
pode passar por um
caminho
completamente
diferente da
transação de call
setup.

Operação SIP no Modo

Redirect

Servidor SIP - Proxy x

Redirection
 Um servidor SIP pode ambos (proxy ou redirect)
uma chamada.
 Qualquer método pode ser alcançado por
configuração. E pode ser estaticamente ou
dinamicamente (CPL) programado.
 Redirection é interessante quando um usuário é
móvel ou mudou de provedor (PSTN - “Este número
mudou para”). O chamador não precisa discar o
número anterior (memoriza).
 Proxy é interessante quando AAA, firewall, ou
métodos de segurança são necessários.

49
 Métodos SIP - RFC 2543
 INVITE - Inicia uma sessão
 descrição de sessão incluída no corpo da
mensagem.
 Re-INVITEs usados para mudar o estado de uma
sessão.
 ACK - Confirma o estabelecimento de uma
sessão
 Só pode ser usado com INVITE.
 BYE - Termina uma sessão.
 CANCEL - Cancela um INVITE pendente.

Métodos SIP - RFC 2543

 OPTIONS - Capacitação de Serviços

 REGISTER - Agrupa um endereço
permanente à localização corrente. Pode
carregar dados do usuário (scripts CPL)

Métodos de Extensão SIP

 INFO - Sinalização durante a chamada (RFC

2976)
 COMET - Precondição encontrada (draft-ietf-
sip-manyfolks-resource)
 PRACK - provisional reliable responses
acknowledge (draft-ietf-sip-100rel)
 SUBSCRIBE/NOTIFY/MESSAGE -
mensagem instantânea (draft-rosemberg-
impp-*)

50
Códigos Respostas SIP

 Emprestados do HTTP - texto explicativo xyz.

 Receptores precisam entender x.
 x80 ou maiores devem evitar conflito com as
futuras mensagem HTTP.
 1yz Informacional
 100 Trying
 180 Ringing (processed locally)
 181 Call is Being Forwarded

Códigos Respostas SIP

 2yz Success
 200 ok
 3yz Redirection
 300 Multiple Choices
 301 Moved Permanently
 302 Moved Temporarily

Códigos Respostas SIP

 4yz Client error

 400 Bad Request
 401 Unauthorized
 482 Loop Detected
 486 Busy Here
 5yz Server failure
 500 Server Internal Error
 6yz Global Failure
 600 Busy Everywhere

51
 Estrutura de Mensagens SIP

Session Description Protocol

(SDP)

 Carrega suficiente informação para habilitar a

participação em uma sessão multimídia.
 SDP inclui descrição de:
 mídia à ser usada (codecs, taxa de amostragem, etc).
 mídia destino (endereço IP e número de porta).
 Nome da sessão e propósito.
 tempo de sessão aberta.
 informação de contato.
 Observe que o SDP é mais um formato de
dados que propriamente um protocolo.

Session Description Protocol

(SDP)

v= 0
o= sisalem 28908044538 289080890 IN IP4
193.175.132.118
s= SIP Tutorial
e= sisalem@ fokus. gmd.de
c= IN IP4 126.16.69.4
t= 28908044900 28908045000
m= audio 49170 RTP/ AVP 0 98
a= rtpmap: 98 L16/ 11025/ 2

52
Design do Protocolo SIP
 Infra-estrutura segue o modelo de estados
do IP.
 Mais inteligência e estados no dispositivos
terminais.
 O núcleo da rede mantém apenas os estados
transacionais.
 A borda da rede pode manter os estados da
sessão
 Benefícios: Consumo de CPU e memória é baixo
nos servidores; confiabilidade de escalabilidade
muito alta (sem pontos críticos de falha).

Design do Protocolo SIP

 Usa UDP
 Setup mais rápido
 Menos estados

Futuro

 Capacidade de serviços futuros

desconhecida - cria serviços
independentes da sinalização.
 Lição Histórica: HTTP não é mais para
transporte de Hypertexto.
 Ele também provê e-mail, e-commerce, pc-
banking, movies, etc.
 Programabilidade adicionou numerosas
aplicações, o protocolo permaneceu o
mesmo.

53
 Futuro
 Projetistas do SIP aprenderam com as
lições do HTTP.
 Self-identifying Attribute-Value-Pairs (AVPs)
seguidos de separadores (EoL)
 best-effort: receivers ignoram AVPs
desconhecidas saltam para o próximo
separador.
 SDP suporta compulsoriamente, payloads
arbitrários MIME, incluindo (JPEG,
 ISUP, troca de informação, Multipart,...)
 Transparent proxying

Futuro
 Require, Proxy-require, Supported Header Fields
 Classes de códigos de status (1xx in-progress, 2xx
success, 3xx forwarding, ...)
 Guia para desenvolver novas extensões é
provisionada (draft-ietf-sip-guidelines)
 Pergunta de Capacitação com OPTION -- retorna
métodos suportados (Allow), tipos de mídia (Accept),
métodos de compressão (Accepted-Encoding),
Supported (supported features)

54
 UNIDADE 6

RTP e RTCP

1. Introdução:

O Protocolo de transporte mais utilizado para aplicações é o TCP. Este tem mostrado o seu
valor ao longo do tempo, porém, para aplicações em tempo real, o TCP não possui as
características desejadas. No caso de aplicações distribuídas em tempo real, ou seja, as
máquinas envolvidas geram um fluxo de dados à bit constante, e um ou mais destinos
devem receber estes dados e passar às suas aplicações à essas mesmas taxas constantes.
Exemplos desses tipos de aplicação incluem conferência de voz e vídeo, distribuição de
vídeo ao vivo (ou seja, não para gravação, mas para visualização imediata), áreas de
trabalho compartilhadas, diagnóstico médico à distância, telefonia, sistema de controle e
comando, simulações interativas distribuídas, jogos e monitoração em tempo real. Algumas
funções do TCP o desqualificam para o seu uso como protocolo de transporte dessas
aplicações.

1 – O TCP é um protocolo ponto-a-ponto e estabelece conexão entre dois pontos finais. No

entanto não é concebido para transmissão multicast.

2 – O TCP inclui mecanismos de retransmissão de longos segmentos, que cheguem fora de

ordem. Este tipo de mecanismo não é possível de ser usado em aplicações de tempo real.
3 – O TCP não contém mecanismos convenientes de associação de informação de
temporização dos segmentos, que é outro requerimento de aplicações em tempo real.

55
 Outro protocolo de transporte largamente usado é o UDP, ele não possui as duas primeiras
características listadas, mas da mesma forma que o TCP, não provê informações de
temporização. Sozinho, o UDP também não provê todas as ferramentas de propósito geral
para as aplicações de tempo real.
Como cada aplicação de tempo real possui seus próprios mecanismos de preservação de
transporte em tempo real. Porém algumas funções são comuns à todas as aplicações, assim
o IETF definiu um protocolo na RFC 1889 chamado RTP (Real Time Protocol), para o
transporte da aplicação e um protocolo chamado RTPC (Real Time Control Protocol) para o
controle do RTP.

2. O Transporte do Tráfego em Tempo Real

A instalação de LANs e WANs de alta velocidade, o aumento da capacidade de tratamento

de informação da Internet, tem aberto a possibilidade de usar as redes baseadas em IP para
o transporte de tráfego de tempo real. No entanto, para fins didáticos, é importante
reconhecer quais os requerimentos de tráfego em tempo real e em que este difere do tráfego
de alta velocidade, mas não em tempo real.

No caso das aplicações tradicionais da Internet, tais como a transferência de arquivo, o

correio eletrônico e aplicações cliente-servidor (incluindo a WEB), as métricas de
performance que interessam são normalmente o throughput e o delay. Existe também algum
interesse com relação à disponibilidade, e alguns mecanismos que previnem a perda de
dados, a sua corrupção e a inversão de ordem de chegada durante o transito. Em contraste, a
aplicações em tempo real são mais sensíveis ao delay. Em muitos casos, existe uma
necessidade que os dados à serem transmitidos saiam à taxa de bit constante. Em outros
casos, um limite de tempo é estabelecido e nenhum pacote é aproveitável se este limite for
estabelecido.

56
Figura 1 – Fluxo de dados em Tempo Real

57
3. Características de Tráfego em Tempo Real

A Figura 1 ilustra um esquema típico em tempo real. Nela, um servidor gera áudio à ser
transmitido a 64 kbps. O sinal de áudio digitalizado é transmitido em pacotes de 160 bytes
de dados, assim cada pacote é transmitido à cada 20ms. Estes pacotes são entregues a uma
Internet encaminhados à um PC multimídia, que recompõe este áudio no instante que
chega. No entanto, devido ao delay variável imposto pela Internet, os pacotes não chegam à
cada 20ms no destino. Para compensar isto, os pacotes que chegam são bufferizados,
atrasados um pouco, e então liberados à taxa constante ao software que recompõe o áudio.

A compensação que os buffer de delay provê é limitada. Para entender isso, necessitamos
definir o conceito de jitter de delay, que é a máxima variação de delay experimentada pelos
pacotes em uma mesma sessão. Por exemplo, se o delay mínimo fim a fim observado por
qualquer pacote é de 1 ms e o máximo é de 6 ms, então o jitter de delay será de 5 ms. Ao
longo do tempo o buffer de delay atrasa os pacotes em no máximo 5 ms, e então encaminha
à saída, e isso será feito para todos os pacotes recebidos. Se o buffer de delay nas mesmas
condições for dimensionado para 4 ms, um pacote cujo delay absoluto for maior que 5 ms
deverá ser descartado, senão poderá vir a ser usado fora de ordem.

A descrição do tráfego de tempo real de maneira geral implica em uma série de quadros de
mesmo tamanho gerados à uma taxa constante. Porém outros tipos de tráfego são também
possíveis:

Fonte de Dados Contínuo: Pacotes de tamanho constante são gerados em intervalos fixos.
Isto caracteriza aplicações que estão constantemente gerando dados, tem poucas
redundâncias, e é muito importante comprimi-las sem perdas. Exemplos são o controle de
tráfego aéreo com radar e simulações em tempo real.

Fonte On/Off: A fonte alterna períodos onde pacotes de tamanho fixo são gerados em
períodos constantes e períodos com inatividade. Telefonia e audio-conferência são
exemplos desse tipo de fonte.

Tamanho Variável de Pacotes: A fonte gera pacotes de tamanho variável em períodos

uniformes. Um exemplo é vídeo digitalizado em que quadros diferentes podem obter
diferentes taxas de compressão para um mesmo nível de qualidade de serviço.

4. Requerimentos para Comunicação em Tempo Real

Abaixo são listadas as propriedades desejáveis para uma comunicação em tempo real:

58
  Baixo Jitter

 Baixa Latência

 Habilidade para integrar facilmente serviços em tempo real e não em tempo real

 Adaptabilidade para dinamicamente mudar as condições de tráfego da rede

 Boa performance para redes grandes com um número grande de conexões

 Requerimentos modestos de bufferização dentro da rede

 Alta capacidade efetiva de utilização

 Baixo overhead em bits de header por pacote

 Pequeno processamento do overhead por pacote dentro da rede e nos sistemas finais.

Estes requerimentos são difíceis de serem alcançados em redes grandes baseadas em IP ou

na Internet. Nem o TCP, nem o UDP possuem sozinhos esta capacidade. Veremos que o
RTP provê fundamentos razoáveis para atingir estes requisitos.

5. Aplicações Hard versus Soft Real Time

Uma distinção precisa ser feita entre aplicações de comunicação hard e soft real time.
Aplicações soft real time podem tolerar a perda de porções de dados enquanto aplicações
hard real time tem tolerância zero. Em geral, aplicações soft real time impõem poucos
requerimentos à rede, e podemos focar na maximização da utilização da rede, mesmo às
custas de entrega fora de ordem ou perdas de pacotes. Em aplicações hard real time, um
limitante superior determinado de jitter e alta disponibilidade tem prioridade sobre as
considerações de utilização.

59
 RTP é melhor adaptado para comunicações soft real time. Ele não possui os mecanismos
necessários para suportar tráfego hard real time.

6. Arquitetura do Protocolo RTP

No RTP, existe uma estreita ligação entre a funcionalidade do protocolo RTP e a

funcionalidade da aplicação. Assim, o RTP é melhor visto como uma área de trabalho em
que as aplicações o podem usar diretamente para implementar um protocolo próprio. Sem a
especificação da informação da aplicação específica, o RTP não é um protocolo completo.
Por outro lado, o RTP impõe uma estrutura e define funções comuns de tal forma que as
aplicações muitas vezes distintas possam ser implementadas diretamente nele.

O RTP segue os princípios da arquitetura de protocolos desenvolvida pelos pesquisadores

Clark e Tennenhouse. Os dois conceitos chaves apresentados por estes autores são, o
encapsulamento em quadros do nível aplicação e o processamento integrado das camadas.

(A) Encapsulamento em Quadros do nível Aplicação:

Em um protocolo de transporte tradicional, tal como o TCP, a responsabilidade da

recuperação de porções de dados perdidos é feito de forma transparente pelo nível
transporte. Os autores listam dois cenários em que seria mais apropriado a recuperação dos
dados perdidos pela aplicação.

1. A aplicação, dentro de certos limites, pode aceitar menos do que uma entrega perfeita e
continuar sem checagem. Este é o caso de áudio e vídeo em tempo real. Para estas
aplicações, pode ser necessário informar à fonte em termos mais gerais sobre a
qualidade da entrega, ao invés de pedir retransmissão. Se muitos dados estiverem sendo
perdidos, a fonte pode mudar para uma transmissão de mais baixa qualidade que exigirá
menos demanda na rede, aumentando a probabilidade de entrega.

2. Seria preferível ter a aplicação provendo a retransmissão dos dados (se houver) ao invés
do protocolo de transporte, nos seguintes contextos:

a) A aplicação que transmite pode processar grandes quantidades de dados ao invés de

armazená-los.
b) A aplicação que transmite pode prover valores revisados ao invés de repetir valores
perdidos, ou transmitir dados novos que consertam as conseqüências da perda original.

Para habilitar a aplicação a ter controle sobre a função de retransmissão, Clark e

Tennenhouse propuseram que as camadas inferiores (tais como Apresentação e Transporte)

60
 trabalhem com um tamanho unificado de pacotes, cujo tamanho seja especificado pela
Aplicação. A aplicação quebra o fluxo em dados em Unidades de Dados da Aplicação
(ADU), e as camadas inferiores devem preservar os limites dessas ADUs enquanto
processam os dados. A ADU passa a ser a unidade de recuperação de erros. Então, se uma
porção de uma ADU é perdida na transmissão, a aplicação ficaria incapaz de fazer uso das
porções remanescentes, neste caso, a camada aplicação descartará todas as porções que
cheguem e arranjará a retransmissão da ADU inteira, se isto for necessário.

(B) Processamento Integrado de Camadas

Em arquiteturas de protocolos em camadas, tais como o TCP/IP e o OSI, cada camada da

arquitetura contém um subconjunto de funções a ser desempenhadas para a comunicação, e
cada camada deve ser estruturada logicamente como um módulo separado em sistemas
finais. Assim, na transmissão, um bloco de dados flui das camadas mais altas para as mais
baixas, e é seqüencialmente processada por cada camada da arquitetura. esta estrutura
restringe aos implementadores a invocar certas funções em paralelo ou fora da seqüência
das camadas para atingirem maior eficiência. O processamento Integrado de Camadas,
como proposto por Clark e Tennenhouse, defende a idéia que as camadas adjacentes devem
ser acopladas modo mais flexível e o implementador deve ser livre para desenvolver as
funções dessas camadas de maneira mais flexível.

A Figura 2 ilustra a maneira na qual o RTP realiza o princípio de processamento integrado

de camada. O RTP é projetado para rodar sobre um protocolo de transporte sem conexão tal
como o UDP. O UDP provê a funcionalidade básica de endereçamento de portas da camada
transporte. O RTP implementa as funções de transporte, como seqüenciamento, no entanto,
o RTP sozinho não é completo, ele necessita fazer modificações e/ou adições de header que
incluam as funcionalidades específicas do nível aplicação. A figura indica que diversos
padrões diferentes de compressão de vídeo podem ser usados em conjunto com o RTP para
transmissão da aplicação vídeo.

61
 Figura 2 – Adaptabilidade do Protocolo RTP

Primeiramente olharemos os conceitos básicos do protocolo de transferência de dados RTP

e então examinaremos o formato do header do protocolo. Ao longo deste item, o termo RTP
se referirá ao protocolo de transferência de dados RTP.

(C) Conceitos do RTP

O RTP suporta a transferência de dados em tempo real entre elementos participantes em

uma sessão de comunicação. A sessão é simplesmente a associação entre dois ou mais
entidades RTP que é mantida durante a fase de transferência de dados. A sessão é definida
da seguinte forma:

 Número da porta RTP: O endereço da porta destino é utilizada por todos os

participantes na transferência RTP. Se o UDP é o protocolo de nível inferior, este
número de porta está especificada no campo Destination Port do header UDP.

 Número da Porta RTCP: O endereço da porta destino é utilizada por todos os

participantes na transferência RTCP.

62
  Endereços IP dos Participantes: Este pode ser tanto um endereço IP multicast como um
endereço normal, de maneira que o grupo multicast é definido por um endereço
registrado como multicast, ou por um conjunto de endereços unicast (normais).

Apesar do RTP ser usado para transmissão ponto a ponto, a sua força está na sua habilidade
em suportar transmissões multicast. Para este propósito, cada unidade de dados RTP inclui
um identificador da fonte, usado para designar qual o membro do grupo que gerou este
dado. Ele também inclui um timestamp, dessa forma uma temporização adequada pode ser
recriada pelo receptor utilizando um buffer de delay. O RTP também identifica o formato
do payload do dado sendo transmitido.

O RTP permite o uso de dois tipos de equipamentos: os transladores e o mixers.

Um mixer é um equipamento que recebe um fluxo de dados RTP de uma ou mais fontes,
combina estes fluxos, manda este novo fluxo de pacotes RTP para um ou mais destinos. Um
mixer pode mudar o formato dos dados ou simplesmente fazer a função de mixagem.
devido à falta de sincronismo entre as diversas entradas, o mixer prove um novo timestamp
do fluxo combinado, e identifica a si próprio como fonte de sincronismo.

O translador é um equipamento simples que produz um ou mais fluxos de pacotes RTP para
cada fluxo de pacotes RTP entrante. O translador pode mudar o formato dos dados no
pacote ou usar uma suite de protocolos de nível inferior diferente para transferir de um
domínio à outro.

(D) Header fixo do RTP

Cada pacote RTP inclui um header fixo e pode incluir um header opcional específico da
aplicação. A figura 3 mostra este header fixo. Os primeiros 12 octetos estão sempre
presentes e são constituídos dos seguintes campos:

63
 Figura 3 – Header fixo RTP

0 8 16 31
V PX CC M Payload Type Sequence Number

Timestamp

Sinchronization Source (SSCR) Identifier

Contributing Source (CSCR) Identifier

...

Contributing Source (CSCR) Identifier

V=Version
P=Padding
X=Extension
CC=CSCR count.
M=Marker

Version (2 bits): A versão atual é 2.

Padding (1 bit): Indica quando octetos de enchimento aparecerem no fim do payload. O

enchimento é usado se a aplicação requer que o payload seja um inteiro múltiplo de algum
tamanho, tal como um múltiplo de 32 bits (4 bytes).

Extension (1bit): Se setado, o header fixado é seguido por exatamente um header

estendido, que é usado para extensões experimentais do RTP.

CSRC Count (4 bits): O número de identificadores de CSRC que seguem o header fixo.

Marker (1 bit): A interpretação do Marker bit depende do tipo de payload; ele é usado para
identificar um limite no fluxo de dados. Para sinais de vídeo, é setado para marcar o fim de
um quadro de imagem. Para sinais de áudio é setado para marcar o início de um surto de
voz.

Payload Type (7 bits): Identifica o formato de um payload RTP, que seguirá o header.

Sequence Number (16 bits): Cada fonte começa com um número de seqüência randômico,
que é incrementado para cada pacote RTP transmitido. Isso permite a detecção de perda de
pacotes e geração de estatísticas de timestamp. Um conjunto de pacotes podem ter um
mesmo timestamp se são gerados logicamente no mesmo tempo, por exemplo vários
pacotes levando o mesmo quadro de vídeo.

64
 Timestamp (32 bits): Corresponde ao instante de geração do primeiro octeto dos dados do
payload, a unidade de tempo deste campo depende do tipo de payload. Os valores devem
ser gerados por um clock interno.

Synchronization Clock Identifier: Um valor gerado randomicamente que identifica de

maneira única a fonte dentro de uma sessão.

Seguindo este header fixo, podem haver um ou mais desses campos seguintes:

Contributing Source Identifier: Identifica uma fonte de contribuição para o payload.

Usada na função mixer.

O campo Payload Type identifica o tipo de mídia do payload e o formato dos dados,
incluindo o tipo de compressão e encriptação. No estado permanente, uma fonte deve usar
apenas um tipo de payload durante a sessão, mas pode haver uma mudança do tipo de
payload em resposta à condições de mudanças, através do RTCP. A tabela 1 sumariza os
tipos de payload definidos na RFC 1890.

Tabela 1 – Descrição do Campo Payload Type

0 PCMU audio 16-23 unassigned audio

1 1016 audio 24 unassigned audio
2 G.721 audio 25 CelB video
3 GSM audio 26 JPEG video
4 unassigned audio 27 unassigned
5 DV14 audio (8kHz) 28 nv video
6 DV14 audio (16kHz) 29-30 unassigned video
7 LPC audio 31 H.261 video
8 PCMA audio 32 MPV video
9 G.722 audio 33 MP2T video
10 L16 audio (stereo) 34-71 unassigned
11 L16 audio (mono) 72-76 reserved
12-13 unassigned audio 75-95 unassigned
14 MPA audio 96-127 dynamic
15 G.728 audio

7. RTCP (RTP Control Protocol)

O protocolo RTP é usado apenas para a transmissão de dados do usuário, tipicamente em

conexões multicast entre todos os participantes em uma sessão. Um protocolo separado de
controle (RTCP) também opera de modo multicast para prover a realimentação para as

65
fontes do RTP assim como para todos os participantes de uma sessão. O RTCP usa o
mesmo serviço de transporte do UDP porém em porta diferente. Cada participante manda
periodicamente um pacote RTCP para todos os outros participantes da sessão. A RFC 1889
mostra quatro funções desenvolvidas pelo RTCP:

Controle de Qualidade de Serviço e Congestionamento: O RTCP provê uma realimentação

da Qualidade de Serviço de distribuição. Por causa dos pacotes RTCP serem enviados em
multicast, todos os membros da sessão podem acessar os dados de quão boa está as
conexões dos companheiros. Os relatórios do receptor indicam qualquer problema
encontrado por receptores, incluindo pacotes faltando e jitter excessivo. Por exemplo, uma
aplicação áudio e vídeo pode decidir reduzir a taxa de transmissão sobre links de baixa
velocidade se a qualidade apresentada não é grande o suficiente para a taxa atual. A
realimentação dos receptores também é importante no diagnóstico de falhas da distribuição.
Pela monitoração dos relatórios de toda as sessões, um gerenciador de rede pode dizer se o
problema é específico à um usuário ou mais distribuído.

Identificação: Pacotes RTCP leva uma descrição textual da fonte RTCP. Isto provê mais
informações sobre a fonte dos pacotes que o identificador randômico SSR e habilita um
usuário a associar múltiplos feixes para sessões diferentes. Por exemplo, sessões distintas
entre áudio e vídeo podem estar em progresso.

Estimativa do Tamanho da Sessão e Escala: Para atingir as duas primeiras funções, todos os
participantes mandam periodicamente pacotes RTCP. A taxa de transmissão destes pacotes
devem ser escalados para baixo à medida que o número de participantes aumente. Em uma
sessão com poucos participantes, os pacotes RTCP são transmitidos à taxa máxima de um
pacote à cada cinco segundos. A RFC 1889 inclui um algoritmo relativamente complexo no
qual cada participante limita a taxa do RTCP com base na população de participantes. O
objetivo é limitar o tráfego RTCP em menos que 5% do tráfego total da sessão.

Controle da Sessão: O RTCP provê opcionalmente informação mínima de controle da

sessão. Um exemplo é uma identificação do participante que é mostrada na interface do
usuário.

Os seguintes tipos de pacotes RTCP são definidos na RFC 1889:

Sender Report (SR)

Receiver Report (RR)

Source Description (SDES)

Goodbye (BYE)

Application Specific

66
 A figura à seguir mostra o formato desses pacotes. Cada pacote começa com uma palavra
de 32 bits contendo os seguintes campos:

Figura 4 – Pacotes RTCP

Version (2 bits): Versão atual 2

Padding (1 bit): Se setado significa que este pacote contém bytes de enchimento e é o
último desta transmissão. Neste caso, o último byte do enchimento contém o número de
bytes de enchimento.

Count (5 bits): O número de blocos de relatório de recepção contido em um pacote SR ou

RR, ou o número de fontes contidas em um pacote SDES ou BYE.

Packet Type (8bits): Identifica o tipo de pacote RTCP.

Lenght (16 bits): Contado em agrupamentos de 32 bits.

Em adição, os pacotes RR e SR contém os seguintes campos:

Synchronization Source Identifier: Identifica a fonte do pacote RTCP.

Vamos agora descrever cada tipo de pacote:

(A) Sender Report (SR):

Os receptores RTCP provêem uma realimentação da qualidade usando um pacote Sender

Report (SR) ou Receiver Report (RR), dependendo se o receptor é também um transmissor
durante esta sessão. A Figura 10.22a mostra o formato de um pacote SR. O campo Sender
Information Block inclui os seguintes campos:

NTP Timestamp (64 bits): Este campo é usado para, em combinação com os timestamps
retornados dos relatórios de recepção para medir o tempo de percurso entre esses
receptores.
RTP Timestamp (32 bits): Este campo é usado para criar timestamps em pacotes de dados
RTP.
Senders Packet Count (32 bits): Número total de pacotes RTP transmitidos pelo transmissor
nesta sessão.
Senders Object Count (32 bits): Número total de octetos de payload transmitidos pelo
transmissor nesta sessão.

67
 Seguindo o bloco de informação do transmissor existem zero ou mais blocos reception
report. Um bloco é incluído para cada fonte em que este participante tenha recebido dados
durante esta sessão. Cada bloco desses possui os seguintes campos:

SSRC_n (32 bits): Identifica a fonte referida por este bloco de relatório.

Fraction Lost (8 bits): A fração de pacotes de dados RTP desta fonte perdidos desde que o
pacote SR ou RR imediatamente anterior foi transmitido.

Cumulative Number of Packets Lost (24 bits): Número total de pacotes RTP desta fonte
perdidos desde o início desta sessão.

Extended Highest Sequence Number Received (32 bits): Os 16 bits menos significativos
contém o maior número de seqüência dos pacotes RTP recebidos desta fonte. Os 16 bits
menos significativos mostra o número de vezes que o número de seqüência foi resetado.

Interarrival Jitter (32 bits): Contém uma estimativa do jitter experimentado pelos pacotes
RTP nesta sessão.

Last SR Timestamp (32 bits): Contém o último Timestamp do Bloco SR recebido da

fonte.

Delay Since Last SR (32 bits): O delay, expresso em frações de 2-16 segundos, entre a
recepção do último SR da fonte n e a transmissão deste relatório.

(B) Receiver Report

O formato dos pacotes RR é o mesmo que o SR, exceto que o campo Packet Type possui
outro valor e não há informações de transmissor.

(C) Source Description:

O pacote Source Description (SD) é usado por uma fonte para prover mais informações
sobre si. O pacote consiste de um header de 32 bits seguido de zero ou mais comandos,
cada um dos quais contém informações de descrição da fonte.

(D) Goodbye
O pacote BYE indica que um ou mais fontes não estão mais ativas. Isto é usado pelos
receptores para deixar de contar o silêncio dessas fontes como falha de comunicação.

(E) Application Defined Packet

Este pacote tem caráter experimental.

68
 UNIDADE 7

MGCP – Media Gateway Control

Protocol

1. Introdução

O protocolo MGCP está ainda nos estágios de Internet Draft. A versão atual é a 0.1 e
engloba as especificações do SGCP (Simple Gateway Control Protocol) e do IPDC
(Internet Protocol Device Control).

O seu propósito é controlar os Gateways de Telefonia com Elementos de Controle de

Chamadas Externas, conhecidos como Agentes de Chamadas (Call Agents) ou Media
Gateway Controlers (MGC). Os Gateways de Telefonia provêm as operações de
conversão entre os sinais de áudio usados em circuitos telefônicos e em circuitos de pacotes
(usados na Internet ou em qualquer outra rede de pacotes).

O MGCP está de acordo com diversos tipos de Gateway, alguns são mostrados na Figura 1.
O Gateway de Entroncamento (Truncking Gateway) opera em uma rede de telefonia
convencional e uma rede de VoIP (Voice over IP). O Gateway Residencial opera entre um
usuário tradicional de telefonia (com interface RJ-11) e a rede de VoIP. O Gateway ATM
atua de certa forma como um Gateway de Entroncamento, exceto que as informações são
trocadas com uma outra rede de pacotes (no caso o ATM) e a rede VoIP. O Gateway de
Acesso provê interfaces analógicas ou digitais para um PABX dentro de uma rede VoIP.

69
 Figura 1 – Tipos de Gateway MGCP
G
a
t
e
way
d
eE
nt
r
on
ca
m
en
t
o

T
EL
C
O
V
o
I
P
B
A
C
KB
O
NE

G a te w a y d e A c e sso

PABX

V o IP

G
a
t
e
way
R
es
i
de
nc
i
al

L
O
CA
L
V
o
I
P
L
O
OP

G
a
t
e
way
A
TM

R
E
D
E
V
o
I
P
A
T
M

70
 O MGCP assume a tarefa de ser a inteligência das operações de controle de chamada e
reside em um elemento externo, conhecido como Agente de Chamadas. Isto não significa
que os Gateways sejam completamente desprovidos de inteligência. Na verdade, a maior
parte das operações de controle são feitas pelo Agente de Chamadas. Na Figura 2, o Agente
de chamadas controla três Gateways. A mesma figura mostra que os Agentes de Chamadas
se comunicam entre si. O MGCP define as operações entre os Agentes e os Gateways, mas
não define as operações entre os Agentes de Chamadas.

Figura 2 – Os Agentes de Chamadas e os Gateways

G
a
te
wa
y

G
a
te
wa
y

Ag
en
t
e
d
e Ag
en
t
e G a
t
ewa
y
C
h
ama
das d
e
C
h
ama
das

O MGCP é baseado no método orientado à conexão. Estas conexões são estabelecidas

entre os pontos finais. Estes pontos finais podem ser físicos ou virtuais. Um exemplo de
ponto final físico é uma conexão à um nó físico ou à um tronco. Um ponto final virtual é
um módulo de software rodando em um ponto final físico.

2. Relação entre o MGCP e o H.323

O relacionamento do MGCP com o H.323 é mostrado na figura 3. Na verdade, o MGCP

não é dependente da arquitetura H.323, mas se esta for implementada, o Agente de
Chamadas MGCP age como um Gatekeeper H.323. Isto se dá, por causa das funções
semelhantes desempenhadas pelo Gatekeeper H.323 e do Agente de Chamadas (MGC)
do MGCP, pois ambos provêm translação de endereço e serviços de controle de chamada
dos pontos finais H.323.

71
 Figura 3 – Relação entre H.323 e MGCP

MGCP MGCP
Call Agent Gateway
Terminal MCU
H.323 H.323
LAN

Gatekeeper Gateway Terminal Terminal

H.323 H.323 H.323 H.323
an el
Ch ann
l
ne

el Ana
Ch

nn log
Cha ne
l
ID N D

N B h an Q.
D

C 29
ISD ISU
GS
D

S0 31
LC

/LS

UN
IS

CD

DS0
L P
ID

I
Digital Analog
Telco
Local ATM Local
Backbone
Loop Loop
Canais de Sinalização
Canais de Suporte ao Serviço

Neste exemplo o Agente de Chamadas MGCP/Gateway H.323 mantém operações de

sinalização com 4 redes diferentes. Estas quatro redes mostram sua associação lógica de
sinalização com a rede MGCP, estas associações não dependem, em alguns casos do aceite
do mercado, especialmente para LECs (Local Exchange Control) do acesso baseado no IP.

Para melhor entender a figura, as linhas contínuas indicam os links de sinalização e as

linhas tracejadas os links de tráfego. Em alguns casos de interfaces de rede, esses dois links
podem compartilhar o mesmo link físico.

Vamos examinar as interfaces de sinalização primeiro. No caso de uma conexão entre uma
Rede de Acesso Digital e um Terminal Remoto Digital (RDT), o Agente de Chamadas
MGCP/Gatekeeper H.323 utiliza o canal D (com Q.931 operando sobre o canal D). No
caso de conexão com a Planta Telefônica (TELCO) o Agente de Chamadas
MGCP/Gatekeeper H.323 trocam mensagens ISUP (SS7) com os STP (Signalling
Transfer Point). Com uma rede ATM as mensagens trocadas são Q.2931, etc.

Considerando o tráfego de usuário (linhas tracejadas na figura 3), o Gateway

MGCP/Gateway H.323 manipula o tráfego do usuário e provê as translações necessárias.
DS0 com a planta TELCO, UNI com o ATM, links analógicos ou B para a planta de
acesso.

Estas quatro interfaces não são as únicas. Não estão incluídas as interfaces wireless fixas e
móveis, ou redes coaxiais (HFC). Em linhas gerais isso expõe as relações entre a
arquitetura H.323 e a MGCP. Porém um fato à mais merece explicação:

72
 O objetivo do MGCP é atuar como um protocolo interno em sistemas distribuídos, para
que quem olhar de fora enxergue o todo como um único Gateway VoIP. O sistema possui
Agentes de Chamadas e Gateways que se interfaceiam de um lado com o sistema telefônico
e do outro com o sistema em conformidade com o H.323. Desta forma, o Agente de
Chamadas deve convergir os protocolos ISUP e outros (de fora) para protocolos H.323
(H.225.0/RAS, H.245 e Q.931). Isso é mostrado na Figura 4.
Figura 4 – Visão externa da Rede VoIP

Gateway VoIP Único

Agentes de Chamadas
H.323 e Telco
Gateways

3. Comandos MGCP

O MGCP possui 8 comandos, que são divididos em duas classes:

Os comandos para API (Application Programming Interface) dos softwares de aplicação no

Agente de Chamadas e nos Gateways

Os comandos trocados entre o Agente de Chamadas (MGC) e os Gateways. Ver figura 5.

73
 Figura 5 – API e MGCP

Call Agent Gateway

User User
Application Application
A A
P P
I I

MGCP MGCP
Mensagens
MGCP

Os Comandos do MGCP são listados abaixo:

NotificationRequest (RQNT): O Agente de Chamadas prepara o gateway para observar

eventos específicos, tais como atividade de um Ponto Final especificado.

Notify (NTFY): O Gateway responde ao Agente de Chamadas com este comando quando o
evento especificado ocorrer.

CreateConnection (CRCX): O Agente de Chamadas solicita a criação de uma conexão que

termina em um ponto final especificado no Gateway.

ModifyConnection (MDCX): O Agente de Chamadas solicita este comando para mudar os

parâmetros associados `a uma conexão previamente estabelecida.

DeleteConnection (DLCX): O Agente de Chamadas solicita este comando para eliminar

uma conexão existente. Este comando também pode ser usado por um Gateway para
informar ao Agente de Chamadas que uma conexão não pode mais ser sustentada.

AuditEndpoint (AUEP) e AuditConnection (AUCX): O Agente de Chamadas solicita

esses comandos para checar o status de um Ponto Final e quaisquer conexões associadas à
ele e chamadas em andamento.

RestartInProgress (RSIP): O Gateway usa este comando para notificar ao agente de

Chamadas que o Gateway (ou grupo de Pontos Finais) estão sendo tirados ou sendo
retornados ao estado de serviço.

74
(A) Particularidades do MGCP

1. Observe que o MGCP não define nenhuma mensagem para que o Agente de Chamadas e
o Gateway estabeleçam o tipo de relacionamento entre si, tais como troca de autenticações,
e parâmetros de configuração. Na verdade, antes do MGCP ser usado, outro protocolo é
responsável pela execução desses procedimentos. Este protocolo é conhecido como IPDC
(IP Device Control). Este protocolo será visto no fim deste trabalho.

2. Os parâmetros passados na API são similares aos parâmetros carregados nas mensagens
entre o Agente de Chamadas e o Gateway. No entanto eles não são os mesmos, por
exemplo, a NotificationRequest na API define oito parâmetros para esta chamada, mas
apenas um é requerido ser transportado pela mensagem ao outro nó. Para explicar de
maneira coerente e mostrar as relações entre a API e as mensagens, vamos a partir de agora:

 Descrever cada parâmetro que é carregado pela API e o Conjunto de Mensagens,

 Mostrar cada comando API e os parâmetros associados,

 Mostrar cada mensagem e os parâmetros associados.

4. Parâmetros do MGCP

Os parâmetros estão presentes na API e/ou nas Mensagens MGCP. A melhor forma de
estudar este item é estudá-lo e depois usá-lo como referência para os próximos itens. Os
parâmetros estão descritos pela ordem alfabética:

CallID: Parâmetro global e único que identifica a chamada originadora da conexão.

ConnectionID: Valor retornado pelo Gateway durante a criação de uma conexão. Ele
identifica a conexão entre pontos finais.

ConnectionIdentifiers: Uma lista de Identificadores de Conexão existentes em um Ponto

Final.

ConnectionParameters: Um termo geral para descrever uma lista de parâmetros de uma

conexão.

DetectEvents: Durante o período de quarentena, uma lista com os eventos que forem
detectados.

DigitMap: Um método para coletar dígitos de acordo com o plano de numeração.

75
EndPointID: O nome do Ponto Final no Gateway.

EndPointIdList: Lista de todos os EndPointIDs.

LocalConnectionDescriptor: Um descritor da conexão associada pelo Gateway. Ela contém

endereços e portas RTP usadas.

LocalConnectionOptions: Usado pelo Agente de Chamadas para direcionar o gateway para

as conexões que se deseja manipular.

Mode: Define o modo de operação para este lado da conexão.

NotifiedEntity: Especifica para onde os comandos Notify ou DeleteConnection foram

transmitidos, default é o originador do comando CreateConnection.

ObservedEvents: Lista dos eventos detectados pelo Gateway.

QuarantineHandling: Em mensagens de Notificação os Gateways podem receber uma lista

de eventos que eles devem observar e monitorar. Este estado é conhecido como
Quarentena.

ReasonCode: Indica a razão da desconexão.

RemoteConnectionDescriptor: Descritor das conexões em andamento nos Gateways.

RequestEvents: Lista de eventos que o Gateway é requisitado para direcionar e reportar ao

Agente de Chamadas. Regras detalhadas estipulam como os eventos são manipulados no
Gateway e como/quando/onde/se são reportados ao Agente de Chamada. Exemplos desse
parâmetro são: (a) dígitos discados acumulados, (b) eventos ignorados, (c) notificar o
Agente de Chamadas imediatamente do evento (notificação de delay), (d) manter sinal
ativo, etc.

RequestInfo: Informação que é requisitada com uma ConnectionID dentro de um ponto

final. Este campo pode conter: CallID, NotifiedEntity, LocalConnectionOptions, Mode,
RemoteConnectionDescriptor, LocalConnectionDescriptor e ConnectionParameters.

RequestIdentifier: Um valor único que identifica uma requisição.

RestartDelay: O número de segundos antes de uma operação de restart ser atendida. O

valor é randomicamente sorteado de forma a reduzir as chances de várias máquinas
restartarem ao mesmo tempo.

RestartMethod: Codificado, forçado ou atrasado.

SignalRequests: Conjunto de sinais que o Gateway deve aplicar para o ponto final, tal
como chamando (ringing), fora do gancho, tom contínuo, etc.

SuportedModes: Lista os modos suportados.

76
5. Comandos da API e os Parâmetros Associados

(A) NotificationRequest
Comando e Parâmetros Associados: A estrutura do comando NotificationRequest é como
segue:

NotificationRequest ( EndPointID,
NotifiedEntity,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests,
QuarantineHandling,
DetectEvents, )

Comentário: O gateway deve mandar uma mensagem para o Agente de Chamadas na

ocorrência dos eventos especificados neste comando. Muitos eventos podem ser
identificados. Como exemplos, fora do gancho, tipo de sinal de modem Série V do ITU-T,
etc. podem ser identificados como eventos que o Agente de Chamadas deseja saber.

(B) Notify
Comando e Parâmetros Associados: A estrutura do comando Notify é como segue:

Notify ( EndPointID,
NotifiedEntity,
RequestIdentifier,
ObservedEvents, )

Comentário: O parâmetro ObservedEvents é uma lista de eventos que o Gateway tem

observado. Esta lista deve conter apenas os eventos que estavam nos parâmetros
RequestedEvents do NotificationRequest. Ele pode conter eventos acumulados, e eventos
de que atingimos o número de dígitos especificado no mapa de dígitos.

77
(C) CreateConnection
Comando e Parâmetros Associados: A estrutura do comando CreateConnection mandado
pelo Agente de Chamadas é como segue:

CreateConnection (CallID,
EndPointID,
[NotifiedEntity]
LocalConnectionOptions,
Mode,
RemoteConnectionDescriptor,
RequestedEvents,
RequestIdentifier,
DigitMap,
SignalRequests,
QuarantineHandling,
DetectEvents,)

Comentário: O parâmetro LocalConnectionOptions descreve do ponto de vista do

Gateway relativamente ao seguinte (a) método de codificação do tráfego, (b) período de
empacotamento (duração do pacote), (c) banda para a conexão (em kbps), (d) tipo de
serviço (campo TOS do datagrama Ipv4), (e) uso de cancelamento de eco.
O Gateway responde ao comando CreateConnection retornando um ConnectionID que
identifica a conexão dentro de um ponto final. Além disso é retornado um
LocalConnectionDescriptor.

(D) ModifyConnection
Comando e Parâmetros Associados: A estrutura do comando ModifyConnection
mandado pelo Agente de Chamadas é como segue:

ModifyConnection ( CallID,
EndPointID,
ConnectionID,
NotifiedEntity,
LocalConnectionOptions,
Mode,
RemoteConnectionDescriptor,
RequestedEvents,
RequestIdendifier,
DigitMap,
SignalRequests,
QuarantineHandling,
DetectEvents, )

78
Comentário: Este comando pode ser usado para prover informação sobre a outra ponta da
conexão, através do RemoteConnectionDescriptor. Também pode ser usado para ativar ou
desativar uma conexão. Esta operação ocorre pela mudança do valor do parâmetro Mode.
Outras operações podem ser modificadas, por exemplo, cancelamento de eco, atraso de
empacotamento.

a) DeleteConnection pelo Agente de Chamadas

Uma conexão pode ser deletada pelo Agente de Chamadas ou pelo Gateway, vamos
inicialmente ver o caso dela ser feita pelo Agente de Chamadas.

Comando e Parâmetros Associados: A estrutura do comando DeleteConnection originado

pelo Agente de Chamadas é como segue:

DeleteConnection ( CallID,
EndPointID,
ConnectionID,
NotifiedEntity,
RequestedEvents,
RequestIdendifier,
DigitMap,
SignalRequests,
QuarantineHandling,
DetectEvents, )

Comentários: Se dois Gateways estão envolvidos em uma conexão, este comando é

mandado para ambos. Uma vez recebido este comando, o Gateway responde com uma lista
de parâmetros (estatísticas) que descrevem o que aconteceu com a conexão. As seguintes
informações são mandadas ao Agente de Chamadas pelo Gateway:

 Número de Pacotes Transmitidos: O número total de pacotes RTP mandados

pelo Gateway desde que a conexão iniciou.

 Número de Octetos Transmitidos: Número total de Octetos do RTP (Apenas

tráfego de usuário, header não incluso) mandados pelo Gateway desde que a
conexão iniciou.

 Número de Pacotes Recebidos: O número total de pacotes RTP recebidos pelo

Gateway desde que a conexão iniciou.

 Número de Octetos Recebidos: Número total de Octetos do RTP (Apenas

tráfego de usuário, header não incluso) recebidos pelo Gateway desde que a
conexão iniciou.

79
  Número de Pacotes Recebidos: Número total de pacotes RTP perdidos pelo
Gateway desde o começo da conexão.

 Jitter entre chegadas: Uma estimativa da variância do tempo entre chegadas

dos pacotes RTP, expressado em milissegundos.

 Delay Médio de Transmissão: Uma estimativa do delay médio da rede,

expresso em milissegundos.

b) DeleteConnection pelo Gateway

Uma conexão pode ser deletada pelo Gateway mas somente se um problema ocorrer, tais
como a perda de uma interface de tronco. Em situação normal a conexão só pode ser
deletada pelo Agente de Chamadas.

Comando e Parâmetros Associados: A estrutura do comando DeleteConnection originado

pelo Gateway é como segue:

DeleteConnection ( CallID,
EndPointID,
ConnectionID,
NotifiedEntity,
ReasonCode,
Connection-parameters, )

(E) AuditEndpoint

Comando e Parâmetros Associados: A estrutura do comando AuditEndpoint originado

pelo Agente de Chamadas é como segue:

AuditEndpoint ( EndPointIdList,
NotifiedEntity,
Requested\Events,
DigitMap,
SignalRequests,
RequestIdentifier,
NotifiedEntity,
ConnectionIdentifiers,
DetectEvents,
LocalConnectionOptions,
SuportedModes, )

80
 Comentário: Este comando permite que o Agente de Chamadas audite um ou mais pontos
finais. O Gateway é responsável por retornar ao Agente de Chamadas informações sobre o
evento requisitado, o mapa de dígitos sendo usado, qualquer sinal que esteja sendo aplicado
no ponto final, etc.

(F) AuditConnection

Comando e Parâmetros Associados: A estrutura do comando AuditConnection originado

pelo Agente de Chamadas é como segue:

AuditConnection ( CallID,
NotifiedEntity,
LocalConnectionOptions,
Mode,
SignalRequests,
RemoteConnectionDescriptor,
LocalConnectionDescriptor,
ConnectionParameters, )

Comentário: Este comando é similar ao AuditEndpoint, exceto que é usado para auditar
uma conexão específica.

(G) RestartInProgress

Comando e Parâmetros Associados: A estrutura do comando RestartInProgress originado

pelo Agente de Chamadas é como segue:

RestartInProgress ( EndPointID,
RestartMethod,
RestartDelay, )

Comentário: O EndPointID identifica um ou mais pontos finais que estão sendo tirados fora
de serviço. O RestartMethod pode ser normal quando nenhuma conexão entrante estiver
com problemas, ou pode ser forçada, na ocorrência de problemas, neste caso as conexões
serão perdidas.

81
6. Mensagens MGCP e Parâmetros Associados

Como temos visto o Agente de Chamadas e os Gateways trocam oito tipos de mensagens
MGCP, e temos discutido sobre eles em termos gerais. As mensagens são Conhecidas como
Comandos quando transmitidos para o Gateway e Respostas quando transmitidas pelo
Gateway.

A Figura 6 mostra o formato da mensagem MGCP. As mensagens são codificadas como

linhas de texto consistindo de um header com o comando, seguido por uma descrição de
sessão. O header de comando é composto de uma linha de comando e um conjunto de
parâmetros de linha. Linhas de texto são separadas por um caracter de line feed. Os itens da
mensagem são strings ASCII imprimíveis, separadas por um caracter de espaço (0x20) ou
caracter de tabulação (0x09).

A linha de comando contém 4 campos: (a) o identificador da mensagem (conhecido como

ação), (b) o número de transação, (c) os pontos finais sobre os quais o comando é
requisitado, e (d) o número de versão do protocolo.

Figura 6 – Estrutura dos Comandos MGCP

Verb TransactionNumber Endpoint Version Command Line

ParameterName: ParameterValue
ParameterName: ParameterValue Parameters Line
etc.
As linhas de parâmetros são formadas do nome do parâmetro, dois pontos, espaço, seguida
do valor do parâmetro. A tabela 1 mostra os códigos reservados para os parâmetros dos
comandos e respostas do MGCP.

82
 Tabela 1 – Parâmetros MGCP e seus Códigos

Parameter name Code Parameter value

CallId C Hexadecimal string, at most 32
characters
ConnectionId I Hexadecimal string, at most 32
characters
NotifiedEntity N An identifier, in RFC 821 format,
composed of an arbitrary string and of
the domain name of the requesting
entity, possibly completed by a port
number, as in:
Call-agent@ca.example.net:5234
RequestIdentifier X Hexadecimal string, at most 32
characters
LocalConnectionOptions L See description
Connection Mode M See description
RequestedEvents R See description
SignalRequests S See description
DigitMap D A text encoding of a digit map
ObservedEvents O See description
ConnectionParameters P See description
ReasonCode E An arbitrary character string
SpecificEndpointID Z An identifier, in RFC 821 format,
composed of an arbitrary string,
followed by an "@" followed by the
domain name of the gateway to which
this endpoint is attached.
RequestedInfo F See description
QuarantineHandling Q See description
DetectEvents T See Description
RestartMethod RM See description
RestartDelay RD A number of seconds, encoded as a
decimal number

Abaixo mostramos a estrutura de uma mensagem MGCP:

Line 1 RQNT 4561 endpoint-44@tgw-21.infoinst.com MGCP 0.1

Line 2 N: abc@cal.infoinst.com:5777
Line 3 X: 45848484
Line 4 R: hd

83
 A Linha 1 é a linha de comando, RQNT é o comando de NotificationRequest; o número
da transação é o 4561; o endpoint direcionado é o endpoint-44@tgw-21.infoinst.com; e a
versão do MGCP é a 0.1.

A linha 2 é a NotifiedEntity de: abc@cal.infoinst.com:5777. A linha 3 é a string

hexadecimal da RequestIdentifier. A linha 4 é o código para o nome do evento transição
para fora do gancho.

Este comando está direcionando o Gateway para monitorar o evento fora do gancho no
endpoint-44 no gateway de entroncamento com sufixo de nome de domínio cal.infoinst. O
número da porta UDP é a 5777.

7. Mensagens e Parâmetros MGCP

Cada mensagem MGCP possui um código de 4 caracteres, como mostrado na tabela 2.

Tabela 2 – Códigos dos comandos MGCP

Comando Código
CreateConnection CRCX
ModifyConnection MDCX
DeleteConnection DLCX
NotificationRequest RQNT
Notify NTFY
AuditEndpoint AUEP
AuditConnection AUCX
RestartInProgress RSIP

Os comandos possuem os seguintes parâmetros conforme a tabela 3:

84
 Tabela 3 – Comandos e seus Parâmetros

Parâmetro CRCX MDCX DLCX RQNT NTFY AUEP AUCX RSIP

CallID M M O F F F F F
ConnectionID F M O F F F M F
RequestIdentifier O O O M M F F F
LocalConnectionsOpt O O F F F F F F
ions
ConectionMode M M F F F F F F
RequestedEvents O O O O F F F F
SignalRequests O O O O F F F F
NotifiedEntity O O O O O F F F
ReasonCode F F O F F F F F
ObservedEvents F F F F M F F F
DigitMap O O O O F F F F
Connection F F O F F F F F
Parameters
SpecificEndpoint F F F F F F F F
ID
RequestedInfo F F F F F M M F
Quarantine O O O O O F F F
Handling
DetectEvents O O O O O F F F
RestartMethod F F F F F F F M
RestartDelay F F F F F F F O
RemoteConnectionD O O F F F F F F
escriptor

Onde M=Mandatory, O=Optional e F=Forbiden.

A tabela 4 mostra as Respostas MGCP e seus Parâmetros.

85
 Tabela 4 – Respostas e seus Parâmetros

Parâmetro CRCX MDCX DLCX RQNT NTFY AUEP AUCX RSIP

CallID F F F F F F O F
ConnectionID O F F F F F O F
RequestIdentifier F F F F F O F F
LocalConnectionsOpt F F F F F O O F
ions
ConectionMode F F F F F F O F
RequestedEvents F F F F F O F F
SignalRequests F F F F F O F F
NotifiedEntity F F F F F F F F
ReasonCode F F F F F F F O
ObservedEvents F F F F F O F F
DigitMap F F F F F O F F
Connection F F O F F F O F
Parameters
SpecificEndpoint O F F F F F F F
ID
RequestedInfo F F F F F O F F
Quarantine F F F F F O F F
Handling
DetectEvents F F F F F O F F
RestartMethod F F F F F F F F
RestartDelay F F F F F F F F
LocalConnection M O F F F F O F
Descriptor
RemoteConnectionD F F F F F F O F
escriptor

86
8. Exemplo de Operação do MGCP

A Figura 7 apresenta um exemplo do MGCP em ação. O exemplo se baseia no SGCP,

outros exemplos podem ser conseguidos em “Media Gateway Control Protocolo (MGCP)
Call Flows”; Draft-huitema-mgcp-flows-00.txt em www.ietf.org” . Neste exemplo dois
Gateways estão envolvidos, um gateway residencial e um gateway de entroncamento. É
mostrado um base de dados comum, bem como um gateway de tarifação. Abaixo
decrevemos cada evento.

Evento 1: Um comando NotificationRequest deve ser mandado para o Gateway

Residencial antes dele poder manipular uma conexão. Este comando não é de configuração,
os Gateways e o Agente de Chamadas devem ser pré-configurados. Este comando fará com
que o Gateway seja direcionado à monitorar uma condição de fora do gancho em uma
conexão de ponto final específica.

Evento 2: O Gateway reconhece o comando. É usado o mesmo número de transação usado

no Evento 1.

Evento 3: A partir daí o Gateway fica monitorando esta transição e eventualmente o usuário
tirará o fone do gancho para iniciar uma chamada.

Evento 4: O gateway transmite um comando Notify para o Agente de Chamadas, com a

mensagem codificada para mostrar o evento de “fora do gancho” que estava sendo
monitorado no ponto final.

Evento 5: O Agente de Chamadas reconhece o comando Notify proveniente do gateway.

Evento 6: A decisão do Agente de Chamadas sobre o que dizer para o gateway dependerá
do tipo de linha monitorada, assumindo que é uma linha convencional discada, será
mandado um comando NotificationRequest direcionando o Gateway para mandar um tom
de discagem.

Evento 7: O gateway responde com ACK, e dá o tom de discar ao usuário. A seqüência

exata desses dois eventos varia, dependendo de implementação específica.

Evento 8: Baseado no Mapa de Dígitos informado no evento 7, o Gateway acumula os

dígitos discados.

Evento 9: Baseado no Mapa de Dígitos, o Gateway informa ao Agente de Chamadas uma

mensagem ObservedEvents. Esta mensagem/parâmetro contém os dígitos coletados.

Evento 10: O Agente de Chamadas reconhece o recebimento desta mensagem.

87
Evento 11: O Agente de Chamadas manda um comando NotificationRequest para que o
Gateway pare de coletar os dígitos e monitore o evento “retorna ao gancho”.

Evento12: ACK do Gateway para o Agente de Chamadas.

Evento 13: O comando CreateConnection é mandado pelo Agente de Chamadas para

capacitar o circuito entrante. Esta mensagem contém os parâmetros CallID,
LocalConnectionOptions e ConnectionMode. Lembrando que o LocalConnectionOptions é
formado de : (a) período de empacotamento em milissegundos, (b) Algoritmo de
Compressão (G.711, G.729, etc.), (c) Banda para esta conexão e (d) uso ou não de
cancelamento de eco. O parâmetro ConnectionMode é setado para receber somente.

Evento 14: o Gateway reconhece o comando. Nesta mensagem a nova conexão é

identificada (ConnectionID), assim como a descrição da sessão que será usada para receber
o tráfego de áudio. Esta descrição pode conter o endereço IP em que o Gateway deve
esperar os dados de áudio, o protocolo que será usado para transportar os pacotes (RTP), a
porta do RTP (3456), a qualidade do áudio (de acordo com a RFC 1890).

Evento 15: Agora o Agente de Chamadas deve determinar onde rotear a chamada e para
qual Gateway a conexão deve ser estabelecida. É mandado um Querry para a Base de
Dados comum para obter esta informação.

Evento 16: A informação solicitada é retornada ao Agente de Chamadas.

Evento 17: O Agente de Chamadas tem informações suficientes para mandar um comando
de CreateConnection para p Gateway Destino, que neste exemplo é um Gateway de
Entroncamento. Os parâmetros nesta mensagem espelham os parâmetros trocados nos
eventos 13 e 14. Porém com 2 diferenças básicas: (a) o EndPointID identifica a linha de
saída do gateway de Entroncamento; (b) O Parâmetro de Modo é setado para
transmitir/receber.

Evento 18: O gateway de entroncamento responde um ACK. Nesta mensagem está a

descrição da sessão, tais como seu endereço IP, sua porta e a QoS para o RTP.

Evento 19: Baseado nas informações obtidas no evento 18, o Agente de Chamadas agora
prepara uma mensagem ISUP (IAM – Initial Address Message) e manda para o gateway de
entroncamento. Este Gateway encaminha esta mensagem para um LEC (Local Exchange
Carrier). Este é o trabalho do Agente de Chamadas para correlacionar os pontos finais
MGCP aos CIC da SS7. Algumas informações obtidas nos eventos de 1 à 18 são usadas
para auxiliar a formação da IAM. Por exemplo, número do chamado e do chamador,
cancelamento de eco, chamadas internacionais, ISUP usado fim-a-fim e outros campos
alocados na mensagem.

Evento 20: A informação obtida no evento 18 é usado para criar o comando

ModifyConnection que é enviado para o Gateway Residencial. Os parâmetros neste
comando refletem os comandos ACK do evento 18.

Evento 21: O Gateway reconhece o comando ModifyConnection.

88
Evento 22: A LEC retorna uma mensagem ACM (Address Complete Message) ISUP ao
Agente de Chamadas. Esta mensagem contém campos (indicador de chamada para trás)
para ajudar o Agente de Chamadas no direcionamento do Gateway Residencial, como
veremos no próximo evento.

Evento 23: O recebimento do ACM pelo Agente de Chamadas precipita o envio do

comando NotificationRequest ao gateway residencial. Esta mensagem direciona o gateway
para colocar um tom de alerta na linha.

Evento 24: O Gateway reconhece o comando e coloca o tom de alerta na linha de acesso.

Evento 25: Quando o chamado atende na ponta distante, uma mensagem ISUP (ANM –
Answer Message) é retornada para o Agente de Chamadas.

Evento 26: O Agente de Chamadas manda um comando NotificationRequest para o

gateway residencial para remover o tom de alerta da linha.

Evento 27: O Gateway remove o tom de alerta e reconhece o comando.

Evento 28: Neste ponto, a conexão na ponta local está no modo de apenas recebimento.
Para modificar a conexão para o modo full-duplex, o Agente de Chamadas manda um
comando ModifyConnection ao Gateway.

Evento 29: O Gateway responde, e manda de volta um ACK. A conexão é então

estabelecida.

Evento 30: Neste exemplo, o chamado desliga antes, e esta condição gera uma mensagem
ISUP (REL – Release Message), que é enviada para o Agente de Chamadas.

Evento 31: O Agente de Chamadas manda um comando DeleteConnection para ambos os

Gateways. Cada mensagem contém o respectivo EndPointID e ConnectionID e CallID.

Evento 32: Os Gateways respondem com o campo de performance de dados.

Evento 33: A linha local é colocada no gancho pelo usuário local.

Evento 34: O evento no gancho gera uma mensagem de Notify para o Agente de
Chamadas.

Evento 35: ACK do Agente de Chamadas.

Evento 36: O Agente de Chamadas “reseta” o ponto final, colocando este para monitorar a
condição de transição “fora do gancho”.

Evento 37: ACK.

89
 RGW Tarifação TGW LEC
Usuário RGW Base de Tarifação TGW LEC
Usuário MGC Dados Base de
MGC Dados

Notification
Request 1
REL
ACK 2 REL 30

Offhook Delete 31
3 Connection
Notify 4 ACK Delete 31
Dialtone Connection
4 performance 32
ACK 5 ACK
Offhook
Notification
33 performance 32
Request 6
Notify 34
ACK 7
Digits ACK 35
8
Notify 9 Notification 36
Request
ACK 10 ACK
Notification 11
Request
ACK 12

Create 13
Connection
ACK 14
QUERRY 15

Response 16

Create 17
ACK Connection
18
IAM 19
Modify 20
Connection
ACK 21
ACM 22

Modify 23
Connection
ACK 24
ANM 25

Notification 26
Remove Request
27 ACK 27
Ringing
Modify 28
Connection
ACK 29

90
 UNIDADE 8

Técnicas de Compressão de Voz

e Controle de Tráfego Multimídia

1. Propriedades do Sinal de Voz

Tradicionalmente, a voz para conversação é transmitida em um par trançado com banda

passante de 3,4 kHz. A fim de digitalizar este sinal, a forma de onda analógica é
primeiramente amostrada na taxa de 8kHz (teorema de Nyquist), depois é quantizada e
compandida em 8 ou 16 bits pela técnica PCM (Pulse Code Modulation). O resultado desta
técnica é um feixe de bits com taxa de 64kbps (para 8 bits/amostra x 8000 amostras/s) ou
128kbps (para 16 bits/amostra x 8000 amostras/s), o que é uma taxa extremamente elevada.

Especificamente, para sinais com banda passante de 3,4kHz e com uma relação sinal-ruído
(SNR) de 30dB (o que corresponde à uma qualidade muito boa, isto é, qualidade de
trabalho), e assumindo um canal com ruído branco gaussiano aditivo (AWGN), a taxa
binária necessária (C), baseado no Teorema da Capacidade do Canal de Shannon, é dado
por:

C=W.log2[1+(P/G)]

Onde W é a banda passante e P/G é o SNR. A equação acima mostra que a taxa de bit
teórica requerida para atingir a performance requerida é de apenas 34kbps. Isso eqüivale à
uma redução por um fator de 3 (no caso de amostras de 16 bits) ainda é muito alta mesmo
para os sistemas de telecomunicações modernos. O limite apontado por Shannon de 34kbps

91
é na verdade o valor limite para atingirmos o nosso objetivo sem que retiremos as
redundâncias do sinal à ser transportado pelo canal. Usando técnicas como a predição
linear, e eliminando as redundâncias de longa duração e de pequena duração podemos
alcançar taxas ainda menores.

É importante que se tenha um bom entendimento das propriedades do sinal de voz de forma
à compreender como funcionam os codificadores de voz (VOCODER). As propriedades da
voz de que nos referimos tem a ver com as suas características no domínio do tempo e da
freqüência, assim como a forma que o ser humano à percebe.

As características da voz no domínio do tempo pode ser dividida em períodos com sinal e
períodos de silêncio. Os períodos de silêncio(ausência de voz) são aperiódicos e possuem
uma aparência de ruído. O fato de que os períodos de silêncio terem o formato de ruído é
que se o substituirmos por uma fonte de ruído (gaussiano por exemplo), o ouvido humano
não é capaz de sentir a diferença. O períodos com sinal de voz, por outro lado é periódico e
tem correlações de longa e pequena duração. As correlações de pequena duração implicam
na ocorrência de redundâncias entre uma amostra e outra. Enquanto as correlações de longa
duração implicam em periodicidade (ou seja, uma similaridade entre ciclos de amostras.
Ambas as formas de redundância podem ser removidas, usando predictors de longa e curta
duração. A Figura 1 mostra um diagrama em blocos típico de um VOCODER.

Figura 1 – Diagrama em blocos Típico Usado em VOCODERS

As características no domínio do tempo estão relacionadas com as freqüências de formação,

que são as freqüências de ressonância do sistema do trato vocal, elas estão normalmente
localizadas abaixo de 4 kHz. Esta é a região onde a maior parte da energia da voz está
concentrada. Os VOCODERS de formação procuram estas freqüências e usam elas para
codificar as suas característica, enquanto o decodificador sintetiza a voz baseado nestas
informações. Isto serve para melhorar a qualidade da voz usando algoritmos de compressão
comuns.

92
 A última característica importante está relacionada com a forma com que o ser humano
percebe os sinais de voz. Neste caso o ouvido é suscetível ao que é conhecido como
mascaramento espectral. Isto é, um sinal pode ser feito inaudível para o ouvido humano se
for mascarado por outro sinal de mais alta energia, na mesma faixa de freqüência.

(A) Atributos de um Codificador de Voz

Os Codificadores de voz possuem uma série de atributos, alguns deles são conflitantes. Por
isso eles são normalmente otimizados de acordo com as necessidades do uso, porém os
atributos mais importantes estão descritos abaixo.
a) Taxa de Bit
A redução da taxa binária é a motivação primária dos codificadores de voz, Muitos padrões
existentes, incluindo o G.729 (8kbps), especificam uma taxa fixa de compressão. A taxa
requerida de bits/s é função normalmente do canal utilizado e da aplicação envolvida. Por
exemplo, para aplicações de satélite e telefonia celular as taxas variam de 3,3 à 13kbps,
para aplicações de telefonia fixa de propósito gera esta taxa fica em torno de 16kbps, ou
acima.
b) Qualidade da Voz
A qualidade da voz é um atributo vital dos codificadores. A maior dificuldade aqui é
encontrar critérios objetivos que a correlacionem bem para uma variedade de codificadores
e sinais de entrada. Teste subjetivos como os de Contagem Média de Opiniões (MOS –
Mean Opinion Score), onde diferentes grupos de ouvintes treinados e não treinados são
argüidos para caracterizar conjuntos de expressões numa escala que vai de 1 (qualidade
inaceitável) à 5 (qualidade excelente). Em testes como este uma média de 4 ou acima é
considerada como qualidade de trabalho, o que significa que a comunicação reconstruída é
indistingüível da comunicação original.
c) Delay
O Delay é importante especialmente para comunicações em tempo real full duplex. O
limiar de delay é dependente da natureza da aplicação. Por exemplo para conversação com
alto grau de interatividade, um delay acima de 150ms pode ser percebida como um
incômodo. Por outro lado em conversação normal um delay de 400 a 500ms pode ser
tolerada sem grande degradar a performance geral do sistema. Se não implementamos
cancelamento de eco, um delay na faixa de 100ms já produz um efeito incômodo (eco).

O delay de Codificação é normalmente dividido em quatro componentes. O primeiro é o

delay do algoritmo adotado, que é o delay para acumular um certo número de amostras para
que possamos processar a informação (o G.729 tem um algoritmo que possui um delay de
15ms). O segundo componente é o delay de transmissão, que é o atraso para que possamos
transmitir um quadro em particular. O terceiro componente é devido à multiplexação, no
caso de tratamento de múltiplos canais (pois são tratados em fila de maneira serial). O
quarto e último componente é o tempo de processamento (característica do processador
usado, e do software criado). Estes delays aparecem na codificação e na decodificação.

93
 d) Sensibilidade à Erros no Canal (Robustez)
Os erros no canal são divididos em dois tipos. O primeiro são os erros randômicos
(normalmente relacionados com o ruído do canal). Estes são normalmente especificados
pela taxa de erro de bit (BER) e são limitados à cerca de 1%. Para controlar este tipo de
erro basta conseguir atingir a correta relação sinal-ruído. Podemos ainda fazer uma
codificação de canal (não confundir com a codificação de voz, que é uma codificação de
fonte) incluindo redundâncias que melhoram a relação sinal ruído do sistema. O problema
desta técnica é o aumento da taxa de transmissão no canal, pela adição de overhead. O
segundo tipo de erro é conhecido como erro de burst, que são muito comuns em aplicações
móveis principalmente devido ao fading (desvanecimento). Para se resguardar deste tipo de
erro um sistema de detecção comum é a inclusão de um bit de paridade à cada 80 bits
codificados, estes mecanismos são de detecção de erro, pois não temos forma de corrigi-los
eficientemente, assim quando os detectamos eliminamos o quadro todo codificado, o efeito
é um hiato na comunicação normal.

2. Recomendação G.711

A recomendação G.711 é a mais conhecida de todas, e não é uma técnica VOCODER, pois
representa a forma de transformar um sinal analógico em digital, por um processo direto de
amostragem e posterior quantização (feita por um conversor analógico/digital), não vamos
entrar em detalhes nesta técnica pois ela é a base de qualquer sistema de transmissão de
voz. Apenas vamos ressalvar o fato de que para diminuir o ruído introduzido no sistema
devido à quantização, vamos fazer uma modificação do sinal entrante, conhecida como
compressão seguindo uma lei logarítmica, que para os sistemas europeus é conhecida como
lei A, e para os sistemas Americanos é conhecida como lei mu.

3. Recomendação G.726

(A) Introdução ao ADPCM

ADPCM (Adaptive Differential Pulse Code Modulation) é uma forma muito eficiente de
codificar formas de onda analógicas (como a voz). Sua principal aplicação está em
Telecomunicações na compressão de voz, porque come esta técnica é possível realizar uma
redução do fluxo de bits mantendo ainda uma qualidade aceitável. No entanto pode ser
aplicada para qualquer forma de onda (áudio de alta qualidade, imagem e modem). Ele é
diferente dos VOCODERS (tais como CELP VCELP, ACELP, etc.), porque estes usam
propriedades inerentes à voz humana para reconstruir a forma de onda do lado do receptor,
da maneira mais similar possível ao sinal original. Portanto, estas técnicas são aplicadas
necessariamente para voz humana.

94
 Consideremos um sinal original, que desejamos transformar para reduzir a taxa de bits que
iremos transmitir no canal. O princípio do ADPCM é usar o nosso conhecimento passado
do sinal para predizer o futuro, sendo que o sinal resultante da técnica é o erro entre o sinal
e a predição. Este princípio é geral e se baseia na transcodificação de um sinal previamente
codificado em PCM (Pulse Code Modulation – G.711).

Por conseguinte temos que previamente codificar o sinal em PCM (G.711) e depois aplicar
os princípios de transcodificação ADPCM (recomendação G.726). Esta recomendação faz
uso na verdade das recomendações G.721 e G.723, todas do ITU-T.

(B) Princípios do ADPCM.

As características descritas são recomendadas para a conversão de um canal PCM à 64kbps
(lei A ou lei um) para um canal ADPCM à 40, 32, 24 ou 16kbps. A conversão usando a
técnica de transcodificação ADPCM, conforme descrito na Figura 1(a) e (b).

A principal aplicação dos canais de 24 e 16kbps é para transportar sinais de voz sobre
canais de dados em equipamento de comunicação de dados (DCE). Enquanto que a
principal aplicação do canal de 40kbps é carregar informação sinais de dados modulado
(principalmente de modems acima de 4800bps) em equipamentos de comunicação de
dardos (DCE). A Figura 2 mostra um diagrama em blocos simplificado com ambos o
codificador e o decodificador ADPCM.

95
 Figura 2 – Diagrama em Blocos do Codificador e Decodificador ADPCM

a) Codificador ADPCM.
Logo após a conversão PCM (lei A ou lei um), este sinal é colocado para alimentar o
transcodificador, um sinal de diferença é obtido (pela subtração uma estimativa do sinal de
entrada do sinal de entrada propriamente dito). Um quantizador adaptativo (de 31, 15, 7 ou
4 níveis) é usado para gerar 5, 4, 3 ou 2 bits respectivamente, para o sinal de diferença para
ser transmitido para o decodificador. Um quantizador adaptativo inverso, é usado para
reconstruir o sinal original e alimentar um predictor adaptativo, que também recebe o sinal
da diferença anteriormente calculado. Esse predictor adaptativo usa estes sinais para gerar
uma nova estimativa do sinal de entrada, que será usado para gerar um novo sinal de erro à
ser transmitido.
b) Decodificador ADPCM.
O decodificador inclui uma estrutura idêntica à porção de realimentação do codificador,
juntamente com um conversor uniforme para PCM (lei A ou lei um) e um ajuste de

96
 codificação síncrona. O ajustador de codificação síncrona previne contra distorções
cumulativas que ocorrem na codificação adaptativa em tandem (ADPCM-PCM-ADPCM).

4. Recomendação G.723.1

(A) Visão geral do Algoritmo

O codificador de voz G.723.1 foi desenvolvido para fazer compressão de voz e áudio como
parte da família H.324 (que define padrões para comunicação multimídia). Este codificador
pode operar à duas taxas de bit diferentes (5,3kbps e 6,3kbps). Isto dá ao projetista do
sistema uma certa flexibilidade relativamente à qualidade da voz em relação ao nível de
complexidade do algoritmo usado. Neste padrão usamos a codificação dos quadros de voz
usando codificação preditiva linear de análise e síntese. No caso da taxa de 6,3kbps o
codificador usa o método de Quantização Multipulso por Máxima Verossimilhança
(Multipulse Maximum Likelihood Quantization - MP-MLQ) para formar o sinal excitação.
Na taxa de 5,3kbps o codificador usa a técnica de Predição Algébrica Linear do Código de
Excitação (Algebraic-Code-Excited Linear Prediction - ACELP). Para ambas as taxas, o
tempo de codificação de um quadro é de 30ms, o que é bastante grande comparativamente à
outros métodos descritos em outras recomendações.

(B) Descrição do Algoritmo

O codificador descrito no padrão G.723.1 usa o princípio de codificação preditiva linear de
análise e síntese, para minimizar a percepção do sinal de erro de codificação (é ouvido
como ruído). O codificador começa com um quadro de 30ms (240 amostras), este quadro
passa por um Filtro Passa Alta e depois é quebrado em subquadros de 4ms à 60ms. Um
filtro Codificador de Predição Linear de 10a ordem (LPC - Linear Prediction Coder) é
computado em cada subquadro. Um sinal de coeficientes do sinal de voz percebida é
calculado à partir desses coeficientes do LPC. A seguir o sinal de coeficientes da voz é
usado para computar o período de latência de malha aberta (latência unidirecional), em dois
subquadros de 120 amostras.

Todo o processamento remanescente é feito com quadros de 60 amostras. Começamos pela

computação de um filtro harmônico em forma de ruído, que é usado com o filtro de síntese
LPC para criar uma resposta ao impulso. A resposta ao impulso é usada para calcular a
predição de latência de malha fechada. O período de latência e um valor diferencial
computado no primeiro passo são passados ao decodificador. Finalmente dois métodos são
usados para computar os componentes não periódicos de excitação do decodificador. o
ACELP (para 5,3kbps) e o MP-MLQ(para 6,3kbps)

O decodificador opera com a recepção quadro à quadro. A decodificação começa com os

Coeficientes de Predição Linear, que são usados para criar o filtro de síntese LPC. A
excitação de cada subquadro é computada usando os coeficientes passados, O sinal de
excitação resultante é passado pelo pós-filtro de latência e então filtrado pelo filtro de

97
 síntese para produzir um resultado decodificado, por fim é aplicado um ganho ao sinal
resultante.

5. Recomendação G.729 e G.729/A

Esta técnica de VOCODER usa um algoritmo muito parecido com o explicado na

recomendação G.723.1, porém a diferença está no uso de estruturação conjugada (CS). O
algoritmo agora se chama CS-ACELP (Conjugate-Structure Algebraic-Code Excited
Linear Prediction). No caso do algoritmo definido na G.729 usa um feixe PCM com 8000
amostras por segundo codificado com 16 bits (G.712). Este feixe será convertido em um
sinal de 8kbps. O diagrama abaixo mostra um codificador e um decodificados típico G.729.

Figura 3 - Codificador G.729

98
 Figura 4 - Decodificador G.729

A técnica VOCODER G.729/A ( que é mais usada) usa o mesmo algoritmo mas usa como
base um feixe G.711. O feixe resultante também será de 8kbps, como no caso anterior.

99
 UNIDADE 9

Qualidade da Voz em Redes de

Pacotes

1. Latência em Telefonia IP

Com o crescimento do interesse na implementação e instalação de aplicações de Telefonia

IP, há um aumento da necessidade de se entender as causas e os efeitos da latência em
sistemas instalados. Este item descreve os efeitos da latência na conversação humana,
analisando os sistemas componentes que provocam a latência, e os métodos de
gerenciamento da latência para manter suficiente qualidade de serviço.

(A) Introdução
Quando projetamos e instalamos uma solução em Telefonia IP, muitos atributos diferentes
irão afetar a qualidade final do sistema. esses atributos incluem a correta seleção do
algoritmo de codificação (compressão) de voz (VOCODER), a latência inerente à
tecnologia dos links usados, entre outros. Assumindo que a solução de Telefonia IP para
VOCODER será um padrão, então o parâmetro mais importante para os projetistas dessas
redes é a latência, pois ela pode Ter um impacto muito grande na qualidade de serviço
desejada.

Latência é o atraso de tempo que ocorre na conversação em sistemas de Telefonia IP. A

latência é tipicamente medida em milissegundos, desde o momento em que uma palavra é

100
 pronunciada pelo usuário origem, até o momento em que o usuário destino a houve. Por
definição a latência boca-a-ouvido é conhecida como latência unidirecional, que é a
latência que os usuários percebem quando usam o sistema. A latência total é a soma das
duas latências unidirecionais (ida e volta). Em uma rede tradicional PSTN, a latência total
típica para ligações domésticas gira em torno de 150ms. Nestes níveis, a latência nem é
notada pela maioria das pessoas. Muitas chamadas internacionais (especialmente as
carregadas via satélite) tem uma latência total, que nos piores casos pode chegar à 1
segundo, o que é um incômodo para qualquer usuário.

(B) Quais são os Efeitos da Latência?

Uma conversação telefônica entre duas pessoas depende do sincronismo da fala mais do
que as pessoas podem imaginar. A maior parte das conversações incluem certas expressões
colocadas pelo ouvinte para melhorar o entendimento por parte do que está falando, são
confirmações de que o ouvinte está realmente entendendo o que está sendo dito. Ouça você
mesmo mais atentamente na próxima ligação que fizer ou atender. Observe as expressões
que você naturalmente coloca quando a outra parte esta fazendo a maior parte da fala. Se
você remover essas expressões, o que está falando irá parar e esperar pela sua
realimentação. Se você atrasar essas expressões, elas chegarão ao que está falando em um
tempo errado, causando confusão e interrupções no fluxo normal da conversação.
Experimente atrasar e parar essas expressões e veja o que acontece com a sua conversação.

(C) Quanto de Latência é Considerado Aceitável?

Como a maioria das considerações envolvendo fator humano, cada um terá a sua própria
opinião acerca dessa questão, mas baseado em experimentação feita pelos primeiros à
adotar sistemas de Telefonia IP, foi definida uma latência máxima que é tolerada pela
maioria dos usuários. O valor exato de latência tolerado pelos usuários é difícil de
determinar, porque o ser humano é capaz de se adaptar rapidamente e corrigir pequenos
aumentos de latência e degradações adicionados no sistema. Além disso a irritação devido à
latência é proporcional à diminuição dos gastos na conta telefônica.

Assumindo que um sistema de telefonia IP é primariamente usada para reduzir custos ou

bypassar centros de custos, foi desenvolvida o seguinte gráfico, que mostra a relação entre
qualidade desejada no link vs. quantidade de latência unidirecional. Outras aplicações que
exijam menor qualidade acomodarão certamente uma latência maior.
Figura 1 – Qualidade Percebida vs. Latência Unidirecional

101
 Como podemos ver o usuário começa a perceber que a qualidade do link deteriorou quando
a latência unidirecional excede a 150ms. Se a latência unidirecional exceder à 450ms, é
muito difícil de manter uma conversação. Se fosse dado uma chance de escolha, a maior
parte dos usuários preferiria que a latência unidirecional ficasse menor que 200ms.

Isto nos dá um parâmetro para projetar o nosso sistema de Telefonia IP. Mantenha a latência
unidirecional menor que 200ms. Mesmo que um sistema ofereça uma qualidade excelente
de voz a um custo muito pequeno, os usuários migrarão onde a latência não exceda demais
do que foi dito.

(D) Quais são as Causas da Latência?

Geralmente um sistema d Telefonia IP é construído usando Gateways para interfacear os
sistemas telefônicos existentes junto com a WAN (Wide Area Network). Essa instalação
típica é mostrado na figura 9,que mostra dois telefones conectados à uma WAN via
Gateways e Roteadores.

Mesmo que um sistema integre a funcionalidade do Gateway dentro dos telefones ou do

equipamento roteador o mesmo processamento básico deve ocorrer. Para todo propósito
prático, podemos visualizar que qualquer chamada usando telefonia IP requer dois
gateways, apenas a localização física deles é que muda.

Figura 2 – Sistema Típico de Telefonia IP

A latência neste sistema é introduzida por duas fontes primárias. A primeira ocorre no
próprio Gateway na formação dos pacotes IP e na Compressão da voz e na Descompressão
da mesma, além da latência devido à bufferização para eliminar o jitter. A Segunda fonte
está na rede WAN (rede IP), que está relacionada com a tecnologia usada nos links e na
capacidade de processamento dos Roteadores.

Desde que a latência é cumulativa, a latência introduzida por qualquer componente do

sistema de telefonia IP, afetará diretamente o resultado final notado pelo usuário.

102
 a) Latência Ocorrida nos Gateways
Vamos observar dentro de um Gateway e examinar a origem da latência introduzida por ele.
Um diagrama em blocos simplificado do processamento de um Gateway é mostrado na
Figura 10. O diagrama em blocos mostra as funções que ocorrem em ambos os Gateways
envolvidos no sistema. A interface para os equipamentos telefônicos está no lado esquerdo
e a interface para a rede está do lado direito.

Seguindo o caminho da voz proveniente de um telefone para outro, cada bloco funcional
tem o seu efeito próprio na latência experimentada pelo sistema. Vamos passar a descrevê-
las a partir de agora.

Figura 3 – Processamento do Gateway de Interface

Latência da Interface de rede

A interface de rede inclui qualquer hardware ou software que conecta o gateway ao sistema
telefônico ou à rede IP. Uma interface típica de rede coloca os quadros gerados pelo IP em
um feixe PCM, através de um bus interno PCM que liga o bloco DSP à interface física de
saída. A latência aqui introduzida é normalmente muito pequena ficando bem abaixo de
1ms.

103
Latência do bloco Digital Signal Processing (DSP)

O processamento digital de sinal (DSP) é um dos blocos mais complexos dentro do

Gateway. Normalmente é formado por um processador dedicado à função DSP associado à
um software que contém os algoritmos que comprimem e descomprimem a voz, detecta os
tons, detectam o silêncio, gera os tons, geram ruído de conforto, e fazem cancelamento de
eco. Este conjunto de funções é conhecido como VOCODER.
Figura 4 – Subsistema DSP de Compressão de Voz

Latência de Formação do Quadro

Para aumentar a eficiência do VOCODER, as implementações do DSP devem processar o

quadro de dados completo de uma só vez. Isto permite ao DSP usar algumas instruções
especiais que resultam em na eficiência exigida por sistemas de Telefonia IP de alta
densidade.
Figura 5 – Processamento de Quadros

104
O outro lado da moeda neste caso é que nenhum dado pode sair para a interface enquanto
todo o quadro não for preenchido pelo VOCODER. Como a taxa que o áudio digitalizado é
normalmente fixada em 8000 amostras por segundo, o tamanho do quadro afeta
diretamente na quantidade de latência. Um quadro para 100 amostras demora 12,5ms para
ser preenchido, enquanto um quadro para 1000 amostras demora 125ms para ser
preenchido. A correta decisão quanto ao tamanho do quadro está no fato de que maior o
quadro maior eficiência, menor o quadro menor a latência.

Felizmente, ou infelizmente (depende do ponto de vista), nós não precisamos nos preocupar
com isso. Nos processos de normatização está previsto que todos os fabricantes devem
convergir para um único padrão de tamanho de quadro e de algoritmo de compressão de
voz. Assim a máxima latência vai depender exclusivamente da seleção do VOCODER.

Tabela 1 – Tamanho dos Quadros de Codificação de Voz

Voice Coder Banda Duração do Tamanho do

Passante Frame em Quadro em
em bits/sec ms bytes
G.711* 64000 15 120
G.723.1 5300-6300 30 24
G.729a 8000 10 10
SX7300 7300 15 14
SX9600 9600 15 18
*G.711 não é um VOCODER em si, mas está citado para prover comparação.

Tempo de Processamento

Depois que uma coleção de amostras é armazenada o algoritmo DSP irá processar a
informação (para comprimi-la), este tempo depende da velocidade do processador DSP, e
do algoritmo escolhido para isso, mas uma coisa é certa esse tempo nunca pode exceder ao
tempo de formação de uma nova coleção de amostras, pois senão nunca poderíamos
encaminhar um quadro completo para a interface de saída.

Como a maior parte dos gateways de sistemas de Telefonia IP de alta densidade processam
múltiplos canais de voz em cada DSP, calcular a latência introduzida pelo processamento
para cada canal é uma tarefa muito complexa. Nesta situação cada DSP irá processar um
certo número de quadros dos canais que está tratando de maneira seqüencial. Isto significa
que o primeiro canal processado estará completo muito antes do último, mas uma coisa é
certa o último canal processado deverá ficar pronto antes que uma nova coleção de quadros
fique pronta para processamento.

Como resultado, não podemos dizer exatamente quantos milissegundos um canal particular
demorará para ficar pronto pois isso depende da posição que ele ocupa na fila, mas

105
podemos garantir que na pior hipótese este tempo não poderá ser maior que duas vezes o
valor de formação do quadro.

Latência de Encaminhamento de Pacotes

Entre o processamento DSP e os dados serem passados efetivamente para a WAN, existem
um certo número de operações de encaminhamento desse pacote (processamento de fila),
que irá alterar o valor de latência do sistema.

Buferização

Depois dos processos de codificação, alguns sistemas de Telefonia IP buferizam os quadros

contendo a voz comprimida antes deles serem passados para o software de rede. Esta
buferização adicional é feita para diminuir a quantidade de vezes que o DSP precisa se
comunicar com a CPU no Gateway. Em outras situações isso é feito para que o resultado da
codificação tenha uma única duração de Frame.

Por exemplo: se um sistema está rodando com compressão G.723.1 para um canal e G.729a
para outro, devemos buferizar para que os tempos sejam ditados pelo quadro G.723.1. Isto
permite para o sistema transferir um bufer à cada 30ms, independente do algoritmo usado.

Envelopamento

Para que a voz comprimida seja transmitida para a WAN, é necessário que ela seja utilizada
para a formação dos pacotes, isso é feito pela pilha de protocolos do TCP/IP, que usa o
UDP (User Datagram Protocol) e o RTP (Real Time Protocol). A seleção desses protocolos
acelera a entrega dos pacotes e elimina o overhead de reconhecimentos e retransmissões.

Olhando por dentro de um pacote típico de VoIP, cada pacote começa com um Header IP,
um UDP e um RTP, o que dá um total de 40 bytes. O Header contém os endereços IP de
origem e destino, o número da porta IP, o número de seqüência de pacotes e outras
informações necessárias para que os protocolos possam transportar apropriadamente os
dados.

Depois de um Header IP, um ou mais quadros de voz comprimida podem ser colocados. a
decisão de quando empacotar mais de um quadro de dados em um simples pacote é uma
consideração muito importante. Vela por exemplo um canal codificado em G.723.1, o
codificador irá produzir um quadro de 24 bytes à cada 30ms, se cada pacote possui um
Header de 40 byte, então teremos um overhead de 167%.

106
 Figura 6 – Anatomia de um Pacote de Telefonia IP

O meio mais comum de reduzir a ineficiência do empacotamento IP, é colocar mais de um

quadro de voz comprimida em um mesmo pacote, no caso anterior com dois quadros
empacotados juntos o overhead cai para 83%, porém o efeito de adicionar outro quadro é o
aumento da latência pois devemos esperar que os dois quadros fiquem prontos para
empacotá-los juntos.

Um truque interessante que pode reduzir o overhead, sem aumentar a latência no sistema é
deixar os quadros de voz de outros canais "pegarem carona" no mesmo pacote. Isso quando
a voz de um outro canal do mesmo gateway possuir o mesmo destino. Este truque não é
suportado pelo protocolo padrão H.323, mas pode ser usado por soluções proprietárias para
aumentar eficiência.

Latência do Bufer de Jitter.

Por causa das redes IP não poderem garantir o tempo da entrega dos pacotes (ou a sua
ordem, da mesma forma), os dados chegam ao receptor de uma forma inconsistente. A
variação da taxa de chegada é conhecida como Jitter. Durante o processo de decodificação
da voz, todo sistema deve compensar esse jitter dos dados que chegam da rede. O método
mais importante para fazer isso é fazer uma buferização atrasando todos os dados que
chegam e depois entregando para o decodificador com uma temporização padrão.

Porém com estes bufers vamos aumentar ainda mais a latência. Quanto maior for esse bufer
de jitter, mais tolerante é o sistema ao jitter e maior a latência introduzida

Latência Inerente à Rede de Transporte

Agora que o Gateway já tem a voz comprimida e empacotada, temos que entregá-la para
uma rede transportar até o destino final. Passando os dados através dessa rede algumas
forma potenciais de latência ocorrerão, e afetarão a latência total.

107
 b) Latência de Acesso ao Meio

Para cada ponto onde os dados vão passar existe um delay causado pela forma de acesso ao
meio, isso causa latência. Como existem muitos modos diferentes de conectar fisicamente
os Roteadores nos meios físicos disponibilizados para o transporte dos dados esta latência
deve ser considerada.

Se uma conexão à WAN é feita com conexões seriais de baixa velocidade, como a RS-232
ou modems dial-up, o tempo de transferência dos dados para o meio pode ser muito grande,
diferentemente de se usarmos portas de alta velocidade.

Exemplo:

 Se um link para WAN está usando uma conexão à 28800bps, cada byte
requer 0,35ms para ser transferido. Assim a transferência de 100 bytes
durará 35ms, o que é um valor bastante elevado.

 Se ao invés de uma conexão RS-232, a interface usada fosse de 1,54Mbps

(conexão T1), o tempo de latência para os mesmos 100 bytes seria de
0,5ms.

 Se fosse uma Fast Ethernet (100Mbps), o tempo de latência dos mesmos

100 bytes seria de 0,008ms, porém como o acesso ao meio dessas redes usa
o método CSMA/CD, qualquer colisão ou congestionamento aumentará a
latência.

c) Latência de Roteamento

Para ser roteado um pacote IP só dispõe de um endereço de destino e de origem, assim todo
pacote deve ser examinado pelo roteador, processado e assim determinada a sua rota. A
forma de tratar as filas dentro dos roteadores de IP foram desenvolvidas muito antes do
advento da Telefonia IP, e deixam muito à desejar quando necessitamos trafegar dados com
necessidade de tempo real. Os roteadores usam o método do "Maior Esforço", o que é
muito longe do ideal para tráfego sensível à delay como o de voz.

O protocolo RSVP (Resource Reservation Protocol) foi definido pelo IETF como um meio
de criar e gerenciar recursos em roteadores. O RSVP permite estabelecer uma conexão
gateway-to-gateway com de comprometimento de banda garantida nos equipamentos
intermediários da rede, o que irá reduzir dramaticamente a variabilidade da entrega dos
pacotes e aumentar a qualidade de serviço. Porém o RSVP é relativamente recente o que
faz com que não possamos contar com este recurso na rede pública. Assim esse protocolo
só pode ser usado em sistemas fechados onde um administrador da rede pode controlar os
equipamentos que farão parte da rede.

108
 d) Servidores Proxy e Firewalls

Muitas redes usam Firewalls e Servidores Proxy para prover segurança entre a LAN
corporativa e a Internet. Porém como o funcionamento desses elementos requer que eles
examinem cada pacote IP entrando ou saindo da rede, eles podem acabar gerando uma
quantidade bastante significativa de latência, assim o seu uso deve ser evitado para
aplicações de telefonia IP.

Uma filtragem de pacotes oferecida pelos roteadores pode ser uma alternativa mais simples
para aumentar a segurança, sem que seja usado os Firewalls ou servidores Proxy, dando um
resultado bom em relação à latência introduzida.

(E) Como Posso Controlar a Latência?

A chave do sucesso de um sistema de Telefonia IP está em controlar as fontes de latência.
assim alguns passos fundamentais para atingir este objetivo estão descritos à seguir:

 Conhecer todas as fontes de latência do seu sistema (fazer uma planilha).Use a

planilha para identificar pontos que podem ser melhorados. Sem um entendimento
completo dos vários componentes da latência total, você não terá uma idéia
completa do que está acontecendo e a latência poderá passar os limites aceitáveis.

 Usar roteadores que suportem a priorização de portas selecionadas ou que

implementem o RVSP para garantir um certo nível de throughput dos pacotes de
voz.

 Assegure-se de que a rede possui banda suficiente para evitar congestionamento.

Uma ferramenta importante para gerenciar a banda e diminuir o congestionamento é
a seleção do VOCODER apropriado. Use plataforma de telefonia IP que tenham
seleção dinâmica de VOCODER em base de chamada à chamada, ou mesmo dentro
de uma chamada estabelecida. Isto permitirá à rede responder às condições de banda
disponível em tempo real e corrigir estados de congestionamento.

 Fique longe dos equipamentos e meios que você não pode controlar (a rede pública
Internet).

 Reduza o overhead dos pacotes. Usando o mecanismo de "piggybacking". Isso pode

reduzir o overhead até valores como 50%, em sistemas bem projetados.

a) Um Exemplo de Planilha

Veja a tabela 3, onde temos um exemplo de planilha com todos os tempo de latência
relevantes mostrados.

109
 Tabela 2 – Exemplos de Latência

Source Latency
(in milliseconds)
Network Interface 1 (1.54 Mbps T1)
Framing 30 (G.723.1)
Processing Time 10 (worst case)
Buffering 0 (no additional buffering)
Packetization 30 (two frames per packet)
Media Access Delay 10 (5 – 2msec hops)
Routing 50 (router dependent)
Jitter Buffering 30 msec (one buffer)
Total One-Way 161 msec
Latency

A planilha é particularmente importante para isolar os gargalos de latência do sistema.

110