Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Se a requisição INVITE cuja resposta está sendo reconhecida tinha campos-cabeçalhos Route, esses campos-cabeçalhos PRECISAM aparecer no ACK. Isso é para garantir que o ACK possa ser roteado adequadamente através de quaisquer proxy's downstream sem estado.

Embora qualquer requisição POSSA conter um corpo, um corpo em ACK é especial, porque a requisição não pode ser rejeitada se o corpo não for compreendido. Portanto, a colocação de corpos em ACK para não-2xx NÃO É RECOMENDADO, mas se for feito, os tipos de corpo são restritos a quaisquer que apareceram no INVITE, assumindo que a resposta ao INVITE não seja 415. Se fosse, o corpo no ACK PODE ser qualquer tipo listado no campo-cabeçalho Accept no 415.

Por exemplo, considere a seguinte requisição:

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
   To: Bob <sip:bob@biloxi.com>
   From: Alice <sip:alice@atlanta.com>;tag=88sja8x
   Max-Forwards: 70
   Call-ID: 987asjd97y7atg
   CSeq: 986759 INVITE

A requisição ACK para uma resposta final non-2xx a essa requisição pareceria com isso:

   ACK sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
   To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
   From: Alice <sip:alice@atlanta.com>;tag=88sja8x
   Max-Forwards: 70
   Call-ID: 987asjd97y7atg
   CSeq: 986759 ACK


17.1.2 Transação Não-INVITE Cliente

17.1.2.1 Visão Geral da Transação não-INVITE

Transações não-INVITE não fazem uso de ACK. Eles são simples interações requisição-resposta. Para transportes não confiáveis, requisições são retransmitidas em um intervalo que começa com T1 e dobra até atingir T2. Se uma resposta provisória for recebida, retransmissões continuam para transportes não confiáveis, mas em um intervalo T2. A transação servidor retransmite a última resposta que enviou, a qual pode ser uma resposta provisória ou final, somente quando uma retransmissão da requisição for recebida. Isso é porque retransmissões de requisição necessitam continuar, mesmo após uma resposta provisória; elas são para garantir a entrega confiável de resposta final.



Rosenberg, et. al.          Standards Track                   [Página 130]

Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:

User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.

Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de 
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:

MUST:
    PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO, 
    NECESSITAR, É MANDATÓRIO.

MUST NOT:
    NÃO PODE, É PROIBIDO, É VEDADO.

SHOULD:
    DEVE, É RECOMENDADO.

SHOULD NOT:
    NÃO DEVE, NÃO É RECOMENDADO.

MAY:
    PODE, É OPCIONAL.