Redes - VoIP SIP

1 Voz sobre IP - VoIP Luiz Arthur

SIP - Protocolo de Inicialização de Sessão

O SIP (Session Initiation Protocol - Protocolo de Inicialização de Sessão) é um
protocolo de aplicação e sinalização usado para estabelecer, manter e terminar
sessões multimídia. Dentre essas sessões multimídias estão incluídas voz sobre
IP, telefonia IP, conferências de áudio e vídeo, e outras aplicações similares
envolvendo áudio, vídeo e dados.

O SIP foi definido em março de 1999 no RFC 2543 do grupo de trabalho
MMUSIC (Multiparty Multimedia Session Control) do IETF. Pode-se usar o SIP
para estabelecer sessões de mídia e transportar descrições de sessões dessas. O
SIP suporta sessões unicast e multicast bem como chamadas ponto-a-ponto e
multiponto.

SIP é um protocolo de aplicação baseado em texto, que utiliza o modelo
requisição-resposta, similar ao HTTP, para iniciar sessões de comunicação
interativa entre usuários, estabelecer chamadas e conferências através de redes
via IP. Além disso, não utiliza o padrão H.323, e possui os seus próprios
mecanismos de segurança e confiabilidade.

Dentre os vários protocolos VoIP de sinalização, o SIP está se tornando
rapidamente um padrão de mercado para novas implementações, devido à
grande quantidade de serviços agregados que oferece, estrutura relativamente
simples (semelhante ao protocolo HTTP) e facilidade de desenvolvimento de
novos produtos.


SIP - Protocolo de Inicialização de Sessão

Em geral, o SIP é utilizado em conjunto com outros protocolos também
especificados pelo IETF.

Por exemplo, o RTP/RTCP são utilizados para transportar dados em tempo real e
prover informações sobre Qualidade de Serviço (QoS).

Outros protocolos utilizados pelo SIP são: RTSP (Real-Time Streaming Protocol)
para controlar a entrega de fluxos de distribuição de mídia; o MGCP e o
Megaco/H248 para controlar gateways de mídia, e o SDP (Session Description
Protocol) para descrever sessões multimídia. Outros protocolos também
podem ser utilizados em conjunto com o SIP para prover serviços especializados
aos usuários.

Independente da necessidade de outros protocolos para viabilizar a comunicação
entre os participantes de uma sessão, o SIP oferece primitivas que podem ser
utilizadas para estabelecer, modificar e terminar uma sessão. Assim, o
tratamento da sinalização de uma comunicação é independente do tratamento do
transporte de mídias.

Como exemplo de funções básicas do SIP, podem ser destacadas: localização
de uma terminação, sinalização do desejo de se comunicar, negociação dos
parâmetros necessários para estabelecer a sessão e término da sessão.


Os principais componentes/elementos da arquitetura do SIP são: User Agents e
Network Servers.

User Agents SIP

Os User Agents podem ser um cliente (UAC - User Agent Client), capaz de
iniciar requisições SIP; ou um servidor (UAS - User Agent Server), capaz de
receber e responder a requisições SIP.

O Agente do Usuário é o terminal SIP ou o software de estação final.

Funciona como um cliente no pedido de inicialização de sessão e também
como um servidor quando responde a um pedido de sessão. Além disso, é
considerado inteligente, pois armazena e gerencia situações de chamada. Dessa
forma, a arquitetura básica é cliente/servidor.

Os User Agents fazem chamadas utilizando um endereço parecido com o de e-
mail ou número de telefone, como por exemplo:
SIP:user@proxy.university.edu. Isso faz URLs SIP fáceis de associar com o
endereço de e-mail do usuário.

Um agente do usuário pode aceitar e receber chamadas de outro agente sem
requerer nenhum componente adicional do SIP. Esses componentes restantes
fornecem gerenciamento e funcionalidades adicionais.


Network Servers

Os Network Servers que se dividem em três tipos, sendo:

● Servidor Proxy, atua tanto como um servidor como um cliente, com o
propósito de fazer requisições SIP em benefício de outros clientes que não
podem fazer as requisições diretamente;
● Servidor de redirecionamento (Servidor Redirect), que ao invés de
repassar pacotes, envia um para o remetente, avisando quem é o próximo
servidor, mapeando endereços.
● Servidor de registro (Servidor Registrar) que recebe atualizações da
localização dos usuários na rede, aceitando requisições do tipo REGISTER;

