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.

Servidores de Redirecionamento

• Usados para diminuir a "responsabilidade" dos proxies.
• Quando o requisitante recebe uma resposta de redirecionamento, ele usa o URI desta.
• Tem um sistema de localização baseado em um banco de dados, associando um URI a várias localizações alternativas.
• Este servidor não emite SIP requests por si próprio. Quando recebe uma requisição não CANCEL, retorna um 3xx (redirecionamento) e rejeita este request. Para um CANCEL retorna 2xx (sucesso).
• Na resposta 3xx ele adiciona mais opções de tentativas em Contact.
• Existe um valor "expire" no contact que indica por quantos segundos o URI é válido. Quando não entende o valor do expire, usa 3600. Pode também existir um campo "Expire".
• Estes servidores ignoram as mensagens que eles não entendem.

Cancelando uma Requisição

• Um CANCEL indica que o processamento deve ser parado, e retornado um erro. Geralmente usadas para INVITEs que podem demorar a ser processados.
• Um CANCEL vai de hop em hop (proxies ou clientes podem mandá-la e ela desde de elemento por elemento)

Comportamento do Cliente

• Um CANCEL não deve ser usado para cancelar um não INVITE.
• Request-URI, Call-ID, To, a parte numérica de Cseq e From devem ser iguais ao da requisição, até as tags.
• O CANCEL tem um valor em Via que confere com o avlor mais alto de Via da requisição sendo cancelada, além do método ser especificado no CSeq.
• Os valores de Route precisam também ser incluídos se existirem, já Require não pode existir.
• Cancel não pode ser enviada se nenhuma resposta provisória foi recebida, nem se já recebeu a resposta final.

• Se demorar a resposta para o CANCEL a transação é considerada cancelada.

Comportamento do Servidor

• Um stateless apenas redireciona, enquanto o stateful responde e gera alguns CANCEL por sí próprio.
• O CANCEL só tem efeito em INVITES ainda sem resposta final. Se não for encontrada a transação a ser cancelada envia-se 481 (Call Leg/Transaction Does Not Exist).
• As tags To devem ser iguais na resposta à requisição original e na resposta ao CANCEL.

Pedidos de Registro

• Os proxys e redirects consultam um serviço de localização para encontrar o usuário.
• Eles associam um URI do endereço de registro com um ou mais endereços de contato, se o Request-URI bate com um endereço de registro são tentados os contatos.
• O Servidor registrador é responsável por receber o REGISTER, e montar as associações entre os endereços. É importante lembrar que estas funções são lógicas (proxy e registrador)
• O Registrador escreve, e os proxies e redirects leem os serviços de localização.

Construindo a requisição REGISTER

• Essas requisições podem adicionar ou remover ligações.
• Não existe estabelecimento de diálogo com esta requisição.
• Record-Route deve ser ignorado por um registrador.
• Os campos que precisam ser incluídos em um REGISTER (o Contact pode ser incluído):
  • Request-URI: nomeia o domínio para o qual o pedido é destinado, onde não existe "userinfo" nem "@".
  • To: contém o endereço de registro que deve ser criado ou modificado. Precisa ser um URI ou SIPS URI.
  • From: Costuma ser o mesmo valor do To, ou seja contém o endereço de registro da pessoa responsável por pedí-lo. Só não é o mesmo de To quando o pedido é de um terceiro.
  • Call-ID: É sempre o mesmo para um UAC.
  • CSeq: Deve ser incrementado para garantir ordem.
• Pedidos de registro não podem ser reenviados até que o pedido anterior tenha sido respondido ou expirado.
• O parâmetro "action" ficou obsoleto e o "expires" indica por quanto tempo deveria ser válido. Estes são parâmetros do Contact.
• Segue uma figura com um exemplo de REGISTER:

Exemplo de REGISTER

Bindings

• Pode ser usado o campo Contact para registrar números de telefone ou email. Assim podem ser registrados vários "bindings", que são retornados em uma resposta 2xx no campo Contact.
• Tipicamente um UA só atualiza seus próprios endereços de contato.
• A expiração de um binding pode ser feita como descrito umas linhas atrás, com o parâmetro expires ou o campo Expires.
• O Parêmtro "q" pode indicar preferência entre os endereços de contato.
• O Expires "0" exclui um binding em um REGISTER. Se o Contact for "*" exclui todos. Os dois não podem ser usados simultaneamente.
• Um UA não pode atualizar bindings de outros usuários. Para atualizar basta enviar um REGISTER alterando o valor de expires ou Expires.

Clock, Buscando Registrar, Transmitindo requisições e respostas de erro

• Se houver um campo Date na resposta de um REGISTER, este pode ser usado para definir relógios internos.
• Para descobrir um registrador pode ser usada uma configuração, uma busca a partir do URI, ou por multicast
• Se a camada de transação retorna erro quanto ao recebimento de uma reposta para o REGISTER, não se deve tentar o mesmo registrador de novo. (Pode esperar um tempo e tentar no mesmo depois).
• Uma resposta 423 (Interval Too Brief), faz com que o UA coloque os intervalos de expiração exigidos no campo "Min-Expires" da resposta.

Processando Requisições REGISTER

