Aplicações em Redes e Qos - Aula 4

Prévia do material em texto

DESCRIÇÃO
Protocolos de transporte de tempo real e de sinalização para a transmissão de voz.
PROPÓSITO
Compreender as características dos protocolos de transporte de tempo real e o funcionamento
dos protocolos de sinalização de aplicações para a transmissão de áudio e vídeo.
OBJETIVOS
MÓDULO 1
Descrever o funcionamento dos protocolos de transporte de tempo real utilizados na internet
MÓDULO 2
Descrever o funcionamento dos protocolos de sinalização utilizados para a transmissão de voz
na internet
INTRODUÇÃO
Os protocolos de transporte tradicionais da internet não podem prover um suporte adequado ao
funcionamento das aplicações multimídia – uma realidade particularmente presente nas
transmissões em tempo real. Devido a tal fato, foram desenvolvidos protocolos específicos
para esse tipo de aplicação que procuraram satisfazer aos requisitos para o correto
funcionamento destas aplicações.
Outra situação que se apresentou ao longo do tempo foi a necessidade de permitir a
transmissão de voz do tipo telefonia pela internet. Isso também gerou a necessidade de novos
protocolos que garantissem uma compatibilidade entre o sistema telefônico e as redes IP.
Esses dois aspectos serão o objeto de nosso estudo neste tema.
MÓDULO 1
 Descrever o funcionamento dos protocolos de transporte de tempo real utilizados na
internet
CAMADA DE TRANSPORTE NA INTERNET
A camada de transporte da internet possui dois protocolos principais:
TCP
Protocolo orientado à conexão e confiável, o TCP busca garantir a entrega de todos os pacotes
e a sua ordenação antes de passá-los para a camada de aplicação.
Para obter essa confiabilidade, ele implementa reconhecimentos positivos (ACK) e a
retransmissão de pacotes perdidos. Além disso, o TCP realiza mecanismos de controle de
congestionamento que podem fazer com que a taxa de transmissão caia muito.
 ATENÇÃO
Essas características o tornam inadequado para a transmissão de multimídia, principalmente
em tempo real, pois elas implicam tempo de processamento elevado para cada pacote.
UDP
Trata-se de um protocolo muito mais simplificado; afinal, seu cabeçalho é extremamente
simples (vide figura a seguir). De forma resumida, podemos dizer que ele basicamente
acrescenta apenas o número da porta da aplicação de destino à funcionalidade do IP,
permitindo a multiplexação da transmissão.
PORTA
Porta é o endereço utilizado na camada de transporte, permitindo a indicação para qual, entre
os processos em execução, host de destino se deseja enviar o pacote. O número da porta de
destino é necessário para a entrega; o da porta de origem, para a resposta.
 Datagrama UDP.
Isso faz com que ele seja um protocolo leve e de processamento muito rápido.
Apenas isso, entretanto, não o torna suficiente para a transmissão de multimídia. Para que
esse tipo de dado possa ser processado de forma eficaz, é necessário algum mecanismo de
javascript:void(0)
sequenciamento dos pacotes e de controle de tempo.
RTP
Por conta das deficiências dos protocolos da camada de transporte da internet para o
tratamento de transmissão de multimídia, foi criado o real–time transport protocol (RTP), ou,
em português, protocolo de transporte em tempo real.
Associado ao UDP, o RTP permite a realização eficiente das trocas de áudio e vídeo em tempo
real pela internet.
CONCEITO
Embora seja considerado um protocolo de transporte, o RTP não é encapsulado em um
datagrama IP, e sim em um datagrama UDP.
Seu objetivo é multiplexar, conforme indica a figura a seguir, diversos fluxos de dados de tempo
real em um único fluxo de pacotes UDP:
 Posição do RTP na pilha TCP/IP.
O RTP em si não possui mecanismos de entrega, como, por exemplo, os números das portas.
Essas funcionalidades continuam sendo fornecidas pelo UDP, que o encapsula.
Ele também não provê nenhuma garantia especial sobre a entrega. Os pacotes, portanto,
podem ser perdidos, atrasados, adulterados etc.
O que o protocolo RTP acrescenta são dois novos recursos:
UM NÚMERO SEQUENCIAL PARA CADA PACOTE
Isso permite ao receptor verificar se eles chegaram em ordem ou se ocorreu alguma perda.
UMA ESTAMPA DE TEMPO
Com isso, pode ser realizado o controle da reprodução no destinatário.
PACOTE
Um pacote RTP é composto de um cabeçalho genérico, contendo campos e parâmetros
definidos na RFC-0064, adicionado de informações específicas e particulares a cada perfil.
PERFIL
Cada tipo de carga RTP pode conter amostras diferentes, codificadas da forma que a aplicação
desejar.
Os perfis estão definidos em RFCs distintas e para permitir a interoperabilidade ele pode
permitir vários formatos de codificação.
 EXEMPLO
