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

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.

Comportamento UAC

Gerando a Requisição

• As informações de estado do diálogo são usadas nestas requisições.
• Se o número de sequência local for vazio, um valor inicial precisa ser escolhido.
• O valor do CSeq pode ser escolhido com base no tempo.
• Se o conjunto de rotas estiver vazio o URI do alvo remoto é colocado no Request-URI. O UAC não pode colocar o campo Route na requisição.
• Se o conjunto de rotas não estiver vazio e o primeiro URI tiver o parâmetro lr, o UAC inclui o campo Route com os valores do conjunto de rotas em ordem. O request-URI é igual ao anterior
• Se não tiver o lr, o primeiro URI do conjunto de rotas é que vai pro Request-URI. Depois o Route é construído com o resto, sendo o último valor o URI do destino remoto.

Exemplo

• O campo Contact deve estar sempre presente. O URI deve ser o mesmo, e se secure for TRUE deve ser um URI do SIPS. O resto do procedimento é o padrão já descrito lá atrás.

Processando as Respostas

• As respostas são recebidas da camada de transação.
• Uma resposta 3xx para uma requisição dentro do diálogo tem o mesmo processamento se fosse fora.
• Uma resposta 2xx, indica a substituição do URI alvo pelo URI do campo Contact desta resposta.
• Para timeout ou respostas do tipo: 481 (Call/Transaction Does Not Exist) ou 408 (Request Timeout), o diálogo deve ser encerrado (mandando BYE).

Comportamento UAS

• Estas requisições são atômicas.
• O UAS recebe da camada de transação a requisição, e se existir uma tag no To, computa o identificador do diálogo e compara com os existentes, se bater, identifica uma requisição no meio do diálogo que é processada igual a fora de um diálogo.
• Se existe a tag do To, mas não bate o identificador, pode ser erro de roteamento ou este próprio UAS reiniciou/quebrou e perdeu as informações. Ele pode rejeitar ou aceitar, se rejeitar ele manda 481 (Call/Transaction Does Not Exist).
• Requisição que não muda estado, tipo OPTIONS são processadas como se estivessem fora do diálogo.
• Se o número de seq é vazio ele recebe o valor de CSeq da requisição. Se não for vazio e o número da requisição for inferior retorna 500 (Server Internal Error).
• O UAS atualiza o URI alvo a partir do campo Contact se ele existir em uma requisição de atualização.

Terminando um Diálogo

• O método BYE termina uma sessão e o diálogo associado a ela.
• Uma resposta final não-2xx encerra todos os diálogos early's.

Iniciando uma Sessão

• Uma sessão (jogo, áudio, vídeo) é iniciada com um INVITE. Um convite aceito por um UAS tem resposta 2xx, ou antes de terminar pode enviar respostas provisórias 1xx.
• Para cada resposta que recebe o UAC deve gerar um ACK. Uma resposta 2xx cria a sessão e também o diálogo.
• Um UA que suporta INVITE também deve suportar BYE, ACK e CANCEL.

Processamento do UAC

Criando o INVITE inicial

• Este INVITE é uma requisição fora do diálogo processada como já foi explicado.
• Devem estar presentes Allow e Supported.
• O Accept pode estar presente, indicando os Content-Types. O Expires também pode aparecer, e se acabar este tempo sem resposta, o UAC gera um CANCEL a este INVITE.
• Subject, Organization, User-Agent e um corpo da mensagem podem ser adicionados.
• Existe o modelo ofera/aceita, onde a sessão é "ofertada" com certas características, e aceita pelo outro UA, sendo que cada uma destas é um diálogo. Regras para este modelo:
  • A oferta (offer) deve estar no INVITE e na resposta (2xx). O "aceite" também pode estar nas respostas provisórias.
  • Se a oferta está na resposta, o aceite deve estar no ACK.
  • Depois de um aceite o UAC pode fazer mais ofertas, desde que todas as anteriores foram aceitas. Já um UAS não pode gerar ofertas subsequentes.
• O SDP precisa ser suportado pelos UAs para descrever as sessões.
• O valor de Content-Disposition deve ser "session". Se este campo não existe application/sdp no Content-Type indica uma sessão, outros tipo de conteúdo implicam em "render".

Processando Respostas a INVITE

• No UAC se não chegar a resposta pode acontecer um 408 (Request Timeout).
• Respostas 1xx
  • Estas podem gerar um diálogo early, que só existe quando o UAC quer enviar uma requisição antes do INVITE inicial se completar.
• Respostas 3xx
  • Esta resposta pode contar novas opções em Contact que o UAC pode tentar.
• Respostas 4xx, 5xx e 6xx
  • Encerram todos os diálogos early, e podem contar informações sobre o erro em um local descrito em Contact. A transação INVITE fica completa e um ACk é gerado.
• Respostas 2xx
  • Múltiplas respostas 2xx podem chegar em resposta a um INVITE, cada uma representa um diálogo distinto. Cada resposta tem seu ACK, com credenciais correspondentes ao INVITE, se for um offer o ACK carrega um aceite, se não for aceitável, envia o ACK depois o BYE.
  • Os ACKs vão direto pra camada de transporte. Quem trata a retransmissão é o núcleo UAC e não a camada de transação.
  • O UAC considera um INVITE completado depois de um tempo após a primeira 2xx. Se chegar outra 2xx depois o UAC pode não querer continuar com o diálogo e enviar assim um BYE.

Processamento do UAS

Processamento do INVITE

• Se os procedimentos explicados lá atrás para processar uma requisição derem certo, seguem depois os seguintes passos:
  • 1. Se houver Expires, o UAC inicia um timer. Se ele encerrar antes do fim do processamento responde com 487 (Request Terminated).
  • 2. Uma requisição no meio do diálogo pode alterar a seção.
  • 3. Se houver tag no To e o ID do diálogo não bater, o UAS pode ter reiniciado ou quebrado.
• Um usuário pode receber múltiplos invites, e assim o UAS pode detectar as duplicações (com ajuda do SDP).
• Um INVITE sem descrição da sessão está pedindo uma oferta do UAS, que deve ser enviada no 2xx.
• Se um UAS não puder responder de imediato, pode mandar repostas provisórias (entre 101 e 199), mas estas não são entregues de forma confiável.
• O UAS pode pedir uma extensão do tempo para responder ao invite.
• Se o UAS redirecionar a chamada envia uma resposta 3xx com o campo Contact.
• Um UAS que não tem mais espaço para sessões envia um 486 (Busy Here), e um que não seja capaz de atender a oferta envia 488 (Not Acceptable Here), sendo que esta deve incluir um campo Warning explicando o motivo.
• A transação é destruída com a resposta final, então respostas 2xx é passada periodicamente ao transporte para possíveis retransmissões (até chegar o ACK). Isso independe do protocolo da camada abaixo.
• Se o ACK não chega a sessão é encerrada com um BYE (o tempo segundo a RFC é 64*T1 - T1 será definido depois)

Modificando uma sessão existente

• É diferente de atualizar/modificar um diálogo, aqui podem ser redefinidas portas e até fluxos de mídia. Para modificar uma sessão envia-se outro INVITE dentro do mesmo diálogo.
• Um único re-INVITE pode modificar sessão e diálogo ao mesmo tempo.
• Em caso de falha as mensagens devem ser enviadas após intervalos de tempo aleatórios, para não inundar a rede, em casos que re-INVITEs ou BYEs são gerados automaticamente.

Comportamento UAC

• Aqui usa-se o mesmo modelo oferta/aceite (offer-answer), e uma descrição completa da sessão deve ir junto.
• Se não houver descrição da sessão, espera-se o offer na resposta 2xx. Se houver capacidade para número de versão, o proponente deve atualizar este.
• Os campos To, From, Call-ID, CSeq e Request URI de um re-INVITE seguem o mesmo padrão das requisições de um diálogo existente.
• o UAC pode não adicionar um campo Alert-Info.
• Um re-INVITE só gera uma resposta final.
• Não se pode gerar um INVITE enquanto outro está em curso. Mas transações regulares e INVITEs não tem esse problema um com o outro.
• Uma resposta não 2xx para um re-INVITE mantém a sessão inalterada, a não ser que seja por timeout ou 481 (Call/Transaction Does Not Exist), ou uma 408 (Request Timeout), aí o diálogo é encerrado.
• Se o UAC receber a resposta 491, deve ser iniciado um timer:
  • Se o UAC é dono do Call-ID o valor é aleatoriamente escolhido entre 2.1 a 4 segundos em intervalos de 10ms.
  • Se ele não for dono o valor é entre 0 e 2 segundos.
• Se o timer acabar um re-INVITE deve ser tentado de novo, a não ser que já desligou a chamada com um BYE.

Comportamento do UAS

