RFC 3265 Portugues Pagina 1

Grupo de Trabalho em Rede                                                 A. B. Roach

Request for Comments: 3265                                                dynamicsoft

Atualiza a: 2543                                                           Junho 2002

Categoria: Standards Track

Notificação de Evento

Específico - Session Initiation Protocol (SIP)

Status desse Memorando

Esse documento especifica um protocolo tramitando na padronização pela comunidade Internet, e solicita discussões e sugestões para melhorias. Favor consultar a edição corrente do "Internet Official Protocol Standards" (STD 1) para ver o estado da padronização e o status desse protocolo. A distribuição desse memorando é ilimitada.

Aviso sobre Direitos Autorais

Direitos Autorais (C) Da Internet Society (2002). Todos os Direitos Reservados.

Resumo

Esse documento descreve uma extensão ao Session Initiation Protocol (SIP). O propósito dessa extensão é fornecer uma infra-estrutura extensível pela qual nó's SIP podem requisitar notificação de nó's remotos para indicar que certos eventos aconteceram.

Usos concretos do mecanismo descritos nesse documento podem ser padronizados no futuro.

Note que os mecanismos de notificação de evento definidos aqui NÃO são tencionados ser uma infra-estrutura de propósito geral para todas as classes de subscrição e notificação de evento.

Tabela de Conteúdo

1.       Introdução............................................................  3

1.1.     Visão geral da Operação...............................................  4

1.2.     Convenções da Documentação............................................  4

2.       Definições............................................................  5

3.       Comportamento do Nó...................................................  6

3.1.     Descrição do Comportamento no SUBSCRIBE...............................  6

3.1.1.   Duração da Subscrição.................................................  6

3.1.2.   Identificação de Eventos Subscritos e Classes de Evento...............  6

3.1.3.   Valores Adicionais de Cabeçalho SUBSCRIBE.............................  7

3.1.4.   Comportamento do SUBSCRIBE no Subscritor..............................  7

3.1.5.   Comportamento do SUBSCRIBE no Proxy...................................  9

3.1.6.   Comportamento do SUBSCRIBE no Notificador............................. 10

Roach                            Standards Track                           [Página 1]

Página original:
http://tools.ietf.org/search/rfc3265#page-1

Página 2

RFC 3265 Portugues Pagina 2

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

3.2.     Descrição do Comportamento do NOTIFY.................................. 13

3.2.1.   Identificação de Eventos Reportados, Classes de Evento e

         Estado Corrente....................................................... 13

3.2.2.   Comportamento do NOTIFY no Notificador................................ 14

3.2.3.   Comportamento do NOTIFY no Proxy...................................... 15

3.2.4.   Comportamento do NOTIFY no Subscritor................................. 16

3.3.     Geral................................................................. 18

3.3.1.   Detectando suporte para SUBSCRIBE e NOTIFY............................ 18

3.3.2.   Requisições CANCEL ................................................... 18

3.3.3.   Bifurcando............................................................ 18

3.3.4.   Criação e término de Diálogo.......................................... 18

3.3.5.   Agentes de Estado e Migração de Notificador........................... 19

3.3.6.   Sondando Estado de Recurso............................................ 20

3.3.7.   Uso de cabeçalho Allow-Events......................................... 21

3.3.8.   Compatibilidade com o PINT............................................ 21

4.       Pacotes-Evento........................................................ 21

4.1.     Oportunidade de Uso................................................... 21

4.2.     Modelo de Pacotes-Evento.............................................. 22

4.3.     Quantidade de Estado a ser Transportado............................... 22

4.3.1.   Informação de Completa de Estado...................................... 23

4.3.2.   State Deltas.......................................................... 23

4.4.     Responsabilidades do Pacote-Evento.................................... 24

4.4.1.   Nome do Pacote-Evento................................................. 24

4.4.2.   Parâmetros do Pacote-Evento .......................................... 24

4.4.3.   Corpos de SUBSCRIBE................................................... 24

4.4.4.   Duração da Subscrição................................................. 25

4.4.5.   Corpos de NOTIFY...................................................... 25

4.4.6.   Processamento de requisições SUBSCRIBE no Notificador................. 25

4.4.7.   Geração de requisições NOTIFY no Notificador.......................... 25

