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

4.4.8. Processamento de requisições NOTIFY no Subscritor

Essa seção de um pacote-evento descreve o processo a ser seguido pelo subscritor ao receber uma requisição NOTIFY, incluindo qualquer lógica exigida para formar um estado coerente do recurso (se for aplicável).

4.4.9. Tratamento de requisições bifurcadas

Cada pacote-evento PRECISA especificar se requisições SUBSCRIBE bifurcadas são permitidas instalar múltiplas subscrições.

Se tal comportamento não for permitido, a primeira mensagem potencial para estabelecimento de diálogo vai criar um diálogo. Todas as mensagens NOTIFY subseqüentes que correspondem à mensagem SUBSCRIBE (isto é, que bate com "To", "From", com o parâmetro "tag" do cabeçalho "From", com "Call-ID", "CSeq", "Event", e com o parâmetro "id" do cabeçalho "Event") mas que não bate com o diálogo seria rejeitada com uma resposta 481. Note que a resposta de classe 200 ao SUBSCRIBE pode chegar após um NOTIFY correspondente ser recebido; tais respostas podem não ser correlacionadas ao mesmo diálogo estabelecido pelo NOTIFY. Exceto quando exigido para completar a transação SUBSCRIBE, tais respostas de classe 200 não-correspondentes são ignoradas.

Se a instalação de várias subscrições por meio de um único SUBSCRIBE bifurcado for permitida, o subscritor estabelece um novo diálogo para cada notificador que retorna uma resposta de classe 200 para cada NOTIFY. Cada diálogo é então tratado como sua própria entidade, e é renovado independente dos outros diálogos.

No caso de múltiplas subscrições serem permitidas, o pacote-evento PRECISA especificar se a fusão das notificações para formar um único estado é exigida, e como tal fusão deve ser realizada. Note que é possível que alguns pacotes-evento possam ser definidos de tal forma que cada diálogo seja vinculado a um estado mutuamente exclusivo que não seja afetado pelos outros diálogos; isso PRECISA ser claramente indicado se for o caso.

4.4.10. Taxa de notificações

Cada pacote-evento é esperado definir uma exigência (ao impor o DEVE ou o PRECISA) que define um máximo absoluto sobre a taxa nas quais notificações é permitida a serem geradas por um único notificador.

Cada pacote PODE definir um mecanismo estrangulador adicional que permite aos subscritores limitar mais a taxa de notificação.

Roach                           Standards Track                           [Página 26]