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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Uma vez o INVITE tenha sido criado, o UAC segue os procedimentos definidos para enviar requisições fora de um diálogo (Seção 8). Isso resulta na construção de uma transação cliente que em última instância enviará a requisição e entregará respostas ao UAC.


13.2.2 Processando Respostas a INVITE

Uma vez o INVITE seja passado à transação cliente do INVITE, o UAC espera respostas ao INVITE. Se à transação cliente do INVITE retornar um timeout em vez de uma resposta, o TU age como se uma resposta 408 (Request Timeout) tivesse sido recebida, como descrito na Seção 8.1.3.


13.2.2.1 Respostas 1xx

Zero, uma ou múltiplas respostas provisórias podem chegar antes que uma ou mais respostas finais sejam recebidas. Respostas provisórias a uma requisição INVITE pode criar "diálogos early's". Se uma resposta provisória tiver uma tag no campo To, e se o dialog ID da resposta não bate com um diálogo existente, uma tag é construída usando os procedimentos definidos na Seção 12.1.2.

O diálogo early somente será necessário se o UAC precisar enviar uma requisição a seu par dentro do diálogo antes da transação INVITE inicial se completar. Campos-cabeçalhos presentes em uma resposta provisória são aplicáveis tão logo o diálogo entre no estado early (por exemplo, um campo-cabeçalho Allow em uma resposta provisória que contém os métodos que podem ser usados no diálogo enquanto esse entra no estado early).


13.2.2.2 Respostas 3xx

Uma resposta 3xx pode conter um ou mais valores do campo-cabeçalho Contact fornecendo novos endereços onde a parte chamada pode ser alcançável. Dependendo do código status da resposta 3xx (ver Seção 21.3), o UAC PODE escolher tentar esses novos endereços.


13.2.2.3 Respostas 4xx, 5xx e 6xx

Uma resposta final não-2xx simples pode ser recebida ao INVITE. Respostas 4xx, 5xx e 6xx pode conter um valor do campo-cabeçalho Contact indicando o local onde informação adicional a cerca do erro pode ser encontrada. Respostas finais subsequentes (às quais chegariam somente sob condições de erro) PRECISA ser ignorado.

Todos diálogos early's são considerados terminados quando da recepção da resposta final não-2xx.




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

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.