4.4.8.   Processamento de requisições NOTIFY no Subscritor..................... 26

4.4.9.   Handling of forked requests........................................... 26

4.4.10.  Taxa de notificações.................................................. 26

4.4.11.  Agentes de Estado..................................................... 27

4.4.12.  Exemplos.............................................................. 27

4.4.13.  Uso de URI's ao Buscar Estado......................................... 27

5.       Considerações de Segurança............................................ 28

5.1.     Controle de Acesso.................................................... 28

5.2.     Mecanismo de Privacidade no Notificador............................... 28

5.3.     Ataques de Negação-de-Serviço......................................... 28

5.4.     Ataques de Repetição.................................................. 29

5.5.     Ataques Man-in-the-middle............................................. 29

5.6.     Confidencialidade..................................................... 29

6.       Considerações sobre o IANA............................................ 30

6.1.     Informação de Registro................................................ 30

6.2.     Modelo de Registro.................................................... 31

6.3.     Nomes de Campo-Cabeçalho.............................................. 31

6.4.     Códigos de Resposta................................................... 32

7.       Sintaxe............................................................... 32

Roach                            Standards Track                           [Página 2]

Página original:
http://tools.ietf.org/search/rfc3265#page-2

Página 1

Tabela de Conteúdo

Página 3

RFC 3265 Portugues Pagina 3

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

7.1.     Novos Métodos......................................................... 32

7.1.1.   Método SUBSCRIBE...................................................... 34

7.1.2.   Método NOTIFY......................................................... 34

7.2.     Novos Cabeçalhos...................................................... 34

7.2.1.   Cabeçalho "Event"..................................................... 34

7.2.2.   Cabeçalho "Allow-Events".............................................. 35

7.2.3.   Cabeçalho "Subscription-State"........................................ 35

7.3.     Novos Códigos de Resposta............................................. 35

7.3.1.   Código Resposta "202 Accepted"........................................ 35

7.3.2.   Código Resposta "489 Bad Event"....................................... 35

7.4.     Definições Augmented BNF.............................................. 35

8.       Referências Normativas................................................ 36

9.       Referências Informativas.............................................. 37

10.      Agradecimentos........................................................ 37

11.      Aviso sobre Direitos de Propriedade Intelectual....................... 37

12.      Endereço do Autor..................................................... 37

13.      Declaração Completa de Direitos Autorais.............................. 38

1. Introdução

A capacidade para requisitar notificação assíncrona de eventos se mostra útil em vários tipos de serviços do SIP aos quais a cooperação entre nó's remotos é necessário. Exemplos de tais serviços incluem serviços de rechamada automática (baseado em eventos de estado do terminal), listas de amigos (baseado em eventos de presença do usuário), indicações de mensagem em espera (baseado em eventos da mudança de estado do mailbox), e status da PSTN e da Internet Internetworking (PINT) [2] (baseado em eventos de estado da chamada).

Os métodos descritos nesse documento fornecem uma infra-estrutura pela qual a notificação desses eventos pode ser ordenada.

Os mecanismos de notificação de eventos aqui definidos NÃO se destinam a ser uma infra-estrutura de uso geral para todas as classes de subscrição e notificação de eventos. Encontrar requerimentos para o conjunto amplo de problemas de subscrição e de notificação é complexo demais para um único protocolo. Nosso objetivo é fornecer ao SIP uma infra-estrutura específica para notificação de eventos que não seja tão complexa a ponto de ser inútil para recursos simples, mas que ainda seja flexível o suficiente para fornecer serviços poderosos. Note, no entanto, que pacotes-evento baseados nessa infra-estrutura pode definir arbitrariamente regras elaboradas que regem a subscrição e a notificação para os eventos ou classes de eventos que descrevem.

Esse documento não descreve uma extensão que pode ser usada diretamente; ele precisa ser estendido por outros documentos (aqui referidos como "pacotes-evento"). Na terminologia de projeto orientado a objeto, isso pode

Roach                            Standards Track                           [Página 3]

Página original:
http://tools.ietf.org/search/rfc3265#page-3

Página 2

Tabela de Conteúdo

Página 4

RFC 3265 Portugues Pagina 4

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

