RFC 3261 Português Página 54

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Os seguintes procedimentos são usados para construir uma requisição CANCEL. Os campos-cabeçalhos Request-URI, Call-ID, To, a parte numérica de CSeq e From na requisição CANCEL PRECISAM ser idênticos àqueles da requisição que está sendo cancelada, incluindo tokens de tags. Um CANCEL construído por um cliente PRECISA ter somente um valor no único campo-cabeçalho Via que confere com o valor do campo Via mais alto da requisição sendo cancelada. Usando os mesmos valores para esses campos-cabeçalhos permite ao método CANCEL ser conferido com a requisição que ele está cancelando (Seção 9.2 indica como ocorre tal conferência). No entanto, a parte do método do campo-cabeçalho CSeq PRECISA ter um valor de CANCEL. Isso o permite ser identificado e processado como uma transação em seu próprio domínio (ver Seção 17).

Se a requisição sendo cancelada contém um campo-cabeçalho Route, a requisição CANCEL PRECISA incluir valores desse campo-cabeçalho Route.

Isso é necessário de sorte que proxy's stateless sejam capazes de rotear requisições CANCEL apropriadamente.

A requisição CANCEL NÃO PODE conter campos-cabeçalhos Require ou Proxy-Require.

Uma vez CANCEL seja construída, o cliente DEVE verificar se ele recebeu alguma resposta (provisória ou definitiva) para a requisição que está sendo cancelada (aqui referida como a "requisição inicial").

Se nenhuma resposta provisória foi recebida, a requisição CANCEL NÃO PODE ser enviada, pelo contrário, o cliente PRECISA aguardar a chegada de uma resposta provisória antes de enviar a requisição. Se a requisição inicial gerou uma resposta final, o CANCEL NÃO DEVE ser enviado, porque é um não-op eficiente, já que CANCEL não tem nenhum efeito sobre requisições que já geraram uma resposta final. Quando o cliente decide enviar o CANCEL, ele cria uma transação cliente para a CANCEL e passa-lhe a requisição CANCEL junto com o endereço e porta de destino e o transporte. O endereço e porta destino, e o transporte para o CANCEL PRECISAM ser idênticos àquelas usadas para enviar a requisição original.

Se fosse permitido enviar a CANCEL antes de receber uma resposta à requisição anterior, o servidor poderia receber a CANCEL antes da requisição original.

Note que tanto a transação correspondente à requisição original e a transação CANCEL se encerrarão independentemente. Contudo, um UAC que cancela uma requisição não pode depender da recepção de uma resposta 487 (Request Terminated) ao requisição original, porque um UAS em conformidade com a RFC 2543 não irá gerar tal resposta. Se não houver nenhuma resposta final à requisição original em um prazo de 64*T1 segundos (T1 é

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

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.