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

Se o comportamento acima não era necessário, subscritores que recebem uma notificação para uma subscrição desconhecida seria preciso enviar um código de status de erro em resposta ao NOTIFY e também envia uma requisição SUBSCRIBE para remover a subscrição. Como esse comportamento tornaria subscritores disponíveis para uso como amplificadores em ataques de negação de serviço, nós elegemos, em vez disso, dar o significado especial a resposta 481: ela é usada para indicar que uma subscrição precisa ser cancelada em qualquer circunstância.

Requisições NOTIFY PRECISAM conter um cabeçalho "Subscription-State" com um valor igual a "active", "pending" ou "terminated". O valor "active" indica que a subscrição foi aceita e foi autorizada (em muitos casos, ver seção 5.2). O valor "pending" indica que a subscrição foi recebida, mas que a informação de política é insuficiente para aceitar ou negar a subscrição nesse momento. O valor "terminated" indica que a subscrição não está ativa.

Se o valor do cabeçalho "Subscription-State" for "active" ou "pending", o notificador DEVE também incluir um parâmetro "expires" no cabeçalho "Subscription-State" para indicar o tempo restante da subscrição. O notificador PODE usar esse mecanismo para encurtar uma subscrição; no entanto, esse mecanismo NÃO PODE ser usado para alongar o tempo de validade de uma subscrição.

Incluir informação de expiração para subscrições ativas e pendentes é útil no caso em que a requisição SUBSCRIBE venha a bifurcar, porque a resposta a um método SUBSCRIBE bifurcado pode não ser recebida pelo subscritor. Note bem que esse valor de "expires" é um parâmetro no cabeçalho "Subscription-State", e NÃO um cabeçalho "Expires".

Se o valor do campo-cabeçalho "Subscription-State" for "terminated", o notificador DEVE também incluir um parâmetro "reason". O notificador PODE também incluir um parâmetro "retry-after", quando for apropriado. Para detalhes sobre o valor e semântica dos parâmetros "reason" e "retry-after"; ver seção 3.2.4.

3.2.3. Comportamento do NOTIFY no Proxy

Proxy's precisam de nenhum comportamento adicional além daquele descrito no SIP [1] para suportar NOTIFY. Se um proxy deseja ver todas as requisições SUBSCRIBE e NOTIFY de dado diálogo, ele PRECISA inserir o campo-cabeçalho record-route no SUBSCRIBE inicial e em quaisquer requisições NOTIFY que estabelecem o diálogo. Tais proxy's DEVEM também usar record-route em todas as outras requisições SUBSCRIBE e NOTIFY.

Roach                           Standards Track                           [Página 15]