Voz sobre IP (VoIP)

Marcel Barbosa de Oliveira, Marco Aurelio Goecking Santiago

Cincia da Computao Universidade Federal Fluminense (UFF)
Abstract. This paper describes a little bit of the VoIP tecnologie. VoIP
tecnology is evoluating, especially by the difusion of the Internet.Other reason
is the progress of the new network tecnologies.It will have a huge competition
in the telecomunications market. VoIP has 2 types of protocols: the H. 323
standart gives some base for audio, video and data comunications through IP
network and SIP is a protocol based on text that has the power of the Internet,
as: HTTP format, DNS and the e-mail address style.

Resumo. Este artigo descreve um pouco sobre a tecnologia de voz sobre IP. A
tecnologia VoIP est evoluindo nos ltimos anos, devido especialmente pela
difuso da Internet. Mas no somente por isso, mas tambm pelo progresso
das tecnologias de rede. Assim teremos uma grande competitividade no
mercado. O VoIP tem 2 tipos de protocolos: H. 323 O padro H.323 fornece
uma base para comunicao de udio, vdeo e dados atravs de uma rede
baseada em IP, inclusive a Internet e o SIP um protocolo baseado em texto
que possui a fora da Internet, fazendo uso de elementos comuns, tais como: o
formato do HTTP, DNS e o estilo de endereamento e-mail.

1. Introduo
Nos dias de hoje, temos presenciado uma grande revoluo acontecendo nas
telecomunicaes, resultante do incrvel crescimento das redes baseadas em pacotes,
especialmente pela Internet. Esta revoluo est unificando os mundos de Dados e
Telecomunicaes em uma s rede convergente ubiqa.
Esta mudana no se trata apenas de um movimento do mercado, mas demonstra o
progresso da tecnologia de rede. A telefonia baseada em redes de pacotes j d passos
concretos de maturidade, e muitos "Fornecedores de Telefonia IP" e "Servios 0800 na
Rede" esto sendo construdos dentro deste novo paradigma.
A implementao de VoIP nos permite o trfego de voz (exemplo, chamadas
telefnicas e faxes) sobre uma rede IP.
A proposta de convergncia tornou-se to interessante e importante para a
manuteno da competitividade, que mesmo as operadoras telefnicas tradicionais esto se
rendendo a esta tecnologia. E desenvolvendo solues para racionalizar o uso de suas infraestruturas baseadas em circuitos fazendo a atualizao para comutao de pacotes. No

somente pelo apelo da reduo de custos decorrentes da fuso de duas reas, mas tambm
pela possibilidade de prover uma melhor qualidade no transporte da voz, e ao mesmo tempo
economizar em banda passante nacional e internacional.
As principais causas para evoluo do mercado de VoIP so as seguintes:
o Baixo custo das chamadas telefnicas,
o Servios de valores agregados e mensagem unificada,
o Unio da infra-estrutura de dados/voz.
O sistema de VoIP consiste de um nmero de diferentes componentes:
o Gateway/Media Gateway,
o Gatekeeper,
o Call Agent,
o Media Gateway Controller,
o Signaling Gateway,
o Call Manager.
O gateway converte a mdia por um tipo de rede para o formato requerido por um
outro tipo de rede. O gateway tambm pode executar mensagens de udio/vdeo e outras
funes IVR, ou at mesmo executar conferncia de mdia.
No VoIP, o processador de sinal digital (DSP Digital Signaling Processor) segmenta
o sinal de voz em quadros (frames) e os armazena em pacotes de voz. Estes pacotes de voz
so transportados usando IP de acordo com uma das especificaes para transmisso de
multimdia (voz, vdeo, fax e dados) atravs da rede:
o

H.323 ITU

MGCP Level3, Bellcore, Cisco, Nortel

MEGACO/H2.48 IETF

SIP IETF

T.38 ITU

Dois padres principais disputam a hegemonia da Telefonia IP: ITU-T H.323

(International Telecommunications Union), presente em muitos dos equipamentos e softwares
VOIP, e o SIP, proposto pela IETF (Internet Engineering Task Force), que, apesar do curto
tempo do processo de padronizao, tem mobilizado muitos fabricantes da rea da telefonia e
dados, por causa da sua flexibilidade, aderncia com padres genuinamente Internet e
arquitetura aberta.

Os protocolos ITU-T H.323 e SIP sero descritos nas prximas sesses.