ser pensado como uma classe abstrata de base que precisa ser derivado em uma classe instanciável por extensões adicionais. Diretrizes para criar essas extensões são descritas na seção 4.

1.1. Visão geral da Operação

O conceito geral é que entidades na rede podem se subscrever a recursos ou ao estado de chamada para vários recursos ou chamadas na rede, e essas entidades (ou entidades agindo em nome desses recursos) podem enviar notificações quando esses estados mudam.

Um fluxo típico de mensagens seria:

Subscritor          Notificador

|-----SUBSCRIBE---->|     Requisita a subscrição de estado

|<-------200--------|     Confirma a subscrição

|<------NOTIFY----- |     Retorna a informação corrente de estado

|--------200------->|

|<------NOTIFY----- |     Retorna a informação atual de estado

|--------200------->|

Subscrições expiram e precisam ser renovadas por mensagens SUBSCRIBE subseqüentes.

1.2. Convenções da Documentação

Há vários parágrafos ao longo desse documento que fornecem texto motivacional ou de esclarecimento. Tais passagens são não-normativas, e são fornecidos apenas para auxiliar na compreensão do leitor. Essas passagens são definidas fora do restante do texto por ser indentado assim:

Esse é um exemplo de texto explanatório não-normativo. Não faz parte da especificação, e é usado apenas para clarificação.

Números entre colchetes (por exemplo, [1]) denotam uma referência a alguma das entradas nas seções de referência; ver as seções 8 e 9.

Todos os termos em maiúsculos "MUST", "SHOULD", "MAY", "SHOULD NOT", "MUST NOT" e "RECOMMENDED" são usados conforme definido na RFC 2119 [5].

O uso de aspas junto a pontos e vírgulas segue a convenção usada pela American Mathematical Society; embora contrário a tradicional convenção do Inglês Americano, esse uso dá clareza a certas passagens.

Roach                            Standards Track                           [Página 4]

Página original:
http://tools.ietf.org/search/rfc3265#page-4

Página 3

Tabela de Conteúdo

Página 5

RFC 3265 Portugues Pagina 5

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

2. Definições

Event Package: Um pacote-evento é uma especificação adicional que define um conjunto de informações de estado a ser reportado por um notificador a um subscritor. Pacotes-evento também definem sintaxe e semântica adicional baseada na infra-estrutura definida por esse documento exigido para transportar tais informações de estado.

Event Template-Package: Um pacote-modelo de evento é um tipo especial de pacote-evento que define um conjunto de estados que pode ser aplicado a todos os possíveis pacotes-evento, incluindo-se.

Notification: Notificação é o ato de um notificador enviar uma mensagem NOTIFY a um subscritor para informar ao subscritor o estado de um recurso.

Notifier: Um notificador é um agente-usuário que gera requisições NOTIFY com o propósito de notificar subscritores do estado de um recurso. Notificadores tipicamente também aceita requisições SUBSCRIBE para criar subscrições.

State Agent: Um agente de estado é um notificador que publica informação de estado em nome de um recurso; a fim de proceder assim, ele pode precisar reunir tais informações de estado de múltiplas fontes. Agentes de Estado sempre têm informações completas de estado do recurso para as quais eles estão gerando notificações.

Subscriber: Um subscritor é um agente-usuário que recebe requisições NOTIFY de notificadores; essas requisições NOTIFY contêm informações sobre o estado de um recurso sobre o qual o subscritor está interessado. Subscritores tipicamente também geram requisições SUBSCRIBE e as envia aos notificadores para gerar subscrições.

Subscription: Uma subscrição é um conjunto de estado de aplicação associado a um diálogo. Esse estado de aplicação inclui um ponteiro para o diálogo associado, o nome do pacote-evento, e possivelmente o token de identificação. Pacotes-evento vão definir informações adicionais do estado da subscrição. Por definição, subscrições existem tanto em um subscritor quanto em um notificador.

Subscription Migration: Migração de subscrição é o ato de mover uma subscrição de um notificador para outro notificador.

Roach                            Standards Track                           [Página 5]

Página original:
http://tools.ietf.org/search/rfc3265#page-5

Página 4

Tabela de Conteúdo

Página 6

