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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Isso fornece um nível modesto de retro-compatibilidade com a RFC 2543, que permitiu tempos absolutos neste campo-cabeçalho. Se um tempo absoluto for recebido, ele será tratado como malformado, e então usa padrão igual 3600.

Servidores redirect PRECISAM ignorar recursos que não são compreendidos (incluindo campos cabeçalhos não reconhecidos, quaisquer tags option desconhecidas em Require, ou mesmo nomes de método) e prosseguir com o redirecionamento da requisição em questão.


9 Cancelando uma Requisição

A seção anterior discutiu comportamento geral do UA para gerar requisições e processar respostas de requisições de todos os métodos. Nesta seção, nós discutiremos um método de propósito geral, chamado CANCEL.

A requisição CANCEL, como o nome indica, é usado para cancelar uma requisição anterior enviada por um cliente. Especificamente, ela pede ao UAS que cesse o processamento da requisição e gere uma resposta de erro para essa requisição. CANCEL não tem nenhum efeito sobre uma requisição para qual um UAS já forneceu uma resposta final. Devido a isso, é mais útil CANCEL-AR requisições em que pode tomar um tempo longo do servidor para responder. Por essa razão, CANCEL é melhor para requisições INVITE, que pode tomar um tempo longo para gerar uma resposta. Nesse uso, um UAS que recebe uma requisição CANCEL para um INVITE, mas ainda não enviou uma resposta final, "interromperia o toque", e então responderia ao INVITE com uma resposta específica de erro (uma 487).

Requisições CANCEL podem ser construídas e enviadas tanto por proxy's quanto por clientes agentes-usuários. A Seção 15 discute sob quais condições UAC CANCEL-ARIA uma requisição INVITE e a Seção 16.10 discute uso de CANCEL por proxy.

Um proxy stateful responde a um CANCEL, ao invés de simplesmente encaminhar uma resposta que receberia de um elemento downstream. Por essa razão, CANCEL é referido como uma requisição "hop-by-hop", uma vez que é respondida em cada hop de proxy stateful.


9.1 Comportamento do Cliente

Uma requisição CANCEL NÃO DEVE ser enviada para cancelar uma requisição que não seja um INVITE.

Como requisições diferentes de INVITE são respondidas imediatamente, enviar um CANCEL a uma requisição não-INVITE sempre criaria uma condição race.





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

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.