Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP: 2011




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

terça-feira, 25 de outubro de 2011

Um Pouco de História - Razão de Ser da Rede IP





Fragmento de texto extraído das páginas 33, 34, 35 e 36 do Livro Redes de Computadores 5º Edição 2011

Créditos aos autores da obra:
Autores Originais: Andrew S. Tanenbaum e David Wetherall
Tradução para Português: Daniel Vieira
Revisão Técnica: Prof. Dr. Isaias Lima, Universidade Federal de Itajubá
Editora Pearson Education do Brasil



A INTERNET
 A Internet não é de modo algum uma rede, mas sim um vasto conjunto de redes diferentes que utilizam certos protocolos comuns e fornecem determinados serviços comuns. É um sistema incomum no sentido de não ter sido planejado nem ser controlado por ninguém. Para entendê-la melhor, vamos começar do início e observar como e por que ela foi desenvolvida. Se desejar conhecer uma história maravilhosa sobre o surgimento da Internet, recomendamos o livro de John Naughton (2000). Trata-se de um daqueles raros livros que não apenas são divertidos de ler, mas que também têm 20 páginas de citações destinadas aos historiadores sérios. Uma parte do material a seguir se baseia nesse livro.

 É claro que também foram escritos inúmeros livros técnicos sobre a Internet e seus protocolos. Para obter mais informações consulte, por exemplo, Maufer (1999).


A ARPANET
 A história começa no final da década de 1950. No auge da Guerra Fria, o Departamento de Defesa dos Estados Unidos queria uma rede de controle e comando capaz de sobreviver a uma guerra nuclear. Nessa época, todas as comunicações militares passavam pela rede de telefonia pública, considerada vulnerável. A razão para essa convicção pode ser vista na Figura 1.22(a). Nessa figura, os pontos pretos representam centrais de comutação telefônica, cada uma das quais conectada a milhares de telefones. Por sua vez, essas centrais de comutação estavam conectadas a centrais de comutação de nível mais alto (centrais interurbanas), formando uma hierarquia nacional com apenas uma pequena redundância. A vulnerabilidade do sistema era o fato de que a destruição de algumas centrais interurbanas importantes poderia fragmentar o sistema em muitas ilhas isoladas.

Figura 1.22 |  (a) Estrutura do sistema de telefonia. (b) Sistema distribuído de comutação proposto por Baran.


 Por volta de 1960, o Departamento de Defesa dos Estados Unidos firmou um contrato com a RAND Corporation para encontrar uma solução. Um de seus funcionários, Paul Baran, apresentou o projeto altamente distribuído e tolerante a falhas da Figura 1.22(b). Tendo em vista que os caminhos entre duas centrais de comutação quaisquer
eram agora muito mais longos do que a distância que os sinais analógicos podiam percorrer sem distorção. Baran propôs o uso da tecnologia digital de comutação de pacotes. Ele enviou diversos relatórios para o Departamento de Defesa descrevendo suas idéias em detalhes (Baran. 1964). Os funcionários do Pentágono gostaram do conceito e pediram à AT&T, na época a empresa que detinha o monopólio nacional da telefonia nos Estados Unidos, que construísse um protótipo. A AT&T descartou as idéias de Baran. Afinal, a maior e mais rica corporação do mundo não podia permitir que um jovem pretensioso lhe ensinasse a criar um sistema telefônico. A empresa informou que a rede de Baran não podia ser construída e a ideia foi abandonada. 


