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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Como a 2xx é retransmitida fim-a-fim, pode haver saltos entre o UAC e o UAS que são UDP. Para garantir a entrega confiável através desses saltos, a resposta é retransmitida periodicamente mesmo que o transporte no UAS seja confiável.

Se o servidor retransmite a resposta 2xx durante 64*T1 segundos sem receber um ACK, o diálogo é confirmado, mas a sessão DEVE ser encerrada. Isso é conseguido com um BYE, como descrito na Seção 15.


14 Modificando uma Sessão Existente

Uma requisição INVITE sucesso (ver Seção 13) estabelece tanto um diálogo entre os dois agentes-usuários quanto uma sessão usando o modelo oferta-aceite. A Seção 12 explica como modificar um diálogo existente usando uma requisição para atualizar destino (por exemplo, mudando o URI do destino remoto do diálogo). Essa seção descreve como modificar a sessão real. Essa modificação pode envolver alterações de endereços ou portas, adicionando um fluxo de mídia, excluir um fluxo de mídia, e assim por diante. Isso é feito enviando uma nova requisição INVITE dentro do mesmo diálogo que estabeleceu a sessão. Uma requisição INVITE enviada dentro de um diálogo existente é conhecido como um re-INVITE.

Observe que um único re-INVITE pode modificar o diálogo e os parâmetros da sessão ao mesmo tempo.

Tanto o chamador como o chamado podem modificar uma sessão existente.

O comportamento de um UA na detecção de falha de mídia é uma questão de política local. No entanto, a geração automática de re-INVITE ou de BYE NÃO é RECOMENDADA para evitar inundação da rede com tráfego quando houver congestionamento. Em qualquer caso, se essas mensagens são enviadas automaticamente, elas DEVEM ser enviadas após algum intervalo aleatório.

Note que o parágrafo acima se refere a BYE's e re-INVITE's gerados automaticamente. Se o usuário desliga o telefone quando de falha de mídia, o UA enviaria uma requisição BYE como usual.


14.1 Comportamento do UAC

O mesmo modelo oferta-aceite que se aplica às descrições de sessão em INVITE's (Seção 13.2.1) aplica-se a re-INVITE's. Como resultado, um UAC que deseja adicionar um fluxo de mídia, por exemplo, vai criar uma nova oferta que contém esse fluxo de mídia, e envia isso em uma requisição INVITE ao seu par. É importante notar que a descrição completa da sessão, e não apenas a mudança, é enviada. Isto suporta o processamento de sessão sem estado em vários elementos, e suporta capacidades de failover e de recuperação. Naturalmente, um UAC PODE 




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

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.