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

subscrever de novo a qualquer momento (a menos que um parâmetro "retry-after" esteja presente, caso em que o cliente NÃO DEVE tentar a subscrição novamente até após o número de segundos especificado pelo parâmetro "retry-after"). Os códigos-razão definidos são:

deactivated: A subscrição foi encerrada, mas o subscritor DEVE tentar de novo imediatamente com uma nova subscrição. Um uso primário de tal código de status é permitir migração de subscrições entre nó's. O parâmetro "retry-after" não tem semântica para "deactivated".

probation: A subscrição foi encerrada, mas o cliente DEVE tentar de novo em algum tempo posterior. Se um parâmetro "retry-after" estiver também presente, o cliente DEVE esperar pelo menos o numero de segundos especificado por esse parâmetro antes de tentar subscrever de novo.

rejected: A subscrição foi encerrada devido à mudança na política de autorização. Clientes NÃO DEVEM tentar subscrever de novo. O parâmetro "retry-after" não tem semântica para "rejected".

timeout: A subscrição foi encerrada porque ela não foi renovada antes de ela ter expirado. Clientes PODEM subscrever de novo imediatamente. O parâmetro "retry-after" não tem semântica para "timeout".

giveup: A subscrição foi encerrada porque o notificador não pôde obter autorização a tempo. Se um parâmetro "retry-after" estiver também presente, o cliente DEVE esperar pelo menos o número de segundos especificado por esse parâmetro antes de tentar subscrever de novo; do contrário, o cliente PODE tentar de novo imediatamente, mas provavelmente vai voltar ao estado pendente.

noresource: A subscrição foi encerrada porque o estado do recurso que sendo monitorado não mais existe. Clientes NÃO DEVEM tentar subscrever de novo. O parâmetro "retry-after" não tem semântica para "noresource".

Uma vez que a notificação seja considerada aceita pelo subscritor, o subscritor DEVE retornar uma resposta 200. Em geral, não é esperado que respostas a NOTIFY vão conter corpos; contudo, elas PODEM conter, se a requisição NOTIFY continha um campo-cabeçalho "Accept".

Outras respostas definidas no SIP [1] podem também ser retornada, quando for apropriado. Em nenhum caso uma transação NOTIFY deve se estender por mais tempo que o necessário para o processamento automático. Em particular, os subscritores NÃO PODEM esperar por uma resposta de usuário antes de retornar uma resposta final a uma requisição NOTIFY.

Roach                           Standards Track                           [Página 17]