RFC 3265 Portugues Pagina 6

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

3. Comportamento do Nó

3.1. Descrição do Comportamento do SUBSCRIBE

O método SUBSCRIBE é usado para requisitar o estado atual e atualizações de estado de um nó remoto.

3.1.1. Duração da Subscrição

Requisições SUBSCRIBE DEVEM conter um cabeçalho "Expires" (definido no SIP [1]). O valor no campo-cabeçalho Expires indica a duração da subscrição. A fim de manter subscrições efetivas além da duração comunicada no cabeçalho "Expires", subscritores precisam renovar subscrições periodicamente usando uma nova mensagem SUBSCRIBE no mesmo diálogo conforme definido no SIP [1].

Se nenhum cabeçalho "Expires" estiver presente em uma requisição SUBSCRIBE, o padrão implícito é definido pelo pacote-evento sendo usado.

Respostas de classe 200 a requisições SUBSCRIBE também PRECISAM conter um cabeçalho "Expires". O período de tempo na resposta PODE ser mais curto, mas NÃO PODE ser maior do que o especificado na requisição. O período de tempo na resposta é aquele que define a duração da subscrição.

Um parâmetro "expires" no cabeçalho "Contact" não tem semântica para SUBSCRIBE e não é explicitamente equivalente a um cabeçalho "Expires" em uma requisição ou resposta ao SUBSCRIBE.

Uma conseqüência natural desse esquema é que um SUBSCRIBE com um campo-cabeçalho "Expires" igual a 0 constitui uma requisição para cancelar a subscrição a um evento.

Além de ser uma requisição para cancelar a subscrição, uma mensagem SUBSCRIBE com "Expires" igual a 0 também causa uma busca de estado; ver a seção 3.3.6.

Notificadores podem também querer cancelar subscrições a eventos; isso é útil, por exemplo, quando o recurso ao qual uma subscrição se refere não está mais disponível. Mais detalhes sobre esse mecanismo é discutido na seção 3.2.2.

3.1.2. Identificação de Eventos Subscritos e Classes de Evento

Identificação de eventos é fornecida por três partes da informação: Request-URI, Tipo de Evento e (opcionalmente) o corpo da mensagem.

Roach                            Standards Track                           [Página 6]

Página original:
http://tools.ietf.org/search/rfc3265#page-6

Página 5

Tabela de Conteúdo

Página 7

RFC 3265 Portugues Pagina 7

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

O Request-URI de uma requisição SUBSCRIBE, ainda mais importante, contém informações suficientes para rotear a requisição à entidade apropriada de acordo com os procedimentos para roteamento de requisição detalhados no SIP [1]. Ele também contém informações suficientes para identificar o recurso ao qual a notificação de evento é desejada, mas não é informação necessariamente suficiente para identificar exclusivamente a natureza do evento (por exemplo, "sip:adam@dynamicsoft.com" seria um URI adequado para subscrever ao meu estado de presença; esse seria também um URI apropriado para subscrever ao estado de meu mailbox de voz).

Subscritores PRECISAM incluir exatamente aquele cabeçalho "Event" em requisições SUBSCRIBE, que indica a qual evento ou classe de eventos eles estão subscrevendo. O cabeçalho "Event" vai conter um token que indica o tipo de estado para o qual uma subscrição está sendo requisitada. Esse token será registrado no IANA e vai corresponder a um pacote-evento que descreve mais a semântica adicional do evento ou classe de evento. O cabeçalho "Event" PODE também conter um parâmetro "id". Esse parâmetro "id", se presente, contém um token opaco que identifica a subscrição específica dentro de um diálogo. Um parâmetro "id" é somente válido dentro do escopo de um único diálogo.

Se o pacote-evento a qual o token do evento corresponde define o comportamento associado com o corpo de suas requisições SUBSCRIBE, tal semântica se aplica.

Pacotes-evento podem também definir parâmetros no cabeçalho Event; se eles assim definirem, eles precisam definir a semântica para tais parâmetros.

3.1.3. Valores Adicionais de cabeçalho em SUBSCRIBE

