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

Note que subscritores e notificadores podem optar por usar criptografia S/MIME em requisições SUBSCRIBE e NOTIFY; conseqüentemente, proxy's não podem depender de ser capazes de acessar qualquer informação que não seja explicitamente exigida para ser legível ao proxy SIP [1].

3.2.4. Comportamento do NOTIFY no Subscritor

Ao receber uma requisição NOTIFY, o subscritor deverá verificar se ela confere, pelo menos, com uma de suas subscrições pendentes; se não, ele PRECISA retornar uma resposta "481 Subscription does not exist" a menos que outra resposta de classe 400 ou 500 seja mais apropriada. As regras para bater requisições NOTIFY contra subscrições que criam um novo diálogo são descritas na seção 3.3.4. Notificações para subscrições que foram criadas dentro de um diálogo existente conferem se elas estão no mesmo diálogo e os cabeçalhos "Event" conferirem (conforme descrito na seção 7.2.1).

Se, por alguma razão, o pacote-evento designado no cabeçalho "Event" da requisição NOTIFY não for suportado, o subscritor responderá com uma resposta "489 Bad Event".

Para evitar falsificação de eventos, requisições NOTIFY DEVEM ser autenticadas, usando qualquer mecanismo de autenticação definido no SIP.

Requisições NOTIFY PRECISAM conter campos-cabeçalhos "Subscription-State" que indicam o status da subscrição.

Se o valor do campo-cabeçalho "Subscription-State" for igual a "active", isso significa que a subscrição foi aceita e (em geral) foi autorizada. Se o campo-cabeçalho contiver também um parâmetro "expires", a subscrição DEVE tomá-lo como a duração da subscrição autorizada e ajustar convenientemente. Os parâmetros "retry-after" e "reason" não têm semântica para "active".

Se o valor de "Subscription-State" for igual a "pending", a subscrição foi recebida pelo notificador, mas não há informação suficiente da política para conceder ou negar a subscrição ainda. Se o cabeçalho contiver também um parâmetro "expires", o subscritor DEVE tomá-lo como a duração da subscrição autorizada e ajustar convenientemente. Nenhuma ação adicional é necessária por parte do subscritor. Os parâmetros "retry-after" e "reason" não têm semântica para "pending".

Se o valor "Subscription-State" for igual a "terminated", o subscritor deve considerar a subscrição encerrada. O parâmetro "expires" não tem semântica para "terminated". Se um código-razão estiver presente, o cliente deve se comportar conforme descrito abaixo. Se nenhum código-razão ou se um código-razão desconhecido estiver presente, o cliente PODE tentar

Roach                           Standards Track                           [Página 16]