RFC 3261 Português Página 88

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Se um UAC receber uma resposta 491 a um re-INVITE, ele DEVE iniciar um timer com um valor T escolhido como:

1. Se o UAC é o dono do Call-ID do diálogo ID (significando que ele gerou o valor), T tem um valor aleatoriamente escolhido entre 2.1 e 4 segundos em unidades de 10 ms.

2. Se o UAC não for o dono do Call-ID do diálogo ID, T tem um valor aleatoriamente escolhido entre 0 e 2 segundos em unidades de 10 ms.

Quando o timer disparar, o UAC DEVE tentar o re-INVITE uma vez mais, se ele ainda desejar que essa modificação de sessão ocorra. Por exemplo, se a chamada já foi desligada com um BYE, o re-INVITE não ocorreria.

As regras para transmitir um re-INVITE e gerar um ACK a uma resposta 2xx de um re-INVITE são as mesmas que para o INVITE inicial (Seção 13.2.1).

14.2 Comportamento do UAS

A Seção 13.3.1 descreve o procedimento para distinguir re-INVITEs entrantes de INVITE's entrantes iniciais e tratar um re-INVITE em um diálogo existente.

Um UAS que recebe um segundo INVITE antes dele enviar a resposta final a um primeiro INVITE com um número de sequência CSeq inferior no mesmo diálogo PRECISA retornar uma resposta 500 (Server Internal Error) ao segundo INVITE e PRECISA incluir um campo-cabeçalho Retry-After com um valor randomicamente escolhido entre 0 e 10 segundos.

Um UAS que recebe um INVITE em um diálogo enquanto um INVITE que ele enviou nesse diálogo está em progresso PRECISA retornar uma resposta 491 (Request Pending) ao INVITE recebido.

Se um UA recebe um re-INVITE para um diálogo existente, ele PRECISA verificar quaisquer identificadores de versão na descrição de sessão ou, se não houver nenhum identificador de versão, verificar o conteúdo da descrição de sessão pra ver se foi alterado. Se a descrição de sessão foi alterada, o UAS PRECISA ajustar os parâmetros da sessão de forma conveniente, possivelmente após pedir ao usuário a confirmação.

Versionamento da descrição de sessão pode ser usado para acomodar as capacidades of new arrivals a uma conferência, adicionar ou deletar mídia, ou alterar uma conferência de unicast para multicast.

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

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.