Como requisições SUBSCRIBE criam um diálogo como definido no SIP [1], elas PODEM conter um cabeçalho "Accept". Esse campo-cabeçalho, se estiver presente, indica os formatos de corpo permitidos em requisições NOTIFY subseqüentes. Pacotes-evento PRECISAM definir o comportamento para requisições SUBSCRIBE sem cabeçalhos "Accept"; usualmente, isso conotará um tipo de corpo único e padrão.

Valores de cabeçalho não descritos nesse documento devem ser interpretados conforme descritos no SIP [1].

3.1.4. Comportamento do SUBSCRIBE no Subscritor

3.1.4.1. Requisitando uma Subscrição

SUBSCRIBE é um método que cria diálogo, conforme descrito no SIP [1].

Quando um subscritor quer subscrever a um estado particular de um recurso, ele forma uma mensagem SUBSCRIBE. Se o SUBSCRIBE inicial

Roach                            Standards Track                           [Página 7]

Página original:
http://tools.ietf.org/search/rfc3265#page-7

Página 6

Tabela de Conteúdo

Página 8

RFC 3265 Portugues Pagina 8

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

representa uma requisição fora de um diálogo (como tipicamente será), sua construção segue os procedimentos descritos no SIP [1] para UAC que gera requisição fora de um diálogo.

Essa requisição SUBSCRIBE será confirmada com uma resposta final. Respostas de classe 200 indicam que a subscrição foi aceita, e que um NOTIFY será enviado imediatamente. Uma resposta 200 indica que a subscrição foi aceita e que o usuário está autorizado a subscrever ao recurso requisitado. Uma resposta 202 meramente indica que a subscrição foi entendida, e que a autorização pode ou não ter sido dada.

O cabeçalho "Expires" em uma resposta de classe 200 ao SUBSCRIBE indica a duração real ao qual a subscrição permanecerá ativa (a menos que seja renovada).

Respostas finais de classe não-200 indicam que nenhuma subscrição ou diálogo foi criado, e nenhuma mensagem NOTIFY subseqüente será enviada. Todas as respostas de classe não-200 (com a exceção de "489", descrito aqui) têm o mesmo significado e tratamento conforme descrito no SIP [1].

Uma requisição SUBSCRIBE PODE incluir um parâmetro "id" em seu cabeçalho "Event" para permitir diferenciação entre múltiplas subscrições no mesmo diálogo.

3.1.4.2. Renovação de Subscrições

A qualquer momento antes de uma subscrição expirar, o subscritor pode renovar o temporizador em tal subscrição enviando outra requisição SUBSCRIBE no mesmo diálogo que a subscrição existente, e com o mesmo parâmetro "id" do cabeçalho "Event" (se algum estava presente na subscrição inicial). O tratamento para tal requisição é o mesmo da criação inicial de uma subscrição, exceto conforme descrito abaixo.

Se a mensagem SUBSCRIBE inicial continha um parâmetro "id" no cabeçalho "Event", então renovações da subscrição precisa também conter um parâmetro "id" idêntico; do contrário, elas serão consideradas novas subscrições em um diálogo existente.

Se uma requisição SUBSCRIBE ao renovar uma subscrição receber uma resposta "481", isso indica que a subscrição foi encerrada e que o subscritor não recebeu notificação desse fato. Nesse caso, o subscritor deve considerar a subscrição inválida. Se o subscritor quiser re-subscrever ao estado, ele faz assim compondo uma requisição SUBSCRIBE inicial não relacionada com um Call-ID gerado recentemente, e uma nova e única tag em "From" (ver seção 3.1.4.1).

Roach                            Standards Track                           [Página 8]

Página original:
http://tools.ietf.org/search/rfc3265#page-8

Página 7

Tabela de Conteúdo

Página 9

RFC 3265 Portugues Pagina 9

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

Se uma requisição SUBSCRIBE para renovar uma subscrição falhar com uma resposta não-481, a subscrição original ainda é considerada válida pela duração do valor em "Expires" mais recentemente conhecido como negociado por SUBSCRIBE e sua resposta, ou conforme comunicado por NOTIFY no parâmetro "expires" do cabeçalho "Subscription-State".

Note que muitos desses erros indicam que pode haver um problema na rede ou com o notificador de modo que mensagens NOTIFY não serão mais recebidas.

3.1.4.3. Cancelando subscrição

