RFC 3261 Português Página 55

RFC 3261 SIP: Session Initiation Protocol Junho 2002

definido na Seção 17.1.1.1), o cliente DEVE então considerar a transação original cancelada e DEVE destruir a transação cliente que gerencia a requisição original.

9.2 Comportamento do Servidor

O método CANCEL requisita ao TU no lado servidor para cancelar uma transação pendente. O TU determina que a transação seja cancelada, tendo a requisição CANCEL e, em então supondo que o método de requisição sejam todos, exceto CANCEL ou ACK e aplicando os procedimentos de transação correspondentes da Seção 17.2.3. A transação correspondente é aquela a ser cancelada.

O processamento de uma requisição CANCEL em um servidor depende do tipo de servidor. Um proxy stateless irá encaminhá-lo, um proxy stateful pode respondê-la e gerar algumas requisições CANCEL por si próprio, e um UAS vai respondê-lo. Veja a Seção 16.10 para tratamento de CANCEL pelo proxy.

Um UAS primeiro processa a requisição CANCEL de acordo com o processamento geral de UAS descrito na Seção 8.2. No entanto, dado que requisições são CANCEL hop-by-hop e não podem ser re-submetidas, elas não podem ser desafiadas pelo servidor para obter credenciais adequadas de um campo-cabeçalho Authorization. Note também que as requisições CANCEL não contêm um campo cabeçalho Require.

Se o UAS não encontrar uma transação correspondente para a CANCEL acordo com o procedimento acima, ele DEVE responder à CANCEL com um 481 (Call Leg/Transaction Does Not Exist). Caso a transação para a requisição original ainda existir, o comportamento do UAS ao receber uma requisição CANCEL depende se ele já enviou uma resposta final a requisição original. Se ele já enviou, a requisição CANCEL não tem nenhum efeito no processamento da requisição original, nenhuma efeito em nenhum estado da sessão, e nenhum efeito nas respostas geradas à requisição original. Se o UAS não lançou uma resposta final à requisição original, o seu comportamento depende do método da requisição original. Se a requisição original foi um INVITE, o UAS DEVE responder imediatamente ao INVITE com uma resposta 487 (Request Terminated). Uma requisição CANCEL não tem nenhum impacto sobre o processamento de transações com qualquer outro método definido nessa especificação.

Independentemente do método da requisição original, tão logo a CANCEL bateu com uma transação existente, o UAS responde por conta própria à requisição CANCEL com uma resposta 200 (OK). Essa resposta é construída seguindo os procedimentos descritos na Seção 8.2.6 observando que o token tag do campo To da resposta à CANCEL e o token tag do campo To na resposta à requisição inicial DEVE ser o mesmo. A resposta à CANCEL é passado para a transação servidor para transmissão.

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.