Académique Documents
Professionnel Documents
Culture Documents
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
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.
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).
- Multiplexação Estatística
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:
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
PABX
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.
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.
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.
Figura 4 – IP Trunking
H.323 H.323
Gatekeeper
H.323
Gateway
Proxy
Internet
PABX
H.323
PSTN
9
(b) Ambiente da Operadora de Telefonia
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.
10
Extrema pulverização de Hosts TCP/IP, principalmente no ambiente corporativo.
11
UNIDADE 3
Telefonia IP
1. Voz sobre IP
12
Figura 1 – Integração das Redes IP e PSTN
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.
13
surgiram os primeiros gateways baseados em H.323, para interoperabilidade com
fabricantes diferentes. Mais tarde voltaremos a abordar este assunto.
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.
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.
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.
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.
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.
18
5. A Rede de Telefonia IP Distribuída
19
6. Futuro da 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.
21
UNIDADE 4
Padrão H.323
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.
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.
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
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.
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:
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.
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
29
controlados centralizadamente pela MCU, e as informações dos Canais de Controle H.245
continuam sendo transmitidos ponto-a-ponto à uma MC.
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.
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.
32
6. Gatekeepers
Figura 8 - Gatekeeper
33
Os Gatekeepers também são responsáveis por esses serviços adicionais:
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.
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.
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
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.
E.164: Formato de endereçamento para redes RDSI. Ver ITU Recommendation E.164
(1991).
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.
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.
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.
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).
41
UNIDADE 5
42
Session Initialization Protocol
Funcionalidade:
Codificação Textual (compatível com TELNET,
TCPDUMP, etc...)
Programabilidade ampliada
43
Lembrar que SIP não é...
Um protocolo de transporte
Um protocolo de reserva de QoS
Um protocolo de controle de Gateways
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
44
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
45
Endereços SIP
Exemplo de Registro
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.
Cadeia Proxy
47
Cadeia Proxy
Exemplo de encadeamento de
proxy
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.
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.
50
Códigos Respostas SIP
2yz Success
200 ok
3yz Redirection
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
51
Estrutura de Mensagens SIP
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).
Usa UDP
Setup mais rápido
Menos estados
Futuro
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.
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.
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.
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
Pequeno processamento do overhead por pacote dentro da rede e nos sistemas finais.
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.
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:
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.
61
Figura 2 – Adaptabilidade do Protocolo RTP
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.
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.
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
...
V=Version
P=Padding
X=Extension
CC=CSCR count.
M=Marker
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.
Seguindo este header fixo, podem haver um ou mais desses campos seguintes:
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.
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:
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.
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:
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.
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.
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.
(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.
68
UNIDADE 7
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 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.
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
71
Figura 3 – Relação entre H.323 e MGCP
MGCP MGCP
Call Agent Gateway
Terminal MCU
H.323 H.323
LAN
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
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.
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
Agentes de Chamadas
H.323 e Telco
Gateways
3. Comandos MGCP
73
Figura 5 – API e MGCP
User User
Application Application
A A
P P
I I
MGCP MGCP
Mensagens
MGCP
Notify (NTFY): O Gateway responde ao Agente de Chamadas com este comando quando o
evento especificado ocorrer.
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:
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:
ConnectionID: Valor retornado pelo Gateway durante a criação de uma conexão. Ele
identifica a conexão entre pontos finais.
DetectEvents: Durante o período de quarentena, uma lista com os eventos que forem
detectados.
75
EndPointID: O nome do Ponto Final no Gateway.
SignalRequests: Conjunto de sinais que o Gateway deve aplicar para o ponto final, tal
como chamando (ringing), fora do gancho, tom contínuo, etc.
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, )
(B) Notify
Comando e Parâmetros Associados: A estrutura do comando Notify é como segue:
Notify ( EndPointID,
NotifiedEntity,
RequestIdentifier,
ObservedEvents, )
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,)
(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.
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.
DeleteConnection ( CallID,
EndPointID,
ConnectionID,
NotifiedEntity,
RequestedEvents,
RequestIdendifier,
DigitMap,
SignalRequests,
QuarantineHandling,
DetectEvents, )
79
Número de Pacotes Recebidos: Número total de pacotes RTP perdidos pelo
Gateway desde o começo da conexão.
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.
DeleteConnection ( CallID,
EndPointID,
ConnectionID,
NotifiedEntity,
ReasonCode,
Connection-parameters, )
(E) AuditEndpoint
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
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
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.
82
Tabela 1 – Parâmetros MGCP e seus Códigos
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.
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.
Comando Código
CreateConnection CRCX
ModifyConnection MDCX
DeleteConnection DLCX
NotificationRequest RQNT
Notify NTFY
AuditEndpoint AUEP
AuditConnection AUCX
RestartInProgress RSIP
84
Tabela 3 – Comandos e seus Parâmetros
85
Tabela 4 – Respostas e seus Parâmetros
86
8. Exemplo de Operação do MGCP
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 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.
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”.
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 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 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.
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 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 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 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 34: O evento no gancho gera uma mensagem de Notify para o 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”.
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
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.
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.
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
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.
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
97
síntese para produzir um resultado decodificado, por fim é aplicado um ganho ao sinal
resultante.
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
1. Latência em Telefonia IP
(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.
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.
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.
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.
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.
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)
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.
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.
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
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
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.
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
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.
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.
Fique longe dos equipamentos e meios que você não pode controlar (a rede pública
Internet).
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
110