2. Arquitetura H.323
2.1 Introduo
O padro H.323 fornece uma base para comunicao de udio, vdeo e dados
atravs de uma rede baseada em IP, inclusive a Internet. O H.323 um leque de
recomendaes da ITU que seta padres para comunicao de multimdia sobre LANs
(Local Area Networks) que no fornecem uma garantia de qualidade de servio. Estas redes
dominam o mercado desktops e incluem TCP/IP e IPX sobre as tecnologias de rede
Ethernet, Fast Ethernet e Token Ring. Os padres H.323 so importantes peas para um
novo range de aplicaes para multimdia baseadas em LAN. Isto inclui partes do H.225.0
RAS, Q.931/Q.932, H.245, RTP/RTCP e codecs de udio/vdeo.
2.2 Elementos da Rede
A arquitetura H.323 possui os seguintes elementos:
??Terminal
??Gateway
??Gatekeeper
??MCU

2.2.1 Terminal
Um terminal ou um cliente, um endpoint onde dados e sinalizao H.323 se originam
e terminam. Este pode ser um PC multimdia com aplicao H.323 ou um equipamento
standalone (como um telefone IP conectado a uma porta USB). Um terminal deve suportar
comunicao de udio, enquanto o suporte a comunicao de vdeo e dados opcional.
2.2.2 Gateway
Um gateway fornece a traduo do formato dos dados, traduo de sinalizao de
controle, traduo de codecs de udio e vdeo, e funcionalidade de call setup e terminao de
chamada em ambos os lados da rede.
2.2.3 Gatekeeper
Elemento opcional da rede H.323. So necessrios para assegurar a confiabilidade e
uma comunicao comercialmente vivel. comumente chamado de crebro de uma rede
H.323 por causa dos servios de controle e gerenciamento centralizado que oferece. Quando
existe um gatekeeper, todos os endpoints (terminais, gateways e MCUs) devem se registrar
com ele. Mensagens de controle de registro de endpoints so roteadas atravs do gatekeeper.
O gatekeeper e os endpoints por ele administrados formam um zona de gerenciamento.
Servios oferecidos pelo gatekeeper a todos os endpoints em sua zona:

??

Traduo de endereamento O gatekeeper mantm uma base de dados para a

traduo entre aliases, tais como nmeros telefnicos internacionais e endereos de rede.

??

Admisso e controle de acesso de endpoints Este controle pode ser baseado em

disponibilidade de banda, limitao do nmero de chamadas H.323 simultneas ou
privilgios de registro de endpoints.

Gerenciamento de banda Administradores de redes podem gerenciar a banda apenas

especificando limitaes no nmero de chamadas simultneas e limitando a autorizao de
terminais especficos a realizar chamadas em horrios especficos.
?? Capacidade de roteamento Um gatekeeper pode rotear todas as chamadas
originadas ou terminadas em sua zona. Esta capacidade fornece numerosas vantagens.
Primeiro, informao de accouting das chamadas podem ser mantidas para cobrana e
segurana. Segundo, um gatekeeper pode re-rotear uma chamada para um gateway
apropriado baseado na banda disponvel. Terceiro, re-roteamento pode ser usado para
desenvolver vrios servios avanados, tais como: endereamento mvel, call forwarding
e voice mail.
??

2.3.4 MCU Multipoint Control Unit

Uma MCU possibilita a conferncia entre trs ou mais endpoints. Consiste
obrigatoriamente de uma controladora multiponto (MC) e zero ou mais processadores
multipontos (MP). Apesar da MCU ser uma unidade lgica separada esta pode ser
combinada dentro de um terminal, gateway ou gatekeeper. A MCU um componente
opcional de uma rede H.323.
A controladora multiponto fornece uma localizao centralizada para call setup
multiponto. Sinalizao de chamada e de controle so roteadas atravs da MC para que as
capacidades dos endpoints possam ser determinadas e parmetros de comunicao possam
ser negociados. Uma MC tambm pode ser usada em uma chamada ponto-a-ponto que mais
tarde pode ser extendida em uma conferncia multiponto. O processador multiponto
responsvel pela mixagem, chaveamento e processamento de udio, vdio e dados entre os
endpoints da conferncia.
A MCU necessria em uma conferncia multiponto centralizada onde cada terminal
estabelece uma conexo ponto-a-ponto com a MCU. A MCU determina a capacidade de
cada terminal e envia para cada um feixe de mdia mixado. No modelo de conferncia
descentralizada, uma MC assegura a compatibilidade da comunicao mas os feixes de mdia
so multicast e a mixagem realizada em cada terminal.
2.3 Conceitos dos Protocolos
As mdias so transportadas pelos protocolos RTP/RTCP. O RTP transporta a mdia
e RTCP transporta as informaes de status e controle. A sinalizao transportada de forma
confivel sobre TCP. Os seguintes protocolos lidam com a sinalizao:
??