• O registrador só aceita requisições REGISTER, e não pode gerar respostas 6xx (erro global).
• O registrador não inclui e nem analisa o campo Record-Route. Ele pode redirecionar requisições.
• As requisições devem ser processadas automaticamente e em ordem.
• O registrador quando recebe um registar segue as etapas:
  • 1. Ele verifica o Request-URI e vê se tem acesso aos bindings deste domínio, se não, ele redireciona.
  • 2. Processa os valores do campo Require.
  • 3. Ele deve autenticar o UAC. Se não tiver mecanismos pra isso, usa o From como identidade.
  • 4. Determina se o usuário autenticado está autorizado a modificar pedidos de registro. Se não retorna 403 (Forbidden) e para o processamento.
  • 5. Extrai o endereço de registro do "To", e se não estiver no domínio retorna 404. Depois os parâmetros URI são removidos para virar uma forma canônica e o resultado serve como um índice.
  • 6. Verifica se tem o campo Contact, se não pula para a etapa 8. Então ele observa os campos Contact e Expires (se possui "*" ou "0" desde que não seja ao mesmo tempo), verifica o Call-ID e o CSeq(maior do que o último).
  • 7. Depois percorre cada endereço no campo Contact e atualiza conforme expires, Expires ou valor padrão. O registrador pode adotar tempos menores ou responder com erro caso o valor esteja abaixo do permitido, daí vem o Min-Expires na resposta. Este valor mínimo é para evitar requisições exageradas. Depois ele atualiza o binding ou adiciona se ele não existir (compara URI, Call-ID e se CSeq > CSeq anterior). Um servidor com erro pode retornar 500 (Server Error).
  • 8. Finalmente ele retorna 200 (OK), com os bindings no Contact (incluindo o expires) e um campo Date.

Consultando Capacidades

• O método OPTIONS do SIP permite a consulta de capacidade. Assim o cliente pode descobrir extensões, conteúdo, métodos e outras coisas suportadas pelo UA requisitado.
• O alvo é identificado pelo campo Request-URI, se for um proxu, este campo não tem a parte do usuário.
• O Max-Forwards igual a zero em uma requisição OPTIONS faz com que um servidor possa responder independente do Request-URI.
• A camada de transação pode retornar um erro se a resposta demorar.
• Uma requisição OPTIONS pode ser enviada em um diálogo estabelecido.

Construção de Requisição OPTIONS

• Usa-se as regras padrões.
• O campo Contacts pode estar presente.
• Um campo Accept deve ser incluído para indicar o que o UAC deseja receber.
• Somente em um diálogo é garantido que as futuras requisições serão recebidas pelo servidor que respondeu ao OPTIONS.

Exemplo de requisição OPTIONS

Processamento de Requisição OPTIONS

• A resposta é a mesma de uma requisição INVITE (200 - OK), e pode ser usada para ver se um INVITE seria aceito.
• A resposta a uma OPTIONS por um servidor proxy não contém corpo.
• Os campos Allow, Accept, Accept-Encoding, Accept-Language e Supported DEVEM estar presentes em uma resposta OK para o OPTIONS, o servidor proxy omite o Allow.
• Contact e Warning podem estar presentes ou não.
• Corpo da mensagem pode ser incluído, descrevendo capacidades de mídia por exemplo.

Exemplo de resposta OPTIONS - pag 69

Diálogos

• Representa uma relação SIP fim a fim.
• O ID do diálogo é obtido a partir do Call-ID e de uma tag local e uma remota (são iguais). A Tag local vem do campo To e a remota do campo From.
• Presentes no diálogo: ID, número de sequência (local e remoto), URI (local e remoto), destino, um flag booleano (secure), e um conjunto de rota.

Criação de um Diálogo

• É criado por respotas 101-199 ou 2xx. Podem ser criados por uma resposta não-final sendo chamado de "early".

Comportamento do UAS

• O UAS precisa copiar todos os valores de Record-Route na mesma ordem para a resposta e adicionar o campo Contact (onde coloca um URI ou URI SIPS para ser contactado a partir deste). A parte host desse precisa ser um IP ou FQDN do host.
• Este URI tem escopo global.
• Se a requisição chega sobre o TLS (Transport Layer Security) o flag secure fica TRUE.
• O destino das respostas deve ser definido como o Contact da requisição. Se não houver rotas em Record-Route, este campo é respondido como uma lista vazia.
• O número de sequência remoto é o valor de Cseq (da requisição) e o local é vazio. O URI remoto é o do campo From e o local do campo To.

Comportamento UAC

• O UAC deve fornecer um URI de escopo global no campo Contact. Se o Request-URI ou valor do campo mais alto do Route for um URI do SIPS, então o Contact tem que ser um URI SIPS.
• O flag secure é TRUE se a requisição foi enviada através do TLS e o Request-URI continha um URI SIPS.
• Deve difinir a lista de rotas, ou um conjunto vazio.
• O número de sequência local é o valor do CSeq, o remoto é vazio. O tag local vem do From, e o remoto vem do To, a mesma coisa com o URI.

Requisições dentro de um diálogo

• Os UAs podem mudar de função depois do diálogo estabelecido.
• Requisições podem contar Contact e Record-Route, mas só mudam estes valores se forem requisições para atualizar. O que em um INVITE anterior seria um re-INVITE. Um ACK não é requisição para atualizar alvo.
• Estas requisições só atualizam o URI do alvo remoto.