• Um UAS que recebe um segundo INVITE enquanto processa um outro, e com um CSeq inferior retorna 500 (Server Internal Error) ao segundo e inclui um campo Retry-After com um valor entre 0 e 10 seg.
• Um UAS que recebe um INVITE enquanto aguarda a resposta de um que ele enviou retorna 491 (Request Pending)
• Se o UAS gerar 2xx e não receber ACK, depois envia BYE.
• O UAS fazendo uma oferta precisa sobrepor a descrição da sessão anterior e colocar as mídias que ele suporta.

Terminando uma Sessão

• O BYE encerra uma sessão e só pode ser enviado em um diálogo.
• Um BYE que encerra um diálogo encerra todas as sessões associadas.
• Um UA chamado não pode enviar BYE em um early.
• o UA chamado só pode encerrar um diálogo se receber o ACK para o 2xx.
• Para um INVITE em curso (respostas não-2xx) usa-se CANCEL.

Requisição BYE

Comportamento UAC

• o UAC passa a requisição BYE para a transação não INVITE.
• Se o BYE receber 481 (Call/Transaction Does Not Exist) ou 408 (Request Timeout) considera-se a sessão encerrada.
• O BYE é construído como qualquer outra requisição dentro de um diálogo

Comportamento UAS

• O UAS compara a requisição BYE, para ver se o diálogo existe (o BYE tem que ter tags)
• Se não existir retorna 481.
• O UAS encerra a sessão desde que não seja multicast (mais usuários)
• O UAS deve gerar uma resposta 2xx ao BYE.
• O UAS deve responder as requisições pendentes, é recomendado que a resposta seja 487 (Request Terminated)

Comportamento do Proxy

• Roteiam requisições e respostas SIP.
• Respostas percorrem o caminho inverso das requisições.
• É uma função lógica, e pode responder mensagens mal formadas.
• Se for o destino de um requisição, comporta-se como um UAS.
• Um stateless só encaminha a mensagem sem guardar informações, diferente do stateful
• Um proxy pode passar de stateful para stateless, desde que nada o "segure" no primeiro.
• Não deve mandar mensagens CANCEL.

Proxy Stateful

• Este tem uma transação servidor associada a uma ou mais de clientes por um componente de processamento, conhecido como núcleo proxy.
• Requisições entrantes -> transação servidor.
• Requisições que saem -> transação cliente.
• As respostas percorrem o caminho inverso.
• O proxy precisa se comportar como um UAS quando envia provisórias
• Passos no proxy:
  • 1. Validar a requisição
  • 2. Pré-processar informação de roteamento.
  • 3. Determinar alvo(s)
  • 4. Encaminhar a requisição para cada alvo
  • 5. Processar as respostas

Núcleo Proxy

(1)Validação da Requisição

• Para validar o proxy segue os passos:
  • 1. Sintaxe Razoável
  • 2. Esquema URI
  • 3. Max-Forwards
  • 4. Detecção de Loop (Opcional)
  • 5. Proxy-Require
  • 6. Proxy-Authorization
• Se uma dessas falhar o proxy como um UAS envia um código de erro
• O proxy não pode tratar requisições mescladas como erro

1.Sintaxe Razoável

• Campos não fundamentais não fazem a requisição ser rejeitada, mas não são alterados.
• Campos não conhecidos também não resultam na rejeição

2.Esquema URI

• Se o Request-URI contém um esquema não conhecido, rejeita-se e responde com 416 (Unsupported URI Scheme)

3.Max-Forwards

• Se não existe o campo, não há rejeição
• Se o valor for zero, rejeita, a não ser que seja OPTIONS que pode ser respondido pelo proxy.

4.Loops

• Se o campo via for igual de um anterior ele está em loop.
• Ele pode calcular o branch e comparar com via (espiral !=, loop ==).
• Resposta: 482 (Loop Detected)

5.Proxy-Require

• Informa extensões que não precisam ser processadas pelo proxy, a menos que ele entenda.
• Se esse campo tiver tags options que não são entendidos, retorna 420 (Bad Extension) e inclui na mensagem um campo Unsupported.

6.Proxy Authorization

• Se exigir credenciais a requisição precisa ser inspecionada, depois vai ser explicado.

(2)Pré-processamento de informação de rota

• Se o valor do Request-URI tiver um valor que o proxy já colocou em Record-Route, ele precisa substituir o Request-URI pelo último valor do campo Route, e remover este valor do Route.
• Se existe o maddr no Request-URI, e bate com os endereços do proxy, ele retira o maddr ou parâmetro transport da requisição (caso a porta e transporte sejam os que estão sendo usados)
• Se a porta ou transporte for diferente, encaminha-se ao que foi indicado.
• Se o primeiro valor de Route indica esse proxy, ele remove esse valor.

(3)Determinação de alvos

• Se existir o maddr o Request-URI é o URI alvo, mesmo que o Request-URI não esteja no domínio do proxy.
• Se não existe maddr o Request-URI pertence ao proxy, e pode ser redirecionado por QUALQUER método (como o serviço de localização)
• Se não der pra determinar a rota com o Request-URI retorna 485 (Ambiguous), com um campo Contact para novas tentativas.
• Informações na requisição ou ambiente atual podem interferir na redireção.
• Um proxy só pode alterar um Request-URI se ele é responsável por ele.
• URI's só podem ser acrescentadas ao conjunto alvo uma vez, e se um recurso do Request-URI é um pelo qual este proxy é responsável.
• O URI ou SIPS URI do próximo salto é adicionado ao Route.
• Se o conjunto destino estiver vazio -> 480 (Temporarily Unavailable)
• Se existe um recurso não suportado pelo proxy em Request-URI -> 404

(4)Encaminhando a Requisição

• Como existe um conjunto de destino o proxy stateful pode enviar para cada um em série ou paralelo.
• Pode ser usado o parâmetro qvalue de Contact, do maior para o menor.
• o proxy stateful tem que ter um mecanismo para manter o conjunto de destinos para manipular as respostas
• Para cada destino, seguem as etapas:
  • 1. Fazer uma cópia da requisição recebida
  • 2. Atualizar o Request-URI
  • 3. Atualizar o campo-cabeçalho Max-Forwards
  • 4. Opcionalmente adiciona um valor no campo-cabeçalho Record-Route
  • 5. Opcionalmente adiciona campos-cabeçalhos adicionais
  • 6. Pós-processa informação de roteamento
  • 7. Determina o endereço, porta e transporte do next-hop
  • 8. Adiciona um valor no campo-cabeçalho Via
  • 9. Adiciona um campo-cabeçalho Content-Length se necessário
  • 10. Encaminha a nova requisição
  • 11. Define o timer C

1.Copiar Requisição

• Todos os campos são copiados em ordem, sem adição, nem modificação do corpo da msg.

2.Request-URI

• O Request-URI da cópia é substituído pelo URI destino, parâmetros não permitidos são removidos.

3.Max-Forwards

• Decrementa o valor detse campo por 1 se existir.
• Se não existir, adiciona com valor 70.

4.Record-Route

• Se este proxy quer ser caminho para futuras requisições ele grava em Record-Route, antes dos outros existentes.
• Se ele não adicionar nada no Record-Route, em requisições de um mesmo diálogo ele pode sair do caminho se um endpoint que falhou reconstituir o diálogo.
• Esta escolha é independente (de adicionar no Record-Route) nos proxys.
• O URI adicionado tem que ter o parâmetro lr, e não ter o tranport, a não ser que este proxy garanta que o próximo elemento suporte isso.
• Este proxy precisa se limitar a uma implementação do SIP por causa dos outros elementos.
• Se o Request-URI é um URI SIPS e o campo mais alto de Route também, então o URI adicionado deve ser um URI SIPS.
• Podem ser colocados parâmetros em Record-Route
• o URI adicionado só tem que ser válido até o fim do diálogo.
• Só deve adicionar em Record-Route se for necessário, porque isso causa processamento mais lento.

5.Campos Adicionais

• Neste ponto a cópia pode receber quaisquer campos adicionais apropriados.

6. Pós-processamento das informações de roteamento

• Se o proxy quiser que uma requisição passe por um conjunto de proxys específicos ele adiciona em Route, desde que estes prxys sejam menos rígidos, o que só pode ser conhecido em um mesmo domínio administrativo.
• No caso de um proxy específico pode colocar até a porta e o transporte, a menos que existe o Route, aí isto não pode ser usado.
• Se o primeiro valor do Route (se existir) não tem lr, adiciona o Request-URI no fim do Route e remove este primeiro valor e coloca no Request-URI (encaminhar para rígido)

7.Determinar endereço, porta e transporte do next-hop

• O mecanismo de encaminhar por um next-hop específico não é recomendado, e só pode ser usado se houver certeza de menos rigidez neste.
• O proxy precisa tentar entragar a mensagem com a primeira tupla em Route, e formatar a mensagem quando apropriado, e enviar a requisição usando uma nova transação cliente.
• O valor branch (em Via - próximo tópico) precisa ser diferente para cada tentativa.
• Se nenhum do conjunto responder retorna 408 (Request Timeout)

8.Adicionar um valor no campo Via

