Voz sobre IP (VoIP)
Marcel Barbosa de Oliveira, Marco Aurelio Goecking Santiago
Ciência da Computação – 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
difusão da Internet. Mas não somente por isso, mas também pelo progresso
das tecnologias de rede. Assim teremos uma grande competitividade no
mercado. O VoIP tem 2 tipos de protocolos: H. 323 O padrão H.323 fornece
uma base para comunicação de áudio, vídeo e dados através de uma rede
baseada em IP, inclusive a Internet e o SIP é um protocolo baseado em texto
que possui a força da Internet, fazendo uso de elementos comuns, tais como: o
formato do HTTP, DNS e o estilo de endereçamento e-mail.
1. Introdução
Nos dias de hoje, temos presenciado uma grande revolução acontecendo nas
telecomunicações, resultante do incrível crescimento das redes baseadas em pacotes,
especialmente pela Internet. Esta revolução está unificando os mundos de Dados e
Telecomunicações em uma só rede convergente ubiqüa.
Esta mudança não 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 "Serviços 0800 na
Rede" estão sendo construídos dentro deste novo paradigma.
A implementação de VoIP nos permite o tráfego de voz (exemplo, chamadas
telefônicas e faxes) sobre uma rede IP.
A proposta de convergência tornou-se tão interessante e importante para a
manutenção da competitividade, que mesmo as operadoras telefônicas tradicionais estão se
rendendo a esta tecnologia. E desenvolvendo soluções para racionalizar o uso de suas infraestruturas baseadas em circuitos fazendo a atualização para comutação de pacotes. Não
somente pelo apelo da redução de custos decorrentes da fusão de duas áreas, mas também
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 evolução do mercado de VoIP são as seguintes:
o Baixo custo das chamadas telefônicas,
o Serviços de valores agregados e mensagem unificada,
o União da infra-estrutura de dados/voz.
O sistema de VoIP consiste de um número 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 mídia por um tipo de rede para o formato requerido por um
outro tipo de rede. O gateway também pode executar mensagens de áudio/vídeo e outras
funções IVR, ou até mesmo executar conferência de mídia.
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
são transportados usando IP de acordo com uma das especificações para transmissão de
multimídia (voz, vídeo, fax e dados) através da rede:
o
H.323 – ITU
o
MGCP – Level3, Bellcore, Cisco, Nortel
o
MEGACO/H2.48 – IETF
o
SIP – IETF
o
T.38 – ITU
Dois padrões 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 padronização, tem mobilizado muitos fabricantes da área da telefonia e
dados, por causa da sua flexibilidade, aderência com padrões genuinamente Internet e
arquitetura aberta.
Os protocolos ITU-T H.323 e SIP serão descritos nas próximas sessões.
2. Arquitetura H.323
2.1 Introdução
O padrão H.323 fornece uma base para comunicação de áudio, vídeo e dados
através de uma rede baseada em IP, inclusive a Internet. O H.323 é um leque de
recomendações da ITU que seta padrões para comunicação de multimídia sobre LANs
(Local Area Networks) que não fornecem uma garantia de qualidade de serviço. Estas redes
dominam o mercado desktops e incluem TCP/IP e IPX sobre as tecnologias de rede
Ethernet, Fast Ethernet e Token Ring. Os padrões H.323 são importantes peças para um
novo range de aplicações para multimídia baseadas em LAN. Isto inclui partes do H.225.0 –
RAS, Q.931/Q.932, H.245, RTP/RTCP e codecs de áudio/vídeo.
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 sinalização H.323 se originam
e terminam. Este pode ser um PC multimídia com aplicação H.323 ou um equipamento
standalone (como um telefone IP conectado a uma porta USB). Um terminal deve suportar
comunicação de áudio, enquanto o suporte a comunicação de vídeo e dados é opcional.
2.2.2 Gateway
Um gateway fornece a tradução do formato dos dados, tradução de sinalização de
controle, tradução de codecs de áudio e vídeo, e funcionalidade de call setup e terminação de
chamada em ambos os lados da rede.
2.2.3 Gatekeeper
Elemento opcional da rede H.323. São necessários para assegurar a confiabilidade e
uma comunicação comercialmente viável. É comumente chamado de cérebro de uma rede
H.323 por causa dos serviços 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 são roteadas através do gatekeeper.
O gatekeeper e os endpoints por ele administrados formam um zona de gerenciamento.
Serviços oferecidos pelo gatekeeper a todos os endpoints em sua zona:
??
Tradução de endereçamento – O gatekeeper mantém uma base de dados para a
tradução entre aliases, tais como números telefônicos internacionais e endereços de rede.
??
Admissão e controle de acesso de endpoints – Este controle pode ser baseado em
disponibilidade de banda, limitação do número de chamadas H.323 simultâneas ou
privilégios de registro de endpoints.
Gerenciamento de banda – Administradores de redes podem gerenciar a banda apenas
especificando limitações no número de chamadas simultâneas e limitando a autorização de
terminais específicos a realizar chamadas em horários específicos.
?? Capacidade de roteamento – Um gatekeeper pode rotear todas as chamadas
originadas ou terminadas em sua zona. Esta capacidade fornece numerosas vantagens.
Primeiro, informação de accouting das chamadas podem ser mantidas para cobrança e
segurança. Segundo, um gatekeeper pode re-rotear uma chamada para um gateway
apropriado baseado na banda disponível. Terceiro, re-roteamento pode ser usado para
desenvolver vários serviços avançados, tais como: endereçamento móvel, call forwarding
e voice mail.
??
2.3.4 MCU – Multipoint Control Unit
Uma MCU possibilita a conferência entre três ou mais endpoints. Consiste
obrigatoriamente de uma controladora multiponto (MC) e zero ou mais processadores
multipontos (MP). Apesar da MCU ser uma unidade lógica 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 localização centralizada para call setup
multiponto. Sinalização de chamada e de controle são roteadas através da MC para que as
capacidades dos endpoints possam ser determinadas e parâmetros de comunicação possam
ser negociados. Uma MC também pode ser usada em uma chamada ponto-a-ponto que mais
tarde pode ser extendida em uma conferência multiponto. O processador multiponto é
responsável pela mixagem, chaveamento e processamento de áudio, vídio e dados entre os
endpoints da conferência.
A MCU é necessária em uma conferência multiponto centralizada onde cada terminal
estabelece uma conexão ponto-a-ponto com a MCU. A MCU determina a capacidade de
cada terminal e envia para cada um feixe de mídia mixado. No modelo de conferência
descentralizada, uma MC assegura a compatibilidade da comunicação mas os feixes de mídia
são multicast e a mixagem é realizada em cada terminal.
2.3 Conceitos dos Protocolos
As mídias são transportadas pelos protocolos RTP/RTCP. O RTP transporta a mídia
e RTCP transporta as informações de status e controle. A sinalização é transportada de forma
confiável sobre TCP. Os seguintes protocolos lidam com a sinalização:
??
RAS – gerencia registro, admissão, status.
??
Q.931 – gerencia call setup e terminação.
??
H.245 – negocia o uso de canais e a capacidade.
Relação dos protocolos H.323 com o modelo OSI.
2.3.1 RTP / RTCP
O RTP (Real-time Transport Protocol) fornece um conjunto de funções de transporte
de rede fim-a-fim para aplicações transmitindo dados em tempo real, tais como: áudio, vídeo
ou dados, sobre serviços de rede multicast ou unicast. RTP não garante qualidade de serviço
para serviços em tempo real.
O RTCP (Real-time Transport Control Protocol) é baseado na transmissão periódica
de pacotes de controle para todos os participantes da sessão, usando o mesmo mecanismo
de distribuição que usado no pacote de dados. O protocolo da camada inferior deve fornecer
multiplexação 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
endereço de um endpoint com seu endereço de transporte do canal de sinalização da
chamada. O canal RAS é um canal não confiável. Já que as mensagens RAS são transmitidas
em um canal não confiável, o H.225.0 recomenda contadores de timeout e retry para várias
mensagens. Um endpoint ou gatekeeper que não pode responder a um pedido com o timeout
específico deve usar a mensagem RIP (Request In Progress) para indicar que ainda está
processando a solicitação. Um endpoint ou gatekeeper que recebe uma mensagem RIP
deverá resetar os contadores de timeout e retry. No item Sinalização de Chamada será
apresentada o procedimento H.225.0 com mais detalhes.
2.3.3 H.245
O H.245 é a linha de transmissão de outros sinais que não são de voz. Estes incluem
capacidade de recepção e transmissão bem como o modo de preferência do ponto de
recepção, canais lógicos de sinalização de controle e indicação. Procedimentos de
confirmação de sinalização são especificados para assegurar comunicação de dados e
audiovisual confiáveis.
As mensagens H.245 são em sintax ASN1. Os tipos de mensagens podem ser
definidos como request, response, command ou indication. O seguinte conjunto de
mensagens estão disponíveis:
??
Mensagem de determinação Master Slave
??
Mensagem de capacidade de terminal
??
Mensagem de sinalização de canal lógico
??
Mensagem de sinalização de tabela de multiplexação
??
Mensagem de Modo Request
??
Mensagem de RTD (Round Trip Delay)
??
Mensagem de Loop de manutenção
??
Mensagens de Request e Responde de conferência
??
TerminalID
??
Commands e Indications
2.4 Sinalização da chamada
Sinalização da chamada são as mensagens e procedimentos usados para estabelecer
uma chamada, solicita mudanças na banda da chamada, recebe status dos endpoints da
chamada e disconecta a chamada. Sinalização da chamada usa mensagens definidas na
H.225.0 e os procedimentos descritos no item Procedimentos de Sinalização 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 serão
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 não é padronizada.
O método automático permite a associação do endpoint – Gatekeeper a qualquer
momento. O endpoint pode não conhecer quem é seu gatekeeper, ou pode ser necessário
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 Endereço de Transporte do canal RAS do gatekeeper. Se um gatekeeper não 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 Automática 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 endereço de transporte e endereço associado. Como parte de seu
processo de configuração, todos os endpoints deverão se registrar com o gatekeeper
descoberto. O registro deverá acontecer antes de que qualquer tentativa de uma chamada e
pode acontecer periodicamente caso seja necessário.
Um endpoint deverá enviar um Registration Request (RRQ) a um gatekeeper. Este
é enviado ao endereço 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 endereço alias associado com o endereço de transporte, ou vice-versa. Se
um endpoint não foi registrado com o gatekeeper, o mesmo deverá retornar uma mensagem
Unregister Reject (URJ) ao endpoint. O gatekeeper também 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 Sinalização da Chamada
O canal de sinalização da chamada é usado para transportar mensagens de controle
de chamada H.225.0. O canal de sinalização deve ser um canal confiável.
Em redes que não possuem um gatekeeper, as mensagens de sinalização da chamada
são passadas diretamente entre os pontos chamador e chamado usando o Endereço de
Transporte de Sinalização de Chamada. Nestas redes, é assumido qie o endpoint chamador
conheça o Endereço de Transporte de Sinalização de Chamada do endpoint chamado e assim
possam se comunicar diretamente.
Nas redes que possuem um gatekeeper, é trocada a mensagem de admissão inicial
entre o endpoint chamador e o gatekeeper usando o endereço de transporte do canal RAS
do gatekeeper. Dentro das mensagens de adimissão trocadas, o gatekeeper indica na
mensagem ACF se a sinalização da chamada será enviada diretamente ao outro endpoint ou
ser será roteada pelo gatekeeper.
No H.225.0 é especificado o uso obrigatório de mensagens Q.931 para a sinalização
de chamada na H.323.
2.6.1 Canal de sinalização de chamada roteada
Mensagens de sinalização de chamada poderão ser trocadas de duas maneiras. O
primeiro método é o roteamento da sinalização de chamada pelo gatekeeper. Neste método,
as mensagens de sinalização de chamada são roteadas através do gatekeeper entre os
endpoints.
Sinalização de Chamada Roteada pelo Gatekeeper
Call Signalling Channel Messages
RAS Channel Messages
Gatekeeper Cloud
1
2
3
Endpoint 1
8
4
5
6
7
1 - ARQ
2 - ACF/ARJ
3 - Setup
4 - Setup
5 - ARQ
6 - ACF/ARJ
7 - Connect
8 - Connect
Endpoint 2
O segundo método é a Sinalização de Chamada Diretamente entre Endpoints. Neste
método as mensagens de sinalização de chamada são trocadas diretamente entre os
endpoints. A escolha de qual método será usado é feita pelo gatekeeper.
Sinalização 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
1
2
4
5
3
Endpoint 1
2.7.1
Endpoint 2
6
Roteamento do canal de controle
Quando a sinalização de chamada roteada pelo gatekeeper é usada, existem dois
métodos para rotear o canal de controle H.245. No primeiro método, o canal de controle
H.245 é estabelecido diretamente entre os endpoints.
Conexão Direta do Canal de Controle H.245 entre os Endpoints
H.245 Control Channel Messages
Call Signalling Channel Messages
RAS Channel Messages
Gatekeeper Cloud
1
2
3
Endpoint 1
8
4
9
5
6
7
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 método, o canal de controle H.245 é roteado entre os endpoints através
do gatekeeper. Este método permite que o gatekeeper redirecione o canal de controle H.245
para uma MC quando uma conferência ponto-a-ponto é trocada para uma conferência multiponto. Esta escolha é feita pelo gatekeeper. Quando é usada a Sinalização de Chamada
Diretamente entre Endpoints, o canal de controle H.245 é obrigatoriamente diretamente
conectado entre os endpoints.
Conexão do Canal de Controle H.245 roteado através do Gatekeeper
H.245 Control Channel Messages
Call Signalling Channel Messages
RAS Channel Messages
Gatekeeper Cloud
1
2
3
8
9
Endpoint 1
4
5
6
7
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 sinalização de chamada
O provisionamento da comunicação é realizada da seguinte maneira:
1) Call setup
2) Comunicação inicial e troca de capacidade
3) Estabelecimento de comunicação audio visual
4) Serviços de chamada
5) Terminação de chamada
2.8.1 Call Setup
É realizada usando as mensagens de controle de chamada definidas no H.225.0 de
acordo com uma série de procedimentos de controle de chamad, abaixo serão descrito dois
procedimentos o call setup básico e call setup onde ambos os endpoints são registrados e a
sinalização de chamada é roteada por ambos os gatekeepers.
2.8.1.1 Call Setup Básico
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 sinalização de chamada do Endpoint 2. O
Endpoint 2 responde com a mensagem Connect (4) que contém o Endereço de Transporte
do Canal de Controle H.245 para uso na sinalização H.245.
Call Setup Básico, 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 são registrados por gatekeepers diferentes e ambos
os gatekeepers escolheram rotear a sinalização da chamada. Endpoint 1 (chamador) inicia a
troca de ARQ (1)/ACF (2) com o gatekeeper 1. O gatekeeper 1 retorna o Endereço de
Transporte do Canal de Sinalização da Chamada dele mesmo na ACF (2). Então, o Endpoint
1 envia a mensagem de Setup (3) usando aquele Endereço de Transporte. Então, o
gatekeeper 1 envia a mensagem de Setup (4) para o Endereço de Transporte do Canal de
Sinalização 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 aceitável, o
gatekeeper 2 retornará seu Endereço de Transporte do Canal de Sinalização da Chamada na
ARJ (7) com o código de causa de routeCallToGatekeeper. O Endpoint 2 responde ao
Gatekeeper 1 com uma mensagem Facility (8) contento o Endereço de Transporte de
Sinalização da Chamada do Gatekeeper 2. Então, o Gatekeeper 1 envia a mensagem de
Release Complete (9) ao Endpoint 2. O Gatekeeper 1 envia a mensagem de Setup (10) para
o Endereço de Transporte do Canal de Sinalização 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. Então, o Endpoint 2 responde ao Gatekeeper 2
com a mensagem Connect (15) que contém seu Endereço de Transporte do Canal de
Controle H.245 para uso da sinalização H.245. O Gatekeeper 2 envia a mensagem Connect
(16) ao Gatekeeper 1 contendo o Endereço de Transporte do Canal de Controle H.245 do
Endpoint 2, ou um Endereço de Transporte do Canal de Controle H.245 do Gatekeeper 2
(MC), baseado na escolha do Gatekeeper 2 do roteamento ou não do Canal de Controle
H.245. O Gatekeeper 1 envia a mensagem de Connect (17) ao Endpoint 1 que deverá conter
o Endereço de Transporte do Canal de Controle H.245 enviado pelo Gatekeeper2, ou um
Endereço de Transporte do Canal de Controle H.245 do Gatekeeper 1 (MC), baseado na
sua escolha do roteamento ou não do Canal de Controle H.245.
Ambos Endpoints Registrados – Sinalização 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 Terminação da Chamada
Qualquer Endpoint pode terminar a chamada seguindo os seguintes procedimentos:
1) Descontinuar a transmissão audio visual e então fechar todos os canais lógicos.
2) Transmitir a mensagem H.245 endSessionCommand no Canal de Controle H.245.
3) Esperar o recebimento da mensagem endSessionCommand do outro endpoint e então
fechar o Canal de Controle H.245.
4) Enviar uma mensagem Release Complete para fechar o Canal de Sinalização de
Chamada.
5) Usar os procedimentos abaixo para desconectar a chamada.
2.9.1
Terminação da Chamada Sem um Gatekeeper
Em redes que não possuem um Gatekeeper, após os 4 passos acima descritos a
chamada é terminada. Nenhum procedimento adcional é requerido.
2.9.2
Terminação da Chamada com um Gatekeeper
Em redes que contém um Gatekeeper, o Gatekeeper precisa ter conhecimento do
release da banda. Após a execução 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 deverão ser
enviadas no canal RAS.
Terminação 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
Terminação 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 então 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.
Terminação 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.1Introdução
SIP (Session Initiation Protocol) é um protocolo baseado em texto que possui a força
da Internet, fazendo uso de elementos comuns, tais como: o formato do HTTP, DNS e o
estilo de endereçamento e-mail. SIP, geralmente, usa o SDP (Session Description Protocol)
para especificar parâmetros da sessão. O SIP fornece os elementos dos protocolos
necessários para fornecer serviços, tais como: call forwarding, call diversion etc.
O endereço SIP (URL) pode ser usado em páginas web e pode então ser integrado
como parte de poderosas aplicações, como por exemplo click-to-talk.
O SIP possui um mecanismo próprio de segurança. Ele cria, modifica e termina
sessões com um ou mais participantes. Estas sessões incluem conferências de multimída na
Internet, chamadas telefônicas via Internet e distribuição de multimídia. O SIP não está
amarrado a nenhum protocolo de controle de conferências 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 terminação de comunicações de multimídia:
??
User location
??
User capabilities
??
User availability
??
Call setup
??
Call handling.
A operação do SIP é baseada em mensagens do tipo Request e Response. O
modelo de básico de operação do SIP consiste em dois SIP UA (user agent) se comunicando
diretamente. Onde os UAs podem ser telefones, aplicações 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
confirmação ao UA chamado.
Operação Básica
O Servidor SIP suporta telefonia baseada em SIP fornecendo um único ponto de
acesso para clientes, mapeando nomes amigáveis em endereços, roteando mensagens de
sinalização entre UAs e redirecionamento de chamadas.
Existem dois tipos de servidores SIP, o Servidor Proxy e o Servidor Redirect. A
operação 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 sinalização.
No modelo de redirecionamento, o servidor redirect SIP deixa que o UA chamador conheça
a localização do UA chamado e então deixa que as mensagens de sinalização subsequentes
sejam trocadas diretamente entre UAs chamador e chamado. No item Operação SIP estas
operações serão melhor descritas.
3.2 Endereçamento
Os endereços SIP, também chamados como SIP URL (Universal Resource Locator),
existe na forma de users@hosts. Similar ao endereço de e-mail, uma SIP URL é identificado
pelo user@host. A parte do endereço referente ao user pode ser um nome de usuário ou um
número telefônico, e a parte do endereço referente ao host pode ser um nome de domínio ou
endereço de rede. Voce pode identificar uma SIP URL do usuário através do seu endereço
e-mail.
3.3 Protocolos
SIP fornece os elementos básicos da telefonia: call setup e terminação, configuração
da chamada e transferência de dados. Estes são alcançados usando SIP para a parte de call
setup e terminação, SDP para descrição da configuração da chamada e RTP para
transferência de dados. RTCP também é 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, serviços de diretórios, serviços de nomes e
um ambiente de desenvolvimento mundialmente conhecido.
O pacotes de áudio e vídeo são transportados usando o RTP sobre o UDP. As
mensagens de sinalização da chamada SIP podem ser transportadas sobre UDP ou TCP,
com o UDP sendo o método preferido devido a melhor performance a escalabilidade. Uma
consideração importante quando estamos usando SIP sobre UDP é que a mensagem inteira
deve ocupar um único pacote. Caso a mensagem SIP seja fragmentada em múltiplos
datagramas, a probabilidade de perda de toda a mensagem aumenta com o número de
fragmentos. Quando as mensagens SIP são transmitidas sobre WAN, as retransmissões que
resultam da perda de fragmentos podem seriamente degradar a performance da sinalização da
chamada. A porta padrão para SIP é 5060 embora qualquer porta disponível possa ser
usada. A porta para ser usada pelo RTP/RTCP é especificada nas mensagens de sinalização
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 sessões SIP. Os parâmetros SDP são 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 cabeçalhos SDP são codificados em texto ASCII. O cabeçalho SDP são da forma
<type>=<value>. O <type> (tipo) é sempre um único caracter e <value> (valor) é uma string
texto cujo formato depende do <type>.
O cabeçalho SDP especifica:
??
Nome da sessão e propósito.
Tempo que a sessão está ativa.
?? A mídia que compreende a sessão.
??
??
Endereço de transporte e formato da mídia da sessão.
??
Largura de banda que será usada pela sessão.
??
Informação de contato para a pessoa responsável pela sessão.
3.5 Mensagens SIP
3.5.1 Mensagens do tipo REQUEST:
??
Invite - Inicia uma sessão.
??
ACK - Confirma a resposta final a um INVITE.
??
Bye - Termina uma sessão.
??
Cancel - Cancela buscas e ringing.
??
Options - Comunica features suportadas.
??
Register - Registra um cliente com um serviço de localização.
3.5.2 Mensagens do tipo RESPONSE:
Indica tanto uma chamada em progresso ou uma informação de final de chamada. Este tipo de
mensagem contém um Código-Status e uma Frase-Razão ou Categoria. O Código-Status é
um número que indica o resultado de um request e a Categoria fornece uma descrição textual
referente ao Código-Status.
Código-status
Categoria
1xx Progress
2xx Successful Request
3xx Redirection
4xx Incorrect Request
5xx Server Failure
6xx Global Failure
3.6 Operação SIP
O SIP funciona da seguinte forma: Origem e destino são identificados por endereços
SIP. Ao efetuar uma chamada SIP, o chamador primeiro localiza o servidor apropriado e
então envia um request SIP. A operação mais comum é a INVITATION. Ao invés de
alcançar diretamente o destino, um SIP request pode ser redirecionado ou pode desencadear
um série de novos SIP requests pelos proxies. Usuários podem registrar suas localizações
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 sinalização entre os UAs de destino e origem. Os pacotes RTP de áudio e/ou
vídeo são enviados diretamente entre os UAs após 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 então procede com o setup da chamada diretamente com o UA de destino.
Operação com Servidor Proxy
Operação com Servidor Redirect
4. Conclusão
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 usuário.
Com implementações VoIP propriamente desenhadas, usuário não serão capazes de
detectar se estão falando através de uma rede de pacotes.
5. Referências Bibliográficas
http://www.voip.nce.ufrj.br
INTELIG TELECOM. Overview VoIP. Rio de Janeiro, 2003.
TELEMAR. Tecnologia Voz Sobre IP. Rio de Janeiro, 2003.