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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


enviar um re-INVITE sem nenhuma descrição de sessão, nesse caso a primeira resposta de não-falha confiável ao re-INVITE conterá a oferta (nessa especificação, essa é uma resposta 2xx).

Se o formato de descrição de sessão tiver a capacidade para números de versão, o proponente DEVE indicar que a versão de descrição da sessão foi alterado.

Os campos-cabeçalhos To, From, Call-ID, CSeq e Request-URI de um re-INVITE são definidos seguindo as mesmas regras que das requisições regulares dentro de um diálogo existente, como descrito na Seção 12.

Um UAC PODE escolher não adicionar um campo-cabeçalho Alert-Info ou um corpo com "alert" no Content-Disposition para re-INVITE's porque UAS's normalmente não alertam o usuário sobre a recepção de um re-INVITE.

Diferente de um INVITE, que pode fork-ar, um re-INVITE nunca forkará e, portanto, sempre vai gerar somente uma única resposta final. A razão para que um re-INVITE nunca forkará é que o Request-URI identifica o alvo como a instância UA com qual ele estabeleceu o diálogo, ao invés de identificar um endereço-de-registro do usuário.

Note que um UAC NÃO PODE iniciar uma nova transação INVITE dentro de um diálogo enquanto outra transação INVITE está em progresso em qualquer direção.

1. Se houver uma transação cliente do INVITE em andamento, o TU PRECISA esperar até que a transação atinja o estado completada ou terminada antes de iniciar o novo INVITE.

2. Se houver uma transação servidor do INVITE em curso, o TU PRECISA esperar até que a transação atinja o estado confirmada ou terminada antes de iniciar o novo INVITE.

Entretanto, um UA PODE iniciar uma transação regular enquanto uma transação INVITE está em progresso. Um UA também PODE iniciar uma transação INVITE enquanto uma transação regular está em andamento.

Se um UA receber uma resposta final não-2xx a um re-INVITE, os parâmetros da sessão PRECISAM permanecer inalterados, como se nenhum re-INVITE tinha sido lançado. Note que, como dito na Seção 12.2.1.2, se a resposta final não-2xx for uma 481 (Call/Transaction Does Not Exist), ou uma 408 (Request Timeout), ou nenhuma resposta for recebida ao re-INVITE (ou seja, um timeout é retornado pela transação cliente do INVITE), o UAC encerrará o diálogo.





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

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.