RAS gerencia registro, admisso, status.

??

Q.931 gerencia call setup e terminao.

??

H.245 negocia o uso de canais e a capacidade.

Relao dos protocolos H.323 com o modelo OSI.

2.3.1 RTP / RTCP

O RTP (Real-time Transport Protocol) fornece um conjunto de funes de transporte
de rede fim-a-fim para aplicaes transmitindo dados em tempo real, tais como: udio, vdeo
ou dados, sobre servios de rede multicast ou unicast. RTP no garante qualidade de servio
para servios em tempo real.
O RTCP (Real-time Transport Control Protocol) baseado na transmisso peridica
de pacotes de controle para todos os participantes da sesso, usando o mesmo mecanismo
de distribuio que usado no pacote de dados. O protocolo da camada inferior deve fornecer
multiplexao de pacotes de dados e controle, por exemplo: usando portas UDP separadas.

O RTP e RTCP foram projetados para serem independentes das camadas de transporte e
rede.
2.3.2 H225.0 RAS
O canal RAS (Registration, Admission, Status) usado para transportar mensagens
usadas para descobrir o gatekeeper e processos de registros de endpoints que associa um
endereo de um endpoint com seu endereo de transporte do canal de sinalizao da
chamada. O canal RAS um canal no confivel. J que as mensagens RAS so transmitidas
em um canal no confivel, o H.225.0 recomenda contadores de timeout e retry para vrias
mensagens. Um endpoint ou gatekeeper que no pode responder a um pedido com o timeout
especfico deve usar a mensagem RIP (Request In Progress) para indicar que ainda est
processando a solicitao. Um endpoint ou gatekeeper que recebe uma mensagem RIP
dever resetar os contadores de timeout e retry. No item Sinalizao de Chamada ser
apresentada o procedimento H.225.0 com mais detalhes.
2.3.3 H.245
O H.245 a linha de transmisso de outros sinais que no so de voz. Estes incluem
capacidade de recepo e transmisso bem como o modo de preferncia do ponto de
recepo, canais lgicos de sinalizao de controle e indicao. Procedimentos de
confirmao de sinalizao so especificados para assegurar comunicao de dados e
audiovisual confiveis.
As mensagens H.245 so em sintax ASN1. Os tipos de mensagens podem ser
definidos como request, response, command ou indication. O seguinte conjunto de
mensagens esto disponveis:
??

Mensagem de determinao Master Slave

??

Mensagem de capacidade de terminal

??

Mensagem de sinalizao de canal lgico

??

Mensagem de sinalizao de tabela de multiplexao

??

Mensagem de Modo Request

??

Mensagem de RTD (Round Trip Delay)

??

Mensagem de Loop de manuteno

??

Mensagens de Request e Responde de conferncia

??

TerminalID

??

Commands e Indications

2.4 Sinalizao da chamada

Sinalizao da chamada so as mensagens e procedimentos usados para estabelecer
uma chamada, solicita mudanas na banda da chamada, recebe status dos endpoints da
chamada e disconecta a chamada. Sinalizao da chamada usa mensagens definidas na

H.225.0 e os procedimentos descritos no item Procedimentos de Sinalizao de

Chamada.
2.5 Canal RAS
O canal RAS dever ser usado para transportar mensagens usadas para descobrir
gatekeeper e processo de registro de endpoints, j introduzido anteriormente. A seguir sero
descritos estes dois processos.
2.5.1

Descoberta do gatekeeper

A descoberta de um gatekeeper o processo que um endpoint usa para determinar

com qual Gatekeeper dever se registrar. Este pode ser feito manualemte ou
automaticamente. A descoberta manual no padronizada.
O mtodo automtico permite a associao do endpoint Gatekeeper a qualquer
momento. O endpoint pode no conhecer quem seu gatekeeper, ou pode ser necessrio
identificar outro gatekeeper devido a uma falha.
O endpoint dever enviar uma mensagem Gatekeeper Request (GRQ) multicast,
perguntando Quem meu Gatekeeper? Um ou mais gatekeepers podem responder com a
mensagem Gatekeeper Confirmation (GCF) indicando Eu posso ser seu Gatekeeper, e
retorna o Endereo de Transporte do canal RAS do gatekeeper. Se um gatekeeper no quer
que um endpoint se registre, este dever retornar uma mensagem Gatekeeper Reject
(GRJ). Se mais de um gatekeeper responde, o endpoint dever escolher qual gatekeeper
quer usar.
Descoberta Automtica H.323