A dualidade do agente SIP possibilita a comunicação ponto-a-ponto com
outros agentes sem a necessidade de utilização dos servidores. O agente é
normalmente implementado em telefones IP, softphones e adaptadores de
telefones analógicos (ATA).

Os demais elementos são necessários quando a estrutura da rede VoIP aumenta.

Por exemplo, entre suas diversas funções o servidor proxy pode reescrever o
cabeçalho das mensagens antes de encaminhá-las para o devido destino, que
pode ser um agente ou mesmo outro servidor proxy.


O servidor de redirecionamento orienta os servidores proxy com respeito ao
próximo passo na rota para o receptor da mensagem SIP.

Qualquer agente SIP deve, primeiramente, registrar-se no servidor de
registro para poder iniciar chamadas no sistema.

As informações sobre localização deve constantemente ser renovadas pelo
agente, com base no tempo de expiração desses registros. A manutenção correta
dessas informações permite o direcionamento adequado das chamadas para os
agentes destinatários.

Servidor Proxy SIP

O Servidor Proxy SIP passa requisições adiante do Agente do Usuário para o
próximo servidor SIP e também retem informações com a finalidade de
contabilidade/ faturamento.

Além disso, pode operar com comunicação stateful (por exemplo, como um
circuito) ou stateless (como um TCP, por exemplo).

O servidor SIP stateful pode dividir chamadas por ordem de chegada para que
várias extensões estejam tocando de uma vez e o primeiro que atender pega
a chamada.


Essa capacidade significa que pode especificar que seu telefone de desktop SIP,
seu telefone celular SIP e suas aplicações de videoconferência de casa SIP
possam TOCAR todas ao mesmo tempo quando qualquer chamada de chegada, e
você atende de alguma dessas locações e começa a conversar enquanto a outras
duas locações param de tocar.

O servidor proxy SIP pode utilizar múltiplos métodos para tentar resolver o
pedido de endereço de host, incluindo busca de DNS, busca em base de dados
ou retransmitir o pedido para o próximo servidor proxy.

Servidor de Redirecionamento SIP

A função do servidor de redirecionamento SIP é fornecer a resolução de nome e
locação do usuário. O servidor de redirecionamento SIP reponde ao pedido do
Agente do Usuário fornecendo informações sobre o endereço do servidor
para que o cliente possa contatar o endereço diretamente.

Registrador SIP - Registrar

O Registrador SIP fornece um serviço de informação de localidades, ele
recebe informações do Agente do Usuário e armazena essa informação de
registro. É um servidor que aceita pedidos Register, ele também pode
implementar outras funções SIP, um registrar pode estar localizado com outros
servidores SIP.


Os resgistrars são necessários para manter-se informado da localização
atual de um usuário. Pois o endereço IP de um usuário pode mudar sob várias
circunstâncias (IPs dinâmicos - DHCP, usuário móvel). Então é para ser capaz de
alcançar esse usuário a partir de seu endereço SIP, uma entidade na rede SIP
precisa manter o mapeamento entre endereços SIP e endereços IP. Este é o
objetivo do registrar.

Apesar de ser mais recente, o SIP está ganhando maior aceitação por parte
de uma grande fatia dos fabricantes que desenvolvem equipamentos de voz sobre
IP. Exemplos notáveis incluem o Messenger da Microsoft. Uma linha mais
desenvolvida de produtos com a arquitetura SIP está disponível pelo Cisco,
PingTel, 3COM, e outros. Além disso, há um certo número de produtos de fonte
aberta do SIP disponíveis atualmente.

Mensagem SIP

Existem dois tipos de mensagens: requests (pedidos) que é feita pelo cliente e
responses (respostas) que são retornadas pelos servidores em resposta aos
pedidos feitos pelos clientes. Todas as mensagens contém um cabeçalho que
descreve os detalhes da comunicação. Mensagens SIP são codificadas usando
a sintaxe de mensagem HTTP/1.1. O conjunto de caracteres é o ISO 10646 com
codificação UTF-8. As mensagens SIP podem ser enviadas sobre TCP ou UDP
através de múltiplas mensagens transportados por uma única conexão TCP ou
UDP.


