RFC 3261 - SIP

Link

• http://tools.ietf.org/html/rfc3261

Introdução

• 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 SIP

Mensagem 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).
• SP = single space
• Request-Line = Method SP Request-URI SP SIP-Version CRLF
  • Method: caracteriza um dos possíveis métodos, que podem ser: INVITE, ACK, CANCEL, BYE, REGISTER e OPTIONS.
  • Request-URI: SIP ou SIPS URI de quem está fazendo a requisição.
  • SIP-Version: versão do protocolo.

Respostas

• A primeira linha é uma Status-Line.
• Status-Line = SIP-Version SP Status-Code SP Reason-Phrase SP
• O status é um valor de 3 dígitos que indica a satisfação de uma requisição. A Reason-Phrase é um resumo textual do status.
• O primeiro dígito do status indica a classe da resposta. São 6 classes:
  • 1xx: Provisória, requisição recebida mas continua sendo processada.
  • 2xx: Sucesso, recebida e aceita.
  • 3xx: Redirecionamento, outra ação deve ser tomada
  • 4xx: Erro no Cliente
  • 5xx: Erro no Servidor
  • 6xx: Erro global: a requisição não pode ser "cumprida" em nenhum servidor.

Campos do cabeçalho

• Cada campo do cabeçalho é formado por um par separado por ":". O número de espaços entre as duas palavras é ignorado.
• Para escrever várias linhas em um campo basta deixar um único SP no fim da linha ou um tab horizontal.
• A ordem dos campos não é significante, mas os campos que são usados no processamento dos proxys devem ficar mais acima para ser mais rápido.
• Podem ser adicionados vários valores pro campo, desde que sejam separados por vírgula, exceto alguns campos.

• Podem ser adicionados parâmetros aos campos, mas num nome de parâmetro não pode repetir.
• Campos do cabeçalho, valores, nomes de parâmetro, valores de parâmetro e tokens são case-insensitive.
• Exemplo:
  • Contact: <sip:alice@atlanta.com>;expires=3600
  • CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
  • 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.
    • Exemplo: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
  • 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