Um único fluxo de áudio pode ser codificado em amostras PCM de 8 bits a 8KHz usando
codificação delta, preditiva ou GSM, MP3, e assim por diante.
O pacote RTP possui o seguinte formato conforme tabela a seguir. Clique em cada um dos
campos e conheça um pouco mais sobre eles:
javascript:void(0)
javascript:void(0)
javascript:void(0)
Ver P X
Contr.
count
M
Tipo de
payload
Número de
sequência
Timestamp
Identificador da fonte de sincronismo
Identificação do participante
.
.
.
Identificação do participante
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Formato do pacote RTP. Tabela: FOROUZAN, 2008, p. 917, adaptada por Ramany Oliveira
e Eduardo Trindade
VER
Este campo possui 2 bits e indica a versão do RTP. A versão atual é a 2.
P
Este campo possui 1 bit.
Se o seu valor for 1, ele indicará a presença de preenchimento (padding) no final do pacote; se
ele for 0, a ausência dele.
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
Preenchimento corresponde à existência de octetos adicionais no final do pacote que não
fazem parte dos dados e que devem ser ignorados. O preenchimento ocorre graças à
exigência de determinados algoritmos de criptografia de trabalhar como blocos de tamanho
fixo. O último octeto do preenchimento informará a quantidade de bytes inserida.
X
Com 1 bit, este campo indica se existe (valor 1) ou não existe (valor 0) no cabeçalho de
extensão extra entre o cabeçalho básico e os dados.
CONTRIBUTOR COUNT.
Campo de 4 bits que indica o número de participantes daquele evento. Um exemplo é uma
videoconferência.
A quantidade é limitada a 15 participantes, já que 4 bits só permitem números de 0 a 15.
M
Este campo de 1 bit constitui um marcador usado pela aplicação para destacar determinados
pacotes. Por exemplo, M pode indicar o último pacote de dados ou o início de cada frame ao
enviar vídeo.
TIPO DE PAYLOAD
Com 7 bits, ele informa o tipo de carga (payload) do pacote usando números inteiros para sua
indicação. Esse tipo define os perfis e como a aplicação deverá tratar os dados.
Os tipos de carga são padronizados. Veremos a seguir dois exemplos de cargas (o primeiro,
para áudio; o segundo, para vídeo):
Número do tipo de
carga útil
Formato de
áudio
Taxa de
amostragem
Vazão
0 PCM µ-law 8KHz 64kbits/s
1 1016 8KHz 4,8kbits/s
3 GSM 8KHz 13kbits/s
7 LPC 8Khz 2,4kbits/s
9 G.722 16KHz
48-
64kbits/'s
14 Áudio MPEG 90KHz -
15 G.728 8KHz 16KHz
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
Número do tipo de carga útil Formato de vídeo
26 Motion JPEG
31 H.261
32 Video MPEG 1
33 Video MPEG 2
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Tabela: KUROSE; ROSS, 2014, p. 462.
 ATENÇÃO
Observe que todos os outros campos a seguir serão interpretados pela aplicação definida pelo
tipo de carga especificada nesse campo.
NÚMERO DE SEQUÊNCIA
Campo de 16 bits que permite a ordenação dos pacotes de uma comunicação.
O primeiro pacote recebe um número aleatório, enquanto os demais são incrementados de 1
em relação ao anterior, permitindo ao receptor reordenar pacotes recebidos fora de ordem ou
identificar aqueles perdidos.TIMESTAMP (CARIMBO DE TEMPO)
Campo de 32 bits que marca o momento em que o primeiro octeto dos dados de cada pacote
foi gerado.
IDENTIFICADOR DA FONTE DE SINCRONISMO
(SSRC)
A fonte de sincronização (ou, em inglês, synchronization source) é um campo de 32 bits usado
para identificar as fontes de sincronização. Cada participante da sessão RTP escolhe um
número aleatório para ser sua identificação frente aos outros participantes.
O protocolo possui procedimentos para lidar com o fato de dois hosts escolherem o mesmo
SSRC.
IDENTIFICADOR DO PARTICIPANTE (CSRC)
A fonte contribuinte (ou contributing source) constitui um campo de 32 bits usado para
identificar as fontes de onde vieram os dados contidos no pacote. O CSRC se aplica a pacotes
gerados por misturadores.
Misturadores são hosts que recebem fluxos de dados de múltiplas fontes e os combinam em
um único fluxo.
Por exemplo, em locais distintos, várias pessoas estão participando de uma teleconferência IP.
Uma possível implementação para minimizar o número de fluxos seria que todas elas
estabelecessem uma sessão RTP com o misturador.
A partir daí, o misturador combinaria os diversos fluxos de áudio (provavelmente convertendo-
os para o analógico e realizando uma nova amostragem do sinal resultante) e os reenviaria
como um único fluxo digital. Com isso, ao atuar, o misturador se torna o SSRC do novo fluxo e
lista no CSRC as fontes dos sinais misturados.
ENCAPSULAMENTO
Conforme vimos, o RTP é encapsulado em um datagrama UDP, e não em um datagrama IP.
Por isso, ele não se comporta como um protocolo de transporte típico; devido a essa
característica, muito autores classificam o RTP como um protocolo de aplicação, e não de
transporte.
É como se o RTP fosse um tipo de aplicação com uma grande diferença: ele não possui um
número de porta fixo.
A porta será alocada quando houver uma solicitação para cada sessão. Isso exige que a
aplicação remota seja informada desse número, sendo que, por convenção, o RTP recebe uma
porta de número par.
 ATENÇÃO