• Cada proxy computa o seu próprio parâmetro branch, que precisa ser adicionado no campo Via antes dos valores já exisstentes.
• O branch é diferente para cada instância de uma requisição.
• Se o proxy detecta loops o branch é dividido em 2, a primeira parte segue a regra, a segunda é para a detecção.
• A segunda parte pode ser baseada em campos, para que requisições em espiral passem (Route, Proxy-Require e Proxy-Authentication podem mudar por exemplo em expirais, mas não em loops)
• O método não pode ser usado no cálculo do branch.

9.Adicionar Content-Length

• Se a requisição for enviada usando um transporte baseado em fluxo, o campo Content-Length deve ser adicionado.

10.Encaminhar a Requisição

• Cria-se uma nova transação cliente e instrui a transação a usar os valores determinados no passo 7.

11.Timer C

• O timer tem que ser maior que 3 min e deve estar presente em cada transação cliente, para casos em que não há resposta final.

(5)Processando Resposta

• Confere a resposta com as transações clientes, se não existir relação, processa como um proxy stateless.
• Se existir passa para a transação cliente correspondente.
• Os passos para passar da trabsação cliente para a camada proxy:
  • 1. Busca o contexto apropriado
  • 2. Atualiza o timer C
  • 3. Remove o Via mais alto
  • 4. Adiciona a resposta ao contexto de resposta
  • 5. Verifica se a resposta deve ser encaminhada imediatamente.
  • 6. Se necessário, escolhe a melhor resposta final no contexto.
• Para cada resposta seguem os passos:
  • 7. Agregar valores nos campos-cabeçalhos Authorization se necessário.
  • 8. Reescrever valores no Record-Route (opcional)
  • 9. Encaminha a resposta
  • 10. Gera requisições CANCEL necessárias

1.Busca de contexto

• O proxy localiza o "contexto resposta" que ele criou antes de encaminhar a requisição.

2.Atualiza timer C

• O timer é ressetado para cada resposta provisória que recebe. (> 3min)

3.Via

• Remove o valor mais alto do campo, se não sobrar valores este proxy é o destino.

4.Adiciona Resposta ao Contexto

• Respostas finais são armazenadas no contexto até que a transação servidor gere a resposta associada a esse contexto.
• O contato não pode ser removido da resposta.
• Se o proxy colocar um URI não SIP e receber 416 (Unsupported URI Scheme) como resposta, ele deve colocar um URI SIP no lugar daquele.

5.Verifica Resposta para encaminhamento

• Respostas provisórias e 2xx devem ser encaminhadas imediatamente.
• 6xx não precisa ser encaminhada imediatamente. O proxy stateful deve cancelar todas as transações clientes pendentes.
• Uma resposta 2xx (a um INVITE) deve ser enviada após uma resposta final ter sido enviada na transação servidor.
• Um proxy não pode enviar a resposta 100 (Trying).

6.Escolhendo a melhor resposta

• Se não houver nenhuma resposta no contexto, o proxy envia 408 (Request Timeout).
• Do contrário ele precisa escolher a melhor. Primeiro as 6xx, se não houver as outras (a mais baixa). Desta classe ele escolhe qualquer resposta, com algumas preferências.
• Uma resposta 503 (Service Unavailable) não deve ser enviada ao upstream, mas uma 500 no lugar. A menos que ele saiba que as próximas requisições também vão gerar 503.
• Respostas 3xx-6xx são entregues de salto a salto.
• O proxy não pode modificar uma tag To de um resposta na qual a requisição tinha uma tag. Assim como em respostas 1xx e 2xx ele não pode adicionar a tag em situação nenhuma (a não ser que seja a que já estava na requisição).
• O proxy não pode gerar respostas provisórias por conta própria, para isto ele pode usar um UAS que partilha o mesmo elemento que ele.

7.Agregando valores no Authorization

• Para respostas 401 (Unauthorized) ou 407 (Proxy Authentication Required) o proxy pega todos os campos WWW-Authenticate e Proxy-Authenticate do contexto a adiciona à resposta sem modificação.

8.Record-Route

• O proxy pode escolher reescrever um valor previsto que esteja nesse campo.
• De um não-TLS para um TLS -> URI SIP
• De um TLS para um não-TLS -> URI SIPS
• Pode ser usado um identificador único no URI, para identificá-lo na hora de reescrever em espirais.
• As vezes as respostas podem não conter Record-Route.

9.Encaminhar Resposta

• O proxy não pode: mexer no corpo da msg, não pode remover nada dos campos (a não ser do Via), não pode remover qualquer parâmetro "received".
• O proxy passa para a transação servidor, se essa não responder, envia como stateless, direto pelo transporte servidor.
• O contexto resposta precisa ser mantido até o fim de todas as transações associadas.

10.Gerar CANCEL's

• Gera-se CANCEL para todas as transações clientes após uma resposta final, ou para as associadas com uma resposta 6xx.

Processando o Timer C

• Se o timer disparar sem resposta provisória envia-se a resposta 408 (Request Timeout). Se houver resposta provisória, envia um CANCEL. Ele deve ser ressetado.

Tratando erros de transporte

• Se o transporte identificar um erro ao tentar transmitir, o proxy trata isso como 503 (Serviço Indisponível).
• Se o proxy é notificado com um erro quando encaminha uma resposta ele simplesmente a descarta.

Processando CANCEL

• O proxy stateful pode gerar um CANCEL para qualquer requisição que ele tenha gerado, e cancelar as transações clientes associadas quando recebe um.
• O proxy pode gerar CANCEL com base em Expires.
• Quando recebe CANCEL, se bate com um contexto resposta existente, ele retorna 200 (ok). Se não ele encaminha o CANCEL sem guardar estado.

Proxy Stateless

• Se comporta como um encaminhador.
• Um stateless é proibido de gerar respostas 100 ou provisórias, ele não transmite mensagens por conta própria.
• Os passos explicados 1, 2, 3, 4 precisam ser seguidos pelo stateless, com as excessões:
  • Ele só escolhe um destino do conjunto destino.
  • O parâmetro branch deve ser o mesmo em retransmissões (mas continua sendo único)
• A requisição é enviada direto para o transporte (ao invés da transação cliente)
• Para variações no tempo no estado de configuração, pode-se optar por um comportamento stateful.
• Não há processamento especial para CANCEL.
• O passo (5) do stateful não vale aqui, o stateless pega o campo Via, olha se o primeiro endereço corresponde a ele, remove e repassa. Se não ele descarta.

Processamento do Route no Proxy

• Se não existir uma política local que comprometa, seguem os passos:
  • 1. Inspeciona o Request-URI e o altera usando os serviços de localização se este pertencer ao seu domínio, se não, não há alterações no Request-URI.
  • 2. Olha o URI do campo mais alto de Route, se for ele, remove-o.
  • 3. A requisição é encaminhada para o Route mais alto, e se não existir para o Request-URI.

Exemplos e Cenários

• Começa na página 118 até 122 da RFC.

Transações

• Uma transação é uma requisição, mais todas as respostas pra ela.
• Em um invite a transação só inclui o ACK se a resposta final não for um 200 (ok).
• As transações cliente e servidor são funções lógicas.
• Proxys stateless não tem essas transações.

Relacionamento de transação

• A transação cliente recebe as respostas e filtra as retransmissões, ou respostas anuladas, além de gerar o ACK em resposta a uma 2xx. (Passa as respostas ao TU)
• A servidor é igual só que para requisições, e ela é que absorve o ACK.
• A retransmissão de respostas 2xx é responsabilidade do núcleo UA.

Transação Cliente

• Ela executa suas funções através de uma máquina de estado.
• Quando o TU quer uma nova transação, ele cria a transação cliente e passa para ela a requisição SIP (com IP, porta e transporte)
• Existem duas transações clientes, a INVITE e a não-INVITE. O ACK passa direto do TU para o transporte, e não entre em nenhum dos tipos.

Transação INVITE Cliente

• Esta transação consiste em um tree way handshake. Em caso de UDP a retransmissão é padronizada em 500ms(T1).
• Respostas provisórias cessam retransmissões da TC, mas estas não são em transporte confiável.
• Quando é TCP a resposta final é mandada só uma vez.
• Um timer B de valor 64*T1 é iniciado de qualquer forma para tratar timeouts de transação.
• O timer A que cuida de retransmitir a requisição tem tempo T1, que dobra a cada retransmissão. Essas retransmissões só são feitas enquanto estiver no estado calling.
• O T1 é uma estimativa do RTT.
• Se o timer B disparar ainda no estado calling a transação avisa o TU.
• Se receber uma resposta provisória no estado "calling" passa-se para o estado "Proceeding". Neste estado para a retransmissão, e todas estas mensagens provisórias devem ser passadas ao TU.
• Se estiver em um dos dois estados e receber uma resposta 3xx até 6xx a transação vai para o estado "Completed" e envia um ACK mesmo que o transporte seja confiável. Um timer D é disparado com valor de pelo menos 32s para não confiável e 0s para confiável, que é o tempo em que permanece neste estado.
• Uma recepção de uma retransmissão de uma resposta final enquanto está no "Completed" exige um novo ACK, mas essa resposta não é passada ao TU.
• Se o timer D dispara no Completed a transação deve ir para Terminated.
• Nos estados Calling e Proceeding uma resposta 2xx passa para o estado Terminated e a resposta é passada ao TU. Um UAC responde com ACK, já um proxy com 200 (OK).
• A camada de transação do cliente deve ser destruída quando ela entra em terminated.