O cancelamento de subscrição é tratada da mesma forma que renovação de uma subscrição, com o cabeçalho "Expires" definido igual a "0". Note que um cancelar bem sucedido de subscrição também acionará uma mensagem NOTIFY final.

3.1.4.4. Confirmação de Criação da Subscrição

O subscritor pode esperar receber uma mensagem NOTIFY de cada nó, que processou uma subscrição bem sucedida ou uma renovação da subscrição. Até que a primeira mensagem NOTIFY chegue, o subscritor deve considerar o estado do recurso subscrito a estar em um estado neutro. Documentos que definem novos pacotes-evento PRECISAM definir esse "estado neutro" de tal forma que faça sentido a sua aplicação (ver seção 4.4.7).

Devido ao potencial tanto de mensagens fora-de-ordem quando de bifurcação, o subscritor PRECISA estar preparado para receber mensagens NOTIFY antes de a transação SUBSCRIBE ser concluída.

Exceto conforme observado acima, processamento desse NOTIFY é o mesmo que da seção 3.2.4.

3.1.5. Comportamento do SUBSCRIBE no Proxy

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

Note que subscritores e notificadores podem eleger usar encriptação S/MIME de 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 requerida para ser legível ao proxy pelo SIP [1].

Roach                            Standards Track                           [Página 9]

Página original:
http://tools.ietf.org/search/rfc3265#page-9

Página 8

Tabela de Conteúdo

Página 10

RFC 3265 Portugues Pagina 10

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

3.1.6. Comportamento do SUBSCRIBE no Notificador

3.1.6.1. Processamento da Transação SUBSCRIBE Inicial

Em nenhum caso uma transação SUBSCRIBE deve se estender além do tempo que é o necessário para o processamento automático. Em particular, os notificantes NÃO PODEM esperar uma resposta do usuário antes de retornar uma resposta final a uma requisição SUBSCRIBE.

Essa exigência é imposta essencialmente para evitar o temporizador F de timeout da transação não-INVITE (ver [1]) disparar durante a transação SUBSCRIBE, porque a interação com um usuário normalmente excederia 64*T1 segundos.

O notificador DEVE verificar se o pacote-evento especificado no cabeçalho "Event" foi entendido. Se não, o notificador DEVE retornar uma resposta "489 Bad Event" para indica que o evento/classe de evento especificado não foi entendido.

O notificador DEVE também executar alguma autenticação e autorização necessária de acordo com sua política local. Ver seção 3.1.6.3.

O notificador PODE também verificar se a duração no cabeçalho "Expires" não é muito pequena. Se, e somente se, o intervalo de expiração for maior que zero E menor que uma hora E menos que o mínimo configurado pelo notificador, o notificador PODE retornar um erro "423 Interval too small" que contém um campo-cabeçalho "Min-Expires". O campo-cabeçalho "Min-Expires" é descrito no SIP [1].

Se o notificador conseguir determinar imediatamente que ele entendeu o pacote-evento, que o subscritor autenticado está autorizado a subscrever, e que não há outras barreiras para criar a subscrição; ele cria a subscrição e um diálogo (se necessário), e retorna uma resposta "200 OK" (a menos que agindo assim revelaria a política de autorização de uma forma indesejável; ver seção 5.2).

Se o notificador não puder imediatamente criar a subscrição (p.ex., ele precisa esperar a entrada do usuário para autorização, ou está agindo para outro nó que não está acessível momentaneamente), ou pretenda mascarar a política de autorização, ele retornará uma resposta "202 Accepted". Essa resposta indica que a requisição foi recebida e entendida, mas não necessariamente implica que a subscrição foi autorizada ainda.

Quando uma subscrição é criada no notificador, ele armazena o nome do pacote-evento e o parâmetro "id" do cabeçalho "Event" (se presente) como parte da informação de subscrição.

Roach                           Standards Track                           [Página 10]

Página original:
http://tools.ietf.org/search/rfc3265#page-10

Página 9

Tabela de Conteúdo

Página 11

RFC 3265 Portugues Pagina 11

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

Os valores no campo-cabeçalho "Expires" presentes nas respostas classe 200 ao SUBSCRIBE se comportam da mesma forma como eles se comportariam em respostas ao REGISTER: o servidor PODE diminuir o intervalo, mas NÃO PODE alongá-lo.

