SIP(Session Initiation Protocol), trabalha com gerenciamento de sessões, com várias formas de sessões multimídia de tempo real.
É um protocolo da aplicação que lida com chamadas de telefone pela Internet.
o SIP suporta 5 "facetas":
Localização do usuário
Disponibilidade do usuário
Aptidões do usuário
Iniciação de sessão (setup)
Gerenciamento de sessão
Pode trabalhar com outros procolos (RTP,RSTP,SDP,MEGACO), mas não precisa deles necessariamente.
O SIP não provê serviços, mas primitivas para que estes possam ser implementados.
Não é oferecido nenhum controle sobre os serviços de conferência, para isto devem ser usados outros protocolos.
São oferecidos serviços de segurança, que envolvem criptografia, autenticação, privacidade...
Funciona com IPv4 e IPv6.
Overview das Operações
As funções básicas do SIP envolvem: localização do ponto final, negociação de parâmetros da sessão, etc.
O SIP usa identificadores (URI) chamados de SIP URI. Cada lado da chamada possui o seu identificador.
Um "INVITE" é uma requisição de chamada, parecido com o acontece no HTTP. Esta mensagem pode conter informações adicionais em seus campos.
Segue abaixo uma figura de uma troca de mensagens SIP, e o modelo de um INVITE:
Setup de uma sessão SIPMensagem INVITE
Os campos do INVITE:
Via: contém o endereço pelo qual Alice espera respostas para esta requisição, que também contém um parâmetro que identifica a transação.
To: contém o destino (nome) e seu SIP URI.
From: tem o nome do solicitante, seu SIP URI adicionado de uma string randômica usada para identificação.
Call-ID: identificador único para esta chamada. A combinação de To, From e Call-ID define o relacionamento SIP peer-to-peer.
CSeq: é um número incrementado para cada requisição (como um numero de sequência).
Contact: traz um SIP ou SIP URI para contato direto com o solicitante. Neste campo pode ter o IP.
Max-Forwards: funciona como o TTL, limitando o número de saltos.
Content-Type: descrição do corpo da mensagem.
Content-Lenght: um contador de bytes do corpo da mensagem.
Uma mensagem SDP pode ser carregada pelo SIP com informações sobre a sessão.
Se Alice não conhece a localização de Bob, seu servidor SIP (atlanta.com) passa a fazer a busca, e manda um Trying falando que recebeu o INVITE. A busca pode ser feita usando DNS e vai passando pelos servidores até chegar no Bob. Estes servidores podem ser chamados de proxy.
Bob manda para Alice um reconhecimento de que recebeu o INVITE e depois um OK, aceitando-o.
A mensagem OK copia os campos do INVITE e adiciona uma tag no "To" que vai ser usada pelo resto da comunicação. Segue abaixo a mensagem OK:
Mensagem OK
Um servidor proxy pode mandar vários invites ao mesmo tempo, isso é chamado de forking.
Alice responde o OK com um ACK, fechando o tree way handshaking do SIP. O ACK é direto pois o endereço de Bob já foi "aprendido".
Um re-INVITE pode ser mandado paraa mudar as características da sessão, o qual deve ser respondido com um OK e depois ACK. Se não for aceito vem uma mensagem de "não aceitável" de número 488.
Para encerrar é gerada uma mensagem BYE que deve ser respondida com uma 200(OK). Neste caso não há ACK.
Um servidor proxy pode solicitar que todas as mensagens passem por ele.
Uma operação comum é regitrar, para que o servidor proxy saiba a localização corrente do SIP phone. Aí fica claro que a distinção entre os servidores SIP é lógica e não física.
Um usuário pode ter vários phones e um phone pode ser usado por vários usuários, assim o proxy pode fazer múltiplas buscas. O "registrar" pode ajudar nisto, mas não é o único meio, algumas funções de mapping podem ser configuradas pelo administrador.
Existem outras mensagens SIP que serão apresentadas depois.
Estrutura
O SIP pode ser estruturado em camadas.
A primeira seria da sintaxe e codificação. A segunda seria a de transporte, que define como o cliente envia e recebe respostas. A terceira seria de transação, que envolve retransmissões, respostas,timeouts. A próxima camada seria o usuário de transação.
Siglas:
UA: User Agent
UAC: User Agent Client
UAS: User Agent Server
Obs: estes componentes serão explicados posteriormente.
Um diálogo é um relacionamento SIP peer-to-peer.
O método mais importante do SIP é o INVITE.
Definições
AOR (Address-of-Record): é como se fosse o endereço público de um usuário, sendo o SIP ou SIPS URI que aponta para um domínio com um serviço de localização.
Back-to-Back User Agent (B2BUA): entidade local que recebe requisições e as processa como um UAS, e para determinar como seriam respondidas funciona como um UAC
Call: refere a alguma comunicação entre peers.
Call Stateful: mantém o estado de um diálogo desde o INVITE até o BYE.
Conferência: Uma sessão com vários participantes.
Core: funções específicas de uma entidade SIP.
Downstream: do UAC até o UAS.
Home Domain: Que oferece servíço de domínio ao usuário.
Location Service: Usado por um redirecionamento SIP ou proxy para obter informações sobre a localização do callee (que recebe a requisição)
Roteamento solto (Loose): segue procedimentos definidos para processar o campo de cabeçalho de roteamento, separando o destino do conjunto de proxies que devem ser visitados.
Proxy de Saída (Outbound): Não pode ser resolvido pelo Request-URI.
Busca paralela: Um proxy procura um usuário em várias possibilidades ao mesmo tempo.
Resposta provisória: indica um avanço na busca, transação SIP, mas não o fim.
"Registrar": Um servidor que aceita requisições do tipo REQUEST.
Transação Regular: Uma transação que não envolva INVITE, CANCEL ou ACK.
Ringback: Um tom produzido na chamada, indicando que a chamada foi alertada.
Route Set: conjunto de SIPs ou SIPS URI que representa uma lista de proxies.
Spiral: a mesma requisição chegando de diferentes formas em um proxy, o que resulta em diferentes respostas.
Stateful/Stateless proxy: mantém ou não máquinas de estado do cliente ou servidor. É uma entidade lógica.
Strict Routing: Outro tipo de roteamento seguindo a RFC 2543. O Proxy destrói os conteúdos do Request URI quando um Route header é presente.
Usuário de Transição (TU): Camada que contém os cores (UAC, UAS, proxy).
Upstream: Do UAS para o UAC.
UAC: Cria uma requisição e a envia.
UAS: Recebe um request e gera uma resposta. Tanto UAC quanto UAS recebem este nome enquanto durar a transação.
UA: Pode ser UAC ou UAS.
Mensagens SIP
O SIP é baseado em texto e usa o UTF-8.
A mensagem pode ser uma requisição ou uma resposta, bem parecidas com o HTTP, mas o SIP NÃO É uma extensão do HTTP.
Requisições
Toda requisição tem uma "Request-Line" como início que termina com CRLF (carriage-return line-feed).
Estes dois são equivalentes, sendo que expires é um parâmetro.
Alguns parâmetros só fazem sentido em requisições ou respostas, se eles forem percebidos em outro caso a mensagem deve ser ignorada.
Existem formas compactas para os campos do SIP, que são usadas para evitar ultrapassar o MTU por exemplo.
Corpo da Mensagem
Respostas e requisições incluem o corpo, que varia segundo o método.
O Content-Type, indica o que vem no corpo, e se ouver compressão por exemplo, deve ser indicado no content type.
Quando não é definido um conjunto de caracteres é adotado o UTF-8.
Request com "multipart" devem mandar uma descrição da sessão.
O campo Content-Length indica o tamanho do corpo.
O SIP pode usar o UDP (diferente do HTTP), e num fluxo deste qualquer CRLF antes da "start-line" é ignorado.
Comportamento do UA (User Agent)
O UA representa a "ponta" do sistema. É um UAC quando faz requisições (de acordo com estímulos externos) e é um UAS quando responde (por estímulos, entradas ou execução de programa).
Os processos de um UA depende de duas coisas:
Se a mensagem está em um diálogo
O método da requisição
Requisições
Uma requisição válida deve ter no mínimo: To, From, CSeq, Call-ID, Max-Forwards e Via.
O Request-URI da mensagem deve ser copiado do URI presente em "To" (a não ser no método REGISTER). Uma rota pré-existente (conjunto de URIs ordenados) pode afetar o Request-URI.
To: Designa o recipiente lógico destino da requisição ou o endereço. Geralmente contém SIP ou SIPS URI, mas pode conter outras combinações.
O UAC preenche esse campo conforme informações do usuário. Ele tenta validar este nome em um domínio (RHS - Right Hand Side) que geralmente é home domain, mas pode ser um proxy mais próximo.
Uma requisição fora do diálogo pode não conter uma tag "to", já que esta identifica o peer do diálogo.
From: Recebe o endereço, URI, do solicitante da requisição, não contém o IP. Pode ser preenchido com "Anonymous". Geralmente este campo é gerado pelo usuário ou administradores do domínio. Se vários usuários usam o mesmo UA, devem existir "Switchable profiles", com uma forma de autenticação.
Este campo deve possui uma tag.
Call-ID: Um campo que identifica todas as mensagens de um diálogo unicamente. Este valor é gerado pelo UAC que tem métodos para garantir. Certas requisições novas não precisam mudar o Call-ID dependendo da falha que aconteceu.
O Call-ID é case sensitive, existe uma comparação byte por byte. É recomendado usar identificadores randomicamente criptografados para proteção.
CSeq: identifica a ordem das transações. Consiste de um número de sequência e de um método (que deve bater com o da request). O valor varia até 2^31.
Para requisições fora de um diálogo (que não sejam REQUEST) este valor é arbitrário.
Exemplo: CSeq: 4711 INVITE
Max-Forwards: Número máximo de saltos, que geralmente é 70. Se o UA conhece a rota este valor pode diminuir.
Via: Indica o transporte usado e identifica a localização para a resposta. Este campo deve conter um parâmetro (branch) que identifica a transação criada pelo request.
Este branch deve ser único no tempo e espaço pelo UA, exceto para CANCEL e ACK para respostas não-2xx. Ele começa com 7 caracteres (z9hG4bK) que funcionam como um cookie.
Contact: Contém um SIP ou SIPS URI pelo qual o UA quer receber requisições. Se o Request-URI é um SIPS URI, contact também deve ser.
Supported and Require: o Supported pode ser incluído listando as extensões suportadas pelo requisitante. O Require deve ser incluído caso o UAC queira "forçar" o UAS a usar uma extensão, pode incluir também Proxy-Require, aí os proxys pelo caminho devem ter a extensão. Estas extensões são definidas por RFCs.