Requerimentos SIP

A comunicação SIP possui como característica seis tipos de mensagens de
pedidos. Esses pedidos provém métodos que permitem aos usuários e
servidores de rede, localizar, convidar e gerenciar chamadas.

Os pedidos SIP são enviados do terminal cliente para o terminal servidor. As
mensagens de pedidos mais comuns são:

●INVITE: é usado para iniciar uma chamada, esse método indica que o usuário
ou serviço está convidado outro a participar de uma sessão. Neste convite é
enviado o tipo de mídia que vai ser usado e se o receptor não suportar a mídia
ele pode enviar na resposta quais tipos de mídia ele suporta, e o terminal
chamador ira reorganizar o pedido e tenta estabelecer novamente a
comunicação.

●ACK: Esse é um pedido correspondente a um pedido INVITE, um pedido ACK é
enviado pelo cliente para confirmar que ele recebeu uma resposta final do
servidor, como 200 OK;

BYE: É enviado pelo agente de origem ou pelo agente de destino para
interromper uma chamada, antes de finalizar a chamada, os terminais
enviam pedidos para o servidor indicando o desejo de encerrar a sessão;


●CANCEL: Pode ser enviado para interromper um pedido que foi enviado
anteriormente, enquanto o servidor ainda não tiver enviado uma resposta final,
esse comando não afeta os pedidos que já foram aceitos pelo servidor;

●OPTIONS: Questiona quais métodos e extensões são suportadas por
ambos os pontos. O servidor pode indicar em sua resposta quais métodos e
extensões são suportadas por ele, e pelo usuário (fornecidos na pergunta).

●REGISTER: Método utilizado pelo cliente para registrar o apelido do seu
endereço em um servidor SIP.

Mensagens de Respostas SIP

As mensagens de resposta são dividas em 6 grupos:

1xx Responses: Respostas de informações. Exemplo: 180 Tocando
●

2xx Responses: Respostas de transações bem sucedidas. Exemplo: 200 OK
●

●3xx Responses: Respostas de redirecionamento. Exemplo: 302 Usuário
deslocado temporariamente.

●4xx Responses: Respostas de falhas de requisição. Exemplo: 404 Não
encontrado.


●5xx Responses: Respostas de falha no servidor. Exemplo: 503 Serviço
Indisponível.

●6xx Responses: Repostas de falha geral do sistema. Exemplo: 600 Todos os
serviços estão ocupados

Dentro destes grupos, inúmeros tipos de repostas são possíveis.

Cabeçalhos de mensagem

Abordaremos agora os campos de cabeçalho SIP mais comumente utilizados,
discriminando-os nos grupos indicados anteriormente.

INVITE sip:1@192.0.0.3:6060;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.0.0.2:6060
From: UserAgent<sip:99@192.0.0.2:6060;user=phone>
To: 1<sip:1@192.0.0.3:6060;user=phone>
Call-ID: 96561418925909@192.0.0.2
Cseq: 1 INVITE
Subject: UTFPR.EDU.BR
Contact: <sip:99@192.0.0.2:6060;user=phone>
Content-Type: application/sdp
Content-Length: 168


v=0
o=- 238540244 238540244 IN IP4 10.0.0.2
s=VOVIDA Session
c=IN IP4 10.0.0.2
t=3174844751 0
m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20

Neste exemplo, podemos verificar que o cabeçalho de constitui de dois
blocos. O primeiro, até o campo Content-Lenght, contém o cabeçalho SIP.
Abaixo disto, temos o corpo da mensagem com os parâmetros do protocolo
SDP, que está especificado como padrão para a sinalização do pacote.

INVITE sip:1@192.0.0.3:6060;user=phone SIP/2.0 na primeira linha, o
comando INVITE vem precedido da identificação do protocolo (SIP), usuário
de destino separado do domínio por uma arroba, porta utilizada na comunicação,
e um ponto e vírgula. Este ponto e virgula tem o objetivo de separar os dados do
destinatário dos primeiros parâmetros do protocolo.

O primeiro (user), informa que a origem da chamada vem de um telefone
(phone), e não de um dispositivo que esteja emulando o aparelho.