Pegando um gancho nesse ponto da narrativa do mestre Tanenbaum sobre a História da Internet, cabe uma observação importante que o autor do Blog gostaria de fazer: Fica claro que topoogia estrela não se harmoniza com a arquitetura TCP/IP porque tal topologia suplime as premissas mais caras para as quais a rede TCP/IP foi desenvolvida. Quais sejam: re-roteamento, contingenciamento, alta disponibilidade e tolerância a falha. Portanto, redes de grandes corporações, como bancos, telecoms, governos, etc. não pode ter como parâmetro de projeto pontos concentradores baseados em topologias estrelas. 

 
 Vários anos se passaram e o Departamento de Defesa ainda não tinha um sistema melhor de comando e controle. Para entender o que aconteceu em seguida, temos de retornar a outubro de 1957, quando a União Soviética derrotou os Estados Unidos na corrida espacial com o lançamento do primeiro satélite artificial, o Sputnik. Quando tentou descobrir quem tinha ‘dormido no ponto’, o presidente Eisenhower acabou detectando a disputa entre o Exército, a Marinha e a Força Aérea pelo orçamento de pesquisa do Pentágono. Sua resposta imediata foi criar uma organização centralizada de pesquisa de defesa, a ARPA, ou Advanced Research Projects Agency. A ARPA não tinha cientistas nem laboratórios; de fato, ela não tinha nada além de um escritório e um pequeno orçamento (para os padrões do Pentágono). A agência realizava seu trabalho oferecendo concessões e contratos a universidades e empresas cujas ideias lhe pareciam promissoras.

 Durante os primeiros anos, a ARPA tentou compreender qual deveria ser sua missão. Porém, em 1967, a atenção do então diretor de programas da ARPA, Larry Roberts, que estava tentando descobrir como oferecer acesso remoto aos computadores, se voltou para as redes. Ele entrou em contato com diversos especialistas para decidir o que fazer. Um deles, Wesley Clark, sugeriu a criação de uma sub-rede comutada por pacotes, dando a cada host seu próprio roteador.

 Após algum ceticismo inicial, Roberts comprou a ideia e apresentou um documento um tanto vago sobre ela no ACM SIGOPS Symposium on Operating System Principies, realizado em Gatlinburg, Tennessee, no final de 1967 (Robens, 1967). Para grande surpresa de Roberts, outro documento na conferência descrevia um sistema semelhante, que não só tinha sido projetado mas, na realidade, havia sido totalmente implementado sob a orientação de Donald Davies no National Physical Laboratory, na Inglaterra. O sistema do NPL não era um sistema nacional (ele simplesmente conectava vários computadores no campus do NPL), mas demonstrava que a comutação de pacotes podia funcionar. Além disso, ele citava o trabalho anteriormente descartado de Baran. Roberts voltou de Gatlinburg determinado a construir o que mais tarde ficou conhecido como ARPANET.

 A sub-rede consistiria em minicomputadores chamados processadores de mensagens de interface, ou IMPs (Interface Message Processors), conectados por linhas de transmissão de 56 kbps. Para garantir sua alta confiabilidade, cada IMP seria conectado a pelo menos dois outros IMPs. A sub-rede tinha de ser uma sub-rede de datagrama, de modo que, se algumas linhas e alguns IMPs fossem destruídos, as mensagens poderiam ser roteadas automaticamente para caminhos alternativos.

 Cada nó da rede deveria ter um IMP e um host na mesma sala, conectados por um fio curto. Um host poderia enviar mensagens de até 8.063 bits para seu IMP que, em seguida, dividiria essas mensagens em pacotes de no máximo 1.008 bits e os encaminharia de forma independente até o destino. Cada pacote era recebido por completo antes de ser encaminhado; assim, a sub-rede se tomou a primeira rede eletrônica de comutação de pacotes de store-and-forward (de armazenamento e encaminhamento).

 Em seguida, a ARPA abriu uma concorrência para a construção da sub-rede. Doze empresas apresentaram propostas. Depois de avaliar todas as propostas, a ARPA selecionou a BBN, uma empresa de consultoria de Cambridge, Massachusetts e, em dezembro de 1968, assinou um contrato para montar a sub-rede e desenvolver o software para ela. A BBN resolveu utilizar, como IMPs, minicomputadores Honeywell DDP-3 16 especialmente modificados, com 12 K palavras de 16 bits de memória principal. Os IMPs não tinham unidades de discos, pois os componentes móveis eram considerados pouco confiáveis. Os IMPs eram interconectados por linhas privadas das companhias telefônicas, de 56 kbps. Embora 56 kbps hoje seja a única escolha de adolescentes que não podem dispor de DSL ou modems a cabo, na época era o melhor que o dinheiro podia comprar.