Esse esquema de encapsulamento (dentro do UDP e recebendo um número distinto a cada
solicitação) permite a um único host possuir múltiplas aplicações, utilizando o RTP
paralelamente e sem interferência.
FUNCIONAMENTO
Quando o host remetente deseja enviar uma mídia, ele a encapsula em um pacote RTP. Esse
pacote, então, recebe um número de porta par e é encapsulado em um datagrama UDP.
A partir daí, a transmissão transcorre no esquema normal de rede, sendo tudo encapsulado em
um datagrama IP. Esse datagrama, como delineia a figura a seguir, sofre esse encapsulamento
no quadro de camada 2 e, em seguida, é transmitido no meio físico.
 (a) Posição do RTP na pilha de protocolos; (b) Aninhamento de pacotes.
Quando recebe o pacote, o receptor realiza o desencapsulamento. Ao chegar ao RTP, ele
extrai a parte de mídia (carga útil do pacote) e a entrega à aplicação para decodificação e
apresentação.
Apresentaremos, agora, um exemplo baseado em transmissão de telefonia IP:
A origem de uma voz é codificada (isto é, amostrada, quantizada e digitalizada) mediante o
emprego do codificador G.711. O remetente precede cada parte dos dados com um cabeçalho
RTP (vide a figura a seguir) no qual são especificados:
O tipo de carga.
Um número de sequência.
Uma estampa de tempo.
 COMENTÁRIO
Não houve a necessidade de preencher os demais campos do cabeçalho.
Em seguida, o pacote é passado para o UDP, que coloca o número das portas de origem e
destino. Reparemos que cada uma é um número par. Ele ainda migra para a camada de
redes e enlace, sendo, por fim, transmitido na camada física.
O receptor processa o pacote e entrega a aplicação que extrai a mídia, usando os campos do
cabeçalho RTP para identificar o tipo de mídia, decodificá-la e reproduzi-la.
 Pacote RTP.
 ATENÇÃO
O RTP não garante a qualidade do serviço (QoS), a entrega dos pacotes e a ordenação deles.
Cabe à aplicação lidar com tais aspectos.
Observemos que o encapsulamento RTP somente é visível nos sistemas finais. Para os
sistemas intermediários, ele é apenas mais um datagrama IP em processamento.
Como se deve agir se faltar um pacote ou se ele chegar fora de ordem?
 RESPOSTA
Normalmente, as aplicações pulam um quadro do vídeo (se ele for o tipo de conteúdo) ou
fazem uma interpolação no áudio, mas dificilmente utilizariam a retransmissão, já que o pacote
retransmitido chegaria muito tarde para ser útil. Por conta disso, o RTP não possui mecanismo
de confirmação nem solicitação de retransmissão.
Outra característica importante de seu funcionamento é o fato de normalmente ser atribuído um
fluxo independente para cada origem.
 EXEMPLO
Em uma videoconferência, em que cada lado possui um microfone e uma câmera, seriam
abertos quatro fluxos RTP: dois para o áudio (um em cada sentido) e outros dois para vídeo
(também um em cada sentido).
Devemos lembrar, entretanto, que várias técnicas de codificação, como MPEG1 e MPEG2,
combinam o áudio e o vídeo em um único fluxo durante a codificação. Isso obviamente faz com
que o RTP abra apenas um fluxo para cada direção.
RTCP
CONCEITO
O RTP cumpre apenas a transmissão de mensagens que realizem o transporte de mídia entre
a origem e o destino. Muitas vezes, contudo, somente isso não é suficiente.
Dependendo das características da sessão, pode haver a necessidade de mensagens que:
Façam o controle do fluxo.
Indiquem a qualidade dos dados.
Permitam o feedback do receptor para as fontes.
Para atender a tais situações, foi criado o protocolo RTCP. Fornecendo recursos para o
controle e o monitoramento da comunicação, ele permite a emissores e receptores a troca de
relatórios com informações adicionais a respeito dos dados, como a variação do atraso (jitter),
a largura de banda e o congestionamento.
 EXEMPLO