Endpoint

Gatekeeper
GRQ

GCF/GRJ

2.5.2

Registro do endpoint

Registro o processo pelo qual um endpoint se junta a uma zona e informa ao

gatekeeper do seu endereo de transporte e endereo associado. Como parte de seu
processo de configurao, todos os endpoints devero se registrar com o gatekeeper

descoberto. O registro dever acontecer antes de que qualquer tentativa de uma chamada e
pode acontecer periodicamente caso seja necessrio.
Um endpoint dever enviar um Registration Request (RRQ) a um gatekeeper. Este
enviado ao endereo de transporte do canal RAS do gatekeeper. O gatekeeper dever
responder com um Registration Confirmation (RCF) ou um Registration Reject (RRJ).
Um endpoint dever se registrar com um nico gatekeeper. Um endpoint poder cancelar seu
registro enviando uma mensagem Unregister Request (URQ) ao gatekeeper. O gatekeeper
dever responder com uma mensagem Unregister Confirmation (UCF). Isto permite ao
endpoint mudar o endereo alias associado com o endereo de transporte, ou vice-versa. Se
um endpoint no foi registrado com o gatekeeper, o mesmo dever retornar uma mensagem
Unregister Reject (URJ) ao endpoint. O gatekeeper tambm poder cancelar o registro de
um endpoint enviando uma mensagem URQ ao endpoint e o endpoint dever responder com
uma mensagem UCF.
Registro H.323

Endpoint

Gatekeeper
RRQ

RCF or RRJ

URQ

UCF/URJ

Endpoint
Endpoint initiated
iniciou
Unregister Request

Unregister Request

URQ
Gatekeeper initiated
iniciou
Gatekeeper

UCF

Unregister
Request
Unregister
Request

2.6 Canal de Sinalizao da Chamada

O canal de sinalizao da chamada usado para transportar mensagens de controle
de chamada H.225.0. O canal de sinalizao deve ser um canal confivel.

Em redes que no possuem um gatekeeper, as mensagens de sinalizao da chamada

so passadas diretamente entre os pontos chamador e chamado usando o Endereo de
Transporte de Sinalizao de Chamada. Nestas redes, assumido qie o endpoint chamador
conhea o Endereo de Transporte de Sinalizao de Chamada do endpoint chamado e assim
possam se comunicar diretamente.
Nas redes que possuem um gatekeeper, trocada a mensagem de admisso inicial
entre o endpoint chamador e o gatekeeper usando o endereo de transporte do canal RAS
do gatekeeper. Dentro das mensagens de adimisso trocadas, o gatekeeper indica na
mensagem ACF se a sinalizao da chamada ser enviada diretamente ao outro endpoint ou
ser ser roteada pelo gatekeeper.
No H.225.0 especificado o uso obrigatrio de mensagens Q.931 para a sinalizao
de chamada na H.323.
2.6.1 Canal de sinalizao de chamada roteada
Mensagens de sinalizao de chamada podero ser trocadas de duas maneiras. O
primeiro mtodo o roteamento da sinalizao de chamada pelo gatekeeper. Neste mtodo,
as mensagens de sinalizao de chamada so roteadas atravs do gatekeeper entre os
endpoints.

Sinalizao de Chamada Roteada pelo Gatekeeper

Call Signalling Channel Messages
RAS Channel Messages

Gatekeeper Cloud

Endpoint 1

1 - ARQ
2 - ACF/ARJ
3 - Setup
4 - Setup
5 - ARQ
6 - ACF/ARJ
7 - Connect
8 - Connect

Endpoint 2

O segundo mtodo a Sinalizao de Chamada Diretamente entre Endpoints. Neste

mtodo as mensagens de sinalizao de chamada so trocadas diretamente entre os
endpoints. A escolha de qual mtodo ser usado feita pelo gatekeeper.

Sinalizao de Chamada Diretamente entre Endpoints

Call Signalling Channel Messages

