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

Comportamento UAC

Gerando 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
  • 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.
  • Outras mensagens adicionais podem ser incluídas após os campos anteriormente definidos serem construídos

Enviando a Requisição

• É feita uma busca DNS. Se o primeiro elemento na rote é um strict router, os procedimentos são aplicados ao Request-URI, em outros casos ao primeiro valor do campo route.
• Políticas locais podem influenciar nos destinos. Não é recomendado usar um único proxy na rota pré configurada.
• O UAC pode usar o processo de tentar cada endereço até que um servidor seja contactado, cada tentaiva caracteriza uma nova transação, com branch diferente.

Processando Respostas

• Respostas são processadas na sequência: Camada de transporte -> camada de transação -> TU (Transaction User)
• Algumas mensagens retornadas pela camada de transação não são SIP, mas erros!
• Se um UAC recebe uma mensagem que não seja x00 ele retorna um erro (resposta não reconhecida), assim deve processar todas respostas x00.
• Se tiver mais de um valor no campo Via em uma resposta, a mensagem é descartada.
• Quando vier uma mensagem do tipo 3xx os clientes usam uma URI que está no "Contact" para enviar novas requisições. Uma URI não deve ser testada mais de uma vez, para evitar loops.
  • Estas novas requisições podem ser feitas em série ou em paralelo.
  • Se toda a lista de contatos acabar, a requisição falha. Algumas respostas podem indicar uma nova tentativa de requisição, isto não é uma falha.
  • No caso do 3xx o URI target deve ser todo copiado no Request-URI.
  • Nas novas requisições podem ser inseridos novos valores se comparado a original se esta permitir uma lista separada por vírgulas, se não, valores podem ser sobrescritos. É recomendado que sejam usados os mesmos To, From e Call-ID do original, mas o UAC pode mudar o Call-ID.
  • As novas requisições devem ter um novo branch ID.
• Certas repostas 4xx necessitam de processamento específico:
  • 401(Unauthorized) ou 407(Proxy Authentication Required): o UAC pode tentar retomar a requisição com credenciais.
  • 413 (Request Entity Too Large): Se possível o UAC tenta retomar request emitindo o corpo ou diminuindo a mensagem.
  • 415 (Unsupported Media Type): o UAC tenta outra requisição atendendo ao campo "Accept" que estava na resposta do UAS que não suporta a mídia inicialmente tentada.
  • 416 (Unsupported URI Scheme): O cliente pode tentar outra requisição usando SIP URI.
  • 420 (Bad Extension): as extensões no Require, ou opções não são suportadas, e o cliente pode tentar de novo emitindo estas extensões.
  • Nestes casos as novas requisições mantém os campos Call-ID, To e From, mas CSeq pode mudar.
  • Outros tipos de 4xx, um "retry" pode ou não ser possível dependendo do método.

Comportamento UAS

• O fato de estar ou não em um diálogo influencia no processamento da UAS.
• Quando uma requisição é aceita todas as mudanças de estado devem ser feitas (Seção 12), se não, não devem ser feitas mudanças.

Inspeção de Método

• Uma requisição autenticada deve ter seu método inspecionado. Se o método não for suportado gera uma resposta 405(Method Not Allowed).
• O UAS pode incluir um campo Allow, mostrando quais são os métodos suportados por ele, quando dá a resposta 405.

Inspeção do Cabeçalho

• A UAS pode ignorar qualquer cabeçalho mal formado que não seja necessário para o processamento.
• O destino da mensagem "To", pode não ser este UAS, assim ele pode repassar adiante.
  • Se não há nada em To, o UAS pode usar qualquer política para processá-lo.
  • É recomendado ao UAS que processe a mensagem quando o To não for reconhecido, mas se ele resolver rejeitar pode responder com um 403 (Forbidden).
  • Se o Request-URI não for suportado pelo UAS, pode ser respondido com 416 (Unsupported URI Scheme). Se o Request-URI não corresponder aos endereços que o UAS está habilitado a receber requisições, este responde com 404 (Not Found).
• Se não há tag no To, o UAS checa as transações. Se bater exatamente o From, Call-ID e CSeq e a requisição não bater com a transação é gerado 482 (Loop Detected).
• No caso do Require, se o UAS não entende o campo ele responde com 420 (Bad Extension). Este campo não pode ser usado em CANCEL e ACK para não-2xx.

Processamento de conteúdo, Requisições e extensões

• Se o UAS não entende algo, responde com um campo Accept, ou Accept-Encoding ou Accept-Language.
• Um servidor pode exigir extensões, mas deve verificar o campo Supported na requisição. Se ele não puder processar sem essa extensão e ela não for suportada pelo UAC, então retorna 421 (Extension Required).
• As condições acima atendidas passa-se para o método.

Gerando a Resposta

• Para uma requisição não INVITE, a UAS pode gerar uma resposta final o mais cedo possível.
• Respostas provisórias são mandadas (100 - Trying), e o timestamp deve ser copiado, e adicionado o delay de gerar a resposta.
• Os campos From, Call-ID, CSeq e Via (inclusive a ordem) são mantidos de acordo com a requisição.
• O campo To quando já possui tags deve ser copiado, se não possui o URI é mantido, mas podem ser adicionadas tags.

Stateless UAS

• Não guarda o estado de transição.
• Ele responde uma requisição normalmente, mas se tiver que guardar algum estado, ele descarta após enviar a resposta.
• Ele não tem camada de transação, recebem a resposta direto da de transporte.
• Este UAS não manda repostas provisórias (1xx), não retransmite respostas, ignora requisições ACK e CANCEL.
• As tags do To devem ser geradas de forma "stateless", de uma maneira que gera a mesma tag para a mesma requisição consistentemente.