Figura 1.23 | O projeto original da ARPANET.


 O software foi dividido em duas partes: sub-rede e host. O software da sub-rede consistia na extremidade IMP da conexão host-IMP, no protocolo IMP-IMP e em um protocolo do IMP de origem para o IMP de destino, criado para aumentar a confiabilidade. O projeto original da ARPANET é mostrado na Figura 1.23.

 Fora da sub-rede, também havia necessidade de software, ou seja, a extremidade referente ao host da conexão host-IMP, o protocolo host-host e o software de aplicação. Logo ficou claro que a BBN era da opinião que, quando tivesse aceitado uma mensagem em uma conexão host-IMP e a tivesse colocado na conexão host-IMP no destino, sua tarefa teria terminado.

 Entretanto, Roberts tinha um problema: os hosts também precisavam de software. Para lidar com ele, Roberts convocou uma reunião com os pesquisadores de rede, em sua maioria estudantes universitários, em Snowbird, Utah, no verão de 1969. Os universitários esperavam que algum perito em redes explicasse o projeto geral da rede e seu software, e depois atribuísse a cada um deles a tarefa de desenvolver uma parte do projeto. Eles ficaram absolutamente surpresos ao verem que não havia nenhum especialista em rede e nenhum projeto geral. Os estudantes teriam de descobrir o que fazer por conta própria.

 No entanto, em dezembro de 1969 entrou no ar uma rede experimental com quatro nós: UCLA, UCSB, SRI e University of Utah. Esses quatro nós foram escolhidos porque todos tinham um grande número de contratos com a ARPA, e todos tinham computadores host diferentes e completamente incompatíveis (para aumentar o desafio). A primeira mensagem host a host havia sido enviada dois meses antes, do nó na UCLA, por uma equipe liderada por Len Kleinrock (pioneiro da teoria de comutação de pacotes) para o nó em SRI. A rede cresceu rapidamente à medida que outros IMPs foram entregues e instalados; logo se estendeu por todo o território norte-americano. A Figura 1.24 mostra a rapidez com que a ARPANET se desenvolveu nos três primeiros anos.

Figura 1.24 | O crescimento da ARPANET. (a) Dezembro 1969. (b) Julho de 1970. (c) Março de 1971. (d) Abril de 1972. (e) Setembro de 1972.

 Além de ajudar no súbito crescimento da ARPANET, a ARPA também financiou pesquisas sobre o uso de redes de satélite e redes móveis de rádio de pacotes. Em uma hoje famosa demonstração, um motorista de caminhão viajando pela Califórnia utilizou a rede de rádio de pacotes para enviar mensagens à SRI, que então foram encaminhadas pela ARPANET até a Costa Leste dos Estados Unidos, de onde foram enviadas à University College, em Londres, pela rede de satélite. Isso permitiu que um pesquisador no caminhão usasse um computador situado em Londres enquanto dirigia pelo estado da Califórnia.

 Essa experiência também demonstrou que os protocolos da ARPANET não eram adequados para execução em redes diferentes. Essa observação levou a mais pesquisas sobre protocolos, culminando com a invenção dos protocolos e do modelo TCP/IP (Cerf e Kahn, 1974). O TCP/IP foi criado especificamente para manipular a comunicação entre redes interligadas, algo que se tomou mais importante à medida que um número maior de redes era conectado a ARPANET.

 Para estimular a adoção desses novos protocolos, a ARPA ofereceu diversos contratos para implementar o TCP/lP em diferentes plataformas de computação, incluindo sistemas IBM, DEC e HP, bem como o UNIX de Berkeley. Os pesquisadores na University of California em Berkeley reescreveram o TCP/IP com uma nova interface de programação (soquetes) para o lançamento iminente da versão 4.2BSD do UNIX de Berkeley. Eles também escreveram muitos programas aplicativos, utilitários e de gerenciamento para mostrar como era conveniente usar a rede com soquetes.

 A ocasião foi perfeita. Muitas universidades tinham acabado de adquirir um segundo ou um terceiro computador VAX e uma LAN para conectá-los, mas não tinham nenhum software de rede. Quando surgiu o 4.2BSD, com TCP/IP, soquetes e muitos utilitários de rede, o pacote completo foi adotado imediatamente. Além disso, com o TCP/IP, era fácil conectar as LANs à ARPANET, e muitos fizeram isso.

 Durante a década de 1980, novas redes, em particular as LANs, foram conectadas à ARPANET. À medida que a escala aumentou, tomou-se cada vez mais dispendioso localizar os hosts, e assim foi criado o sistema de nomes de domínio, ou DNS (Domam Name System), para organizar máquinas em domínios e relacionar nomes de hosts com endereços IP. Desde então, o DNS se transformou em um sistema generalizado de bancos de dados distribuídos, capaz de armazenar uma série de informações referentes à atribuição de nomes... 



 ... para ler o restante dessa História e o conteúdo do livro, esse que uma referência na área de Rede, compre o referido livro. É um ótimo investimento!!! Vale a pena!!!!










sábado, 17 de setembro de 2011

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








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







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







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







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







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







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







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







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







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







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










Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.