1 - ARQ
2 - ACF/ARJ
3 - Setup
4 - ARQ
5 - ACF/ARJ
6 - Connect

RAS Channel Messages

Gatekeeper Cloud

3
Endpoint 1

2.7.1

Endpoint 2

Roteamento do canal de controle

Quando a sinalizao de chamada roteada pelo gatekeeper usada, existem dois

mtodos para rotear o canal de controle H.245. No primeiro mtodo, o canal de controle
H.245 estabelecido diretamente entre os endpoints.

Conexo Direta do Canal de Controle H.245 entre os Endpoints

H.245 Control Channel Messages

Call Signalling Channel Messages
RAS Channel Messages

Gatekeeper Cloud

Endpoint 1

Endpoint 2

1 - ARQ
2 - ACF/ARJ
3 - Setup
4 - Setup
5 - ARQ
6 - ACF/ARJ
7 - Connect
8 - Connect
9 - H.245 Channel

No segundo mtodo, o canal de controle H.245 roteado entre os endpoints atravs

do gatekeeper. Este mtodo permite que o gatekeeper redirecione o canal de controle H.245
para uma MC quando uma conferncia ponto-a-ponto trocada para uma conferncia multiponto. Esta escolha feita pelo gatekeeper. Quando usada a Sinalizao de Chamada
Diretamente entre Endpoints, o canal de controle H.245 obrigatoriamente diretamente
conectado entre os endpoints.
Conexo do Canal de Controle H.245 roteado atravs do Gatekeeper

H.245 Control Channel Messages

Call Signalling Channel Messages
RAS Channel Messages

Gatekeeper Cloud

Endpoint 1

10

1 - ARQ
2 - ACF/ARJ
3 - Setup
4 - Setup
5 - ARQ
6 - ACF/ARJ
7 - Connect
8 - Connect
9 - H.245 Channel
10 - H.245 Channel

Endpoint 2

2.8 Procedimentos de sinalizao de chamada

O provisionamento da comunicao realizada da seguinte maneira:

1) Call setup
2) Comunicao inicial e troca de capacidade
3) Estabelecimento de comunicao audio visual
4) Servios de chamada
5) Terminao de chamada

2.8.1 Call Setup

realizada usando as mensagens de controle de chamada definidas no H.225.0 de
acordo com uma srie de procedimentos de controle de chamad, abaixo sero descrito dois
procedimentos o call setup bsico e call setup onde ambos os endpoints so registrados e a
sinalizao de chamada roteada por ambos os gatekeepers.

2.8.1.1 Call Setup Bsico

Neste tipo de call setup, nenhum dos endpoints registrado a um gatekeeper. Os dois
endpoints se comunicam diretamente. O Endpoint 1 (chamador) envia a mensagem setup (1)
para o conhecido identificador TSAP do canal de sinalizao de chamada do Endpoint 2. O
Endpoint 2 responde com a mensagem Connect (4) que contm o Endereo de Transporte
do Canal de Controle H.245 para uso na sinalizao H.245.
Call Setup Bsico, Sem Gatekeepers

Endpoint 1

Endpoint 2

Setup(1)

Call proceeding(2)

Alerting(3)
Connect(4)

Call Signalling Messages

2.8.1.2 Call Setup Roteada Pelos Gatekeepers

Neste tipo, ambos os endpoints so registrados por gatekeepers diferentes e ambos
os gatekeepers escolheram rotear a sinalizao da chamada. Endpoint 1 (chamador) inicia a
troca de ARQ (1)/ACF (2) com o gatekeeper 1. O gatekeeper 1 retorna o Endereo de
Transporte do Canal de Sinalizao da Chamada dele mesmo na ACF (2). Ento, o Endpoint
1 envia a mensagem de Setup (3) usando aquele Endereo de Transporte. Ento, o
gatekeeper 1 envia a mensagem de Setup (4) para o Endereo de Transporte do Canal de

Sinalizao da Chamada conhecido do Endpoint 2. Se o Endpoint 2 deseja aceitar a

