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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


No final da chamada, Bob desconecta (desliga) primeiro e gera uma mensagem BYE. Esse BYE é roteado diretamente para o softfone de Alice, novamente ignorando os proxy's. Alice confirma o recebimento do BYE com uma resposta 200 (OK), que termina a sessão e a transação BYE. Nenhum ACK é enviado - um ACK é somente enviado em resposta a uma requisição INVITE. As razões para esse tratamento especial ao INVITE será discutido mais adiante, mas se relaciona com os mecanismos de confiabilidade do SIP, o espaço de tempo que pode levar para um telefone chamando ser atendido e bifurcar. Por esta razão, tratamento de requisições, em SIP é freqüentemente classificada como INVITE ou não-INVITE, referindo-se a todos os outros métodos depois do INVITE. Todos os detalhes sobre o término de sessão estão na Seção 15.

Seção 24.2 descreve as mensagens mostradas na Figura 1 em detalhes.

Em alguns casos, pode ser útil aos proxy's está no caminho da sinalização SIP para ver todas as mensagens entre os pontas remotas durante a sessão. Por exemplo, se o servidor proxy biloxi.com desejasse permanecer no caminho da troca de mensagens SIP além do INVITE inicial, adicionaria ao INVITE um campo-cabeçalho de roteamento obrigatório conhecido como Record-Route que conteria uma URI resolvendo o hostname ou endereço IP do proxy. Essa informação seria recebida tanto no telefone SIP de Bob quanto (devido ao campo-cabeçalho Record-Route sendo passados de volta na resposta 200 (OK)) no softphone de Alice e armazenado durante o diálogo. O servidor proxy biloxi.com então receber e proxy-eia o ACK, BYE e 200 (OK) ao BYE. Cada proxy pode decidir de forma independente receber mensagens subseqüentes, e as mensagens atravessarão todos os proxy's que optar por recebê-las. Esse recurso é freqüentemente usado por proxy's que estão fornecendo recursos em meio a chamada.

O pedido de registro é uma outra operação comum no SIP. O pedido de registro é uma forma que o servidor biloxi.com pode aprender a localização atual de Bob. Na inicialização, e em intervalos periódicos, o telefone SIP de Bob envia mensagens REGISTER a um servidor no domínio biloxi.com conhecido como registrador SIP. As mensagens REGISTER associa a URI do SIP ou do SIPS de Bob (SIP: bob@biloxi.com) com a máquina na qual ele está logado (conduzida como um URI do SIP ou do SIPS no campo-cabeçalho Contact). O registrador grava essa associação, também chamado de ligação, a uma base de dados, chamado de serviço de localização, onde pode ser usado pelo proxy no domínio biloxi.com. Muitas vezes, um servidor registrador de um domínio está na mesma máquina que o proxy para esse domínio. Esse é um conceito importante onde a distinção entre os tipos de servidores SIP é lógica, e não física.

Bob não está limitado a se registrar de um único dispositivo. Por exemplo, tanto o seu telefone SIP em casa quanto um no escritório pode enviar pedidos de registro. Essa informação é armazenada conjuntamente no serviço de localização 






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

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.