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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


convite. Após algum tempo, esses UAS's podem aceitar o convite (significando que a sessão deve ser estabelecida), enviando uma resposta 2xx. Se o convite não for aceito, uma resposta 3xx, 4xx, 5xx ou 6xx é enviada, dependendo da razão da rejeição. Antes de enviar uma resposta final, o UAS também pode enviar respostas provisórias (1xx) para avisar o UAC do progresso em contactar o usuário chamado.

Após receber possivelmente uma ou mais respostas provisórias, o UAC receberá uma ou mais respostas 2xx ou uma resposta final não-2xx. Devido à quantidade de tempo prolongado que pode levar para receber respostas finais ao INVITE, os mecanismos de confiabilidade para transações INVITE diferem daqueles de outras requisições (como OPTIONS). Uma vez que ele recebe uma resposta final, o UAC necessita enviar um ACK para cada resposta final que recebe. O procedimento para envio desse ACK depende do tipo de resposta. Para respostas finais entre 300 e 699, o processamento do ACK é feito na camada de transação e segue aquele conjunto de regras (ver Seção 17). Para respostas 2xx, o ACK é gerado pelo núcleo do UAC.

A resposta 2xx a um INVITE estabelece uma sessão, e ela também cria um diálogo entre o UA que lançou o INVITE e o UA que gerou a resposta 2xx. Portanto, quando múltiplas respostas 2xx são recebidas de diferentes UA's remotos (porque o INVITE bifurcou), cada resposta 2xx estabelece um diálogo diferente. Todos esses diálogos são parte da mesma chamada.

Essa seção fornece detalhes sobre o estabelecimento de uma sessão usando o INVITE. Um UA que suporta INVITE PRECISA também suportar ACK, CANCEL e BYE.


13.2 Processamento do UAC

13.2.1 Criando o INVITE Inicial

Desde o INVITE inicial representa uma requisição fora de um diálogo, sua construção segue os procedimentos da Seção 8.1.1. Processamento adicional é necessário para o caso específico de INVITE.

Um campo-cabeçalho Allow (Seção 20.5) DEVE estar presente no INVITE. Ele indica quais métodos podem ser invocados dentro de um diálogo, quando o UA enviando o INVITE, durante o diálogo. Por exemplo, um UA capaz de receber requisição INFO dentro de um diálogo [34] DEVE incluir um campo-cabeçalho Allow listando o método INFO.

Um campo-cabeçalho Supported (Seção 20.37) DEVE estar presentes no INVITE. Ele enumera todas as extensões compreendidas pelo UAC.





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

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.