chamada, este inicia a troca de ARQ (6)/ACF (7) com o gatekeeper 2. Se aceitvel, o
gatekeeper 2 retornar seu Endereo de Transporte do Canal de Sinalizao da Chamada na
ARJ (7) com o cdigo de causa de routeCallToGatekeeper. O Endpoint 2 responde ao
Gatekeeper 1 com uma mensagem Facility (8) contento o Endereo de Transporte de
Sinalizao da Chamada do Gatekeeper 2. Ento, o Gatekeeper 1 envia a mensagem de
Release Complete (9) ao Endpoint 2. O Gatekeeper 1 envia a mensagem de Setup (10) para
o Endereo de Transporte do Canal de Sinalizao da Chamada do Gatekeeper 2. O
Gatekeeper 2 envia mensagem de Setup (11) ao Endpoint 2. O Endpoint 2 inicia a troca de
ARQ (12)/ACF (13) com o Gatekeeper 2. Ento, o Endpoint 2 responde ao Gatekeeper 2
com a mensagem Connect (15) que contm seu Endereo de Transporte do Canal de
Controle H.245 para uso da sinalizao H.245. O Gatekeeper 2 envia a mensagem Connect
(16) ao Gatekeeper 1 contendo o Endereo de Transporte do Canal de Controle H.245 do
Endpoint 2, ou um Endereo de Transporte do Canal de Controle H.245 do Gatekeeper 2
(MC), baseado na escolha do Gatekeeper 2 do roteamento ou no do Canal de Controle
H.245. O Gatekeeper 1 envia a mensagem de Connect (17) ao Endpoint 1 que dever conter
o Endereo de Transporte do Canal de Controle H.245 enviado pelo Gatekeeper2, ou um
Endereo de Transporte do Canal de Controle H.245 do Gatekeeper 1 (MC), baseado na
sua escolha do roteamento ou no do Canal de Controle H.245.
Ambos Endpoints Registrados Sinalizao de Chamada Roteada por Ambos os
Gatekeepers

Endpoint 1

Gatekeeper 2

Gatekeeper 1

Endpoint 2

ARQ(1)
ACF(2)
Setup(3)
Setup(4)

Call Proceeding(5)

Call Proceeding(5)
ARQ(6)
ARJ(7)
Facility(8)
Release Complete(9)

Setup(10)
Setup(11)
Call Proceeding(5)
Call Proceeding(5)
ARQ(12)
ACF/ARJ(13)
Alerting(14)

Alerting(14)

Alerting(14)
Connect(15)

Connect(17)

RAS Messages
Call Signalling Messages

Connect(16)

2.9 Terminao da Chamada

Qualquer Endpoint pode terminar a chamada seguindo os seguintes procedimentos:
1) Descontinuar a transmisso audio visual e ento fechar todos os canais lgicos.
2) Transmitir a mensagem H.245 endSessionCommand no Canal de Controle H.245.
3) Esperar o recebimento da mensagem endSessionCommand do outro endpoint e ento
fechar o Canal de Controle H.245.
4) Enviar uma mensagem Release Complete para fechar o Canal de Sinalizao de
Chamada.
5) Usar os procedimentos abaixo para desconectar a chamada.

2.9.1

Terminao da Chamada Sem um Gatekeeper

Em redes que no possuem um Gatekeeper, aps os 4 passos acima descritos a

chamada terminada. Nenhum procedimento adcional requerido.
2.9.2

Terminao da Chamada com um Gatekeeper

Em redes que contm um Gatekeeper, o Gatekeeper precisa ter conhecimento do

release da banda. Aps a execuo dos passos de 1 a 4 acima, cada endpoint transmite uma
mensagem H.225.0 Disengage Request (DRQ) (3) para o Gatekeeper. O Gatekeeper
responde com uma mensagem Disengage Confirm (DCF) (4). Neste ponto a chamada
terminada. A figura abaixo mostra o modelo da Chamada Direta, um procedimento similar
realizado para o modelo Roteado pelo Gatekeeper. As mensagens DRQ e DCF devero ser
enviadas no canal RAS.
Terminao da Chamada Iniciada pelo Endpoint

Gatekeeper 1

Endpoint 1

Endpoint 2

Gatekeeper 2

EndSessionCommand(1)

EndSessionCommand(1)

Release Complete (2)

DRQ(3)
DRQ(3)
DCF(4)
DCF(4)

RAS messages
Call Signalling messages
H.245 messages

Note: Gatekeeper 1 and

Gatekeeper 2 may be
the same Gatekeeper.

2.9.3

Terminao da Chamada pelo Gatekeeper

O gatekeeper pode terminar uma chamada enviando uma DRQ para um endpoint. O
Endpoint imediatamente segue os passos de 1 a 4 e ento responde ao Gatekeeper com uma
DCF. O outro endpoint, recebendo endSessionCommand deve seguir os procedimentos
descritos acima. A figura abaixo mostra o modelo de Chamada Direta, um procedimento
similar realizado para o modelo Roteado pelo Gatekeeper.