Essa troca de relatórios permite que o emissor aumente ou diminua sua taxa de dados em
função da carga da rede, melhorando (se a rede estiver relativamente ociosa) ou diminuindo
(se ela estiver congestionada) a qualidade da transmissão a partir da alternância da codificação
utilizada. Isso é possível ao se passar de um MP3 para um PCM de 8 bits, ou vice-versa.
O RTCP usa o mesmo método de envio dos pacotes RTP, porém o faz em uma porta UDP
diferente. Além disso, ela sempre será a porta subsequente daquela utilizada pelo RTP ao qual
ele se associa.
 RTP e RTCP (portas UDP).
Notemos, na figura anterior, que a porta do RTP é 7000 (um número par), e a do RTCP, 7001
(ímpar).
PACOTE
O pacote RTCP possui o seguinte formato. Clique em cada um dos campos e conheça um
pouco mais sobre eles:
2 1 5 8 16
Versão p RC Tipo Pacote Tamanho
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
Dados
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Pacote RTCP. Tabela: Sidney Nicolau Venturi Filho, adaptado por Ramany Oliveira e
Eduardo Trindade.
V (VERSÃO)
Campo com 2 bits que identifica a versão de RTP utilizada, sendo a mesma para o RTP e o
RTCP.
P (PREENCHIMENTO OU PADDING)
Com 1 bit, o R informa se existe preenchimento no pacote.
RC (CONTADOR DE RELATÓRIOS)
Campo com 5 bits que indica a quantidade de relatórios contidos.
TIPO DO PACOTE
Com 8 bits, ele indica o tipo de pacote RTCP (mensagem).
TAMANHO
Informa o tamanho do pacote RCTP.
javascript:void(0);
DADOS
Eles contêm a mensagem RTCP.
MENSAGENS
O RTCP possui cinco tipos básicos de mensagem:
RELATÓRIO DO EMISSOR (SENDER REPORT) –
CÓDIGO 200
Essa mensagem é enviada de tempos em tempos pelos transmissores ativos para reportar
estatísticas de transmissão e recepção de pacotes RTP enviados. Ela inclui um registro de
estampa de tempo absoluto, que corresponde ao número de segundos decorridos desde a
meia-noite de 1º de janeiro de 1970.
RELATÓRIO DO RECEPTOR (RECEIVER REPORT) –
CÓDIGO 201
Enviado por participantes passivos, ou seja, aqueles que não são fontes de pacote RTP, esse
relatório informaao emissor e aos receptores sobre a qualidade dos serviços de rede.
DESCRIÇÃO DE ORIGEM (SOURCE DESCRIPTION) –
CÓDIGO 202
Código utilizado pelas fontes para periodicamente reportar informações adicionais a seu
respeito. Essas informações podem incluir o nome, o endereço de e-mail, o número de telefone
e, principalmente, o cname.
DESPEDIDA (BYE) – CÓDIGO 203
Utilizada por uma fonte para encerrar uma sessão de multimídia.
ESPECÍFICA DA APLICAÇÃO (APP) – CÓDIGO 204
Uma mensagem APP (sigla da expressão application-specific message) permite que uma
aplicação defina novos tipos de mensagens não estabelecidas no padrão do RTCP.
javascript:void(0)
Conhecido como nome canônico, o cname é o único campo necessário em uma Source
Description. Ele tem como formato geral o endereço usuario@host, em que:
Host é o nome de domínio do computador (ou seu endereço IP) na forma decimal ou
hexadecimal pontuada.
Usuário (user) é um nome de login.
FUNCIONAMENTO
Os computadores emissores enviam periodicamente uma mensagem de relatório do emissor
que fornece uma estampa de tempo absoluta.
 ATENÇÃO
Você deve entender que o uso dessa estampa é de extrema importância, pois, como o RTP
permite que cada fluxo escolha uma origem diferente para sua estampa de tempo, seria
impossível fazer a sincronização entre a voz e o vídeo de uma videoconferência pelas
estampas de tempo do RTP.
Utiliza-se, para isso, a estampa absoluta do RTCP.
A figura a seguir mostra a captura no wireshark de um pacote RTCP do tipo relatório do
emissor.
WIRESHARK
Classificado como snnifer, esse aplicativo permite a captura dos pacotes que trafegam em uma
rede
javascript:void(0)
 Relatório do emissor.
Nela podemos notar que:
A porta de origem e de destino são ímpares.
O tipo da mensagem é 200.
O emissor envia o seu SSRC.
Existe a estampa de tempo absoluta em relação a uma origem especificada.
Os receptores enviam periodicamente mensagens de relatório do receptor informando a origem
e as condições de recepção. Esses relatórios possuem duas funções importantes:
Permitir que outros receptores presentes na sessão aprendam, na companhia do emissor, a
respeito das condições da recepção.
Possibilitar que os receptores adaptem sua frequência de geração de relatório a fim de poupar
a largura de banda e não sobrecarregar o emissor.
O esquema adaptativo utilizado faz com que tráfego de controle total permaneça menos de 5%
do tráfego de dados em tempo real e que os relatórios do receptor gerem menos de 75% do
tráfego de controle.
 SAIBA MAIS
