WirelessBR |
WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade comercial, feito por voluntários, para divulgação de tecnologia em telecomunicações |
|
Série de artigos sobre VoIP (5) |
||
José de Ribamar Smolka Ramos |
Série
de artigos sobre
VoIP
Quinto artigo - Parte 05
Série VoIP (5) – Sinalização
(continuação)
Em paralelo com o H.323, embora com algum atraso, o IETF atacou o mesmo problema formando dois working groups, chamados SIP (session initiation protocol[1]) e SIPPING (session initiation proposal identification[2]). O trabalho destes grupos definiu um framework genérico onde todos os tipos de interação entre endpoints multimídia (chamados, neste contexto, de user agents) pudessem se encaixar, e depois acrescentou os detalhes específicos (profiles) para o tratamento de cada situação particular. Este processo só ficou razoavelmente completo a partir de 2002, e todo o conjunto de RFCs (pela minha última contagem são quase 70 RFCs, fora os drafts) passou a ser chamado de família SIP.
No modelo SIP, são utilizados os seguintes componentes de software:
User agent (UA) – elemento responsável pela originação e recepção das chamadas. O UA que solicita o estabelecimento da conexão é o user agent client (UAC), e o UA que recebe a solicitação é o user agent server (UAS);
Proxy server – elemento que intermedia conexões entre UAs;
Redirect server – elemento que indica a localização atual dos UAs;
Registrar server – elemento que mantém o registro dos UAs disponíveis na rede. Geralmente co-locado com o redirect server.
O modelo de call setup é, essencialmente, peer to peer entre os UAs (um servidor de aplicação tembém é um UA). A utilização de um proxy server geralmente é devida a necessidades de tradução de formatos de mensagem entre UAs com capacidades diferentes.
O diálogo entre os UAs pode ser dividido em cinco facetas:
Location – determinação do endereço IP associado à localização atual do destinatário da chamada. No modelo SIP, a identificação dos UAs segue o modelo usual da Internet, no formato userid@domain;
Availability – determinação da disponibilidade do UA de destino para aceitar a chamada (ele pode estar desligado temporariamente, ou pode estar ocupado com outra chamada);
Capabilities – determinação das características dos UAs necessárias para o encaminhamento da chamada, a depender da mídia utilizada;
Call setup – estabelecimento das características que serão utilizadas na chamada e “tocar a campainha” no UA de destino;
Call handling – tratamento de situações como transferência e terminação de chamadas.
Estas facetas de diálogo são implementadas através dos métodos do protocolo. Cada método passa uma série de informações entre os UAs, e é executado em modo transacional (request-response). Os principais métodos são:
REGISTER – sinaliza para o registrar server a disponibilidade e localização atual de um UA;
OPTIONS – consulta para verificar as características de um UA;
INVITE – sinaliza para o UA de destino que o UA de origem deseja estabelecer uma conexão;
ACK – confirma o estabelecimento da conexão iniciada com o INVITE;
CANCEL – cancela solicitações pendentes;
BYE – pode ser enviado por qualquer dos UAs envolvidas na conexão, e sinaliza para a(s) outra(s) parte(s) o encerramento da chamada.
O fluxo de dados entre os UAs, irá variar, conforme seja utilizado ou não um proxy server entre eles. As figuras 8 e 9 mostram o processo de call setup, de forma simplificada, para as situações onde, respectivamente, exista ou não um proxy server entre os UAs.
Comparando estas figuras com a figura 7, fica evidente a preocupação do IETF em especificar um modelo de comunicação simples e que preserva o end-to-end principle.
Figura 8 – Call setup SIP, com proxy server
Figura 9 – Call setup SIP, com redirect server
Muito bem... Meu headiness index meter agora já está indicando +2, o que, considerando as circunstâncias, já é bem aceitável.
Pelo que vimos, tanto o modelo H.323 quanto o modelo SIP são capazes de resolver o problema genérico de comunicações multimídia em ambientes distribuídos sobre TCP/IP. Qual dos dois é melhor? Depende da sua situação particular. Até uns dois anos atrás, eu responderia que para soluções carrier-grade o melhor era optar pelo H.323. Hoje em dia, o SIP já está bem estabelecido, e ganhando impulso mesmo em ambientes onde a cultura bellhead é forte. Portanto já me sinto em condições de, como dizem os americanos, put my money where my mouth is com relação ao SIP.
Deve ter dado para observar, pelos diagramas de call setup, tanto do H.323 quanto do SIP, que ambos são capazes de manter informações sobre a localização na rede (determinação do endereço IP) de um determinado usuário, com certa vantagem para o SIP no caso de usuários móveis. O que os diagramas não mostram é como seria montado um esquema de troca confiável de informações de registro e localização de usuários entre domínios administrativos diferentes. Este é o assunto do último tópico deste artigo.