Em seguida, é informado que o protocolo SIP versão 2.0 é suportado.


VIA (Cabeçalho de Requisição e Resposta)- No nosso exemplo: Via:
SIP/2.0/UDP 192.0.0.2:6060. Guarda dados do caminho que o pacote está
percorrendo. A cada passagem por um Servidor Proxy, um novo campo VIA é
acrescentado com informações deste servidor. Um parâmetro Branch pode ser
adicionado junto ao VIA, informando a origem da mensagem em relação ao
sistema. Assim, evita-se que o pacote caia em looping na rede.

FROM (Cabeçalho de Requisição e Resposta) - Campo de extrema importância
nesta categoria de mensagens, pois identifica quem está enviando o pacote.
Neste exemplo, a SIP URL <sip:1@192.0.0.2:6060;user=phone> é relacionada
ao nome User Agent.

TO (Cabeçalho de Requisição e Resposta) - Trabalha da mesma forma que o
FROM, porém identifica o destinatário, com o nome seguido de sua SIP URL.
No nosso exemplo: To: 1<sip:1@192.0.0.3:6060;user=phone>

Call-ID (Cabeçalho de Requisição e Resposta) - Provê uma identificação única
para convites ou registros de um mesmo usuário. Segue de @ e o endereço
IP de origem. Exemplo: Call-ID: 96561418925909@192.0.0.2

Cseq (Cabeçalho de Requisição e Resposta) - Número seqüencial enviado junto a
requisição. Permite ao destinatário saber a ordem correta das chamadas, a
fim de evitar confusões na interpretação das mesmas. No exemplo Cseq: 1
INVITE, verificamos que é a primeira mensagem sendo enviado do tipo INVITE.


Subject (Cabeçalho de Requisição e Resposta) - Campo normalmente não
utilizado. Serve para descreve a natureza da ligação.

Contact (Cabeçalho de Requisição e Resposta) - Mostra uma SIP URL da
origem a fim de fornecer ao destinatário um endereço de resposta. Exemplo:
Contact: <sip:99@192.0.0.2:6060;user=phone>

Content-Type (Cabeçalho de Corpo de Mensagem) - Informa o formato da
mensagem de mídia. Neste caso Content-Type: application/sdp, para tal será
utilizado o protocolo SDP.

Lenght (Cabeçalho de Corpo de Mensagem) - Mostra o tamanho da mensagem
de mídia enviada. Neste caso, 168 octetos enviados por SDP.

SDP (Sintaxe de Descrição de Sessão)

O SIP utiliza o protocolo de descrição de sessão o SDP (Session Description
Protocol) provê a informação necessária para habilitar a conversação em
uma sessão multimídia. Este protocolo inclui descrição sobre a mídia a ser usada
(codecs, taxas de amostragem), o destino da mídia (endereço IP e número da
porta), o protocolo de transporte a ser empregado, informações sobre a banda
a ser utilizada, o nome da sessão e motivo da mesma, bem como o tempo de
atividade da sessão, ou seja, para negociar os parâmetros necessários para
estabelecer uma sessão.


Durante o processo de estabelecimento de uma sessão, é necessário negociar a
mídia a ser utilizada (voz, vídeo ou dados) e as respectivas informações para a
transmissão dessa mídia, como o padrão do codec e o protocolo de controle para
transmissão.

Enquanto o SIP especifica o processo para o anúncio da descrição das
informações de uma sessão, o SDP especifica apenas o formato para
descrição dessas informações.

Com base nesse formato, a descrição das informações de uma sessão é
inteiramente representada de forma textual utilizando a codificação UTF-8.

Ao contrário de representações binárias que economizam largura de banda da
rede, a representação textual de informações foi adotada para facilitar a
portabilidade, permitir uma variedade de formas de transporte e possibilitar
que ferramentas baseadas em texto pudessem gerar e processar as descrições
das sessões.

Para contornar a ineficiência no consumo de banda, a descrição é especificada
em uma forma compacta, substituindo o nome por caracteres únicos.

O texto puro também causa problemas com segurança.


Como o protocolo SIP, o SDP usa códigos em texto. Uma mensagem SDP é
composta de varias linhas, chamadas campos, onde os nomes, abreviados em
uma letra minúscula, indicam qual parâmetro está sendo definido.