Em cada relatório, são identificados:
As origens de sincronização.
Uma seção para cada origem, em que é especificado o número sequencial mais alto de
um pacote recebido.
A perda de pacote cumulativa e percentual experimentada.
O tempo decorrido desde que o último relatório RTCP chegou da origem.
O jitter entre as chegadas.
O emissor também transmite periodicamente mensagens de descrição de origem. Essa
mensagem é dividida em seções, uma para cada fluxo RTP. Além de seu nome canônico,
obrigatório, ela pode possuir outros dados, como e-mail do usuário, número de telefone e
endereço ou ferramenta utilizada para criar o fluxo.
Esse tipo de mensagem está destinado à leitura de humanos em uma interface.
A figura a seguir mostra a captura no wireshark de um pacote RTCP do tipo descrição da
origem. Podemos observar nela:
Identificação do tipo de mensagem 202.
Cname do emissor.
 Descrição da origem.
Um emissor transmite uma mensagem de despedida (Bye) quando encerra um fluxo. Tendo
isso em vista, a figura a seguir demonstra a captura no wireshark de um pacote RTCP do tipo
mensagem de despedida origem. Podemos verificar nela:
Tipo da mensagem.
Mensagem propriamente dita, correspondendo ao shutdown da sessão.
 Mensagem de despedida.
Uma aplicação pode definir um novo tipo de mensagem RTCP, por exemplo, para enviar as
informações de legenda de um vídeo.
FUNCIONAMENTO DO RTP E RTCP
O especialista fala sobre o funcionamento dos protocolos RTP e RTCP, utilizando exemplos
práticos para auxiliar o entendimento do aluno.
VERIFICANDO O APRENDIZADO
MÓDULO 2
 Descrever o funcionamento dos protocolos de sinalização utilizados para a
transmissão de voz na internet
H.323
CONCEITO
O H.323 é um padrão (pilha de protocolos) desenvolvido pelo International Telecommunication
Union (ITU) para permitir a comunicação entre os telefones da rede pública convencional e os
computadores conectados à internet.
ARQUITETURA GERAL
Esta figura ilustra a arquitetura geral do H.323:
 Arquitetura H.323.
Listaremos a seguir alguns componentes dessa arquitetura:
TERMINAIS
São os computadores pessoais utilizados na rede, a qual provê uma comunicação em tempo
real. Todos os terminais devem suportar voz. Já o suporte a vídeo e dados é opcional.
GATEWAYS
São equipamentos que estabelecem uma conexão entre a internet e a rede de telefonia
pública, transformando uma mensagem da rede telefônica em uma da internet. Eles se
comunicam por meio de dois tipos de protocolo:
H.323 (no lado da internet).
PSTN (na rede telefônica).
GATEKEEPERS
Trata-se de um de seus componentes mais importantes. Gatekeepers atuam como um ponto
central para todas as chamadas dentro de sua zona e proveem serviços de controle de
chamada para registrar participantes. Entre outras coisas, eles também são responsáveis pelo
gerenciamento da largura de banda em conferências H.323.
javascript:void(0)
javascript:void(0)
PSTN
Abreviação da expressão em inglês public switched telephone network, o PSTN é usado para
descrever uma rede de sistemas de telefonia (estatal ou comercial) interligada.
ZONA
Zona é o conjunto de todos terminais e gateways gerenciados por um único gatekeeper. Uma
zona precisa incluir, pelo menos, um terminal, embora possa incluir ainda segmentos de LAN
conectados usando roteadores.
OUTROS PROTOCOLOS
O H.323 suporta uma série de protocolos para estabelecer e manter a comunicação de voz (ou
de vídeo). Esta figura apresenta tais protocolos:
 Protocolos H.323.
