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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


contendo um ou mais URI's de novos endereços a ser tentados. A resposta é passada à transação servidor do INVITE, que vai tratar as suas retransmissões.


13.3.1.3 O INVITE é Rejeitado

Um cenário comum ocorre quando a parte chamada não está atualmente disposta ou capaz de atender chamadas adicionais nesse sistema final. Uma 486 (Busy Here) DEVE ser retornada em tal cenário. Se o UAS souber que nenhum outro sistema fim será capaz de aceitar essa chamada, uma resposta 600 (Busy Everywhere) DEVE ser enviado no lugar. No entanto, é improvável que um UAS seja capaz de saber isso no geral, e, portanto, essa resposta não será usada usualmente. A resposta é passada à transação servidor do INVITE, que vai tratar as suas retransmissões.

Um UAS rejeitando uma oferta contido em um INVITE DEVE retornar uma resposta 488 (Not Acceptable Here). Essa resposta DEVE incluir um valor no campo-cabeçalho Warning explicando o motivo que a oferta foi rejeitada.


13.3.1.4 O INVITE é Aceito

O núcleo UAS gera uma resposta 2xx. Essa resposta estabelece um diálogo e, portanto, segue os procedimentos da Seção 12.1.1 além daqueles da Seção 8.2.6.

Uma resposta 2xx a um INVITE DEVE conter o campo-cabeçalho Allow e o campo-cabeçalho Supported, e PODE conter o campo-cabeçalho Accept. Incluindo esses campos-cabeçalhos permite ao UAC determinar os recursos e as extensões suportadas pelo UAS durante a chamada, sem sondagem.

Se a requisição INVITE tinha um oferta, e o UAS ainda não enviou um aceite, a 2xx PRECISA conter um aceite. Se o INVITE não tinha um oferta, a 2xx PRECISA conter um oferta se o UAS ainda não enviou um oferta.

Uma vez a resposta seja construída, ela é passada à transação servidor do INVITE. Note, contudo, que a transação servidor do INVITE será destruída tão logo ela receba essa resposta final e a passe ao transporte. Portanto, é necessário passar periodicamente a resposta diretamente ao transporte até que chegue o ACK. A resposta 2xx é passada ao transporte com um intervalo que começa em T1 segundos e dobra a cada retransmissão até que atinja T2 segundos (T1 e T2 são definidos na Seção 17). Re-transmissões de resposta cessam quando uma requisição ACK a resposta for recebida. Isso é independente de qual seja os protocolos de transporte que são usados para enviar a resposta.





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

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.