Então voltando ao nosso exemplo o corpo do SDP iniciamos com:

v=0 – Essa linha marca o inicio de descrição do nível de sessão, em que é
identificada a versão do SDP utiliza. Até o momento, o valor zero é o padrão.

o=- 238540244 238540244 IN IP4 10.0.0.2 Essa linha indica o
originador/criador da sessão. Podendo ser representado pelo caractere hífen
caso o sistema não suporte identificação do sistema, como neste caso. O segundo
valor refere à identificação da sessão, que é único, normalmente é um NTP
(Network Time Protocol). O terceiro valor é o número da versão do anúncio
feito para a sessão e visa indicar qual o anúncio mais recente, normalmente
também é o NTP, a seqüência seguinte define o tipo de rede bem como o
endereço da origem da sessão representada pelo IP.

s=VOVIDA Session Esta linha indica o nome da sessão e é representada por
uma cadeia de caracteres no formato ISO 10646.

c=IN IP4 10.0.0.2 Essa linha apresenta os dados para conexão. O primeiro
valor define o tipo de rede. É no final o endereço de quem vai gerar a mídia.

T=3174844751 0 Essa linha apresenta o horário que a sessão foi ativa, o
segundo valor é o horário do encerramento da sessão, no caso de 0 essa não
tem horário para termino.


m=audio 23456 RTP/AVP 0 Essa linha marca o início da descrição do nível de
mídia e apresenta os informações sobre uma das mídias de sessão. O
primeiro valor é o tipo de mídias que pode ser: audio, video, application, data e
control. O segundo valor indica a porta de transporte que a mídia deve ser
transmitida. O valor seguinte indica o protocolo de transporte normalmente o
RTP. Por fim, os últimos valores indicam as opções de padrão de codecs da
mídia, em ordem de preferência.

a=rtpmap:0 PCMU/8000 Essa linha define um primeiro atributo específico para
a mídia identificada anteriormente, com respeito à opção de código 0.
Embora o RTP determine as características de mídia, a especificação
determina uma descrição explicita desta mídia neste campo.

a=ptime:20 Essa linha define um quarto atributo específico para a mídia
identificada anteriormente, independente da opção selecionada. O valor
determina que cada pacote terá 20 ms de amostra de voz.

Transações

O SIP é um protocolo baseado em transação e, assim, determina etapas ou pontos
e controle após uma série de trocas de mensagens independentes entre os
componentes de sua arquitetura.


As transações possuem sempre um lado cliente e um lado servidor. A
transação cliente envia a requisição, enquanto a transação servidora envia a
resposta.

Existem dois modos de comunicação possíveis utilizando a arquitetura de
sinalização. O modo ponto-a-ponto e o modo indireto que é feito via servidor
proxy e requer a presença de outros servidores de apoio que integram a infra-
estrutura de um sistema de telefonia baseado em SIP.

Comunicação ponto-a-ponto

A descrição do fluxo de mensagens com o modo simples ponto-a-ponto é descrito
a seguir:

1. O usuário do agente A inicia a chamada e uma requisição INVITE é enviada
diretamente para o endereço do agente B, iniciando a primeira transação. O
INVITE contém informações de oferta SDP listando os padrões de codecs de
mídia suportados e a porta RTP para receber o stream de mídia.

2. A resposta 180 Ringing é imediatamente enviada pelo agente B para o
agente A, tão logo o agente B receba o INVITE, selecione um dos padrões de
codecs suportados e ative uma indicação áudio e/ou visual para alertar o usuário.
Essa resposta indica qual padrão de codecs de mídia foi selecionado e qual porta
o agente B receberá o streaming RTP


3. Quando o usuário do agente B atende a chamada, a resposta 200 OK é
enviada para o agente A, encerrando a primeira transação.

4. O agente A, tendo recebido as respostas 180 Ringing e 200 OK, envia uma
requisição ACK para completar o 3-handshake, iniciando e encerrando a
segunda transação.

5. Os dois canais de voz de mão única estabelecidos entre os agentes, uma A para
B, e outro de B para A, através do RTP, são utilizados pelos usuários para a
conversação.

7. Quando ao encerramento da comunicação, um exemplo seria, o agente B
encerra a conversação e envia uma requisição BYE para o agente A, iniciando a
terceira transação.