Falaremos um pouco mais sobre alguns desses protocolos:
H.225 RAS
Ele é responsável pela sinalização de chamadas e pelo encapsulamento de um fluxo de dados
multimídia para sistemas de comunicação baseada em pacotes.
Esse padrão engloba outros protocolos responsáveis pela:
Comunicação entre gatekeepers: ela é feita por meio de mensagens trocadas entre os
GKs (gatekeepers) para estabelecer o processo de sinalização e o controle entre zonas
distintas.
Transporte de mídia: realizado graças aos protocolos RTP e RTCP, que são
responsáveis pelo transporte da voz.
Controle de conferência e equipamentos de rede: esse controle é realizado por meio
do protocolo RAS (sigla para register, adimission and status), que é responsável pelo
registro, pela admissão e pelo status dos equipamentos da rede.
H.245
Control protocol for multimedia communication ou protocolo de controle para
comunicação multimídia)
Esse protocolo fornece os padrões para o controle do transporte da voz nas chamadas
realizadas entre os terminais. Utilizado depois do estabelecimento da chamada, o H.245 possui
a capacidade de se adaptar às mudanças que ocorrem na rede – como as alterações na
disponibilidade dela ou nas capacidades dos elementos H.323 – por meio de uma negociação
dinâmica que ocorre entre os terminais com o propósito de estabelecer alguns aspectos da
comunicação. Exemplo: formato de imagens e áudio, codecs e taxa de transmissão.
Q.931
Trata-se do protocolo de sinalização para o estabelecimento e a finalização de chamadas entre
dois equipamentos terminais originalmente desenvolvido para o PSTN. No contexto do H.323,
o Q.931 estabelece o formato das mensagens que trafegam entre equipamentos, terminais ou
gatekeepers.
CODECS
javascript:void(0)
Codec é um acrônimo para codificador/decodificador, que é o software ou o hardware que
realiza a codificação e a decodificação de sinais.
OPERAÇÃO
Para entenderemos a operação do H.323,estabeleceremos agora um exemplo simples
desenvolvido por Forouzan (2008).
A comunicação entre o terminal e um telefone ocorre em sete passos:
 Operação do H.323.

Inicialmente, o terminal precisa descobrir o IP do gatekeeper; para isso, envia uma mensagem
de broadcast na rede solicitando o IP.
O gatekeeper responde com seu endereço IP.


O terminal envia uma mensagem H.225 para o gatekeeper solicitando a largura de banda.
Ocorre o estabelecimento da conexão entre o terminal e o telefone, passando pelo gatekeeper
e pelo gateway com a utilização de uma mensagem Q.931.


O método de compressão é negociado entre os quatro componentes mediante o emprego do
protocolo H.245.
O áudio é trocado utilizando o RTP gerenciado pelo RCTP.


Para encerrar a comunicação, novamente é utilizada uma mensagem Q.391.
PROTOCOLO DE INICIALIZAÇÃO DE
SESSÃO (SIP)
O protocolo SIP (sigla para session initiation protocol) é um padrão para a implementação de
aplicações de voz sobre o IP que está se impondo ao H.323.
CONCEITO
Desenvolvido pelo IETF, o SIP é um protocolo de aplicação que permite estabelecer, gerenciar
e encerrar uma sessão multimídia (tipicamente uma chamada VOIP), permitindo, no processo,
sessões entre duas partes, várias partes ou em multicast.
MULTICAST
Tipo de comunicação que engloba um grupo de usuários, ou seja, constitui uma informação
enviada para os usuários que pertencem a determinado grupo.
O SIP é um protocolo independente do de transporte, podendo ser encapsulado em qualquer
um de seus protocolos.
 SAIBA MAIS
Ele provê mecanismos para:
Estabelecer chamadas entre dois interlocutores por uma rede IP.
Avisar ao destinatário que alguém o está chamando.
Encerrar uma chamada.
javascript:void(0)
Permitir que o chamador determine o IP atual do destinatário, já que pode estar sendo
utilizado um endereçamento dinâmico (DHCP).
Gerenciar a chamada adicionando novos fluxos de mídia ou alterando a codificação
utilizada.
Convidar novos participantes para uma chamada ativa.
Transferir e segurar chamadas.
COMPONENTES
Para poder funcionar, o SIP utiliza basicamente três componentes:
 Componentes do SIP.
AGENTES DE USUÁRIO (UA)
São as aplicações nos terminais que enviam e recebem solicitações SIP em nome dos
usuários. Os User Agent Clients (UAC) enviam solicitações SIP à parte chamadora, enquanto
os User Agent Servers (UAS) as recebem da parte chamada. Cada usuário pode ter múltiplos
agentes de usuário. Por exemplo, pode haver agentes de usuário separados para o telefone do
trabalho, o residencial, o móvel e o computador multimídia. Um endereço SIP é associado a
cada agente de usuário.
SERVIDORES PROXY
Os servidores proxy são as aplicações que recebem solicitações SIP dos clientes e iniciam
novas em nome deles para os agentes de usuário de destino. Eles operam como roteadores
SIP, que encaminham mensagens de sinalização de chamada a seu destino.
REGISTRADORES
Eles aceitam registros de clientes que indicam os endereços nos quais podem ser encontrados.
A funcionalidade do registrador é normalmente combinada com um servidor proxy ou de
redirecionamento, embora ele constitua um processo lógico independente, estando fora do
escopo do SIP.
MENSAGENS
O SIP, assim como o HTTP, é um protocolo baseado em texto.
São empregadas seis mensagens para o gerenciamento das chamadas:
INVITE
ACK
BYE
OPTIONS
CANCEL
REGISTER
INVITE
Solicita o início de uma sessão.
ACK
Confirma que uma sessão foi iniciada.
BYE
Solicita o término de uma sessão.
OPTIONS
Consulta um host sobre seus recursos.
CANCEL
Cancela uma solicitação pendente.
REGISTER
Informa um servidor de redirecionamento sobre a localização atual do usuário.
Escrita em ASCII, cada mensagem corresponde ao nome do método a ser executado na
primeira linha, sendo seguido por linhas adicionais que contêm cabeçalhos com parâmetros da
comunicação.
Esta mensagem Cancel foi extraída de uma captura com o wireshark.
 Mensagem Cancel.