Se a duração especificada em uma mensagem SUBSCRIBE é inaceitavelmente curta, o notificador pode ser capaz de enviar uma resposta 423, conforme descrito mais cedo nessa seção.

Respostas de classe 200 às requisições SUBSCRIBE geralmente não vão conter nenhuma informação útil além da duração da subscrição; seu propósito primário é servir como um mecanismo confiável. Informação de estado será comunicada via uma requisição NOTIFY subseqüente a partir do notificador.

Outros códigos de resposta definidos no SIP [1] podem ser usados em respostas às requisições SUBSCRIBE, quando for apropriado.

3.1.6.2. Confirmação de Criação/Renovação da Subscrição

Após o sucesso em aceitar ou renovar uma subscrição, notificadores PRECISAM enviar uma mensagem NOTIFY imediatamente para comunicar o estado atual do recurso ao subscritor. Essa mensagem NOTIFY é enviada no mesmo diálogo que foi criado pela resposta ao SUBSCRIBE. Se o recurso não tem estado significativo no momento em que a mensagem SUBSCRIBE for processada, essa mensagem NOTIFY PODE conter um corpo vazio ou neutro. Ver a seção 3.2.2 para mais informações sobre a geração de mensagens NOTIFY.

Note que uma mensagem NOTIFY é sempre enviada imediatamente após qualquer resposta classe 200 a uma requisição SUBSCRIBE, independentemente de a subscrição já foi ou não autorizada.

3.1.6.3. Autenticação/Autorização de requisições SUBSCRIBE

Preocupações com a privacidade podem exigir que notificadores apliquem política para determinar se um determinado subscritor está autorizado a subscrever a certo conjunto de eventos. Tal política pode ser definida por mecanismos, tais como listas de controle de acesso ou interação em tempo real com um usuário. Em geral, autorização de subscritores antes da autenticação não é particularmente útil.

Mecanismos de autenticação SIP são discutidos no SIP [1]. Note que, mesmo que o nó notificador atue normalmente como um proxy, autenticação para requisições SUBSCRIBE será sempre realizada via uma resposta "401", e não uma resposta "407"; notificadores sempre atuam como agentes-usuários quando aceitam subscrições e enviam notificações.

Roach                           Standards Track                           [Página 11]

Página original:
http://tools.ietf.org/search/rfc3265#page-11

Página 10

Tabela de Conteúdo

Página 12

RFC 3265 Portugues Pagina 12

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

Claro, quando atuando como proxy, um nó vai executar a autenticação como proxy normal (usando 407). A explicação precedente é um lembrete de que os notificadores são sempre UA's, e, como tais, realizam autenticação como UA.

Se a autorização falhar baseado em uma lista de acesso ou algum outro mecanismo automatizado (ou seja, ele pode ser automaticamente determinado autorizado que o subscritor não está autorizado a subscrever); o notificador DEVE responder à requisição com uma resposta "403 Forbidden" ou uma resposta "603 Decline", a menos que agindo assim poderia revelar informações que devem permanecer privadas, ver a seção 5.2.

Se o proprietário notificador é interativamente consultado para determinar se uma subscrição é aceita, uma resposta "202 Accept" é retornada imediatamente. Note que uma mensagem NOTIFY ainda é formada e enviada sob essas circunstâncias, conforme descrito na seção anterior.

Se a autorização da subscrição foi atrasada e o notificador deseja transmitir que tal autorização foi recusada, poderá fazê-lo assim enviando uma mensagem NOTIFY contendo um cabeçalho "Subscription-State" com um valor "terminated" e um parâmetro razão "rejected".

3.1.6.4. Renovação de Subscrições

Quando um notificador recebe uma renovação de subscrição, supondo que o subscritor está ainda autorizado, o notificador atualiza o tempo de expiração para a subscrição. Da forma que a subscrição inicial, o servidor PODE encurtar o tempo até a expiração, mas NÃO PODE aumentá-la. O tempo de expiração final é colocado no cabeçalho "Expires" da resposta. Se a duração especificada em uma mensagem SUBSCRIBE é inaceitavelmente curta, o notificador DEVE responder com uma mensagem "423 Subscription Too Brief".