Transação INVITE cliente

Contrução da requisição ACK

• Os ACKs aqui descritos são os que são gerados na transação cliente.
• Os campos Call-ID, From e Request-URI são iguais ao da requisição.
• O Campo To é igual ao da resposta sendo reconhecida.
• O Campo CSeq deve ser igual ao da requisição, mas o method deve mudar para "ACK".
• O Via deve possui o valor no topo do Via da requisição original.
• Se a resposta possui Route, esse deve aparecer no ACK também.
• Não é recomendado que ACKs para não-2xx possuam corpo.

Um ACK para respostas finais não 2xx

Transação não-INVITE Cliente

• Não fazem o uso de ACK.
• Modelo requisição-resposta.
• Requisições são retransmitidas em intervalo T1, que dobra até atingir T2.
• Quando uma resposta provisória é recebida, as retransmissões são em T2.
• Retransmissões da requisição continuam mesmo após uma resposta provisória, para garantir a entrega confiável.
• Não existe tratamento especial para uma resposta 2xx.
• O estado Trying define um timer F de 64*T1, e se não for um meio confiável um timer E que dispara em T1 s é definido (que dobra até T2).
• Se uma resposta 2xx for recebida, passa-se para Completed. Se uma resposta provisória for recebida, passa-se para Proceeding. Se o timer F disparar ocorreu timeout e passa para Terminated.
• Mo estado Completed um timer K é definido com T4 (não confiável) ou 0 (confiável), o valor padrão de T4 é 5s, e se ele dispara passa-se para o estado "Terminated". Este estado (Completed) existe para receber qualquer retransmissão de resposta adicional.

Estados não-INVITE transação cliente

Respostas às Transações Clientes

• Uma resposta deve ser direcionada a uma transação, comparando o method (o mesmo da requisição) e o branch.
• Em multicast, o branch de cada resposta é o mesmo, apesar da tag de To mudar, mas apenas a primeira resposta é recebida, as outras são consideradas retransmissões.

Tratando Erros de Transporte

• Se o transporte falhar, a transação cliente deve informar ao TU a falha e passa-se direto ao estado Terminated.

Transação Servidor

• Entrega de requisições ao TU e transmissão confiável de respostas.

Transação INVITE Servidor

• Quando uma transação servidor é criada para um requisição ela entra no estado Proceeding. Neste ponto deve ser gerada uma resposta 100 (Trying), a menos que se saiba que o TU vai gerar uma resposta provisória dentro de 200ms, aí o 100 é opcional.
• Se receber uma requisição retransmitida (no estado Proceeding), reenvia a última resposta recebida do TU.
• Se durante esse mesmo estado a transação servidor receber do TU uma resposta 2xx ela precisa ser passada ao transporte, e passa-se ao estado Terminated. Retransmissões de 2xx são tratadas pelo TU.
• Se o TU passa uma resposta de 300-699 para a transação, ela vai para o estado Completed. Para transaportes não confiáveis um timer G é definifo com T1 seg.
• No completed o timer H também é definido (64*T1) para abandonara as retransmissões e passar ao estado Terminated (e indica ao TU que ouve falha), já o G é para retransmitir e duplica até no máximo T2.
• Um ACK recebido no estado Completed, passa para o estado Confirmed e cessam as retransmissões.
• O propósito do Confirmed é absorver todos ACKs adicionais que chegam. Um timer I igual a T4 é iniciado, e se disparar passa-se ao estado Terminated, I é zero se o transporte for confiável.
• Quando chega em Terminated a transação deve ser destruída imediatamente.

Transação INVITE servidor

Transação não-INVITE Servidor

• Essa transação é inicializada para requisições diferentes de INVITE ou ACK, e começa no estado Trying. Uma vez nesse estado, retransmissões adicionais de requisição são descartadas.
• Se receber uma resposta provisória do TU passa para Proceeding. Qualquer resposta provisória recebida nesse estado á passada para o transporte, e se receber retransmissões de requisição, reenvia a última resposta provisória. Se receber do TU uma resposta final 200-699 passa-se para o estado Completed.
• No estado Completed cria-se um timer J de 64*T1 seg para transportes não confiáveis. Sempre que uma retransmissão de requisição for recebida, repassa a resposta final. Qualquer outra resposta final passadas pelo TU devem ser descartadas nesse estado. Se J disparar passa-se para Terminated.
• Como sempre, deve ser destruída a transação no estado Terminated.

Transação INVITE servidor

Conferindo requisições às Transações Servidor e Erros de transporte

• Para conferir uma requisição com uma transação:
  • Obs: Se o branch começa com "z9hG4bK" a requisição foi gerada por uma transação cliente, e assim será único ao longo de todas as transações desse cliente.
  • Confere o branch, o parâmetro sent-by do Via e o método da requisição (exceto para ACK)
• Se não existir o parâmetro branch, os outros campos são usados, como tag de To e From, Call-ID e CSeq, além de Via.
• Em caso de erro no tranporte, tenta-se fazer um backup da resposta e se os procedimentos falharem, comunica ao TU e encerra.

Transporte

• Responsável pela transmissão real, sobre TCP, SCTP...
• Conexões indexadas por: endereço IP, porta e protocolo de transporte.
• São duas conexões entre os proxys, uma para enviar outra para receber.
• As conexões precisam (é recomendado) ficar abertas pelo menos um tempo depois após a última mensagem.
• Todos elementos SIP precisam implementar TCP e UDP.

Clientes

• O usuário da camada de transporte passa ao transporte cliente o IP, porta, transporte e possivelmente TTL.
• Se uma requisição está a 200 bytes do MTU, ou se ela for maior que 1300 bytes e o MTU for desconhecido, então deve-se usar o TCP (controle de congestionamento). Se não der certo com o TCP reenvia usando UDP.
• Em requisições multicast deve adicionar o parâmetro maddr no Via com o endereço multicast e adicionar o parâmentro ttl p/ IPv4 com valor l.
• Antes de enviar a requisição o transporte cliente insere um valor do campo "sent-by" no Via que contém endereço IP ou nome do host e a porta. Se a porta não for especificada usa-se o padrão (5060 - UDP, TCP e SCTP; 5061 - TLS)
• Geralmente é usada a mesma conexão (no caso confiável) para enviar a resposta, se não der, o servidor pode tentar uma nova conexão, aí a porta em sent-by será usada. Pode acontecer de usar outra porta, assim o cliente deve estar preparado.
• Quando recebe a resposta, se o sent-by não é um valor configurado para inserir requisições, descarta-se a mensagem silenciosamente.
• O mecanismo de conferir a resposta com uma transação já foi descrito.

Servidores

• Qualquer IP, porta e combinação que possa ser retornada em uma consulta DNS, o servidor deve estar preparado para atender.
• É bom sempre ouvir as portas padrões, e escutar na porta UDP também o TCP, já que se a msg for grande ela pode vir em TCP.
• O servidor adiciona um parâmetro received em Via, que contém o endereço origem pelo qual o pacote foi recebido.

Exemplo

• O transporte tenta bater requisição com transação e se não bate manda ao núcleo, que decide se cria uma nova ou não (como no caso do ACK).
• O transporte servidor usa o campo mais alto do Via para mandar uma resposta.
  • No caso de transporte confiável, usa-se a conexão se ela ainda existir, se não, tenta abrir conexão com o endereço IP de received e da porta em sent-by.
  • Se o Via contém o maddr a resposta é encaminhada ao endereço listado lá, usando a porta sent-by (ou a padrão se essa não for especificada). Se for multicast usa o TTL indicado mo parâmetro, ou com TTL igual a l se esse parâmetro não existir.

Enquadramento e Tratamento de Erro

• Se existe o campo Content-Lenght no UDP, se bytes do pacote de transporte passarem esse tamanho são descartados esses bytes, se forem menores é considerado um erro. Se não tem o campo, o corpo da mensagem termina ao final do pacote de transporte.
• O resultado de falhas no transporte são erros ICMP, o qual são geralmente informados ao usuário de transporte (menos source quench e TTL exceeded). No caso confiável, se não conseguir conectar, o usuário de transporte também é informado.

Componentes Comuns de Mensagem

URI do SIP e SIPS