A figura a seguir apresenta o binário do pacote presente no exemplo anterior. Nota-se que a
mensagem é passada em texto claro, sendo possível realizar sua leitura:
 Mensagem Cancel em ASCII.
A fim de iniciar uma sessão, o chamador envia uma mensagem Invite para o destinatário. A
partir da segunda linha do cabeçalho, estão presentes as informações sobre os recursos do
chamador, os tipos de mídia e o formato.
Esta figura contém uma mensagem Invite e seu cabeçalho:
 Mensagem Invite.
Se o destinatário aceitar a chamada, ele responderá com um código de resposta de três dígitos
similar ao do HTTP.
 EXEMPLO
Eis alguns exemplos de códigos de resposta:
Código Significado Exemplos
1xx Informação
100 = classe informacional (ela contém mensagens
que indicam o progresso da chamada).
2xx Sucesso
200 = solicitação com sucesso.
204 = nenhum conteúdo presente.
3xx Redirecionamento
301 = página movida.
304 = página em cache ainda válida.
4xx Erro do cliente
403 = página proibida.
404 = página não localizada.
5xx Erro do servidor
500 = erro interno do servidor.
503 = tente novamente mais tarde.
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Códigos de resposta do protocolo SIP. Tabela: Sidney Nicolau Venturi Filho.
Após a linha do código, o host chamado também pode fornecer:
Informações de seus recursos.
Tipo de mídia que ele utiliza.
Formatos suportados.
Esta figura apresenta a resposta de aceitação de um Invite pelo host chamado e os dados
informados:
 Mensagem de aceitação de chamado.
Finalmente, para confirmar que recebeu a resposta, o host chamador responde com uma
mensagem ACK:
 Mensagem ACK.
Para tornar tudo mais claro vamos ver um exemplo baseado no exemplo disponível em Kurose
e Ross (2014, p 463).
Observe esta situação:
A figura a seguir possui dois hosts: um utilizado por Alice (167.180.112.24) e outro por Bob
(192.64.210.89). Considerando que ela conhece o IP dele, o procedimento se dividiria pelas
seguintes etapas:
ETAPA 1
Alice envia a Bob uma mensagem de Invite para a porta 5060 (portão padrão do SIP) utilizando
UDP (o que é mais comum) ou TCP, o qual, por sua vez, inclui:
Identificador para Bob (bob@193.64.210.89).
IP atual de Alice (167.180.112.24).
Tipo de dados que deseja receber (áudio).
Codificação do áudio AVP 0 (PCM codificado com lei μ).
Porta pela qual deseja receber o áudio (38060).
Encapsulamento a ser utilizado (RTP).
ETAPA 2
Como Bob resolveu aceitar a chamada, ele envia uma mensagem com o código 200 (OK) para
a porta 5060 de Alice, incluindo:
O seu endereço IP (192.64.210.89).
O tipo de dado: Áudio.
A codificação de áudio que deseja: AVP3 (GSM).
O encapsulamento que deseja: RTP.
A porta para a qual deve ser enviado o áudio: 48753.
ETAPA 3
Após receber a resposta de Bob, Alice envia um reconhecimento (ACK) SIP para a porta 5060.
Assim, a partir desse ponto, eles podem conversar.
 Chamada SIP para IP conhecido.
Notemos que, neste exemplo:
Alice e Bob estão utilizando codificações diferentes para seu áudio e as enviam para as portas
solicitadas, e não para a porta do SIP.
O SIP é um protocolo fora de banda, já que suas mensagens são enviadas para portas
diferentes daquelas utilizadas para a transmissão da mídia.
O SIP exige que toda mensagem seja reconhecida; por isso, houve o envio do ACK por Alice.
Consideremos agora que Bob não tivesse o codec necessário para transmitir para Alice (PCM
μ-law). O que aconteceria?
Ele enviaria para ela uma mensagem 606 informando que não pôde aceitar o Invite e listaria
todos os codecs que possui.

Ela escolheria um dos codecs listados e enviaria um novo Invite.

Ele, então, poderia aceitar a chamada enviando um 200: OK.
Após o término da conversa, qualquer uma das partes poderia solicitar o término da sessão
enviando uma mensagem Bye. Quando ela for confirmada (ACK) pelo outro usuário, a sessão
será encerrada.
ENDEREÇOS
Para que o SIP possa funcionar, é necessário que cada usuário possua um endereço.No
exemplo anterior, o endereço SIP de Bob era sip:bob@193.64.210.89, ou seja, o nome dele
estava associado a seu endereço IP. Isso, porém, não é a única possibilidade.
Um e-mail ou o telefone fixo convencional também pode ser um endereço SIP.
 Formatos de endereço SIP.
 ATENÇÃO