Terminao de Chamada Iniciada pelo Gatekeeper

Gatekeeper 1

Endpoint 1

Endpoint 2

Gatekeeper 2

DRQ(3)
EndSessionCommand(1)

EndSessionCommand(1)

Release Complete (2)

DCF(4)
DRQ(3)
DCF(4)

RAS messages
Call Signalling messages
H.245 messages

Note: Gatekeeper 1 and

Gatekeeper 2 may be
the same Gatekeeper.

3. SIP
3.1Introduo
SIP (Session Initiation Protocol) um protocolo baseado em texto que possui a fora
da Internet, fazendo uso de elementos comuns, tais como: o formato do HTTP, DNS e o
estilo de endereamento e-mail. SIP, geralmente, usa o SDP (Session Description Protocol)
para especificar parmetros da sesso. O SIP fornece os elementos dos protocolos
necessrios para fornecer servios, tais como: call forwarding, call diversion etc.
O endereo SIP (URL) pode ser usado em pginas web e pode ento ser integrado
como parte de poderosas aplicaes, como por exemplo click-to-talk.
O SIP possui um mecanismo prprio de segurana. Ele cria, modifica e termina
sesses com um ou mais participantes. Estas sesses incluem conferncias de multimda na

Internet, chamadas telefnicas via Internet e distribuio de multimdia. O SIP no est

amarrado a nenhum protocolo de controle de conferncias em particular. Este foi projetado
para ser independente dos protocolos de transporte da camada inferior e pode ser extendido
com capacidade adcional.
SIP suporta 5 tipos de estabelecimento e terminao de comunicaes de multimdia:
??

User location

??

User capabilities

??

User availability

??

Call setup

??

Call handling.

A operao do SIP baseada em mensagens do tipo Request e Response. O

modelo de bsico de operao do SIP consiste em dois SIP UA (user agent) se comunicando
diretamente. Onde os UAs podem ser telefones, aplicaes ou gateways interfaceando a
PSTN. O UA chamado pode aceitar o convite confirmando-o com uma resposta de OK.
Finalmente, o UA chamador vai fechar loop com o UA chamado enviando de volta uma
confirmao ao UA chamado.
Operao Bsica

O Servidor SIP suporta telefonia baseada em SIP fornecendo um nico ponto de

acesso para clientes, mapeando nomes amigveis em endereos, roteando mensagens de
sinalizao entre UAs e redirecionamento de chamadas.
Existem dois tipos de servidores SIP, o Servidor Proxy e o Servidor Redirect. A
operao do SIP depende do tipo de servidor usado. No modelo proxy, o servidor proxy
SIP o nico ponto de contato que os UAs possuem para troca de mensagens de sinalizao.
No modelo de redirecionamento, o servidor redirect SIP deixa que o UA chamador conhea

a localizao do UA chamado e ento deixa que as mensagens de sinalizao subsequentes

sejam trocadas diretamente entre UAs chamador e chamado. No item Operao SIP estas
operaes sero melhor descritas.
3.2 Endereamento
Os endereos SIP, tambm chamados como SIP URL (Universal Resource Locator),
existe na forma de users@hosts. Similar ao endereo de e-mail, uma SIP URL identificado
pelo user@host. A parte do endereo referente ao user pode ser um nome de usurio ou um
nmero telefnico, e a parte do endereo referente ao host pode ser um nome de domnio ou
endereo de rede. Voce pode identificar uma SIP URL do usurio atravs do seu endereo
e-mail.

3.3 Protocolos
SIP fornece os elementos bsicos da telefonia: call setup e terminao, configurao
da chamada e transferncia de dados. Estes so alcanados usando SIP para a parte de call
setup e terminao, SDP para descrio da configurao da chamada e RTP para
transferncia de dados. RTCP tambm usado para o gerenciamento do transporte de
dados.
SIP pode ser executado sobre qualquer datagrama ou protocolo de transporte, tais
como: UDP, TCP, ATM e Frame Relay. SIP usualmente executado sobre TCP/IP por
causa da conectividade amplamente difundida, servios de diretrios, servios de nomes e
um ambiente de desenvolvimento mundialmente conhecido.
O pacotes de udio e vdeo so transportados usando o RTP sobre o UDP. As
mensagens de sinalizao da chamada SIP podem ser transportadas sobre UDP ou TCP,
com o UDP sendo o mtodo preferido devido a melhor performance a escalabilidade. Uma
considerao importante quando estamos usando SIP sobre UDP que a mensagem inteira
deve ocupar um nico pacote. Caso a mensagem SIP seja fragmentada em mltiplos
datagramas, a probabilidade de perda de toda a mensagem aumenta com o nmero de
fragmentos. Quando as mensagens SIP so transmitidas sobre WAN, as retransmisses que
resultam da perda de fragmentos podem seriamente degradar a performance da sinalizao da
chamada. A porta padro para SIP 5060 embora qualquer porta disponvel possa ser
usada. A porta para ser usada pelo RTP/RTCP especificada nas mensagens de sinalizao
da chamada SIP.
Pilha de Protocolos SIP

