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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


O núcleo UAC considera a transação INVITE completada 64*T1 segundos após a recepção da primeira resposta 2xx. Nesse ponto todos os diálogos early's que não transitaram para diálogos estabelecidos são finalizados. Uma vez que a transação INVITE seja considerada completada pelo núcleo UAC, não mais novas respostas 2xx são experadas chegar.

Se, após confirmar alguma resposta 2xx a um INVITE, o UAC não quiser continuar com esse diálogo, então o UAC PRECISA terminar o diálogo enviando uma requisição BYE como descrito na Seção 15.


13.3 Processamento do UAS

13.3.1 Processamento do INVITE

O núcleo UAS receberá requisições INVITE da camada de transação. Ele primeiro executa os procedimentos de processamento de requisição da Seção 8.2, que são aplicados tanto para requisições dentro quanto fora de um diálogo.

Assumindo que esses estados de processamento são completados sem gerar uma resposta, o núcleo UAS executa os passos adicionais de processamento:

1. Se a requisição for um INVITE que contém um campo-cabeçalho Expires, o núcleo UAS define um timer com o número de segundos indicado no valor do campo-cabeçalho. Quando o timer disparar, o convite é considerado estar expirado. Se o convite expirar antes do UAS ter gerado uma resposta final, uma resposta 487 (Request Terminated) DEVE ser gerada.

2. Se a requisição é uma requisição em meio-ao-diálogo, o processamento independente de método descrito na Seção 12.2.2 é primeiro aplicado. Ela pode também modificar a sessão; a Seção 14 fornece detalhes.

3. Se a requisição tem uma tag no campo-cabeçalho To mas o identificador de diálogo não bate com nenhum dos diálogos existentes, o UAS pode ter quebrado e re-startado, ou pode ter recebido uma requisição para um UAS diferente (possivelmente por falha). A Seção 12.2.2 fornece orientações para conseguir um comportamento robusto em tal situação.

O processamento daqui em diante assume que o INVITE está fora de um diálogo, e, portanto, é para os propósitos de estabelecimento de uma nova sessão.

O INVITE pode conter uma descrição de sessão, nesse caso o UAS está sendo apresentado com um oferta para essa sessão. É possível que o usuário já seja um participante dessa sessão, ainda que o INVITE estiver fora de um diálogo. Isso pode acontecer quando um usuário é convidado para a mesma conferência multicast por múltiplos outros participantes. Se desejado, o UAS PODE usar identificadores dentro da descrição de sessão para detectar essa duplicação. Por exemplo, o SDP 



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

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.