8. O agente A recebe a requisição BYE e envia a resposta 200 OK finalizando a
chamada, fechando o canal de voz e encerrando a terceira transação.

A comunicação ponto-a-ponto é o modo mais simples e direto de negocia
uma sessão entre agentes SIP. Porém, como não existe nenhum servidor de
apoio, diversos recursos e serviços podem não ser suportados, como por
exemplo, serviço de localização.


Exemplo de conexão ponto-a-ponto:

Agente A Agente B

1. INVITE
INVITE
agenteB@10.1.1.1
c=IN ipv4 10.1.1.5 2. 180 Ringing
m=audio 49170 RTP/AVP 0

3. 200 OK

4. ACK

5. Voz RTP

6. BYE

7. 200 OK


Comunicação via Proxy

A comunicação via proxy é a forma tradicional de comunicação em um sistema de
telefonia baseado em SIP. Nesse modo indireto, o agente envia as mensagens
de sinalização para o servidor proxy, responsável por encaminhar as
mensagens.

No proxy, o encaminhamento das mensagens pode ser feito de duas maneiras:
sem estado e com estado.

No encaminhamento sem estado, nenhuma informação sobre a sessão é
mantida pelo proxy após o encaminhamento de uma mensagem.

No encaminhamento com estado, o proxy mantém informações sobre a
sessão corrente, facilitando o encaminhamento de mensagens referentes à
mesma sessão. Para que este controle possa ser feito, é necessário garantir que
as mensagens sigam sempre através de um mesmo caminho entre a origem
e o destino. Para o processo de intermediação, o campo Via, é utilizado para
mapear o caminho percorrido por uma mensagem de requisição.

Em muitos sistemas, para que possam ser implementados controles de chamadas,
como tarifação, é fundamental que mensagens de requisição referentes à
mesma sessão sigam sempre pelo mesmo caminho, como por exemplo, INVITE,
ACK e BYE.


Registro

Quando um agente é conectado a um sistema de telefonia baseado em SIP, o
primeiro passo é se registrar em um servidor de registro. Assim, as
mensagens de entrada no sistema que sejam destinadas ao usuário poderão ser
encaminhadas corretamente para a localização corrente do usuário.

O processo de registro pode ser feito de forma direta mas geralmente existe
um proxy no meio do caminho. Esse processo utiliza a requisição REGISTER e
alguns campos-chave no cabeçalho da mensagem.

O processo de registro pode ser como o exemplo a seguir:
Servidor Servidor
Agente
Proxy registrar
1. REGISTER

2. 100 Trying
1. REGISTER

4. 200 OK

5. 200 OK


Depois de registrado o agente pode fazer ligações, a seguir é apresentado
um esquema é demonstrado um esquema de comunicação entre dois agentes
devidamente registrados:
Servidor Servidor Servidor
Agente A proxy A registrar proxy B Agente B

1. Invite

3. Invite
2. 100 4. 302
Trying Moved
Temporarily

5. ACK

6. Invite
7. Trying

8. Invite
9. 302
Moved
Temporarily

10. ACK
11. Invite

12. Trying


1. O Agente A envia uma requisição INVITE para o servidor proxy encaminhar para o Agente B.

2. O servidor proxy A recebe o INVITE e notifica o Agente A enviando a resposta Trying.

3. Como o esquema de autenticação é simplificado, o servidor proxy A simplesmente encaminha a
mensagem INVITE para o servidor de redirecionamento.

4. O servidor de redirecionamento envia a resposta 302 Moved Temporarily com o mapeamento
obtido a partir do serviço de localização.

5. O servidor proxy A envia a requisição ACK para o servidor de redirecionamento a fim de
completar o 3-handshake.

6. O proxy A utiliza a informação de mapeamento da resposta recebida para gerar um novo
INVITE a ser enviado para o servidor proxy B.

7. O servidor proxy B recebe o INVITE e notifica o servidor proxy A.

8. O servidor proxy B encaminha o um INVITE para o servidor de redirecionamento.

9. O servidor de redirecionamento envia a resposta 302 com o mapeamento da localização de A.

10. O proxy B envia seu ACK para completar o 3-handshake.