• Um URI do SIPS especifica que o recurso seja contactado de forma segura. Um URI SIP pode ser atualizado para SIPS.
• Seguem padrões parecidos com URL.
• Exemplo de URI do SIP:
  • sip:user:password@host:port;uri-parameters?headers
  • O URI do SIPS é igual só que escreve "sips" no lugar de "sip".
  • Os significados:
    • user: Indicador de um recurso particular, onde host se refere frequentemente a um domínio.
    • password: o uso não é recomendado, mas é a senha associada ao usuário.
    • host: que fornece o recurso SIP.
    • port: número da porta aonda a requisição deve ser enviada.
    • uri-parameters: parâmetros que afetam uma requisição construída a partir da URI. São da seguintes forma: par-name = par-value
      • Um nome de parâmetro não pode aparecer mais de uma vez
      • Mecanismos SIP precisam ignorar parâmetros que eles não entendem.
      • Parâmetros: transport (mecanismo de transporte a ser usado), maddr (endereço do servidor a ser contactado, ttl (time-to-live do pacote multicast UDP e só é usado se maddr for um endereço multicast), method, lr (indica que o elemento responsável por este recurso implementa os mecanismos de roteamento)
      • Por exemplo, especificar uma chamada para alice@atlanta.com usando multicast para 239.255.255.1 com valor TTL 15, o URI seguinte seria usado:
      • sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
      • O parâmetro URI existe para distinguir nomes de usuários e números de telefone (que podem aparecer antes do @)
    • Headers: campos cabeçalhos a serem incluídos em uma requisição.
• Tabela: A coluna externa descreve URI's que aparecem em qualquer lugar fora de uma mensagem SIP, por exemplo, em página Web ou cartão de visita. Entradas marcadas com "m" são obrigatórios, aqueles marcados com "o" são opcionais, e aqueles marcados com "-" não são permitidos. Elementos que processam URI's DEVEM ignorar quaisquer componentes não permitidos se estiverem presentes. A segunda coluna indica o valor padrão de um elemento opcional, se não estiver presente. O "--" indica que o elemento nem é opcional, e nem possui valor padrão.

Tabela

• Para escapar caracteres usa-se o modelo % HEX HEX. Por exemplo "j@son" vira "j%40son".
• Exemplos de URIs:

Exemplo

Comparação de URI

• Regras:
  • Um URI SIPS e um URI SIP nunca são equivalentes.
  • Comparação do userinfo é case sensitive.
  • A ordenação dos campos não é significativa.
  • O IP resultado de busca DNS não bate com o nome do host.
  • Para dois URIs serem iguais: usuário, senha, host e porta devem ser iguais.
  • Um URI que omite um parâmetro não é igual um que declara o parâmetro no valor padrão. Isso vale pra porta, transport-parameter, ttl-parameter, o user-parameter e method.
• Para comparar os componentes uri-parameter:
  • Qualquer uri-parameter aparecendo em ambos URI's precisam bater.
  • Os componentes user, ttl, parameter uri ou até maddr não podem aparecer em só um dos comparados. Os outros parâmetros podem.
  • Componentes Header do URI nunca são ignorados.
• URIs equivalentes:

• URIs não-equivalentes:

• Lembrando, se aparecer security em um dos URIs esse parâmetro é ignorado, mas se aparecer nos dois, eles devem ter o mesmo valor!

Formando requisições a partir de um URI

• URIs podem contar partes inadequadas para a formação de uma requisição.
• É preciso incluir os parâmetros: method, transport, maddr, ttl ou user.
• Os campos From, Call-ID, CSeq, Via e Record-Route não devem ser honrados (perigosos).
• Não devem ser incluídos campos que podem mentir sobre localização ou capacidade.
• Campos descritivos devem ser verificados.
• Se a requisição for inválida, o URI é inválido e não deve prosseguir a transmissão.
• Uma implementação NÃO PODE enviar uma requisição que requer uma extensão que ela não suporta.

Relação entre URIs do SIP e URL de tel

• A porção assinante do URL tel é colocada no userinfo do URI SIP ou SIPS.
  • Exemplos:
    • tel:+358-555-1234567;postd=pp22 torna-se
    • Corretos:
      • sip:+358-555-1234567;postd=pp22@foo.com;user=phone
      • sips:+358-555-1234567;postd=pp22@foo.com;user=phone
    • Já os abaixo estão incorretos:
      • sip:+358-555-1234567@foo.com;postd=pp22;user=phone
      • sips:+358-555-1234567@foo.com;postd=pp22;user=phone
• O case sensitive não afeta o URL tel, ou até a ordem de parâmetros, mas afeta o URI, ou seja URLs equivalentes podem não produzir URIs equivalentes.
• Para não ter esse problema é padrão passar tudo pra minúsculo, e ordenar os parâmetros pelo nome, exceto isdn-subaddress e post-dial (neste caso o que aparece primeiro prevalece)

Exemplo

Tags Option

• Identificadores únicos que designam novas opções ao SIP.
• Aparecem nos campos: Require, Proxy-Require, Supported e Unsupported.

Tags

• Campos To e From.
• As tags do requisitante e do destinatário, mais o Call-ID identificam o diálogo.
• Uma tag deve ser globalmente única e com pelo menos 32 bits de aleatoriedade.

Campos-Cabeçalho

• Seguem abaixo as tabelas 2 e 3 com o resumo dos campos cabeçalho. Para entender cada caractere das tabelas consulte as pags 160 e 161 da rfc 3261.

Accept

• Se esse campo não estiver presente o padrão é application/sdp.
• Um Accept vazio significa que nenhum formato é aceito.
• Exemplo:
  • Accept: application/sdp;level=1, application/x-private, text/html

Accept-Encoding

• Similar ao Accept, restringe os content-codings que são aceitos na resposta
• Valor padrão: identity (nenhuma codificação é permissível)
• Exemplo:
  • Accept-Encoding: gzip

Accept-Language

• Indica preferência de língua para descrições de sessão, status, etc.
• A ausência significa que qualquer língua pode ser usada
• Exemplo:
  • Accept-Language: da, en-gb;q=0.8, en;q=0.7

Alert-Info

• Especifica um toque alternativo.
• Alguns cuidados devem ser tomados, e um usuário deve ser capaz de desabilitar este recurso.
• Exemplo:
  • Alert-Info: <http: moo.wav="" sounds="" www.example.com="">

Allow

• Lista os métodos suportados pelo gerador da mensagem.
• A ausência não pode ser interpretada como o não suporte de qualquer método.
• Exemplo:
  • Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

Authentication-Info

• Autenticação mútua com HTTP Digest. Pode ser incluído em uma resposta 2xx a uma requisição autenticada com sucesso.
• Exemplo:
  • Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

Authorization

• Credenciais de autenticação de um UA e divide as regras gerais com Proxy-Authorization.
• Exemplo:
  • Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e",

response="7587245234b3434cc3412213e5f113a5432"

Call-ID

• Identifica uma chamada ou pedidos de registro de um cliente em particular.
• São case-sensitive e comparados byte a byte. A forma compacta é i.
• Exemplos:
  • Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
  • i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

Call-Info

• Fornece informações adicionais a cerca do chamador ou chamado.
• Parâmetros:
  • icon: imagem do chamador ou chamado
  • purpose: propósito do URI
  • info: descreve um dos lados em geral (um exemplo é através de uma página web)
  • card: cartão de visita
• Esse campo é perigoso, então o UA só o analiza se puder verificar autenticidade.
• Exemplo:
  • Call-Info: <http: alice="" photo.jpg="" wwww.example.com=""> ;purpose=icon,

<http: alice="" www.example.com=""> ;purpose=info

Contact

• Fornece um URI. Pode contar um nome de exibição, URI com parâmetros URI e parâmetros de cabeçalho.
• Dois parâmetros definidos: "q" e "expires".
• Um nome de exibição contem delimitadores "<" e ">", se não todos os parâmetros após o URI são do cabeçalho.
• O papel é similar ao Location no HTTP, mas no HTTP é permitido apenas um endereço.
• A forma compacta é "m".
• Exemplos:
  • Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com> ;q=0.7; expires=3600, "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
  • m: <sips:bob@192.0.2.4>;expires=60

Content-Disposition

• Descreve o corpo ou como parte do corpo deve ser interpretada. Estende o Content-Type.
• Valores:
  • session: parte do corpo descreve uma sessão.
  • render: parte do corpo deve ser exibida ou processada.
• Tipos:
  • icon: parte do corpo contém uma imagem representativa.
  • alert: o corpo contém informações que devem ser processadas para alertar o usuário (como um vídeo ou toque)
• O parâmetro handling (handling-param) descreve como o UAS deve reaagir se não entender o conteúdo da mensagem. Ele pode ter os valores optional e required. Se ele não existe o valor padrão é required.
• Exemplo:
  • Content-Disposition: session

Content-Encoding

• Modificador para o media-type. É usado geralmente para compactação.
• Se múltiplas codificações foram aplicadas, elas devem ser listadas em ordem.
• Os valores desse campo não são case-sensitive.
• A forma compacta é "e".
• Exemplos:
  • Content-Encoding: gzip
  • e: tar

Content-Language

• Exemplo:
  • Content-Language: fr

Content-Length

• Determina o tamanho do corpo (em octetos)
• No caso do TCP ele deve ser usado.
• Se não há corpo o valor é zero, e o CRLF que separa cabeçalho e corpo não deve ser contado.
• A forma compacta é "l".
• Exemplos:
  • Content-Length: 349
  • l: 173

Content-Type

• Indica o tipo de mídia do corpo da mensagem.
• Precisa aparecer quando a mensagem tem corpo.
• A forma compacta é "c".
• Exemplos:
  • Content-Type: application/sdp
  • c: text/html; charset=ISO-8859-4

CSeq

• Contém um número de sequência decimal único e o método da requisição.
• O número é de 32 bits sem sinal e o método é case-sensitive.
• Exemplo:
  • CSeq: 4711 INVITE

Date

• Contém hora e data.
• Pode ser usado por sistemas finais sem relógio persistente para adquirir noção do tempo atual, mas pode conter uma forma GMT que exige o offset.
• Exemplo:
  • Date: Sat, 13 Nov 2010 23:29:00 GMT

Error-Info

• Fornece um ponteiro para informações adicionais a cerca da resposta de status de erro.
• URI SIP ou SIPS pode ser colocado como novo contato. Um URI não-SIP pode ser apresentado.
• Exemplos:
  • SIP/2.0 404 The number you have dialed is not in service
  • Error-Info: <sip:not-in-service-recording@atlanta.com>

Expires

• O tempo relativo após o qual a mensagem expira.
• É um número decimal inteiro entre 0 e (2^32)-1, medido a partir do recebimento da requisição.
• Exemplo:
  • Expires: 5

From

• Indica o iniciador da requisição. O "display-name" é opcional e "Anonymous" deve ser usado se a identidade do cliente estiver escondida.
• Dois cabeçalhos from são equivalentes de o URI bater e os parâmetros conferirem.
• A forma compacta é "f".
• Exemplos:
  • From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
  • From: sip:+12125551212@server.phone2net.com;tag=887s
  • Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

In-Reply-To

• Enumera os Call-IDs que essa chamada referencia ou retorna.
• Exemplo:
  • In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com

Max-Forwards

• Precisa ser usado com qualquer método SIP para limitar o número de "encaminhadores".
• Elementos que não podem detectar loop de outra forma devem inserí-lo.
• Valor entre 0-255, com padrão 70.
• Exemplo:
  • Max-Forwards: 6

Min-Expires

• Transmite o intervalo de atualização mínimo de elementos gerenciados por este servidor.
• Contém um número decimal entre 0 até (2^32)-1, a unidade é segundos.
• Exemplo:
  • Min-Expires: 60

MIME-Version

• Exemplo:
  • MIME-Version: 1.0

Organization

• Transmite o nome da organização que o elemento SIP que emitiu a mensagem pertence.
• Exemplo:
  • Organization: Boxes by Bob

Priority

• Indica a urgência da requisição como percebido pelo cliente.
• Pode ser: non-urgent, normal, urgent e emergency. O emergency só pode ser usado quando vida, integridade física estão em perigo iminente.
• Exemplos:
  • 1-
  • Subject: A tornado is heading our way!
  • Priority: emergency
  • 2-
  • Subject: Weekend plans
  • Priority: non-urgent

• Obs.: São dois exemplos, Subject fica na primeira linha e Priority na segunda.

Proxy-Authenticate

• Contém um desafio de autenticação
• Exemplo:
  • Proxy-Authenticate: Digest realm="atlanta.com", domain="sip:ss1.carrier.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5

Proxy-Authorization

• Permite ao cliente identificar-se a um proxy que requer autenticação.
• Combinado com Authorization.
• Exemplo:
  • Proxy-Authorization: Digest username="Alice", realm="atlanta.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022"

Proxy-Require

• Indica características proxy-sensitive que precisam ser suportadas pelo proxy.
• Exemplo:
  • Proxy-Require: foo

Record-Route

• É inserido para forçar requisições futuras a passar por aquele elemento (proxy).
• Exemplo:
  • Record-Route: <sip:server10.biloxi.com;lr>,

<sip:bigbox3.site3.atlanta.com;lr>

Reply-To

• Contém um URI de retorno lógico diferente do From.
• Exemplo:
  • Reply-To: Bob <sip:bob@biloxi.com>

Require

• Usado pelo UAC para dizer ao UAS quais opções ele quer que sejam suportadas.
• Esse campo não pode ser ignorado se estiver presente.
• Contém uma lista de tags option, onde cada uma define uma extensão SIP. Essas tags são padronizadas.
• Exemplo:
  • Require: 100rel

Retry-After

• Pode ser usado com respostas 500 (Server Internal Error) ou 503 (Service Unavailable) para indicar quanto tempo o serviço é esperado estar indisponível, e com 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy) ou 603 (Decline) para indicar quando a parte da chamada vai estar disponível novamente.
• É um tempo decimal em segundos.
• Um parâmetro duration opcional indica quanto tempo o lado chamado estará alcançável a partir do instante inicial de disponibilidade. Se este campo não aparecer a disponibilidade é indeterminada.
• Exemplos:
  • Retry-After: 18000;duration=3600
  • Retry-After: 120 (I'm in a meeting)

Route

• Forçar o roteamento para uma requisição através do conjunto de proxys listados.
• Exemplo:

Route: <sip:bigbox3.site3.atlanta.com;lr>, <sip:server10.biloxi.com;lr>

Server

• Informação sobre o software usado pelo UAS para tratar a requisição.
• Essa é uma opção configurável, pelo perigo de vulnerabilidade.
• Exemplo:
  • Server: HomeServer v2

Subject

• Fornece um resumo ou indica a natureza da chamada.
• A forma compacta é "s".
• Exemplos:
  • Subject: Need more boxes
  • s: Tech Support

Supported

• Enumera as extensões suportadas pelo UAC ou UAS.
• Contém uma lista de tags options, e se estiver vazio, nenhuma extensão é suportada.
• Forma simplificada é "k".
• Exemplo:
  • Supported: 100rel

Timestamp

• Descreve quando o UAC enviou a requisição.
• Exemplo:
  • Timestamp: 54

To

• Especifica o destino lógico da requisição. O "display-name" é opcional (para usuário humano).
• Possui a tag que identifica o diálogo.
• A comparação destes campos é igual a do From.
• Forma compacta é "t".
• Exemplos:
  • To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
  • t: sip:+12125551212@server.phone2net.com

Unsupported

• Lista os recursos não suportados pelo UAS.
• Exemplo:
  • Unsupported: foo

User-Agent

• Contém informação sobre o UAC que originou a requisição.
• Deve ser configurável por questão de segurança.
• Exemplo:
  • User-Agent: Softphone Beta1.5

Via

• Indica o caminho da requisição "até aqui" e o roteamento das respostas.
• Contém o branch ID, identificador da transação.
• Pode conter os parâmetros: maddr, ttl, received, e outros.
• Contém o protocolo de transporte, hostname do cliente ou endereço de rede, e possivelmente a porta que ele deseja receber as respostas.
• A forma compacta é "v".
• A questão do cookie mágico (Seção 8.1.1.7 da RFC)
• Exemplo:
  • Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
  • Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 ;branch=z9hG4bK77asjd

Warning

• Informações adicionais sobre o status da respostas.
• Contém um código de aviso (3 dígitos), hostname e texto de aviso.
• O "warn-text" deve ser inteligível ao usuário humano, pode-se usar até o Content-Language para isso.
• Para ver os tipos basta consultar as pags 181 e 182 da RFC.
• Exemplos:
  • Warning: 307 isi.edu "Session parameter 'foo' not understood"
  • Warning: 301 isi.edu "Incompatible network address type 'E.164'"

WWW-Authenticate

• Contém um desafio de autenticação.
• Exemplo:
  • WWW-Authenticate: Digest realm="atlanta.com", domain="sip:boxesbybob.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5

Códigos de Resposta

• Estendem e são consistentes com os códigos do HTTP/1.1, mas nem todos são adequados. Além disso, o 6xx é uma nova classe.

Provisional 1xx

• Indica uma ação do servidor que ainda não tem uma resposta definitiva.
• Ele envia a mensagem se espera gastar mais de 200 ms pra obter a resposta final.
• Estas respostas não são transmitidas de forma confiável.
• Podem conter corpos com descrições e não exigem ACK do cliente.
• Exemplos:
  • 100 Trying
  • 180 Ringing
  • 181 Call Is Being Forwarded
  • 182 Queued
  • 183 Session Progress

Sucessful 2xx

• Requisição bem sucedida.
• Exemplo:
  • 200 OK

Redirection 3xx

• Fornecem informações sobre a nova localização do usuário, ou sobre serviços que podem satisfazer a chamada.
• Exemplos:
  • 300 Multiple Choices (Pode usar o corpo e até o campo Contact para oferecer mais opções)
  • 301 Moved Permanently (Usa Contact)
  • 302 Moved Temporarily (Usa Contact)
  • 305 Use Proxy (Usa Contact)
  • 380 Alternative Service (Usa o corpo da mensagem)

Request Failure 4xx

• São respostas de falhas definitivas em um servidor particular.
• O Cliente não deve tentar a mesma requisição sem modificá-la, mas a mesma pode ser tentada em um servidor diferente.
• Exemplos:
  • 400 Bad Request
  • 401 Unauthorized (Resposta lançada por UAS e registradores)
  • 402 Payment Required
  • 403 Forbidden
  • 404 Not Found
  • 405 Method Not Allowed (método permitido, mas não
  • 406 Not Acceptable
  • 407 Proxy Authentication Required (igual a 401 mas lançada pelo proxy)
  • 408 Request Timeout
  • 410 Gone
  • 413 Request Entity Too Large
  • 414 Request-URI Too Long
  • 415 Unsupported Media Type
  • 416 Unsupported URI Scheme
  • 420 Bad Extension
  • 421 Extension Required
  • 423 Interval Too Brief (esta é aquela do tempo de expiração muito curto)
  • 480 Temporarily Unavailable (pode usar Retry-After para indicar uma próxima tentativa)
  • 481 Call/Transaction Does Not Exist
  • 482 Loop Detected
  • 483 Too Many Hops
  • 484 Address Incomplete (Request-URI incompleto)
  • 485 Ambiguous (Request-URI ambíguo)
  • 486 Busy Here
  • 487 Request Terminated
  • 488 Not Acceptable Here (Mesmo significado que 606, mas só se aplica ao recurso específico endereçado pelo Request-URI)
  • 491 Request Pending
  • 493 Undecipherable

Server Failure 5xx

• São respostas de falhas quando o servidor se confundiu, ou entrou em condição inesperada.
• Exemplos:
  • 500 Server Internal Error
  • 501 Not Implemented
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Server Time-out
  • 505 Version Not Supported
  • 513 Message Too Large

Global Failures 6xx

• Indicam que um servidor tem uma informação definitiva sobre um usuário em particular, e não apenas a instância particular no Request-URI.
• Exemplos:
  • 600 Busy Everywhere
  • 603 Decline
  • 604 Does Not Exist Anywhere
  • 606 Not Acceptable

Uso da Autenticação HTTP

• O SIP oferece um mecanismo stateless que é um desafio para autenticação baseado na autenticação HTTP.
• O sistema "Básico" de autenticação não é mais usado, o mecanismo descrito neste documento é o Digest.

Infra-Estrutura

• No SIP usa-se a resposta 401 (Unauthorized) para desafiar a identidade de um UAC, já um proxy usa 407 (Proxy Authentication Required).
• Operadores de UA ou servidor proxy devem seguir as orientações abaixo para a string realm:
  • Elas precisam ser globalmente únicas, é recomendado que contenham nome de domínio ou hostname.
  • Elas devem apresentar um identificador legível a humanos.
• Exemplo:
  • INVITE sip:bob@biloxi.com SIP/2.0
  • Authorization: Digest realm="biloxi.com", <...>
• A autenticação SIP é pensada para um realm específico, um domínio de proteção, que contém seu conjunto de nomes de usuário e senhas.
• Duas requisições requerem tratamento especial: ACK e CANCEL.
• Um ACK não pode ser desafiado, e ele copia todos os valores dos campos Authorization e Proxy-Authorization que aparecem no INVITE a qual esse ACK corresponde.
• A CANCEL também não pode ser desafiada, ela deve ser aceita se vem do mesmo salto que enviou a requisição que está sendo cancelada.
• Um UAC recebe um desafio quando o conteúdo de realm é entregue ao usuário (em WWW-Authenticate ou Proxy-Authenticate), desde que o dispositivo já não conheça esse realm.
• Um UAC não pode re-tentar requisições com credenciais que acabaram de ser rejeitadas.

Autenticação Usuário a Usuário

• o UAS pode desafiar (exigir autenticação) antes da requisição ser processada.
• O Campo WWW-Authenticate deve estar incluído na resposta 401 (Unauthorized). O valor do campo é composto de pelo menos um desafio que indica o esquema de autenticação e os parâmetros aplicáveis ao realm.
• Um exemplo de desafio:

WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"

• Quando o UAC recebe a 401 ele deve re-originar a requisição com as credenciais adequadas e pode exigir entrada do usuário. Depois de gerar as credenciais elas são "cache-adas" para o cabeçalho To e "realm" e tenta usar este mesmo valor para as próximas requisições para o mesmo destino.
• Se não for encontrada nenhuma credencial, pode tentar repetir com Anonymous e sem senha.
• Com as credenciais localizadas inclui-se o campo Authorization com estas, e com parâmetros exigidos no suporte de proteção a autenticação e resposta.
• Um exemplo de Authorization:
  • Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"
• O valor de CSeq deve ser incrementado após receber 401 ou 407.

Autenticação Proxy-a-Usuário

• O proxy pode desafiar autenticação normalmente com a mensagem 407 (Proxy Authentication Required).
• Os campos: Proxy-Authenticate (proxy preenche), Proxy-Authorization (UAC preenche).
• A autenticação aqui é similar à anterior, usa-se o "realm" da mesma forma.
• No caso de bifurcação, o proxy onde ela acontece é responsável por juntar todos os desafios em uma só mensagem. Aí o UAC pode incluir um campo Authorization ou Proxy-Authorization para cada desafio (diferenciados por realm).

Esquema de autenticação Digest

• As diferenças do HTTP para o SIP(pag 199, 200):
  • Muda de HTTP/1.1 para SIP/2.0
  • O URI no desafio:
    • URI = SIP-URI / SIPS-URI
  • 'uri' delimitado por aspas no SIP
  • digest-uri-value = Request-URI
  • Operação de cache no HTTP não vale para o SIP.
  • O URI no Authorization e na linha da requisição não precisam apontar para o mesmo recurso no SIP.
  • É permitido usar o campo cabeçalho Authentication-Info.

S/MIME

• O padrão MIME possui recursos para proteger o conteúdo e assegurar confidencialidade.
• O problema é que ele pode impedir intermediários de alterar o corpo da mensagem, assim eles não funcionam.

Certificados S/MIME

• São usados para identificar um usuário final, associados com chaves que são usadas para assinar ou criptografar os corpos das mensagens.
• Chaves públicas do dentino são usadas para criptografar e a chave privada do remetente é usada para assinar.
• Cada UA que suporta S/MIME precisa de um keyring para certificados.
• UACs devem ter um mecanismo para importar certificados descobertos em diretórios públicos que correspondem a URIs de destino.

Troca de Chave S/MIME

• A mensagem SignedData CMS é usada para a obtenção da chave pública, se ela já é conhecida, usa EnvelopedData encapsulada dentro de uma SignedData. Isto é no início de um diálogo ou em uma mensagem fora do diálogo.
• O UAS valida o certificado (com algum certificado raiz disponível por autoridades de certificação), e determina o assunto do mesmo (observando SubjectAltName e o campo From).
• Se a conferência deu certo adiciona o certificado ao keyring local, se não o usuário é notificado. A resposta para esta primeira mensagem também será SignedData, ou EnvelopedData encapsulada.
• O UAC quando recebe a resposta checa o certificado e também faz comparação, só que com To. Igual acima o UAC envia ao usuário se não validar o certificado esperando que este autorize ou não. Se der certo, adiciona o certificado no keyring.
• No futuro se o UA comparar um certificado com os já existentes e ver que mudou, novamente pede autorização ao usuário.
• A mensagem 493 (Undecipherable) é enviada quando uma chave pública é desconhecida. Na resposta deve ser enviado um certificado válido. Se não houver certificado mensagens S/MIME criptografadas não serão aceitas.
• Se não compreender MIME envia 415 (Unsupported Media Type).
• Mensagens não seguras S/MIME são notificadas ao usuário.

Protegendo corpos MIME

• Pontos importantes:
  • "multipart/signed" precisa ser usado só com assinaturas CMS detached.
  • Corpos S/MIME tem que ter o campo Content-Disposition, com o parâmetro handling de valor "required".
  • Existe o atributo que deve ser usado para expressar capacidades e preferências (SMIMECapabilities).
  • Cada corpo S/MIME deve ter apenas um certificado. Se tiver mais de um considera-se o mais externo.
• Segue um exemplo de um corpo SDP S/MIME criptografado em uma mensagem SIP

Privacidade e Integridade do Cabeçalho SIP usando S/MIME: Tunelamento SIP

• A mensagem SIP inteira pode ser encapsulada dentro de corpos MIME.
• Pode ocorrer discrepância entre a mensagem "interna" e a "externa".
• A integridade de uma mensagem é verificada batendo os campos-cabeçalho do corpo assinado com os da mensagem externa, a não ser aqueles que proxys podem alterar. As regras de comparação são aquelas descritas lá atrás...
• Se encontrar discrepância os usuários devem ser avisados.
• Campos criptografados podem não estar incluídos na mensagem externa.
• Um corpo MIME assinado, desde que contenha os identificadores de diálogo fundamentais (To, From, Call-ID, CSeq), pode fornecer autenticação limitada. Mesmo que o certificado for desconhecido, a assinatura pode identificar mensagens de uma mesma fonte.
• Alguns campos, como o Date, devem ser idênticos, outros não é nem útil criptografá-los.
• Os campos internos podem ser usados para identificar a integridade da mensagem, como o campo Date. Se uma violação for detectada pode ser respondida com 403 (Forbidden). Neste caso o usuário deve ser notificado e é requisitada uma orientação explícita do mesmo sobre como proceder.
• Exemplo de mensagem tunelada: pags 210 e 211 da RFC.
• Um corpo MIME com tunelamento pode ser criptografado, ou seja, os cabeçalhos da mensagem interior seriam criptografados. Esses corpos devem ser assinados pelo remetente.
• Exemplo de mensagem tunelada e com cabeçalhos criptografados: pags 212 e 213.

Exemplos

• Da pag 213 até a pag 219 tem dois exemplos de interações SIP.

BNF "aumentado" para SIP

• Esta seção engloba da pág 219 até 232, que são regras e caracteres para serem usados na mensagem SIP.
• A partir da pág 222 tem exemplos de como escrever cada campo cabeçalho e parâmetros do SIP.

Considerações de Segurança: Modelo de Ameaça e Recomendações de Uso de Segurança

• A segurança não é básica no SIP, são muitos intermediários e pontos não confiáveis.

Modelos de Ataques e Ameaça

• Existem algumas ameaças comuns no SIP que serão descritas a seguir.
• O SIP é usado em Internet Pública, assim várias situações podem aparecer desde a modificação de pacotes, até interferência nas sessões.

Sequestro de Registro

• O Campo FROM de uma requisição SIP pode ser alterado, abrindo portas para registros maliciosos. Assim registros do registrador poderiam ser alterados, deletados, ou até direcionados a um dispositivo.
• O método para evitar seriam as próprias autenticações dos originadores das mensagens

Passando-se por um Servidor

• Um dispositivo pode passar por um servidor específico, gerar respostas apropriadas e assim direcionar chamadas de um UAC para conteúdos maliciosos.
• Uma forma de prevenir é a autenticação em servidores.

Adulteração de Corpos de Mensagem

• Os proxys geralmente são confiáveis, mas não para alterar a mensagem.
• Assim um proxy malicioso pode querer alterar chaves de sessão e até o conteúdo transportado.
• Alguns campos devem ser protegidos até o fim (como o Subject).
• Alternativas englobam autenticação, e confidencialidade do conteúdo da mensagem.

Derrubando Sessões

• Requisições, depois do estabelecimento de uma sessão, podem alterar o estado de um diálogo, e é crítico que essas não venham forjadas de um atacante.
• Um atacante que tenha acesso às mensagens iniciais pode capturar certas informações (tag de To ou From por exemplo) e enviar um BYE para derrubar a sessão, ou até alterar a sessão reduzindo a segurança.
• Usar confidencialidade e autenticação ajudam a evitar esse tipo de ataque.

Negação de Serviço e Amplificação

• É fazer uma inundação em algum elemento de rede em particular para "travar" o serviço.
• Múltiplos hosts da rede procurando o mesmo destino.
• Campos como Route e até o IP podem ser forjados e falsificados, fazendo mensagens indevidas chegarem em proxys bifurcantes por exemplo, o que piora ainda mais a situação.
• Pode ser usado também o registrador, através de registros falsos, todos apontando para um mesmo local.
• O uso de multicast pode aumentar significativamente esses ataques.
• Neste caso deve definir arquiteturas que minimizem os riscos, além de ficar atento e tentar identificar estes ataques.

Mecanismos de Segurança

• Serviços fundamentais: confidencialidade, autenticação e integridade.
• Reusa serviços do HTTP e SMTP.
• Criptografia não pode ser aplicada a tudo, campos como Via, Route, ..., podem ser modificados pelo caminho pelos proxies.

Segurança nas Camadas de Rede e Transporte

• Duas alternativas para segurança neste nível: TLS e IPSec.
• O IPSec é um conjunto de ferramentas de protocolo na camada de rede, normalmente implementado no nível de sistema operacional. Ele não exige integração com a aplicação SIP o que o torna talvez o mais adequado em casos onde adicionar segurança aos hosts SIP é complicado.
• O TLS é usado sobre transporte confiável (TCP) e é útil em segurança nó a nó (Usuário confia no proxy, que confia em outro proxy, assim por diante). Ele precisa ser acoplado a aplicação SIP.

Esquema URI do SIPS

• Um URI do SIPS no Request-URI significa que todos os elementos por onde a requisição é encaminhada devem ter suporte a TLS.
• Não pode ser usado o UDP, visto que o transporte tem que ser seguro.
• Também devem ser validados os certificados recebidos na autenticação com os mantidos pelo cliente.

Autenticação HTTP

• Baseada nas respostas 401 e 407 e nos desafios e credenciais.

S/MIME

• Criptografar toda a mensagem SIP não é adequado (como dito acima). O S/MIME criptografa corpos MIME da mensagem SIP e pode ser usado em tunelamento também.

Implementando Mecanismos de Segurança

Exigências para Implementadores do SIP

• Servidores proxy, redirect e registradores devem implementar TLS e precisam suportar autenticação mútua e mão única. Além disso devem ter um certificado de site que corresponda a seu hostname canônico. Também devem suportar autenticação Digest e possuir ao menos uma string "realm".
• Todos elementos que possuem TLS devem ter um mecanismo para validar certificados e devem suportar o esquema URI do SIPS.

Soluções de Segurança

• Em um nível peer to peer os UAs confiam na rede para autenticarem entre si, mas o S/MIME pode ser usado quando a rede não é confiável.
• No registro deve se estabelecer uma conexão TLS com o registrador, que se falhar os certificados deve ser cancelada. Se não falhar o REGISTER deve ser mandado e respondido com um 401, desafiando autenticação (tudo sobre a conexão TLS).
• Se o proxy local é sainte, deve ser usada a conexão TLS para enviar um INVITE a outro usuário, que se estiver no domínio deste proxy exige apenas consulta no serviço de localização local. Se o Request-URI se refere a um proxy remoto, um TLS mútuo é aberto entre os dois proxys, e validando os certificados o INVITE pode ser passado adiante. O segundo proxy não tem como saber a identidade do usuário que enviou o INVITE, mas pode ser rigoroso e exigir compartilhamento de informações com o primeiro proxy. O Record-Route pode ajudar neste ponto para que todas as próximas mensagens passem por estes proxys.
• Sem o proxy local sainte não há como o primeiro usuário revelar sua identidade ao proxy remoto, mas ele pode ser redirecionado e estabelece assim uma conexão TCP com o destino, e pode usar de autenticação para começar o diálogo seguro.
• Contra ataques de negação de serviço devem existir defesas operacionais, além do uso de TLS de IPSec. Servidores proxy podem bloquear tráfegos aos destinos, além de que os stateful são mais vulneráveis a estes ataques. É importante saber que autenticação mútua por TLS ajuda muito a diminuir este problema

Limitações

• Existem limitações nestes mecanismos apresentados que precisam ser conhecidas.

HTTP Digest

• Os mecanismos de integridade do Digest não funcionam muito bem no SIP, principalmente porque nem tudo que é interessante ser protegido de fato o é.
• Mecanismos de repetição também possuem algumas limitações para o SIP.
• O escopo de realms também pode ser uma limitação.

S/MIME

• O maior defeito do S/MIME é a ausência de infra-estrutura de chave pública, já que uma mensagem pode ser interceptada e adicionada a chave do atacante (teria que ser a primeira).
• As chaves associadas com o S/MIME são mais úteis quando são associadas a um usuário ao invés de um dispositivo.
• O S/MIME também pode gerar mensagens muito grandes com o tunelamento, daí é por isso que é recomendado o uso do TCP nestes casos.

TLS

• Não pode ser rodado sobre o UDP (tem que ser entrega confiável)
• Manter muitas conexões TLS simultâneas pode ser árduo.
• O TLS só oferece autenticação a servidores adjacentes.

URI's do SIPS

• Ele não garante o uso do TLS fim a fim verdadeiramente, já que muitas arquiteturas dependem de outros mecanismos para chegar ao nó final.
• Alguns intermediários maliciosos poderiam substituir um URI do SIPS por um do SIP para reduzir a segurança.
• Comparar o Request-URI com o To (no sentido de ser URI do SIPS/SIP) pode ser um indício de violação e a conexão pode ser recusada. Além do Via para ver se o TLS foi ou não usado no caminho.

Privacidade

• Podem existir informações abertas que seria bom não serem divulgadas, como um número de telefone por exemplo.
• Em alguns casos os usuários podem querer esconder informações de cabeçalhos que transmitem identidade

IANA

• Todos os nomes de campo cabeçalho, códigos de status e tags option estão registrados no IANA, e suas regras estão detalhadas da pág 252 até 255.

Mudanças da RFC anterior, Referências e Outras Informações

• Detalhadas da pág 255 até a pag 269.