RFC 3261 Português Página 89

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Se a nova descrição de sessão não for aceitável, o UAS pode rejeitá-la retornando uma resposta 488 (Not Acceptable Here) ao re-INVITE. Essa resposta DEVE incluir um campo-cabeçalho Warning.

Se um UAS gerar uma resposta 2xx e nunca receber um ACK, ele DEVE gerar um BYE para terminar o diálogo.

Um UAS PODE escolher não gerar respostas 180 (Ringing) a um re-INVITE porque UAC's tipicamente não apresenta essa informação ao usuário. Pela mesma razão, UAS's PODEM escolher não usar um campo-cabeçalho Alert-Info ou um corpo com "alert" do Content-Disposition em respostas a um re-INVITE.

Um UAS fornecendo uma oferta em uma resposta 2xx (porque o INVITE não tinha um oferta) DEVE construir a oferta como se o UAS estivesse fazendo uma novíssima chamada, sujeita às restrições de envio de uma oferta que atualiza uma sessão existente, como descrito em [13] no caso do SDP. Especificamente, isso significa que ele DEVE incluir tanto quanto formatos de mídia e tipos de mídia que o UA deseja suportar. O UAS PRECISA assegurar que a descrição de sessão sobreponha sua descrição de sessão anterior em formatos de mídia, transportes, ou outros parâmetros que exigem suporte do peer. Isso é para evitar a necessidade do peer rejeitar a descrição de sessão. Se, contudo, for inaceitável ao UAC, o UAC DEVE gerar um aceite com uma descrição de sessão válida, e então enviar um BYE para terminar a sessão.

15 Terminando uma Sessão

Essa seção descreve os procedimentos para encerrar uma sessão estabelecida pelo SIP. O estado da sessão e o estado do diálogo estão intimamente relacionados. Quando uma sessão é iniciada com um INVITE, cada resposta 1xx ou 2xx de um UAS distinto cria um diálogo, e se essa resposta completa o intercâmbio oferta/aceite, ela cria também uma sessão. Como resultado, cada sessão está "associada" a um único diálogo – aquele que resultou na sua criação. Se um INVITE inicial gera uma resposta final não-2xx, que termina todas as sessões (se houver) e todos os diálogos (se houver) que foram criados através de respostas à requisição. Em virtude do término da transação, uma resposta final não-2xx também impede que mais sessões sejam criadas como resultado do INVITE. A requisição BYE é usada para terminar uma sessão específica ou uma sessão tentada. Neste caso, a sessão específica é aquela com o par UA do outro lado do diálogo. Quando um BYE for recebido em um diálogo, qualquer sessão associada a esse diálogo DEVE terminar. Um UA NÃO PODE enviar um BYE fora de um diálogo. O UA do chamador PODE enviar um BYE para diálogos tanto confirmados quanto early's, e o UA do chamado PODE enviar um BYE em diálogos confirmados, mas NÃO PODE enviar um BYE em diálogos early's.

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

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.