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

RFC 3265                Notificação de Evento Específico-SIP               Junho 2002

3.2.2. Comportamento do NOTIFY no Notificador

Quando uma requisição SUBSCRIBE é respondida com uma resposta de classe 200, o notificador PRECISA imediatamente construir e enviar uma requisição NOTIFY ao subscritor. Quando uma alteração no estado subscrito ocorrer, o notificador DEVE imediatamente construir e enviar uma requisição NOTIFY, mediante autorização, política local e considerações de otimização.

Uma requisição NOTIFY é considerada falha se a resposta expirar, ou um código de resposta de classe não-200 for recebido que não tenha cabeçalho "Retry-After" e nem ação implícita adicional que possa levar a repetir a requisição (por exemplo, "401 Authorization Required").

Se a requisição NOTIFY falhar (como definido acima) devido a uma condição timeout, e a subscrição foi instalada usando um mecanismo soft-state (como o SUBSCRIBE), o notificador DEVE remover a subscrição.

Esse comportamento impede a transmissão desnecessária de informação de estado para subscritores que tenham deixado de funcionar ou desapareceram da rede. Como tais transmissões serão enviadas várias vezes, conforme o algoritmo de retransmissão definidos no SIP [1] (em vez da típica transmissão única para clientes em funcionamento), continuando a servi-los quando nenhum cliente estiver disponível para reconhecê-los poderia colocar tensão indevida na rede. Após o reinício do cliente ou restabelecimento de uma conexão de rede, espera-se que os clientes irão enviar mensagens SUBSCRIBE para renovar informações de estado potencialmente obsoletas; tais mensagens irão re-instalar subscrições em todos os nó's relevantes.

Se a requisição NOTIFY falhar (como definido acima) devido a uma resposta de erro, e a subscrição foi instalada usando um mecanismo soft-state, o notificador PRECISA remover a subscrição correspondente.

Uma resposta de erro a notificação, em geral, indicaria que algo deu errado com o subscritor ou com algum proxy no caminho do subscritor. Se o subscritor estiver em erro, faz mais sentido permitir ao subscritor corrigir a situação (subscrevendo de novo) já que a condição de erro foi tratada. Se um proxy estiver em erro, as renovações SUBSCRIBE periódicas irão re-instalar o estado de subscrição uma vez que o problema de rede foi resolvido.

Se uma requisição NOTIFY receber uma resposta 481, o notificador PRECISA remover a subscrição correspondente, mesmo se tal subscrição foi instalada por meios não-SUBSCRIBE (tal como uma interface administrativa).

Roach                           Standards Track                           [Página 14]