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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Entretanto, o UA do chamado NÃO PODE enviar um BYE em um diálogo confirmado até que ele tenha recebido um ACK para sua resposta 2xx ou até que a transação servidor expire. Se nenhuma extensão SIP tem definido outros estados da camada aplicação associado ao diálogo, o BYE também termina o diálogo.

O impacto de uma resposta final não-2xx ao INVITE em diálogos e sessões torna o uso de CANCEL atraente. O CANCEL tenta forçar uma resposta não-2xx ao INVITE (em particular, uma 487). Portanto, se um UAC pretende desistir de sua tentativa de chamada inteiramente, ele pode enviar um CANCEL. Se o INVITE resultar em resposta(s) fina(is) 2xx ao INVITE, isso significa que um UAS aceitou o convite enquanto o CANCEL estava em progresso. O UAC PODE continuar com as sessões estabelecidas com quaisquer respostas 2xx, ou PODE terminá-los com BYE.

A noção de "desligar" não está bem definida dentro do SIP. Ela é específica para uma determinada interface de usuário particular, embora comum. Tipicamente, quando o usuário desliga o telefone, ele indica um desejo de encerrar a tentativa de estabelecer uma sessão e encerrar quaisquer sessões já criadas. Para o UA do chamador, isso implicaria uma requisição CANCEL se o INVITE inicial não gerou uma resposta final, e um BYE para todos os diálogos confirmados após uma resposta final. Para o UA da parte chamada, isso tipicamente implicaria um BYE; presumivelmente, quando o usuário tirou o monofone do gancho, uma resposta 2xx foi gerada, e assim botar o monofone no gancho resultaria em um BYE após o ACK ser recebido. Isso não significa que um usuário não possa desligar antes da recepção do ACK, isso significa apenas que o software no telefone do usuário precisa manter o estado por um curto período de tempo a fim de se restabelecer apropriadamente. Se a UI particular permite ao usuário rejeitar uma chamada antes que seja atendida, uma 403 (Forbidden) é uma boa maneira de expressar isso. De acordo com as regras acima, um BYE não pode ser enviado.


15.1 Terminando uma Sessão com uma Requisição BYE

15.1.1 Comportamento do UAC

Uma requisição BYE é construída como qualquer outra requisição dentro de um diálogo, como descrito na Seção 12.

Uma vez o BYE seja construído, o núcleo UAC cria uma nova transação cliente não-INVITE, e passa-lhe a requisição BYE. O UAC PRECISA considerar a sessão terminada (e, portanto, parar de enviar ou escutar mídia), tão logo a requisição BYE seja passado a transação cliente. Se a resposta ao BYE for uma 481 (Call/Transaction Does Not Exist) ou uma 408 (Request Timeout) ou nenhuma 






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

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.