11. O proxy B utiliza a informação de mapeamento da resposta recebida para gerar um novo
INVITE a ser enviado ao Agente B

12. O Agente B recebe o INVITE e notifica o servidor proxy B.

Um outro exemplo de comunicação SIP é mostrado a seguir:


Esquema comparativo entre H.323 e SIP

O que o SIP faz e o H.323 não faz

Velocidade:
A Primeira coisa que impressiona quando você lê o documento preliminar SIP é a
sua simplicidade. O SIP faz em uma transação o que o H.323 versão 1 faz em
quatro ou cinco trocas de mensagem. Além disso, o SIP pode usar UDP, ao
passo que o H.323v1 e 2 têm de usar o TCP. A combinação dessas diferenças
resultou em um tempo de configuração muito menor para os pontos finais SIP.
Isso inspirou diretamente algumas modificações introduzidas no H.323v2, a
saber, o procedimento Fast connect e a capacidade de ‘tunelar’ mensagens H.
245 em mensagens Q.931. Outras melhorias estão a caminho. Como a capacidade
de usar sinalização UDP.


Multicast:
O IETF ganhou muita experiência em multicast. Há milhares de usuários
regulares do M-bone e cada vez mais aplicações multicast. O SIP foi projetado
para funcionar em backbones com capacidade para multicast, não apenas para
os fluxos de mídia, como o H.323, mas também para as mensagens de
sinalização. Por exemplo, uma mensagem INVITE pode ser enviada para um
grupo multicast. Isso é útil para call centers ou quando se quer encontrar uma
pessoa em uma empresa. As versões 1 e 2 do H.323 precisam usar multi-unicast
para o mesmo fim.

Uso de URLs:
O uso de URLs como identificadores é poderoso. À primeira vista pode parecer
não haver grandes diferenças entre um alias de e-mail H.323
(John@compania.com) e uma URL SIP (sip:John@compania.com). Na verdade, há
uma diferença: um alias de e-mail H.323 considera que o protocolo usado seja o
H.323, ao passo que o SIP especifica ele mesmo o protocolo na URL. Por causa
disso, um servidor SIP pode redirecionar uma chamada para servidores
não SIP de maneira bem flexível. Um terminal SIP, quando recebe uma chamada
de outro terminal SIP, pode redirecionar a chamada para uma página Web
ou para uma URL mailto. Isso facilita a integração de aplicações de áudio e vídeo
com outras aplicações multimídia.
Esse recurso agora está disponível com o tipo URL_ID do aliasAddress no H.
225v2, mas o esquema global de nomes do H.225 está começando a parecer um
pouco desordenado (h323-ID, url-ID, transport-ID, email-ID, partynumber).


Priorização de chamadas:
O campo de cabeçalho ‘Priority’ é um adicional útil que foi negligenciado no H.
323. Muitos países têm exigências legais para priorizar algumas linhas
telefônicas.

Codificação de texto:
A codificação de texto é uma característica atrativa para uns e um problema para
outros. Esta é uma das muitas intermináveis guerras religiosas entre
programadores. A codificação de texto tem muitas vantagens – é simples, pode
ser depurada facilmente usando-se simples sniffers de rede e faz com que
problemas de interoperabilidade sejam detectáveis ‘visualmente’. A maioria dos
programadores concordam sobre esses recursos.
O problema pode ser desempenho e tamanho, como alguns sustentam que
protocolos binários são mais fáceis de codificar e decodificar. Obviamente o
tamanho das mensagens de texto é muito maior que o tamanho das mensagens
codificadas em binário.


O que o H.323 faz que o SIP não faz

Canais lógicos:
O H.323 faz uma distribuição clara entre os tipos de mídia que podem ser
enviados ou recebidos e as combinações que podem ser válidas por outro lado
(capacidades) e os tipos de mídia que estão ativos e, de fato, enviados para a
rede (canais lógicos) por outro lado.

O SIP não tem uma distribuição como esta, uma vez que os pontos finais SIP
divulgam apenas os codificadores que eles podem receber e não há nenhum
procedimento para abrir uma conexão de mídia em separado do ato de
efetivamente enviar a mídia. Isso simplifica a sinalização e pode parecer uma
vantagem à primeira vista. No entanto, em alguns casos, especialmente quando
se implementa servidores que fazem uso intensivo de recursos, isso pode ser
um problema, porque toda vez que o servidor divulga uma capacidade, ele
precisa criar um soquete de escuta.