3.4 SDP
O SIP geralmente faz uso do SDP (Session Description Protocol) para descrever os
atributos das sesses SIP. Os parmetros SDP so encapsulados como corpo da mensagem
de um request SIP. SDP executa uma regra similar quela do H.245 no mundo H.323. Como
o SIP, os cabealhos SDP so codificados em texto ASCII. O cabealho SDP so da forma
<type>=<value>. O <type> (tipo) sempre um nico caracter e <value> (valor) uma string
texto cujo formato depende do <type>.

O cabealho SDP especifica:

??

Nome da sesso e propsito.

Tempo que a sesso est ativa.

?? A mdia que compreende a sesso.
??

??

Endereo de transporte e formato da mdia da sesso.

??

Largura de banda que ser usada pela sesso.

??

Informao de contato para a pessoa responsvel pela sesso.

3.5 Mensagens SIP

3.5.1 Mensagens do tipo REQUEST:

??

Invite - Inicia uma sesso.

??

ACK - Confirma a resposta final a um INVITE.

??

Bye - Termina uma sesso.

??

Cancel - Cancela buscas e ringing.

??

Options - Comunica features suportadas.

??

Register - Registra um cliente com um servio de localizao.

3.5.2 Mensagens do tipo RESPONSE:

Indica tanto uma chamada em progresso ou uma informao de final de chamada. Este tipo de
mensagem contm um Cdigo-Status e uma Frase-Razo ou Categoria. O Cdigo-Status
um nmero que indica o resultado de um request e a Categoria fornece uma descrio textual
referente ao Cdigo-Status.

Cdigo-status

Categoria

1xx Progress
2xx Successful Request
3xx Redirection
4xx Incorrect Request
5xx Server Failure
6xx Global Failure

3.6 Operao SIP

O SIP funciona da seguinte forma: Origem e destino so identificados por endereos
SIP. Ao efetuar uma chamada SIP, o chamador primeiro localiza o servidor apropriado e
ento envia um request SIP. A operao mais comum a INVITATION. Ao invs de
alcanar diretamente o destino, um SIP request pode ser redirecionado ou pode desencadear
um srie de novos SIP requests pelos proxies. Usurios podem registrar suas localizaes
com servidores SIP.
3.7 Servidor Proxy
O modelo de chamada proxy faz uso de um servidor proxy. Este servidor usa uma
regra similar ao servidor proxy usado em um sistema HTTP. O servidor proxy roteia as
mensagens de sinalizao entre os UAs de destino e origem. Os pacotes RTP de udio e/ou
vdeo so enviados diretamente entre os UAs aps o estabelecimento da chamada.
3.8 Servidor Redirector
O servidor redirect SIP informa ao UA de origem a SIP URL do UA de destino. O
UA de origem ento procede com o setup da chamada diretamente com o UA de destino.

Operao com Servidor Proxy

Operao com Servidor Redirect

4. Concluso
O uso de rede de pacotes para transmitir voz uma proposta desafiadora. Porque
devemos tomar alguns cuidados como:
?? A voz deve ser adaptada de uma forma eficiente para a rede de pacotes.
?? Problemas de rede tais como, jitter, perda de pacotes e pacotes fora de ordem
devem ser mascarados do usurio.
Com implementaes VoIP propriamente desenhadas, usurio no sero capazes de
detectar se esto falando atravs de uma rede de pacotes.

5. Referncias Bibliogrficas
http://www.voip.nce.ufrj.br
INTELIG TELECOM. Overview VoIP. Rio de Janeiro, 2003.
TELEMAR. Tecnologia Voz Sobre IP. Rio de Janeiro, 2003.