O endereço SIP tem um recurso muito interessante: a possibilidade de ele ser incluído em
páginas web de forma similar ao que é feito com o e-mail.
Bob poderia colocar seu endereço sip:bob@fhda.edu em uma página web, a qual, ao ser
clicada, fará com que a aplicação SIP do usuário que clicou seja acionada e seja enviado um
Invite para Bob.
Quando o chamador coloca o endereço SIP do tipo e-mail ou telefone fixo convencional no
Invite, a infraestrutura SIP consegue, conforme veremos adiante, descobrir qual é o IP a ser
chamado e roteia a mensagem.
DESCOBRIMENTO DO DESTINATÁRIO DE UMA
CHAMADA
No exemplo que demos, Alice conhecia o IP de Bob. Porém, o que aconteceria se ela não o
conhecesse? Ou se o endereço SIP de Bob fosse sip:bob@fhda.edu? Ou se ele utilizasse um
endereço dinâmico (DHCP)?
COMO BOB PODERIA SER ENCONTRADO?
 RESPOSTA
O SIP utiliza um mecanismo de registro similar ao DNS para poder encontrar o host chamado.
Os servidores de registro do sistema possuem, a todo instante, o registro dos usuários como o
seu endereço IP naquele momento.
Quando alguém precisa chamar determinado endereço SIP, envia um Invite com o endereço do
tipo bob@fhda.edu, o qual, por sua vez, vai ser encaminhado até um servidor proxy. Ele, então,
envia uma mensagem de pesquisa a um dos servidores de registro que possua o endereço IP
de Bob.
Esse servidor lhe responde com o endereço IP. Ao recebê-lo, o proxy o inclui na mensagem de
Invite da chamada, enviando-a ao destinatário.
A figura a seguir ilustra o processo do descobrimento do destinatário de uma chamada.
 Descoberta de destinatário.
REGISTRO DO USUÁRIO
A esta altura, você pode estar se perguntando: como o servidor de registro sabe o IP de Bob?
É aí que entra a mensagem Register do SIP. Quando uma aplicação SIP é acionada em um
dispositivo, ela envia uma mensagem de registro (register) a um servidor de registro
informando seu IP atual.
Eis uma mensagem de registro:
 Mensagem Register.
PROTOCOLOS DE SINALIZAÇÃO PARA VOZ
NA INTERNET
O especialista apresenta o funcionamento dos protocolos de sinalização utilizados para a
comunicação de voz na internet (VoIP).
VERIFICANDO O APRENDIZADO
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Ao longo deste tema, estudamos os protocolos envolvidos na transmissão de mídia,
especialmente naquelas realizadas em tempo real.
No primeiro módulo, após analisarmos as características dos protocolos TCP e UDP,
explicamos por que eles são inadequados para a transmissão multimídia. Em seguida,
descrevemos mais dois protocolos: o RTP, estabelecendo seu cabeçalho e seu funcionamento,
e o RTCP, além de suas mensagens e de sua operação em conjunto com o RTP.
No segundo módulo, nós nos concentramos em protocolos de sinalização para as aplicações
em tempo real. Começamos vendo o padrão H.323 e seus protocolos principais. Por fim,
estudamos o SIP, incluindo seus componentes, suas mensagens e seu funcionamento.
 PODCAST
Agora, o especialista Sidney Nicolau Venturi Filho encerra o tema falando sobre a importância
dos protocolos para aplicações multimídia em tempo real.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
COMER, D. E. Interligação de redes com TCP/IP. 6. ed. Rio de Janeiro: Elsevier, 2015.
FOROUZAN, B. Comunicação de dados e redes de computadores. 4. ed. São Paulo:
McGraw-Hill, 2008.
INTERNET ENGINEERING TASK FORCE. RTP: a transport protocol for real-time applications.
Request for comments: 1889. Consultado em meio eletrônico em: 22 fev. 2021.
KUROSE, J. F.; ROSS, K. W. Redes de computadores e a internet: uma abordagem top-down.
6. ed. Ribeirão Preto: Pearson Education, 2014.
TANENBAUM, A. Redes de computadores. 5. ed. Rio de Janeiro: Campus, 2011.
EXPLORE+
Faça uma pesquisa na internet a respeito destes protocolos:
SDP (session description protocol), que formata as mensagens do SIP.
SCTP (stream control transmission protocol), que pertence à camada de transporte e foi
desenvolvido para fazer a transferência confiável de stream na internet.
CONTEUDISTA
Sidney Nicolau Venturi Filho
 CURRÍCULO LATTES
javascript:void(0);