Se nenhuma renovação para um endereço de notificação for recebida antes do seu tempo de expiração, a subscrição é removida. Ao remover uma subscrição, o notificador DEVE enviar uma mensagem NOTIFY com um valor em "Subscription-State" de "terminated" para informá-lo que a subscrição está sendo removida. Se tal mensagem for enviada, o cabeçalho "Subscription-State" DEVE conter um parâmetro "reason=timeout".

O envio de um NOTIFY quando uma subscrição expira permite ao diálogo correspondente ser encerrado, se for apropriado.

Roach                           Standards Track                           [Página 12]

Página original:
http://tools.ietf.org/search/rfc3265#page-12

Página 11

Tabela de Conteúdo

Página 13

RFC 3265 Portugues Pagina 13

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

3.2. Descrição do comportamento do NOTIFY

Mensagens NOTIFY são enviadas para informar aos subscritores sobre mudanças no estado aos quais o subscritor tem uma subscrição. Subscrições são normalmente implementadas usando o método SUBSCRIBE; no entanto, é possível que outros meios sejam usados.

Se mecanismos não-SUBSCRIBE forem definidos para gerar subscrições, isso será da responsabilidade das partes que definem esses mecanismos para garantir que a correlação de uma mensagem NOTIFY com a subscrição correspondente seja possível. Projetistas de tais mecanismos são também alertados para fazer a distinção entre o envio de uma mensagem NOTIFY para um subscritor que está ciente da subscrição, e o envia de uma mensagem NOTIFY a um nó insuspeito. O segundo comportamento é inválido, e PRECISA receber uma resposta "481 Subscription does not exist" (a menos que outros códigos de erro de classe 400 ou 500 sejam mais aplicáveis), conforme descrito na seção 3.2.4. Em outras palavras, o conhecimento de uma subscrição precisa existir tanto no subscritor quanto no notificador para ser válido, mesmo se instalado via um mecanismo não-SUBSCRIBE.

Um NOTIFY não termina sua subscrição correspondente; em outras palavras, uma requisição SUBSCRIBE simples pode disparar várias requisições NOTIFY.

3.2.1. Identificação de Eventos Reportados, Classes de Evento e Estado Atual

Identificação de eventos sendo reportados em uma notificação é muito similar àquela descrita para subscrição aos eventos (ver seção 3.1.2).

Como em requisições SUBSCRIBE, cabeçalhos "Event" de NOTIFY irão conter um simples nome de pacote-evento para os quais a notificação está sendo gerada. O nome do pacote no cabeçalho "Event" PRECISA coincidir com o cabeçalho "Event" na mensagem SUBSCRIBE correspondente. Se um parâmetro "id" estava presente na mensagem SUBSCRIBE, esse parâmetro "id" PRECISA estar também presente nas mensagens NOTIFY correspondentes.

Pacotes-evento podem definir semântica associada ao corpo de suas requisições NOTIFY; se assim eles a fizerem, tal semântica se aplica. Corpos de NOTIFY devem fornecer detalhes adicionais sobre a natureza do evento que ocorreu e o estado resultante do recurso.

Quando presente, o corpo da requisição NOTIFY PRECISA ser formatado em um dos formatos de corpo especificados no cabeçalho "Accept" da requisição SUBSCRIBE correspondente. Esse corpo irá conter tanto o estado do recurso subscrito como um ponteiro para tal estado sob a forma de um URI (ver seção 4.4.13).

Roach                           Standards Track                           [Página 13]

Página original:
http://tools.ietf.org/search/rfc3265#page-13

Página 12

Tabela de Conteúdo

Página 14

RFC 3265 Portugues Pagina 14

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]

Página original:
http://tools.ietf.org/search/rfc3265#page-14

Página 13

Tabela de Conteúdo

Página 15

RFC 3265 Portugues Pagina 15

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]

Página original:
http://tools.ietf.org/search/rfc3265#page-15

Página 14

Tabela de Conteúdo

Página 16

RFC 3265 Portugues Pagina 16

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]

Página original:
http://tools.ietf.org/search/rfc3265#page-16

Página 15

Tabela de Conteúdo

Página 17