Ao contrario, um cliente H.323 precisa abrir um soquete apenas quando ele
recebe uma mensagem OpenLogicalchannel (se não estive no modo FastStart).
Esse comportamento do SIP pode resultar em vários soquetes inativos e como a
maioria dos codificadores de voz implementam detecção ativa de voz e podem
estar inativos mesmo se os terminais estiverem querendo enviar dados de mídia,
a estratégia para fechar esses soquetes inativos não é completamente trivial.


Controle de conferências :
O H.323 sozinho ou em combinação com o H.332, possui recursos poderosos para
controle de conferência. O SIP não foi projetado para o controle de
conferências e, conseqüentemente, muitos dos recursos necessários para fazer
uma conferência controlada não existem (ainda).

Codificação binária:
As mensagens H.323 são codificadas de acordo com o Q.931 para o
subconjunto de mensagens H.225 provenientes do Q.931 todas as outras
mensagens, bem como as extensões H.323 para mensagens Q.931, são
codificadas usando-se regras de codificação de pacotes (Packet Encoding Rules -
PER) ASN.1 (Abstract Syntax Notation 1). Isso provavelmente gerou tanto
interesse a respeito da ‘complexidade’ do H.323. O fato é que misturar dois
métodos de codificação com regras totalmente diferentes não é a melhor das
idéias. Isso implica também grandes esforços de programação por parte das
empresas que ainda não têm uma implementação Q.931 e um compilador ASN.1.
Finalmente, depurar os problemas de interoperabilidade entre os terminais H.
323 exige monitores de rede com capacidade de decodificação tanto Q.931
quanto PER ASN.1. Existem alguns (um foi distribuído pela Microsoft aos
membros do SG16 do ITU como uma extensão do Network Monitor da Microsoft),
mas ainda não é um recurso padrão da maior parte das ferramentas.


Portanto há de fato uma curva de aprendizado íngreme, mas uma vez que uma
empresa tenha um compilador ASN.1 e uma implementação Q.931, existem
algumas vantagens em usar uma codificação binária:

● Tamanho do PDU é otimizado;
● (talvez) O desempenho é melhor.

O tamanho dos PDUs de sinalização não é, em geral, um problema nas redes
modernas. No entanto, se o H.323 fosse ser usado em redes sem fio (o ETSI está
levando em consideração o H.323 para o sistema móvel de terceira geração,
UMTS), isso seria uma vantagem.

O desempenho é discutível no caso do H.323. É verdade que a maioria dos
protocolos binários são extremamente rápidos porque os programadores
simplesmente mapeiam as estruturas C para buffers e vice-versa. Tanto o PER
quanto o Q.931 são muitos mais complexos que isso e o desempenho depende da
implementação.

Descoberta de Gatekeepers:
No estado atual do RFC SIP, a descoberta de gatekeepers multicast parece ser
mais sólida no H.323, permitindo que um terminal saiba qual gatekeeper está
respondendo. Mas isso é um detalhe secundário que pode ser facilmente
corrigido em versões posteriores do protocolo.


Tendo analisado o funcionamento básico das duas especificações percebe-
se que o H.323 é bem mais complexo que o SIP.

O SIP utiliza campos de cabeçalhos, regras de codificação, códigos de erro e
mecanismos de autenticação semelhantes ao HTTP, e teve assim um
desenvolvimento mais voltado para a Internet, contrariando a complexidade do
H.323. Esta simplicidade e conseqüente capacidade de adaptação em ambiente
WEB criam uma explicita tendência de que o SIP cresça a ponto de dominar a
comunicação por VoIP.

Mas isto é apenas uma expectativa, pois muitas empresas apostam na
padronização do protocolo H.323, e desta forma provavelmente apenas o tempo
dirá qual é o protocolo que dominara, porém isto pode nem acontecer!


fim

Redes - VoIP SIP

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Redes - VoIP SIP

Ähnlich wie Redes - VoIP SIP (20)

Mehr von Luiz Arthur

Mehr von Luiz Arthur (20)

Redes - VoIP SIP