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

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

2011-10-25T21:09:00.000-02:00

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

Créditosaos autores da obra:

AutoresOriginais: Andrew S. Tanenbaum e David Wetherall

Traduçãopara Português: Daniel Vieira

RevisãoTécnica: Prof. Dr. Isaias Lima, Universidade Federal de Itajubá

Editora Pearson Education do Brasil

A INTERNET

A Internet não é de modo algumuma rede, mas sim um vasto conjunto de redes diferentes que utilizam certosprotocolos comuns e fornecem determinados serviços comuns. É um sistema incomumno sentido de não ter sido planejado nem ser controlado por ninguém. Paraentendê-la melhor, vamos começar do início e observar como e por que ela foidesenvolvida. Se desejar conhecer uma história maravilhosa sobre o surgimentoda Internet, recomendamos o livro de John Naughton(2000). Trata-se de um daqueles raros livros que não apenas são divertidos deler, mas que também têm 20 páginas de citações destinadas aos historiadoressérios. Uma parte do material a seguir se baseia nesselivro.

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

AARPANET

Ahistória começa no final da década de 1950. No auge da Guerra Fria, oDepartamento de Defesa dos Estados Unidos queria uma rede de controle e comandocapaz de sobreviver a uma guerra nuclear. Nessa época, todas as comunicaçõesmilitares passavam pela rede de telefonia pública, considerada vulnerável. Arazão para essa convicção pode ser vista na Figura 1.22(a). Nessa figura, ospontos pretos representam centrais de comutação telefônica, cada uma das quaisconectada a milhares de telefones. Por sua vez, essas centrais de comutaçãoestavam conectadas a centrais de comutação de nível mais alto (centraisinterurbanas), formando uma hierarquia nacional com apenas uma pequenaredundância. A vulnerabilidade do sistema era o fato de que a destruição dealgumas centrais interurbanas importantes poderia fragmentar o sistema emmuitas ilhas isoladas.

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

Por volta de 1960, o Departamento de Defesa dos Estados Unidos firmou umcontrato com a RAND Corporation para encontrar uma solução. Um de seusfuncionários, Paul Baran, apresentou o projeto altamente distribuído etolerante a falhas da Figura 1.22(b). Tendo em vista que os caminhos entre duascentrais de comutação quaisquer eram agora muito mais longos do que a distância que ossinais analógicos podiam percorrer sem distorção. Baranpropôs o uso da tecnologia digital de comutação de pacotes. Ele enviou diversosrelatórios para o Departamento de Defesa descrevendo suas idéias em detalhes (Baran. 1964). Os funcionários do Pentágono gostaram doconceito e pediram à AT&T, na época a empresa quedetinha o monopólio nacional da telefonia nos Estados Unidos, que construísseum protótipo. A AT&T descartou as idéias de Baran. Afinal, a maior e mais rica corporação do mundo nãopodia permitir que um jovem pretensioso lhe ensinasse a criar um sistematelefônico. A empresa informou que a rede de Barannã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 umsistema 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 osEstados Unidos na corrida espacial com o lançamento doprimeiro satélite artificial, o Sputnik. Quando tentou descobrir quemtinha ‘dormido no ponto’, o presidente Eisenhoweracabou detectando a disputa entre o Exército, a Marinha e a Força Aérea peloorçamento de pesquisa do Pentágono. Sua resposta imediata foi criar umaorganização centralizada de pesquisa de defesa, a ARPA, ou AdvancedResearch Projects Agency. A ARPA não tinha cientistas nem laboratórios; defato, ela não tinha nada além de um escritório e um pequeno orçamento (para ospadrões do Pentágono). A agência realizava seu trabalho oferecendo concessões econtratos a universidades e empresas cujas ideias lhepareciam promissoras.

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

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

A sub-rede consistiria em minicomputadores chamados processadores demensagens de interface, ou IMPs (Interface Message Processors), conectadospor linhas de transmissão de 56 kbps. Para garantirsua 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 roteadasautomaticamente para caminhos alternativos.

Cada nó da rede deveria ter um IMP e um host namesma sala, conectados por um fio curto. Um hostpoderia 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 encaminhariade forma independente até o destino. Cada pacote era recebido por completoantes de ser encaminhado; assim, a sub-rede se tomou aprimeira 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, aARPA selecionou a BBN, uma empresa de consultoria de Cambridge, Massachusettse, em dezembro de 1968, assinou um contrato para montar a sub-rede edesenvolver o software para ela. A BBN resolveu utilizar, como IMPs, minicomputadores HoneywellDDP-3 16 especialmente modificados, com 12 K palavras de 16 bits de memóriaprincipal. 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 dascompanhias telefônicas, de 56 kbps. Embora 56 kbps hoje seja a única escolhade adolescentes que não podem dispor de DSL ou modemsa cabo, na época era o melhor que o dinheiro podia comprar.

Figura 1.23 | O projeto original daARPANET.

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 deorigem para o IMP de destino, criado para aumentar a confiabilidade. O projetooriginal da ARPANET é mostrado na Figura 1.23.

Fora da sub-rede, também havia necessidade de software, ou seja, aextremidade referente ao host da conexão host-IMP, o protocolo host-host eo software de aplicação. Logo ficou claro que a BBN era da opinião que, quandotivesse aceitado uma mensagem em uma conexão host-IMPe 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 esperavamque algum perito em redes explicasse o projeto geral da rede e seu software, edepois 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 especialistaem rede e nenhum projeto geral. Os estudantes teriam de descobrir o que fazerpor conta própria.

No entanto, em dezembro de 1969 entrou no ar uma rede experimental comquatro nós: UCLA, UCSB, SRI e University of Utah. Esses quatro nós foram escolhidos porque todos tinhamum grande número de contratos com a ARPA, e todos tinham computadores host diferentes e completamente incompatíveis (paraaumentar 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 cresceurapidamente à medida que outros IMPs foram entreguese instalados; logo se estendeu por todo o território norte-americano. A Figura1.24 mostra a rapidez com que a ARPANET se desenvolveu nos três primeiros anos.

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

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

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

Para estimular a adoção desses novos protocolos, a ARPA ofereceu diversoscontratos para implementar o TCP/lP em diferentesplataformas de computação, incluindo sistemas IBM, DEC e HP, bem como o UNIX deBerkeley. Os pesquisadores na University of California em Berkeley reescreveram o TCP/IPcom uma nova interface de programação (soquetes) para o lançamento iminente daversão 4.2BSD do UNIX de Berkeley. Eles também escreveram muitos programasaplicativos, utilitários e de gerenciamento para mostrar como era convenienteusar a rede com soquetes.

A ocasião foi perfeita. Muitas universidades tinham acabado de adquirirum segundo ou um terceiro computador VAX e uma LAN para conectá-los, mas nãotinham nenhum software de rede. Quando surgiu o 4.2BSD,com TCP/IP, soquetes e muitos utilitários de rede, opacote 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 oshosts, e assim foi criado o sistema de nomes dedomínio, ou DNS (Domam Name System),para organizar máquinas em domínios e relacionar nomes de hostscom endereços IP. Desde então, o DNS se transformou em um sistema generalizadode bancos de dados distribuídos, capaz de armazenar uma série de informaçõesreferentes à 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!!!!

RFC 3265 Portugues Pagina 1

2011-09-17T01:55:00.003-03:00

Grupo de Trabalho em Rede                                                 A. B. Roach
Requestfor 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 umprotocolo tramitando na padronização pela comunidade Internet, e solicitadiscussões e sugestões para melhorias. Favor consultar a edição corrente do"Internet Official Protocol Standards" (STD 1) para ver o estado dapadronização e o status desse protocolo. A distribuição desse memorando éilimitada.

Aviso sobre DireitosAutorais

Direitos Autorais (C) DaInternet Society (2002). Todos os Direitos Reservados.

Resumo

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

Usos concretos do mecanismodescritos nesse documento podem ser padronizados no futuro.

Note que os mecanismos denotificação de evento definidos aqui NÃO são tencionados ser uma infra-estruturade 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 noSUBSCRIBE............................... 6
3.1.1.   Duração da Subscrição.................................................  6
3.1.2.   Identificaçãode 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

2011-09-17T01:05:00.000-03:00

RFC 3265                Notificaçãode Evento Específico-SIP               Junho2002


2.     Descrição do Comportamento do NOTIFY..................................13
2.1.   Identificaçãode Eventos Reportados, Classes de Evento e
         Estado Corrente.......................................................13
2.2.   Comportamento do NOTIFY no Notificador................................14
2.3.   Comportamento do NOTIFY no Proxy......................................15
2.4.   Comportamento do NOTIFY no Subscritor.................................16
3.     Geral.................................................................18
3.1.   Detectandosuporte para SUBSCRIBE e NOTIFY............................ 18
3.2.   Requisições CANCEL................................................... 18
3.3.   Bifurcando............................................................18
3.4.   Criação e término de Diálogo..........................................18
3.5.   Agentesde Estado e Migração de Notificador........................... 19
3.6.   Sondando Estado de Recurso............................................20
3.7.   Uso de cabeçalho Allow-Events.........................................21
3.8.   Compatibilidade com o PINT............................................21
       Pacotes-Evento........................................................21
1.     Oportunidade de Uso................................................... 21
2.     Modelo de Pacotes-Evento..............................................22
3.     Quantidadede Estado a ser Transportado............................... 22
3.1.   Informação de Completa de Estado......................................23
3.2.  State Deltas..........................................................23
4.     Responsabilidades do Pacote-Evento....................................24
4.1.   Nome do Pacote-Evento.................................................24
4.2.   Parâmetros do Pacote-Evento ..........................................24
4.3.   Corpos de SUBSCRIBE...................................................24
4.4.   Duração daSubscrição.................................................25
4.5.   Corpos de NOTIFY......................................................25
4.6.   Processamentode requisições SUBSCRIBE no Notificador................. 25
4.7.   Geração de requisições NOTIFY no Notificador..........................25
4.8.   Processamentode requisições NOTIFY no Subscritor..................... 26
4.9.   Handlingof forked requests........................................... 26
4.10.  Taxa de notificações..................................................26
4.11.  Agentes de Estado.....................................................27
4.12.  Exemplos..............................................................27
4.13.  Usode URI's ao Buscar Estado......................................... 27
       Considerações de Segurança............................................28
1.     Controle de Acesso....................................................28
2.     Mecanismo de Privacidade no Notificador...............................28
3.     Ataquesde Negação-de-Serviço......................................... 28
4.     Ataques de Repetição..................................................29
5.     Ataques Man-in-the-middle.............................................29
6.     Confidencialidade.....................................................29
       Considerações sobre o IANA............................................ 30
1.     Informação de Registro................................................30
2.     Modelo de Registro....................................................31
3.     Nomes de Campo-Cabeçalho..............................................31
4.     Códigosde Resposta...................................................32
       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

2011-09-17T01:00:00.000-03:00

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ódigoResposta "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.      Avisosobre Direitos de Propriedade Intelectual....................... 37
12.      Endereço do Autor.....................................................37
13.      DeclaraçãoCompleta de Direitos Autorais.............................. 38


1. Introdução

A capacidade para requisitar notificação assíncronade eventos se mostra útil em vários tipos de serviços do SIP aos quais a cooperação entrenó's remotos é necessário.Exemplos de tais serviços incluemserviç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 (baseadoem eventos da mudança de estado do mailbox), e status da PSTNe da Internet Internetworking(PINT) [2] (baseado emeventos de estado da chamada).

Os métodos descritos nessedocumento fornecem uma infra-estrutura pela qual a notificação desses eventospode 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çãoe notificação de eventos. Encontrar requerimentospara o conjunto amplo de problemas de subscrição e de notificação é complexo demais para um único protocolo. Nossoobjetivo é fornecer ao SIPuma 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 parafornecer serviços poderosos. Note,no entanto, que pacotes-evento baseados nessa infra-estruturapode 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 serusada 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

2011-09-17T00:55:00.000-03:00

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 é queentidades na rede podem se subscrever a recursos ou ao estado de chamada paravários recursos ou chamadas na rede, e essas entidades (ou entidades agindo emnome 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 precisamser renovadas por mensagens SUBSCRIBE subseqüentes.

1.2. Convenções da Documentação

Há vários parágrafos ao longo dessedocumento que fornecem textomotivacional ou de esclarecimento.Tais passagens são não-normativas, e são fornecidos apenaspara auxiliar na compreensão do leitor. Essas passagens são definidas fora do restantedo texto por ser indentadoassim:

Esse é um exemplo de textoexplanatório não-normativo. Não faz parte da especificação, e é usado apenas paraclarificação.

Números entre colchetes (porexemplo, [1]) denotam uma referência a alguma das entradas nas seções dereferê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 juntoa pontos e vírgulas segue aconvenção usada pela American Mathematical Society; embora contrárioa tradicional convenção do InglêsAmericano, 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

2011-09-17T00:40:00.001-03:00

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

2. Definições

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

EventTemplate-Package: Um pacote-modelo de evento é um tipo especial de pacote-eventoque 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 subscritorpara informar ao subscritor o estado de um recurso.

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

StateAgent: Um agente de estado é um notificador que publica informação de estado emnome de um recurso; a fim de proceder assim, ele pode precisar reunir tais informaçõesde estado de múltiplas fontes. Agentes de Estado sempre têminformaçõ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 sobreo qual o subscritor está interessado. Subscritores tipicamente também geram requisiçõesSUBSCRIBE 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. Esseestado 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çõesadicionais do estado da subscrição. Por definição, subscrições existem tanto emum subscritor quanto em um notificador.

SubscriptionMigration: Migração de subscrição é o ato de mover uma subscrição de um notificadorpara 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

2011-09-17T00:36:00.002-03:00

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

3. Comportamento do Nó

3.1. Descrição doComportamento do SUBSCRIBE

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

3.1.1. Duração da Subscrição

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

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

Respostas de classe 200 a requisições SUBSCRIBE também PRECISAMconter um cabeçalho "Expires". O período de tempo na resposta PODE sermais curto, mas NÃO PODE ser maior do que o especificado na requisição. O períodode 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 SUBSCRIBEe não é explicitamente equivalente a um cabeçalho "Expires" em uma requisiçãoou resposta ao SUBSCRIBE.

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

Além de ser uma requisiçãopara 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 querercancelar subscrições a eventos; isso é útil, por exemplo, quando o recurso ao qualuma 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 Subscritose Classes de Evento

Identificação de eventos é fornecidapor três partes da informação: Request-URI, Tipo de Evento e (opcionalmente) o corpoda 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

2011-09-17T00:31:00.003-03:00

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

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

Subscritores PRECISAM incluirexatamente aquele cabeçalho "Event" em requisições SUBSCRIBE,que indica a qual evento ou classe de eventos eles estão subscrevendo. Ocabeçalho "Event" vai conter um token que indica o tipo de estado parao qual uma subscrição está sendo requisitada. Esse token será registrado noIANA e vai corresponder a um pacote-evento que descreve mais a semântica adicionaldo evento ou classe de evento. O cabeçalho "Event" PODE também conterum parâmetro "id". Esse parâmetro "id", se presente, contémum 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 tokendo evento corresponde define o comportamento associado com o corpo de suasrequisições SUBSCRIBE, tal semântica se aplica.

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

3.1.3. Valores Adicionais decabeçalho em SUBSCRIBE

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

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

3.1.4. Comportamento do SUBSCRIBEno Subscritor

3.1.4.1. Requisitando umaSubscrição

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

Quando um subscritor quer subscrevera um estado particular de um recurso, ele forma uma mensagem SUBSCRIBE. Se oSUBSCRIBE 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

2011-09-17T00:27:00.002-03:00

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

representa uma requisição forade um diálogo (como tipicamente será), sua construção segue os procedimentos descritosno 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 asubscrição foi aceita, e que um NOTIFY será enviado imediatamente. Uma resposta200 indica que a subscrição foi aceita e que o usuário está autorizado a subscreverao 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çãoreal ao qual a subscrição permanecerá ativa (a menos que seja renovada).

Respostas finais de classe não-200indicam que nenhuma subscrição ou diálogo foi criado, e nenhuma mensagem NOTIFYsubseqü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 conformedescrito no SIP [1].

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

3.1.4.2. Renovação deSubscrições

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

Se a mensagem SUBSCRIBEinicial continha um parâmetro "id" no cabeçalho "Event", entãorenovaçõ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 aorenovar uma subscrição receber uma resposta "481", isso indica que asubscriçã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 subscritorquiser re-subscrever ao estado, ele faz assim compondo uma requisição SUBSCRIBEinicial não relacionada com um Call-ID geradorecentemente, 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

2011-09-17T00:22:00.005-03:00

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

Se uma requisição SUBSCRIBE pararenovar 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" maisrecentemente conhecido como negociado por SUBSCRIBE e sua resposta, ou conformecomunicado por NOTIFY no parâmetro "expires" do cabeçalho"Subscription-State".

Note que muitos desses errosindicam que pode haver um problema na rede ou com o notificador de modo que mensagensNOTIFY 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 bemsucedido de subscrição também acionará uma mensagem NOTIFY final.

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

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

Devido ao potencial tanto de mensagensfora-de-ordem quando de bifurcação, o subscritor PRECISA estar preparado parareceber 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 SUBSCRIBEno Proxy

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

Note que subscritores e notificadorespodem 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ãoseja 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

2011-09-17T00:16:00.002-03:00

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

3.1.6. Comportamento do SUBSCRIBE noNotificador

3.1.6.1. Processamento da TransaçãoSUBSCRIBE Inicial

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

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

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

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

O notificador PODE tambémverificar 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 horaE menos que o mínimo configurado pelo notificador, o notificador PODE retornarum 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 conseguirdeterminar imediatamente que ele entendeu o pacote-evento, que o subscritorautenticado está autorizado a subscrever, e que não há outras barreiras paracriar a subscrição; ele cria a subscrição e um diálogo (se necessário), eretorna uma resposta "200 OK" (a menos que agindo assim revelaria apolítica de autorização de uma forma indesejável; ver seção 5.2).

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

Quando uma subscrição é criadano 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

2011-09-17T00:12:00.000-03:00

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 comoeles se comportariam em respostas ao REGISTER: o servidor PODE diminuir ointervalo, mas NÃO PODE alongá-lo.

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

Respostas de classe 200 às requisiçõesSUBSCRIBE 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 estadoserá comunicada via uma requisição NOTIFY subseqüente a partir do notificador.

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

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

Após o sucesso em aceitar ou renovaruma subscrição, notificadores PRECISAM enviar uma mensagem NOTIFY imediatamentepara comunicar o estado atual do recurso ao subscritor. Essa mensagem NOTIFY éenviada no mesmo diálogo que foi criado pela resposta ao SUBSCRIBE. Se orecurso não tem estado significativo no momento em que a mensagem SUBSCRIBE forprocessada, essa mensagem NOTIFY PODE conter um corpo vazio ou neutro. Ver aseçã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, independentementede a subscrição já foi ou não autorizada.

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

Preocupações com a privacidadepodem exigir que notificadores apliquem política para determinar se umdeterminado subscritor está autorizado a subscrever a certo conjunto deeventos. Tal política pode ser definida por mecanismos, tais como listas decontrole 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 SIPsão discutidos no SIP [1]. Note que, mesmo que o nó notificador atuenormalmente como um proxy, autenticação para requisições SUBSCRIBE será semprerealizada via uma resposta "401", e não uma resposta "407";notificadores sempre atuam como agentes-usuários quando aceitam subscrições eenviam 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

2011-09-17T00:07:00.005-03:00

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

Claro, quando atuando comoproxy, um nó vai executar a autenticação como proxy normal (usando 407). Aexplicaçã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 baseadoem uma lista de acesso ou algum outro mecanismo automatizado (ou seja, ele podeser automaticamente determinado autorizado que o subscritor não está autorizadoa subscrever); o notificador DEVE responder à requisição com uma resposta"403 Forbidden" ou uma resposta "603 Decline", a menos que agindoassim poderia revelar informações que devem permanecer privadas, ver a seção5.2.

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

Se a autorização da subscriçãofoi 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 deSubscrições

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

Se nenhuma renovação para um endereçode 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 mensagemNOTIFY com um valor em "Subscription-State" de "terminated"para informá-lo que a subscrição está sendo removida. Se tal mensagem forenviada, o cabeçalho "Subscription-State" DEVE conter um parâmetro"reason=timeout".

O envio de um NOTIFY quandouma subscrição expira permite ao diálogo correspondente ser encerrado, se forapropriado.

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

2011-09-17T00:03:00.000-03:00

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

3.2. Descrição docomportamento do NOTIFY

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

Se mecanismos não-SUBSCRIBEforem definidos para gerar subscrições, isso será da responsabilidade daspartes que definem esses mecanismos para garantir que a correlação de umamensagem NOTIFY com a subscrição correspondente seja possível. Projetistas detais mecanismos são também alertados para fazer a distinção entre o envio deuma mensagem NOTIFY para um subscritor que está ciente da subscrição, e o enviade uma mensagem NOTIFY a um nó insuspeito. O segundo comportamento é inválido,e PRECISA receber uma resposta "481 Subscription does not exist" (a menosque 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 umasubscrição precisa existir tanto no subscritor quanto no notificador para serválido, mesmo se instalado via um mecanismo não-SUBSCRIBE.

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

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

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

Como em requisições SUBSCRIBE,cabeçalhos "Event" de NOTIFY irão conter um simples nome de pacote-eventopara 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 SUBSCRIBEcorrespondente. Se um parâmetro "id" estava presente na mensagemSUBSCRIBE, esse parâmetro "id" PRECISA estar também presente nasmensagens NOTIFY correspondentes.

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

Quando presente, o corpo darequisição NOTIFY PRECISA ser formatado em um dos formatos de corpoespecificados no cabeçalho "Accept" da requisição SUBSCRIBEcorrespondente. Esse corpo irá conter tanto o estado do recurso subscrito comoum 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

2011-09-16T23:58:00.001-03:00

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

3.2.2. Comportamento doNOTIFY no Notificador

Quando uma requisiçãoSUBSCRIBE é respondida com uma resposta de classe 200, o notificador PRECISAimediatamente construir e enviar uma requisição NOTIFY ao subscritor. Quando umaalteração no estado subscrito ocorrer, o notificador DEVE imediatamenteconstruir e enviar uma requisição NOTIFY, mediante autorização, política locale considerações de otimização.

Uma requisição NOTIFY éconsiderada falha se a resposta expirar, ou um código de resposta de classenão-200 for recebido que não tenha cabeçalho "Retry-After" e nem açãoimplí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 foiinstalada usando um mecanismo soft-state (como o SUBSCRIBE), o notificador DEVEremover a subscrição.

Esse comportamento impede atransmissão desnecessária de informação de estado para subscritores que tenhamdeixado de funcionar ou desapareceram da rede. Como tais transmissões serãoenviadas 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 parareconhecê-los poderia colocar tensão indevida na rede. Após o reinício docliente ou restabelecimento de uma conexão de rede, espera-se que os clientesirão enviar mensagens SUBSCRIBE para renovar informações de estadopotencialmente obsoletas; tais mensagens irão re-instalar subscrições em todosos nó's relevantes.

Se a requisição NOTIFY falhar(como definido acima) devido a uma resposta de erro, e a subscrição foiinstalada usando um mecanismo soft-state, o notificador PRECISA remover asubscrição correspondente.

Uma resposta de erro a notificação,em geral, indicaria que algo deu errado com o subscritor ou com algum proxy no caminhodo subscritor. Se o subscritor estiver em erro, faz mais sentido permitir aosubscritor corrigir a situação (subscrevendo de novo) já que a condição de errofoi tratada. Se um proxy estiver em erro, as renovações SUBSCRIBE periódicas irãore-instalar o estado de subscrição uma vez que o problema de rede foiresolvido.

Se uma requisição NOTIFYreceber uma resposta 481, o notificador PRECISA remover a subscriçãocorrespondente, mesmo se tal subscrição foi instalada por meios não-SUBSCRIBE (talcomo 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

2011-09-16T23:53:00.001-03:00

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

Se o comportamento acima nãoera necessário, subscritores que recebem uma notificação para uma subscriçãodesconhecida seria preciso enviar um código de status de erro em resposta aoNOTIFY e também envia uma requisição SUBSCRIBE para remover a subscrição. Comoesse comportamento tornaria subscritores disponíveis para uso comoamplificadores 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 umasubscrição precisa ser cancelada em qualquer circunstância.

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

Se o valor do cabeçalho"Subscription-State" for "active" ou "pending", onotificador DEVE também incluir um parâmetro "expires" no cabeçalho"Subscription-State" para indicar o tempo restante da subscrição. Onotificador 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 umasubscrição.

Incluir informação deexpiração para subscrições ativas e pendentes é útil no caso em que arequisição SUBSCRIBE venha a bifurcar, porque a resposta a um método SUBSCRIBEbifurcado 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", quandofor 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 nenhumcomportamento adicional além daquele descrito no SIP [1] para suportar NOTIFY. Seum 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 quaisquerrequisições NOTIFY que estabelecem o diálogo. Tais proxy's DEVEM também usar record-routeem 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

2011-09-16T23:49:00.000-03:00

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

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

3.2.4. Comportamento do NOTIFYno Subscritor

Ao receber uma requisiçãoNOTIFY, o subscritor deverá verificar se ela confere, pelo menos, com uma desuas subscrições pendentes; se não, ele PRECISA retornar uma resposta "481Subscription does not exist" a menos que outra resposta de classe 400 ou500 seja mais apropriada. As regras para bater requisições NOTIFY contrasubscriçõ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 existenteconferem 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, opacote-evento designado no cabeçalho "Event" da requisição NOTIFY nãofor suportado, o subscritor responderá com uma resposta "489 Bad Event".

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

Requisições NOTIFY PRECISAMconter campos-cabeçalhos "Subscription-State" que indicam o status dasubscriçã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ânticapara "active".

Se o valor de"Subscription-State" for igual a "pending", a subscriçãofoi recebida pelo notificador, mas não há informação suficiente da políticapara 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çãoautorizada e ajustar convenientemente. Nenhuma ação adicional é necessária porparte 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 subscritordeve considerar a subscrição encerrada. O parâmetro "expires" não temsemântica para "terminated". Se um código-razão estiver presente, ocliente deve se comportar conforme descrito abaixo. Se nenhum código-razão ou seum 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

RFC 3265 Portugues Pagina 17

2011-09-16T23:45:00.001-03:00

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

subscrever de novo a qualquermomento (a menos que um parâmetro "retry-after" esteja presente, casoem que o cliente NÃO DEVE tentar a subscrição novamente até após o número desegundos especificado pelo parâmetro "retry-after"). Os códigos-razãodefinidos são:

deactivated:A subscrição foi encerrada, mas o subscritor DEVE tentar de novo imediatamente comuma nova subscrição. Um uso primário de tal código de status é permitir migraçãode subscrições entre nó's. O parâmetro "retry-after" não temsemântica para "deactivated".

probation:A subscrição foi encerrada, mas o cliente DEVE tentar de novo em algum tempo posterior.Se um parâmetro "retry-after" estiver também presente, o cliente DEVEesperar pelo menos o numero de segundos especificado por esse parâmetro antesde tentar subscrever de novo.

rejected: Asubscrição foi encerrada devido à mudança na política de autorização. Clientes NÃODEVEM tentar subscrever de novo. O parâmetro "retry-after" não tem semânticapara "rejected".

timeout: Asubscrição foi encerrada porque ela não foi renovada antes de ela ter expirado.Clientes PODEM subscrever de novo imediatamente. O parâmetro "retry-after"não tem semântica para "timeout".

giveup: Asubscrição foi encerrada porque o notificador não pôde obter autorização atempo. Se um parâmetro "retry-after" estiver também presente, ocliente DEVE esperar pelo menos o número de segundos especificado por esse parâmetroantes de tentar subscrever de novo; do contrário, o cliente PODE tentar de novoimediatamente, mas provavelmente vai voltar ao estado pendente.

noresource:A subscrição foi encerrada porque o estado do recurso que sendo monitorado não maisexiste. Clientes NÃO DEVEM tentar subscrever de novo. O parâmetro"retry-after" não tem semântica para "noresource".

Uma vez que a notificação sejaconsiderada aceita pelo subscritor, o subscritor DEVE retornar uma resposta200. Em geral, não é esperado que respostas a NOTIFY vão conter corpos;contudo, elas PODEM conter, se a requisição NOTIFY continha um campo-cabeçalho"Accept".

Outras respostas definidas noSIP [1] podem também ser retornada, quando for apropriado. Em nenhum caso umatransação NOTIFY deve se estender por mais tempo que o necessário para oprocessamento automático. Em particular, os subscritores NÃO PODEM esperar poruma resposta de usuário antes de retornar uma resposta final a uma requisiçãoNOTIFY.

Roach                           Standards Track                           [Página 17]

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

Página 16
Tabela de Conteúdo
Página 18

RFC 3265 Portugues Pagina 18

2011-09-16T23:40:00.001-03:00

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

3.3. Geral

3.3.1. Detectando suporte paraSUBSCRIBE e NOTIFY

Nem SUBSCRIBE e nem NOTIFYnecessitam do uso de cabeçalhos "Require" ou"Proxy-Require"; de forma similar, não há token definido paracabeçalhos "Supported". Se for necessário, clientes podem sondar osuporte ao SUBSCRIBE e ao NOTIFY usando a requisição OPTIONS definida no SIP[1].

A presença do cabeçalho "Allow-Events"em uma mensagem é suficiente para indicar suporte ao SUBSCRIBE e ao NOTIFY.

O parâmetro"methods" em campo-cabeçalho Contact pode também ser usado para anunciar especificamente suporteàs mensagens SUBSCRIBE e NOTIFY ao se registrar. (Ver referência [8] para detalhessobre o parâmetro "methods").

3.3.2. Requisições CANCEL

Nenhuma semântica está associadaao cancelamento de SUBSCRIBE ou de NOTIFY.

3.3.3. Bifurcação

De acordo com as regras para proxy-iarrequisições não-INVITE conforme definido no SIP [1], requisições SUBSCRIBE bemsucedidas receberão apenas uma resposta de classe 200; contudo, devido àbifurcação, a subscrição pode ter sido aceita por múltiplos nó's. O subscritor PRECISAestar preparado para receber requisições NOTIFY com tag's em "From:"que difiram da tag em "To:" recebido na resposta de classe 200 ao SUBSCRIBE.

Se múltiplas mensagens NOTIFYforem recebidas em diálogos diferentes em resposta a uma mensagem SUBSCRIBEúnica, cada diálogo representa um destino diferente ao qual a requisiçãoSUBSCRIBE foi bifurcada. Para obter informações sobre a manipulação dosubscritor em tais situações, ver seção 4.4.9.

3.3.4. Criação e Términode Diálogo

Se uma requisição SUBSCRIBE inicialnão for enviada em um diálogo preexistente, o subscritor aguardará uma respostaà requisição SUBSCRIBE ou um NOTIFY correspondente.

Respostas são conferidas contratais requisições SUBSCRIBE se elas contiverem o mesmo "Call-ID", o mesmo"tag" no cabeçalho "From" e o mesmo "CSeq". Regraspara a comparação desses cabeçalhos estão descritas no SIP [1]. Se uma respostade classe 200 conferir com tal requisição SUBSCRIBE, ele gera uma nova subscriçãoe um novo diálogo (a menos que já tenham sido geradas por uma requisição NOTIFYcorrespondente; ver abaixo).

Roach                          Standards Track                           [Página 18]

http://tools.ietf.org/search/rfc3265#page-18

Página 17
Tabela de Conteúdo
Página 19

RFC 3265 Portugues Pagina 19

2011-09-16T23:35:00.002-03:00

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

Requisições NOTIFY sãocorrespondentes a tais requisições SUBSCRIBE se elas contiverem omesmo "Call-ID", um parâmetro "tag" no cabeçalho "To"que coincide com o parâmetro "tag" no cabeçalho "From"do SUBSCRIBE, e o mesmo campo-cabeçalho "Event". Regras paracomparações de cabeçalhos "Event" estão descritas na seção 7.2.1. Seuma requisição NOTIFY correspondente contiver um campo-cabeçalho "Subscription-State"com valor "active" ou "pending", gera-se umanova subscrição e um novo diálogo (a menos que já tenhamsido gerados por uma resposta correspondente, como descrito acima).

Se um SUBSCRIBE inicialfor enviado em um diálogo pré-existente, uma resposta de classe 200 correspondenteou uma requisição NOTIFY bem sucedida gera meramente umanova subscrição associada a esse diálogo.

Múltiplassubscrições podem ser associadas a um único diálogo. Subscrições podemtambém existir em diálogos associados a estado de aplicaçãocriado por INVITE e outros estados de aplicação criados por mecanismosdefinidos em outras especificações. Esses conjuntos de estado deaplicação não interagem além do comportamento descrito paraum diálogo (por exemplo, gerenciamento de conjunto de rotas).

Uma subscrição é destruída quandoum notificador envia uma requisição NOTIFY com cabeçalho"Subscription-State" igual a "terminated".

Um subscritor pode enviaruma requisição SUBSCRIBE contendo um cabeçalho "Expires"igual a 0 a fimde desencadear o envio de tal requisição NOTIFY; contudo,para os propósitos de subscrição e de vida do diálogo, a subscriçãonão é considerada encerrada até que o NOTIFY com um"Subscription-State" igual a "terminated" seja enviado.

Se a destruição de umasubscrição não deixa nenhum outro estado de aplicação associado ao diálogo,o diálogo termina. A destruição de outro estado de aplicação (comoo gerado por um INVITE) não encerrará o diálogo se uma subscrição aindaestiver associada a esse diálogo.

Note que o comportamentoacima significa que um diálogo criado com umINVITE não necessariamente termina após o recebimento deum BYE. De forma similar, no caso emque várias subscrições estão associadas a um único diálogo,o diálogo não termina até que todas as subscrições vinculadasao mesmo sejam destruídas.

3.3.5. Agentes de Estado eMigração de Notificador

Quando agentes deestado (ver seção 4.4.11) são usados, muitas vezes é útilpermitir a migração de subscrições entre os agentes de estado eos nó's para os quais eles estão fornecendo agregaçãode estado (ou mesmo entre vários agentes de estado). Talmigração pode ser efetuada ao enviar uma 

Roach                          Standards Track                           [Página 19]

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

Página 18
Tabela de Conteúdo
Página 20

RFC 3265 Portugues Pagina 20

2011-09-16T23:31:00.000-03:00

RFC 3265                Notificação deEvento Específico-SIP               Junho2002

mensagem NOTIFY contendo um cabeçalho"Subscription-State" igual a "terminated", e umparâmetro reason igual a "deactivated". Essa requisição NOTIFY é,do contrário, normal, e é formada conforme descrito na seção 3.2.2.

Após a recepção dessa mensagemNOTIFY, o subscritor DEVE tentar subscrever de novo (conformedescrito nas seções precedentes). Note que essa subscrição é estabelecidaem um novo diálogo, e ela não reusa o conjunto derota do diálogo da subscrição anterior.

A migração real é efetuada aofazer uma mudança na política (tais como decisões de roteamento) de um ou maisservidores aos quais a requisição SUBSCRIBE será enviada de modo que um nódiferente acaba respondendo a requisição SUBSCRIBE. Isso pode ser tão simples quantomudar a política local no notificador a partir do qual a subscrição estarámigrando de sorte que ele sirva como um servidor proxy ou servidor redirect emvez de um notificador.

Quando e por que executar ounão migrações de notificador pode ser descrito em pacotes-evento individuais; docontrário, tais decisões são uma questão de política local do notificador, esão deixados para implementações individuais.

3.3.6. Sondando o Estadode Recurso

Uma conseqüência natural docomportamento descrito nas seções precedentes é que uma busca imediata sem umasubscrição persistente pode ser efetuada ao enviar um SUBSCRIBE com um"Expires" igual a 0.

Claro, uma busca imediataenquanto uma subscrição está ativa pode ser efetuada ao enviar um SUBSCRIBE comum "Expires" igual ao número de segundos restantes na subscrição.

Após a recepção dessa requisiçãoSUBSCRIBE, o notificador (ou notificadores, se a requisição SUBSCRIBE forbifurcada) irá enviar uma requisição NOTIFY contendo o estado de recursos nomesmo diálogo.

Note que as mensagens NOTIFY disparadaspor mensagens SUBSCRIBE com cabeçalhos "Expires" igual a 0 vão conterum valor do campo-cabeçalho "Subscription-State" igual a "terminated",e um parâmetro "reason" igual a "timeout".

Sondagem deestado de evento pode causar significativo aumento de carga sobre a rede e sobre notificadores; como tal, deve somente serusada com moderação. Em particular, sondagem NÃO DEVE ser usada em circunstâncias em que resultarão tipicamente em mais mensagens na rede doque com subscrições de longa duração.

Roach                           Standards Track                           [Página 20]

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

Página 19
Tabela de Conteúdo
Página 21

RFC 3265 Portugues Pagina 21

2011-09-16T23:23:00.000-03:00

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

Quando a sondagem for usada,subscritores DEVEM tentar cachear credenciais de autenticação entre sondagenstanto quanto reduzir o número de mensagens enviadas.

3.3.7. Uso de cabeçalhoAllow-Events

O campo-cabeçalho "Allow-Events",se estiver presente, inclui uma lista de tokens que indica os pacotes-eventosuportados pelo cliente (se enviado em uma requisição) ou pelo servidor (seenviado em uma resposta). Em outras palavras, um nó ao enviar um cabeçalho"Allow-Events" está anunciando que ele pode processar requisiçõesSUBSCRIBE e gerar requisições NOTIFY para todos os pacotes-evento listadosnesse cabeçalho.

Qualquer nó que implementa umou mais pacotes-evento DEVE incluir um cabeçalho "Allow-Events" adequadopara indicar todos os eventos suportados em todos os métodos que iniciamdiálogos e suas respostas (como INVITE) e respostas ao OPTIONS.

Essa informação é muito útil,por exemplo, a fim de permitir aos agentes-usuários processarem os elementos dainterface especial de forma apropriada dependendo se os eventos exigidosimplementam ou não os recursos que eles representam são suportados pelos nó'sapropriados.

Note que cabeçalhos"Allow-Events" NÃO PODEM SER inseridos por proxy's.

3.3.8. Compatibilidade como PINT

O cabeçalho "Event" éconsiderado obrigatório para os propósitos desse documento. Contudo, a fim de mantercompatibilidade com o PINT (ver [2]), servidores PODEM interpretar uma requisiçãoSUBSCRIBE sem cabeçalho "Event" quando requisitando uma subscrição paraeventos PINT. Se um servidor não suporta PINT, ele DEVE retornar "489 BadEvent" em quaisquer mensagens SUBSCRIBE sem um campo-cabeçalho"Event".

4. Pacotes-Eventos

Essa seção cobre vários assuntosque devem ser levados em consideração quando pacotes-evento baseados emSUBSCRIBE e NOTIFY são propostos.

4.1. Aplicabilidade de Uso

Ao projetar um pacote-evento usandoos métodos descritos nesse documento para notificação de evento, é importanteconsiderar: O SIP é um mecanismo apropriado ao conjunto problema? O SIP estásendo selecionado por causa de alguma característica única fornecida peloprotocolo (por exemplo, mobilidade do usuário), ou meramente por que "issopode ser feito?" Se você mesmo descobriu 

Roach                           Standards Track                           [Página 21]

http://tools.ietf.org/search/rfc3265#page-21

Página 20
Tabela de Conteúdo
Página 22

RFC 3265 Portugues Pagina 22

2011-09-16T23:19:00.001-03:00

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

que definir pacotes-evento paranotificações relacionadas, por exemplo, com gerenciamento de rede ou com atemperatura no interior do motor do seu carro, você deve reconsiderar sua seleçãode protocolos.

Os interessados ​​em estendero mecanismo definido nesse documento são instados a seguir o desenvolvimento de"Diretrizes para autores de extensões ao SIP" [7] para obter maisorientações quanto aos usos adequados do SIP.

Além do mais, espera-se queesse mecanismo não deva ser usado em aplicações onde a freqüência de eventos reportadosseja excessivamente rápida (por exemplo, mais de uma vez por segundo). Uma redeSIP geralmente vai ser provisionada para um volume razoável de sinalização; enviaruma notificação toda vez que uma mudança na posição GPS do usuário porcentésimo de segundo pode facilmente sobrecarregar tal rede.

4.2. Pacotes-Evento Modelos

Pacotes-evento normais definemum conjunto de estados aplicáveis a um tipo específico de recurso, comopresença de usuário, estado da chamada e estados de troca de mensagens do mailbox.

Pacotes-evento modelos são um tipoespecial de pacote que define um conjunto de estados aplicáveis a outros pacotes,tais como estatísticas, política de acesso e listas de subscritor. Pacotes-modelode evento podem mesmo ser aplicáveis a outros pacotes-modelo de evento.

Para estender a analogiaorientada a objetos feita anteriormente, pacotes-evento modelos podem serpensados como pacotes modelados em C++ que precisam ser aplicáveis a outrospacotes para serem úteis.

O nome de um pacote-evento modeloquando aplicável a um pacote é formado anexando-se um ponto seguido pelo nome dopacote-evento modelo ao final do pacote. Por exemplo, se um pacote-modelo chamado"winfo" seria aplicado a um pacote chamado "presence", o token-eventousado nos cabeçalhos "Event" e "Allow-Events" seria"presence.winfo".

Pacotes-evento modelos precisamser definidos de tal forma que eles possam ser aplicáveis a qualquer pacotearbitrário. Em outras palavras, pacotes-evento modelos não podem ser especificamentevinculados a um ou alguns pacotes "pai" de tal forma que eles não viriama funcionar com outros pacotes.

4.3. Quantidade de Estadoa ser Transportado

Ao projetar pacotes-evento, éimportante considerar o tipo de informação que será transportada durante umanotificação.

Roach                           Standards Track                           [Página 22]

http://tools.ietf.org/search/rfc3265#page-22

Página 21
Tabela de Conteúdo
Página 23

RFC 3265 Portugues Pagina 23

2011-09-16T23:15:00.002-03:00

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

A tentação natural étransmitir meramente o evento (por exemplo, "uma nova mensagem de vozacabou de chegar"), sem acompanhamento de estado (por exemplo, "7mensagens de voz total"). Isso complica a implementação de entidades que subscrevem(já que eles precisam manter o estado completo da entidade para o qual sesubscreveu), e também é particularmente suscetível a problemas de sincronização.

Existem duas possíveis soluçõespara esse problema que pacotes-evento podem escolher implementar.

4.3.1. Informação Completade Estado

Para pacotes que tipicamente transmiteminformação de estado que é razoavelmente pequeno (na ordem de 1 kb aproximadamente),é sugestionado que pacotes-evento sejam projetados a fim de enviar informação completade estado quando um evento ocorrer.

Em algumas circunstâncias, transmitiro estado atual apenas pode ser insuficiente para uma classe particular de eventos.Nesses casos, os pacotes-evento devem incluir informação completa de estado juntocom o evento que ocorreu. Por exemplo, transmitir "nenhum representante deserviço ao cliente disponível" pode não ser tão útil quanto transmitir"nenhum representante de serviço ao cliente disponível; representante sip:46@cs.xyz.intacabou de fazer logoff".

4.3.2. Deltas do Estado

No caso de a informação de estadoser grande para ser transmitida, o pacote-evento pode escolher detalhar um esquemapelo qual mensagens NOTIFY contêm deltas de estado em vez de estado completo.

Tal esquema funcionaria daseguinte forma: qualquer NOTIFY enviado em resposta imediata a um SUBSCRIBEcontém informação completa de estado. Mensagens NOTIFY enviadas devido a umamudança de estado vão conter apenas informação de estado que sofreu alteração;o subscritor vai então mesclar essa informação em seu conhecimento atual sobreo estado do recurso.

Qualquer pacote-evento que suportadeltas de variação nos estados PRECISA incluir um número de versão que aumentaexatamente por um para cada transação NOTIFY em uma subscrição. Note que o númerode versão do estado aparece no corpo da mensagem, e não em um cabeçalho do SIP.

Se chegar um NOTIFY que tenhaum número de versão que é incrementado por mais de um, o subscritor sabe que umdelta estado foi perdido, mas ele ignora a mensagem NOTIFY que contém o deltaestado 

Roach                           Standards Track                           [Página 23]

http://tools.ietf.org/search/rfc3265#page-23

Página 22
Tabela de Conteúdo
Página 24

RFC 3265 Portugues Pagina 24

2011-09-16T23:12:00.000-03:00

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

(exceto para o número deversão, que ele mantém para detectar perda de mensagem), e reenvia um SUBSCRIBEpara forçar um NOTIFY que contém um instantâneo completo de estado.

4.4. Responsabilidades doPacote-Evento

Pacotes-evento não sãoobrigados a reiterar quaisquer dos comportamentos descritos nesse documento,embora eles possam optar por fazê-lo assim por clareza ou por ênfase. Em geral,porém, tais pacotes são esperados descrever apenas o comportamento que estendeou modifica o comportamento descrito nesse documento.

Note que algum comportamentodesignado usando "DEVE" ou "PRECISA" nesse documento não épermitido ser enfraquecido por documentos de extensão; contudo, tais documentospodem escolher reforçar os requisitos "DEVE" para a força do "PRECISA"se for exigido por sua aplicação.

Em adição as seções normaisesperadas nas RFC's em via de padronização e documentos de extensão ao SIP,autores de pacotes-evento necessitam abordar cada um dos assuntos detalhadosnas subseções a seguir, quando for aplicável.

4.4.1. Nome do Pacote-Evento

Essa seção, a qual PRECISA estarpresente, define o nome token a ser usado para designar o pacote-evento. Ela PRECISAincluir a informação que aparece nos registros do token no IANA. Para informaçãosobre como fazer registro de tais tipos, veja a seção 6.

4.4.2. Parâmetros doPacote-Evento

Se parâmetros devem ser usadosno cabeçalho "Event" para modificar o comportamento do pacote-evento,a sintaxe e semântica de tais cabeçalhos PRECISAM ficar claramente definidas.

4.4.3. Corpos de SUBSCRIBE

Espera-se que muitos, mas nem todos,os pacotes-evento irão definir sintaxe e semântica para os corpos de métodoSUBSCRIBE; esses corpos vão normalmente modificar, expandir, filtrar, estrangular,e/ou definir limiares para classe de eventos sendo requisitados. Projetistas depacotes-evento são fortemente encorajados a reusar tipos MIME existentes paracorpos de mensagens caso seja possível.

Roach                           Standards Track                           [Página 24]

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

Página 23
Tabela de Conteúdo
Página 25

RFC 3265 Portugues Pagina 25

2011-09-16T21:40:00.005-03:00

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

Essa seção que é obrigatóriade um pacote-evento define qual tipo ou tipos de corpos de evento são esperadosem requisições SUBSCRIBE(ou especifica que nenhum corpo de evento é esperado). Ela deve apontar para definiçõesdetalhadas de sintaxe e semântica para todos os tipos de corpos referenciados.

4.4.4. Duração daSubscrição 

É RECOMENDADO que pacotes-eventodêem uma faixa sugestiva de tempos considerados razoáveis para a duração de umasubscrição. Tais pacotes PRECISAM também definir um valor padrão de"Expires" para ser usado se nada for especificado.

4.4.5. Corpos de NOTIFY

O corpo de NOTIFY é usado parareportar o estado do recurso que é monitorado. Cada pacote PRECISA definir qualtipo ou tipos de corpos de evento são esperados em requisições NOTIFY. Taispacotes PRECISAM especificar ou citar especificações detalhadas para a sintaxe esemântica associada a tal corpo de evento.

Pacotes-evento também PRECISAMdefinir qual tipo MIME deve ser assumido se nada for especificado no cabeçalho"Accept" da requisição SUBSCRIBE.

4.4.6. Processamento de requisiçõesSUBSCRIBE no Notificador

Essa seção descreve oprocessamento a ser executado pelo notificador ao receber uma requisição SUBSCRIBE.Essa seção é obrigatória.

Informação nessa seção incluidetalhes de como autenticar subscritores e questões de autorização para o pacote.Tais questões de autorização podem incluir, por exemplo, se todas as requisiçõesSUBSCRIBE para esse pacote são aceitas respostas 202 (ver seção 5.2).

4.4.7. Geração de requisiçõesNOTIFY no Notificador

Essa seção de um pacote-eventodescreve o processo pelo qual o notificador gera e envia uma requisição NOTIFY.Isso inclui informação detalhada sobre quais eventos provocam um NOTIFY a ser enviado,como computar a informação de estado no NOTIFY; como gerar informação de estadoneutra ou falsa para ocultar atrasos de autorização e decisões de usuários, e sea informação de estado está completa ou deltas do estado para notificações; verseção 4.3. Essa seção é obrigatória.

Essa seção pode opcionalmentedescrever o comportamento usado para processar a resposta subseqüente.

Roach                           Standards Track                           [Página 25]

http://tools.ietf.org/search/rfc3265#page-25

Página 24
Tabela de Conteúdo
Página 26

RFC 3265 Portugues Pagina 26

2011-09-16T21:37:00.001-03:00

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

4.4.8. Processamento de requisiçõesNOTIFY no Subscritor

Essa seção de um pacote-eventodescreve 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 (sefor aplicável).

4.4.9. Tratamento de requisiçõesbifurcadas

Cada pacote-evento PRECISA especificarse 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" docabeçalho "Event") mas que não bate com o diálogo seria rejeitada comuma resposta 481. Note que a resposta de classe 200 ao SUBSCRIBE pode chegar apósum NOTIFY correspondente ser recebido; tais respostas podem não ser correlacionadasao mesmo diálogo estabelecido pelo NOTIFY. Exceto quando exigido para completara transação SUBSCRIBE, tais respostas de classe 200 não-correspondentes são ignoradas.

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

No caso de múltiplassubscrições serem permitidas, o pacote-evento PRECISA especificar se a fusãodas notificações para formar um único estado é exigida, e como tal fusão deveser realizada. Note que é possível que alguns pacotes-evento possam serdefinidos de tal forma que cada diálogo seja vinculado a um estado mutuamenteexclusivo que não seja afetado pelos outros diálogos; isso PRECISA ser claramenteindicado se for o caso.

4.4.10. Taxa de notificações

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

Cada pacote PODE definir ummecanismo estrangulador adicional que permite aos subscritores limitar mais a taxade notificação.

Roach                          Standards Track                           [Página 26]

http://tools.ietf.org/search/rfc3265#page-26

Página 25
Tabela de Conteúdo
Página 27

RFC 3265 Portugues Pagina 27

2011-09-16T21:33:00.003-03:00

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

4.4.11. Agentes de Estado

Projetos de pacotes-eventodevem considerar se seu pacote pode se beneficiar de pontos de agregação derede (agentes de estado) e/ou se nó's que agem em nome de outros nó's. (Porexemplo, nó's que fornecem informação de estado sobre um recurso quando talrecurso for incapaz ou indisposto a fornecer tal informação de estado por sipróprio). Um exemplo de tal aplicação é um nó que rastreia a presença edisponibilidade de um usuário na rede.

Se agentes de estado devem serusados pelo pacote, o pacote PRECISA especificar como tais agentes de estado deinformações agregadas e como eles fornecem autenticação e autorização.

Pacotes-evento PODEM também descrevercenários específicos sob quais migrações de notificador acontece.

4.4.12. Exemplos

Pacotes-evento DEVEM incluir váriosdiagramas demonstrativos de fluxo de mensagens emparelhados com várias mensagenstípicas, sintaticamente corretas e completas.

É RECOMENDADO que documentos quedescrevem pacotes-evento indiquem claramente que tais exemplos são informativose não normativos, com instruções para os implementadores consultarem o texto principaldo documento para detalhes exatos do protocolo.

4.4.13. Uso de URI's para RecuperarEstado

Alguns tipos de pacotes-eventopodem definir informação de estado que é potencialmente muito grande paraenviar razoavelmente uma mensagem SIP. Para aliviar esse problema, pacotes-eventopodem incluir a capacidade de transmitir um URI em vez de informação de estado;esse URI será então usado para recuperar a informação de estado real.

Os mecanismos precisos para transportartais URI's estão fora do escopo desse documento.

Roach                           Standards Track                           [Página 27]

http://tools.ietf.org/search/rfc3265#page-27

Página 26
Tabela de Conteúdo
Página 28

RFC 3265 Portugues Pagina 28

2011-09-16T21:29:00.000-03:00

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

5. Considerações de Segurança

5.1. Controle de Acesso

A capacidade de aceitarsubscrições deve estar sob o controle direto do usuário do notificador, porquemuitos tipos de eventos podem ser considerados sensíveis para os propósitos deprivacidade. De forma similar, o notificador deve ter a capacidade pararejeitar seletivamente subscrições baseados na identidade do subscritor (baseadoem listas de controle de acesso), usando os mecanismos de autenticação padrãodo SIP. Os métodos para criação e distribuição de tais listas de controle deacesso estão fora do escopo desse documento.

5.2. Mecanismo de Privacidadedo Notificador

O mero ato de retornar uma resposta200 ou certas respostas 4xx e 6xx às requisições SUBSCRIBE podem, em certascircunstâncias, criar preocupações quanto à privacidade ao revelar informações sensíveisde política. Nesses casos, o notificador DEVE sempre retornar uma resposta 202.Enquanto a mensagem NOTIFY subseqüente não pode transmitir o estado verdadeiro,ela PRECISA parecer conter potencialmente um pedaço correto de dados a partirdo ponto de vista do subscritor, não distinguível de uma resposta válida. Informaçãosobre se um usuário está ou não autorizado a subscrever ao estado requisitado nuncaé transmitida de volta ao usuário original nessas circunstâncias.

Para que tal modo de operaçãofaça sentido, pacotes individuais e seus documentos relacionados podem aindadescrever mais como e por que gerar esses dados potencialmente corretos. Porexemplo, tal modo de operação é obrigatório pela RFC 2779 [6] para informaçõesde presença de usuário.

5.3. Ataques deNegação-de-Serviço

O modelo atual (uma requisiçãoSUBSCRIBE dispara uma resposta ao SUBSCRIBE e um ou mais requisições NOTIFY) é umaconfiguração clássica para um nó amplificador a ser usado em um ataque smurf.

Também, a criação de estado aoreceber uma requisição SUBSCRIBE pode ser usada por atacantes para consumir recursosde uma máquina vítima, tornando-o inutilizável.

Para reduzir as chances de talataque, as implementações de notificadores DEVEM exigir autenticação. Questõesde autenticação são discutidas no SIP [1].

Roach                           Standards Track                           [Página 28]

http://tools.ietf.org/search/rfc3265#page-28

Página 27
Tabela de Conteúdo
Página 29

RFC 3265 Portugues Pagina 29

2011-09-16T21:24:00.001-03:00

RFC3265                Notificação deEvento Específico-SIP               Junho2002

5.4. Ataques de Repetição

Repetições tanto de SUBSCRIBE quantode NOTIFY podem ter efeitos negativos.

No caso de mensagensSUBSCRIBE, atacantes podem conseguir instalar qualquer subscrição arbitráriaque eles viram ser instalada em algum instante passado. Repetição de mensagensNOTIFY pode ser usado para adulterar informação antiga de estado (embora um bommecanismo de versionamento no corpo das mensagens NOTIFY possa ajudar a mitigartal ataque). Note que a proibição de envio de mensagens NOTIFY a nó's que não tenhamsubscritos a um evento também ajuda a atenuar os efeitos de tal ataque.

Para evitar tais ataques,implementações DEVEM exigir autenticação com proteção anti-repetição. Questõesde autenticação são discutidas no SIP [1].

5.5. Ataques man-in-the-middle

Mesmo com autenticação,ataques man-in-the-middle usando SUBSCRIBE podem ser usados para instalarsubscrições arbitrárias, seqüestrar subscrições existentes, encerrarsubscrições pendentes ou modificar o recurso ao qual uma subscrição estámonitorando. Para prevenir tais ataques, implementações DEVEM fornecer proteçãoa integridade aos cabeçalhos "Contact", "Route","Expires", "Event" e "To" em mensagens SUBSCRIBE, nomínimo. Se corpos de SUBSCRIBE são usados para definir informação adicionalsobre o estado da chamada, eles DEVEM ser incluídos no regime de proteção deintegridade.

Ataques man-in-the-middle podemtambém tentar usar mensagens NOTIFY para adulterar informação de estadoarbitrário e/ou encerrar subscrições pendentes. Para prevenir tais ataques,implementações DEVEM fornecer proteção de integridade aos cabeçalhos "Call-ID","CSeq" e "Subscription-State" e corpos de mensagens NOTIFY.

Proteção a integridade decabeçalhos e corpos de mensagens é discutido no SIP [1].

5.6. Confidencialidade

A informação de estado contidaem uma mensagem NOTIFY tem potencial de conter informação sensível.Implementações PODEM encriptar tal informação para garantir aconfidencialidade.

Embora menos provável, étambém possível que a informação contida em uma mensagem SUBSCRIBE contenhainformação que usuários podem não querer que seja revelada. ImplementaçõesPODEM encriptar essa informação para garantir a confidencialidade.

Roach                           Standards Track                           [Página 29]

http://tools.ietf.org/search/rfc3265#page-29

Página 28
Tabela de Conteúdo
Página 29

RFC 3265 Portugues Pagina 30

2011-09-16T21:20:00.000-03:00

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

Para permitir a parte remota ocultarinformação que ela considera sensível, todas as implementações DEVEM ser capazesde tratar mensagens SUBSCRIBE e NOTIFY encriptadas.

Os mecanismos para fornecer confidencialidadesão detalhados no SIP [1].

6. Considerações sobreregistros no IANA 

Esse documento define umespaço de nome para tipo de evento que exige um organismo central decoordenação. O organismo escolhido para essa coordenação é o Internet AssignedNumbers Authority (IANA).

Existem dois tipos diferentesde event-type: pacotes-evento normais e pacotes-evento modelos; ver a seção4.2. Para evitar confusão, nomes de pacote-modelo e nomes de pacote compartilhamo mesmo espaço de nome; em outras palavras, um pacote-evento modelo NÃO PODE compartilharum nome com um pacote.

Seguindo as políticas descritasem "Orientações para Escrever uma Seção Considerações sobre o IANA em RFC's"[4], tokens de identificação de pacote-evento normal são alocados conforme Primeiroa chegar Primeiro Servido e tokens de identificação de pacote-evento modelo sãoalocados com base em Consenso do IETF.

Registros no IANA PRECISAMincluem o token sendo registrado e se o token é um pacote ou um pacote-modelo. Alémdo mais, pacotes PRECISAM incluir informação de contato da parte responsávelpelo registro e/ou um por documento publicado que descreve o pacote-evento. Registrosde token do pacote-evento modelo PRECISAM incluir um ponteiro para a RFC publicadaque define o package-evento modelo.

Tokens registrados paradesignar pacotes e pacotes-modelo NÃO PODEM ter o caractere ".", porqueé usado para separar pacotes-modelo de pacotes normais.

6.1. Informação de Registro

Como esse documento não especificanenhum nome de pacote ou de pacote-modelo, o registro no IANA inicial para tiposde evento será vazio. O restante do texto nessa seção fornece um exemplo do tipode informação a ser mantido no IANA; ele também demonstra todas as cinco possíveispermutações de tipo de pacote, contato, e referência.

A tabela abaixo lista os pacotes-eventoe pacotes-modelo definidos em "Notificação de Evento Específico - SIP"[RFC3265]. Cada nome é designado como um pacote ou um pacote-modelo sob"Type".

Roach                           Standards Track                           [Página 30]

http://tools.ietf.org/search/rfc3265#page-30

Página 29
Tabela de Conteúdo
Página 31

RFC 3265 Portugues Pagina 31

2011-09-16T21:12:00.004-03:00

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

Package Name      Type         Contact      Reference
------------      ----         -------      ---------
example1          package      [Roach]
example2          package      [Roach]      [RFC3265]
example3          package                   [RFC3265]
example4          template     [Roach]      [RFC3265]
example5          template                  [RFC3265]

PEOPLE
------
[Roach] Adam Roach 

REFERENCES
----------
[RFC3265] Roach, A., "Notificaçãode Evento Específico - SIP", RFC 3265, 
Junho 2002.

6.2. Modelo de Registro

To: ietf-sip-events@iana.org
Subject: Registration of new SIP event package

Nome de Pacote:

(Nomes de pacote precisamconformar com a sintaxe descrita na seção 7.2.1.)

Esse registro é para um PacoteModelo?:

(indica sim ou não)

Especificações Publicadas:

(Pacotes modelo exigem uma RFCpublicada. Outros pacotes podem referenciar uma especificação quando apropriado).

Pessoa & endereço de emaila contatar para mais informação:

6.3. Nomes deCampos-Cabeçalhos

Esse documento registra três novosnomes de campo-cabeçalho, descrito em outro lugar nesse documento. Esses cabeçalhossão definidos pela seguinte informação, que deve ser adicionado ao sub-registrodo cabeçalho em http://www.iana.org/assignments/sip-parameters.

Header Name:  Allow-Events
Compact Form: u

Roach                           Standards Track                           [Página 31]

http://tools.ietf.org/search/rfc3265#page-31

Página 30
Tabela de Conteúdo
Página 32

RFC 3265 Portugues Pagina 32

2011-09-16T21:07:00.001-03:00

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


Header Name:  Subscription-State
Compact Form: (none)

Header Name:  Event
Compact Form: o


6.4. Códigos de Resposta

Esse documento registra dois novoscódigos de resposta. Esses códigos-resposta são definidos pela seguinte informação,que deve ser adicionada ao sub-registro do método e código-resposta sob http://www.iana.org/assignments/sip-parameters.

Response Code Number:   202
Default Reason Phrase:  Accepted

Response Code Number:   489
Default Reason Phrase:  Bad Event


7. Sintaxe

Essa seção descreve as extensõespara a sintaxe exigida para notificação de evento no SIP. A semântica é descritana seção 3. Note que as definições da sintaxe formal descritas nesse documento sãoexpressas no formato ABNF usado no SIP [1], e contém referências a elementosdefinidos aqui.


7.1. Novos Métodos

Esse documento descreve dois novosmétodos para o SIP: SUBSCRIBE e NOTIFY.

Essa tabela expande as tabelas2 e 3 do SIP [1].

Cabeçalho                  Onde   SUB NOT
------                    -----    --- ---
Accept                      R       o  o
Accept                     2xx      -  -
Accept                     415      o  o
Accept-Encoding             R       o  o
Accept-Encoding            2xx      -  -
Accept-Encoding            415      o  o
Accept-Language             R       o  o
Accept-Language            2xx      -  -
Accept-Language            415      o  o
Alert-Info                  R       -  -
Alert-Info                 180      -  -
Allow                       R       o  o



Roach                           Standards Track                           [Página 32]


http://tools.ietf.org/search/rfc3265#page-32



Página 31
Tabela de Conteúdo
Página 33

RFC 3265 Portugues Pagina 33

2011-09-16T21:02:00.001-03:00

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


Allow                      2xx      o  o
Allow                       r       o  o
Allow                      405      m  m
Authentication-Info        2xx     o   o
Authorization               R       o  o
Call-ID                    c       m  m
Contact                     R       m  m
Contact                    1xx      o  o
Contact                    2xx      m  o
Contact                    3xx      m  m
Contact                    485      o  o
Content-Disposition                 o   o
Content-Encoding                    o   o
Content-Language                    o   o
Content-Length                      t   t
Content-Type                        *   *
CSeq                        c       m  m
Date                                o   o
Error-Info               300-699    o   o
Expires                             o   -
Expires                    2xx      m  -
From                        c       m  m
In-Reply-To                 R       -  -
Max-Forwards                R      m   m
Min-Expires                423      m  -
MIME-Version                        o   o
Organization                        o   -
Priority                    R       o  -
Proxy-Authenticate         407      m  m
Proxy-Authorization         R      o   o
Proxy-Require               R       o  o
RAck                        R       -  -
Record-Route                R       o  o
Record-Route           2xx,401,484  o   o
Reply-To                            -   -
Require                             o   o
Retry-After        404,413,480,486  o   o
Retry-After              500,503    o   o
Retry-After              600,603    o   o
Route                       R       c  c
RSeq                       1xx      o  o
Server                      r       o  o
Subject                     R       -  -
Supported                   R       o  o
Supported                  2xx      o  o
Timestamp                           o   o
To                         c(1)     m  m
Unsupported                420      o  o



Roach                           Standards Track                           [Página 33]


http://tools.ietf.org/search/rfc3265#page-33



Página 32
Tabela de Conteúdo
Página 34

RFC 3265 Portugues Pagina 34

2011-09-16T20:54:00.004-03:00

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

User-Agent                          o   o
Via                         c       m   m
Warning                     R       -  o
Warning                     r       o  o
WWW-Authenticate           401      m  m

7.1.1. Método SUBSCRIBE

O "SUBSCRIBE" é adicionadoà definição do elemento "Método" na gramática de mensagem do SIP.

Como todos os nomes de métododo SIP, o nome SUBSCRIBE para o método precisa ser maiúsculo. O método SUBSCRIBEé usado para requisitar notificação assíncrona de um evento ou conjunto deeventos posteriores.

7.1.2. Método NOTIFY

O "NOTIFY" é adicionadoà definição do elemento "Método" na gramática de mensagem do SIP.

O método NOTIFY é usado paranotificar um nó SIP que um evento ocorreu que foi requisitado anteriormente porum método SUBSCRIBE. Ele pode também fornecer mais detalhes sobre o evento.

7.2. Novos Cabeçalhos

Essa tabela expande as tabelas2 e 3 do SIP [1], conforme emendada pelas mudanças descritas na seção 7.1.

Campo-cabeçalho   onde proxy ACK BYE CAN INV OPT REG PRA SUBNOT
-----------------------------------------------------------------
Allow-Events        R          o  o   -   o  o   o   o  o   o
Allow-Events       2xx         -  o   -   o  o   o   o  o   o
Allow-Events       489         -  -   -   -  -   -   -  m   m
Event               R          -  -   -   -  -   -   -   m   m
Subscription-State  R         -   -   -   -   -  -   -   -   m

7.2.1. Cabeçalho"Event"

O campo-cabeçalho Event é adicionadoà definição do elemento "message-header" na gramática de mensagem doSIP.

Para os propósitos de baterrespostas e mensagens NOTIFY com mensagens SUBSCRIBE, a porção event-type docabeçalho "Event" é comparado byte-a-byte, e o token do parâmetro "id"(se estiver presente) é comparado byte-a-byte. Um cabeçalho "Event" quecontém um parâmetro "id" nunca bate com um cabeçalho "Event"sem um parâmetro "id". Nenhum outro parâmetro é considerado quando seexecuta uma comparação.

Roach                           Standards Track                           [Página 34]

http://tools.ietf.org/search/rfc3265#page-34

Página 33
Tabela de Conteúdo
Página 35

RFC 3265 Portugues Pagina 35

2011-09-16T20:49:00.001-03:00

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

Note que conforme o texto precedentesignifica que "Event: foo; id=1234" corresponderia a "Event:foo; param=abcd; id=1234", mas não ia conferir com "Event: foo"(id não bate) e nem com "Event: Foo; id=1234" (pois, a porção evento nãoconfere).

Esse documento não definevalores para tipos de evento. Esses valores serão definidos por pacotes-eventoindividuais, e PRECISAM ser registrados no IANA.

PRECISA haver exatamente umtipo de evento listado por cabeçalho Event. Múltiplos eventos por mensagem são desaprovados.

7.2.2. Cabeçalho"Allow-Events"

O campo-cabeçalho Allow-Eventsé adicionado à definição do elemento "general-header" na gramática demensagem do SIP. Seu uso é descrito na seção 3.3.7.

7.2.3. Cabeçalho"Subscription-State"

O campo-cabeçalho Subscription-Stateé adicionado à definição do elemento "request-header" na gramática demensagem do SIP. Seu uso é descrito na seção 3.2.4.

7.3. Novos Códigos deResposta

7.3.1. Código Resposta"202 Accepted"

A resposta 202 é adicionada à definiçãodo campo-cabeçalho "Success". A resposta "202 Accepted" temo mesmo significado daquele que é definido no HTTP/1.1 [3].

7.3.2. Código Resposta"489 Bad Event"

A resposta de evento 489 éadicionada à definição do campo-cabeçalho "Client-Error". A resposta "489Bad Event" é usada para indicar que o servidor não entendeu o pacote-eventoespecificado em um campo-cabeçalho "Event".

7.4. Definições AugmentedBNF (ABNF)

As definições ABNF para os várioselementos novos e sintaxe modificada estão a seguir. A notação é conforme usadono SIP [1], e quaisquer elementos não definidos nessa seção estão conformedefinidos no SIP e os documentos aos quais se referem.

SUBSCRIBEm        = %x53.55.42.53.43.52.49.42.45 ;SUBSCRIBE em maiúscula
NOTIFYm           = %x4E.4F.54.49.46.59 ; NOTIFY emmaiúscula
extension-method  = SUBSCRIBEm / NOTIFYm / token

Roach                           Standards Track                           [Página 35]

http://tools.ietf.org/search/rfc3265#page-35

Página 34
Tabela de Conteúdo
Página 36

RFC 3265 Portugues Pagina 36

2011-09-16T20:40:00.000-03:00

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


   Event             = ( "Event" / "o" ) HCOLON event-type
                        *( SEMI event-param )
   event-type        = event-package *( "." event-template )
   event-package     = token-nodot
   event-template    = token-nodot
   token-nodot       = 1*( alphanum / "-"  /"!" / "%" / "*"
                            / "_" /"+" / "`" / "'" / "~" )
   event-param       = generic-param / ( "id" EQUAL token )

   Allow-Events =  ( "Allow-Events" / "u" )HCOLON event-type
                   *(COMMA event-type)

   Subscription-State   = "Subscription-State" HCOLONsubstate-value
                          *( SEMI subexp-params)
   substate-value       = "active" /"pending" / "terminated"
                          / extension-substate
   extension-substate   = token
   subexp-params        =  ("reason" EQUAL event-reason-value)
                          /("expires" EQUAL delta-seconds)
                          /("retry-after" EQUAL delta-seconds)
                          / generic-param
   event-reason-value   =  "deactivated"
                          /"probation"
                          /"rejected"
                          / "timeout"
                          / "giveup"
                          / "noresource"
                          /event-reason-extension
   event-reason-extension = token


8. Referências Normativas

[1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler,"SIP:
Session Initiation Protocol", RFC 3261,June 2002.

[2]  Petrack, S. and L. Conroy, "The PINT Service Protocol", RFC
2848, June 2000.

[3]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "HypertextTransfer Protocol --
HTTP/1.1", RFC 2616, June 1999.

[4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26,RFC 2434, October 1998.





Roach                           Standards Track                           [Página 36]


http://tools.ietf.org/search/rfc3265#page-36



Página 35
Tabela de Conteúdo
Página 37

RFC 3265 Portugues Pagina 37

2011-09-16T20:33:00.000-03:00

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

[5]  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[6]  Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant
Messaging/Presence Protocol Requirements",RFC 2779, February 2000.

9. Referências Informativas 

[7]  Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of
SIP Extensions", Work in Progress.

[8]  Schulzrinne, H. and J. Rosenberg, "SIP Caller Preferences and
Callee Capabilities", Work in Progress.

10. Agradecimentos

Agradeço aos participantes nosEventos BOF no 48a Encontro IETF em Pittsburgh, bem como aqueles que deramidéias e sugestões na lista de discussão dos Eventos SIP. Em particular, Eu gostariade agradecer a Henning Schulzrinne da Universidade de Columbia por propor oesquema final de identificação de evento em três níveis, Sean Olson pelasdiversas orientações, Jonathan Rosenberg pela depuração minuciosa do draft -00;e os autores do documento "Extensões SIP para Presença" por seuscontributos a semântica de requisições SUBSCRIBE e NOTIFY.

11. Aviso Sobre Direitosde Propriedade Intelectual

O IETF tem sido notificado dedireitos de propriedade intelectual reivindicado no que diz respeito a algumasou todas as especificações contidas nesse documento. Para obter maisinformações consultar a lista de direitos reclamados em http://www.ietf.org/ipr.html.

12. Endereço do Autor

Adam Roach
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
EMail: adam@dynamicsoft.com
Voice: sip:adam@dynamicsoft.com

Roach                           Standards Track                           [Página 37]

http://tools.ietf.org/search/rfc3265#page-37

Página 36
Tabela de Conteúdo
Página 38

RFC 3265 Portugues Pagina 38

2011-09-16T20:25:00.000-03:00

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

13. Declaração Completa deDireitos Autorais

Direitos Autorais (C) DaInternet Society (2002). Todos os Direitos Reservados.

Esse documento e suastraduções podem ser copiados e fornecidos a outros, e trabalhos derivados quecomentem ou que de outra forma explique-o ou ajude na sua implementação podemser preparados, copiados, publicados e distribuídos, no todo ou em parte, semrestrições de qualquer tipo, desde que o aviso de direitos autorais acima eeste parágrafo sejam incluídos em todas as cópias e obras derivadas. Contudo,esse documento em si não pode ser modificado de hipótese alguma, tal comoremover o aviso de direitos autorais ou referências à Internet Society ououtras organizações da Internet, exceto quando for necessário com o propósitode desenvolvimento de Padronizações Internet, caso em que os procedimentos paradireitos autorais definidos no processo de Padronizações da Internet precisamser seguidos, ou quando exigido para traduzi-la para outros idiomas além doInglês.

As permissões concedidas com aslimitações acima são perpétuas e não serão revogadas pela Internet Society ouseus sucessores ou procuradores.

Esse documento e asinformações contidas aqui são fornecidos em uma base "COMO SÃO" e AINTERNET SOCIETY E O INTERNET ENGINEERING TASK FORCE (IETF) EXIME-SE A TODAS ASGARANTIAS, EXPRESSAS OU DECORRENTES, INCLUINDO, MAS NÃO LIMITADAS A QUALQUERGARANTIA QUE O USO DAS INFORMAÇÕES AQUI NÃO VAI INFRIGIR QUAISQUER DIREITOS OUQUAISQUER GARANTIAS DECORRENTES DA COMERCIALIZAÇÃO OU ADEQUAÇÃO PARA UMAFINALIDADE PARTICULAR.

Reconhecimento

A função de Editor de RFC éatualmente financiada pela Internet Society.

Roach                          Standards Track                           [Página 38]

http://tools.ietf.org/search/rfc3265#page-38

Página 37
Tabela de Conteúdo

RFC 3312 Portugues Pagina 1

2011-09-04T14:43:00.000-03:00

Grupo de Trabalho Rede                                         G. Camarillo, Ed.
Request for Comments: 3312                                              Ericsson
Categoria: Standards Track                                      W. Marshall, Ed.
                                                                            AT&T
                                                                    J. Rosenberg
                                                                     dynamicsoft
                                                                    Outubro 2002

 Integração de Gerenciamento Recurso 
e 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 define uma infra-estrutura geral para pré-condições, que são extensíveis através de registro no IANA. Esse documento também aborda como qualidade de serviço na rede pode ser realizada com pré-condição para estabelecimento de sessões iniciadas pelo SIP. Essas pré-condições exigem que o participante reserve recursos de rede antes de continuar a sessão. Nós não definimos novos mecanismos para reservar QoS; essas precondições simplesmente exigem a um participante usar os mecanismos de reserva de recurso existentes antes de iniciar a sessão.

Camarillo, et. al.                 Standards Track                     [Página 1]

Página Original:
http://tools.ietf.org/search/rfc3312#page-1

Tabela de Conteúdo
Página 2

Observação:
  Modelo 'offer/answer' do documento original em inglês foi traduzido para o
  português como: modelo oferta-aceite.

RFC 3312 Portugues Pagina 2

2011-09-04T14:27:00.000-03:00

RFC 3312       Integração de Gerenciamento de Recurso e o SIP        Outubro 2002


Tabela de Conteúdo

   1 Introdução .....................................................  2
   2 Terminologia ...................................................  3
   3 Visão geral ....................................................  3
   4 Parâmetros SDP .................................................  4
   5 Uso de precondições com oferta-aceite ..........................  7
   5.1 Gerando uma oferta ...........................................  8
   5.1.1 Codificando o SDP ..........................................  9
   5.2 Gerando um Aceite ............................................ 10
   6 Suspendendo e Retomando o Estabelecimento de Sessão ............ 11
   7 Confirmação de Status .......................................... 12
   8 Recusando uma oferta ........................................... 13
   8.1 Rejeitando um Fluxo de Media ................................. 14
   9 Tipo Precondição Não Conhecido ................................. 15
   10 Múltiplas Precondições por Fluxo de Media ..................... 15
   11 Tag Opção para Precondições ................................... 16
   12 Indicando Capacidades ......................................... 16
   13 Exemplos ...................................................... 16
   13.1 Tipo Status fim-a-fim ....................................... 17
   13.2 Tipo Status Segmentado ...................................... 21
   13.3 Oferta em uma resposta SIP .................................. 23
   14 Considerações de Segurança .................................... 26
   15 Considerações do IANA ......................................... 26
   16 Aviso Sobre Direitos de Propriedade Intelectual ............... 27
   17 Referências ................................................... 27
   18 Contribuidores ................................................ 28
   19 Agradecimentos ................................................ 28
   20 Endereços dos Autores ......................................... 29
   21 Declaração Completa de Direitos Autorais ...................... 30



1 Introdução

Algumas arquiteturas exigem que no instante do estabelecimento de uma sessão, uma vez a parte chamada tenha sido alertada, as chances de falha no estabelecimento de sessão são mínimas. Uma fonte de falhas é a incapacidade em reservar recursos de rede para uma sessão. A fim de minimizar "rings fantasmas", é necessário reservar recursos de rede para sessão antes da parte chamada ser alertada. No entanto, reservar recursos de rede freqüentemente exige aprender o endereço IP, porta e parâmetros de sessão da parte chamada. Essa informação é obtida como resultado da troca inicial oferta-aceite transportada no SIP. Essa troca normalmente faz o "telefone tocar", portanto introduzindo o problema da galinha e ovo: recursos não podem ser reservados sem fazer uma troca oferta-aceite inicial, e a troca oferta-aceite inicial não pode ser feita sem fazer a reserva de recursos.







Camarillo, et. al.                 Standards Track                     [Página 2]


Página Original:
http://tools.ietf.org/search/rfc3312#page-2



Página 1
Tabela de Conteúdo
Página 3



Observação:
  Modelo 'offer/answer' do documento original em inglês foi traduzido para o 
  português como: modelo oferta-aceite.

RFC 3312 Portugues Pagina 3

2011-09-04T14:14:00.000-03:00

RFC 3312        Integração de Gerenciamento de Recurso e o SIP       Outubro 2002

A solução é introduzir o conceito de pré-condição. Uma pré-condição é um conjunto de restrições à sessão que é introduzida na oferta. O receptor da oferta gera um aceite, mas não alertar o usuário ou, ao contrário, prossegue estabelecendo a sessão. Essa somente ocorre quando as pré-condições são satisfeitas. Isso pode ser conhecido através de um evento local (como uma confirmação de reserva de recursos), ou através de uma nova oferta enviada pela parte chamante.

Esse documento lida com sessões que usam o SIP [1] como um protocolo de sinalização e o SDP [2] como o mecanismo para descrever os parâmetros da sessão.

Nós escolhemos incluir as precondições para qualidade de serviço na descrição do SDP em vez de incluí-las no cabeçalho SIP porque essas pré-condições são específicas de stream.

2 Terminologia

As palavras-verbos chaves "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" nesse documento devem ser interpretados conforme descrito na BCP 14, RFC 2119 [3].

Veja aqui no blog tradução da RFC 2119.

3 Visão geral

A fim de garantir que o estabelecimento de sessão não ocorra até que sejam satisfeitas certas pré-condições, nós distinguiremos entre duas diferentes variáveis ​​de estado que afetam o fluxo de mídia particular: estado atual e estado desejado. Este documento define o status de qualidade de serviço.

O status desejado consiste de um limiar do status atual. O estabelecimento de sessão pára até que o status atual seja atingido ou ultrapassado esse limiar. Uma vez que esse limiar é atingido ou ultrapassado, o estabelecimento da sessão é retomado.

Por exemplo, os valores seguintes para status atual e desejado não permitiram retomar o estabelecimento de sessão:

current status = recursos reservados na direção send
desired status = recursos reservados em ambas as direções (sendrecv)

Por outro lado, os valores do exemplo abaixo fariam retomar o estabelecimento de sessão:

current status = recursos reservados em ambas as direções (sendrecv)
desired status = recursos reservados na direção send

Camarillo, et. al.                 Standards Track                     [Página 3]

Página Original:
http://tools.ietf.org/search/rfc3312#page-3

Página 2
Tabela de Conteúdo
Página 4

Observação:
  Modelo 'offer/answer' do documento original em inglês foi traduzido para o
  português como: modelo oferta-aceite.

RFC 3312 Portugues Pagina 4

2011-09-04T14:08:00.000-03:00

RFC 3312        Integração de Gerenciamento de Recurso e o SIP       Outubro 2002

Essas duas variáveis ​​de estado definem certa parte de estado de um fluxo de mídia no mesmo sentido do atributo direction ou os codec's em uso definir outras partes de estado. Conseqüentemente, nós tratamos essas duas novas variáveis ​​da mesma forma que outros atributos SDP de mídia são tratados no modelo oferta/aceite usado pelo SIP [4]: eles são trocados entre dois agentes-usuários usando uma oferta e um aceite, a fim de ter uma visão partilhada do status da sessão.

A figura 1 mostra uma troca de mensagem típica entre dois agentes-usuários SIP usando precondições. O agente A inclui precondições para qualidade de serviço no SDP do INVITE inicial. O agente A não quer que B seja alertado até que haja reservados os recursos de rede em ambas as direções (sendrecv) fim a fim. O agente B concorda em reservar recursos de rede para essa sessão antes de alertar a parte chamada. O agente B vai cuidar da reserva de recurso na direção B->A, mas precisa A tratar a direção A->B. Para indicar isso, B retorna uma resposta 183 (Session Progress) para A pedindo que A faça a reserva de recurso e confirmar para B tão logo a direção A->B esteja pronta para a sessão. Ambos A e B fazem a reserva de recurso. O agente B completa a reserva de recursos na direção B->A, mas não alerta o usuário ainda, porque os recursos de rede em ambas as direções são necessários. Quando A completa a reserva de recursos na direção A->B, envia um UPDATE [5] para B. B retorna uma resposta 200 (OK) ao UPDATE, indicando que todas as pré-condições para a sessão têm sido satisfeitas. Nesse ponto no tempo, B alerta o usuário, e o estabelecimento de sessão se completa normalmente.

4 Parâmetros do SDP

Nós definimos os seguintes atributos SDP ao nível de mídia:

current-status     =  "a=curr:" precondition-type
                      SP status-type SP direction-tag
desired-status     =  "a=des:" precondition-type
                      SP strength-tag SP status-type
                      SP direction-tag
confirm-status     =  "a=conf:" precondition-type
                      SP status-type SP direction-tag
precondition-type  =  "qos" | token
strength-tag       =  ("mandatory" | "optional" | "none"
                   =  | "failure" | "unknown")
status-type        =  ("e2e" | "local" | "remote")
direction-tag      =  ("none" | "send" | "recv" | "sendrecv")

Current status: O atributo current-status transporta o status atual dos recursos de rede para um fluxo de mídia particular.

Camarillo, et. al.                 Standards Track                     [Página 4]

Página Original:
http://tools.ietf.org/search/rfc3312#page-4

Página 3
Tabela de Conteúdo
Página 5

Observação:
  Modelo 'offer/answer' do documento original em inglês foi traduzido para o
  português como: modelo oferta-aceite.

RFC 3312 Portugues Pagina 5

2011-09-04T13:59:00.000-03:00

RFC 3312        Integração de Gerenciamento de Recurso e o SIP       Outubro 2002

Desired status: O atributo desired-status transporta as precondições para um fluxo de mídia particular. Quando o direction-tag do atributo status atual, com uma dada precondition-type/status-type para um fluxo particular for igual ao (ou melhor que) direction-tag do atributo status desejado com a mesma precondition-type/status-type, para esse fluxo, então as precondições são consideradas ser satisfeitas para esse fluxo.

Confirmation status: O atributo status de confirmação transporta condições de limiar para um fluxo de mídia. Quando o status de recursos de rede atinge essas condições, o peer agente-usuário vai enviar um update da descrição de sessão contendo um atributo status atual atualizado para esse fluxo de mídia particular.

Precondition type: Esse documento define precondições para qualidade de serviço. Extensões podem definir outros tipos de pré-condições.

Strength tag: O strength-tag indica se a parte chamada pode ou não ser alertada, no caso da rede falhar em satisfazer as pré-condições.

Status type: Nós definimos dois tipos de status: end-to-end e segmentado. O status end-to-end reflete o status da reserva de recursos fim a fim. O status segmentado reflete o status das reservas de acesso à rede de ambos agentes-usuários. O status fim a fim corresponde a tag "e2e", definida acima e o status segmentado as tag's "local" e "remote". O status fim a fim é útil quando mecanismos de reserva de recurso fim a fim estão disponíveis. O status segmentado é útil quando um ou ambos UA's executam reservas de recurso em suas respectivas redes de acesso.

Camarillo, et. al.                 Standards Track                     [Página 5]

Página Original:
http://tools.ietf.org/search/rfc3312#page-5

Página 4
Tabela de Conteúdo
Página 6

Observação:
  Modelo 'offer/answer' do documento original em inglês foi traduzido para o
  português como: modelo oferta-aceite.

Trâmite de Padronização no IETF

2011-08-01T20:46:00.007-03:00

O termo Request for Comments (RFC) remonta ao final dos anos 1960, quando os pesquisadores do projeto ARPANET digitavam suas notas técnicas a cerca de determinado recurso relacionado ao desenvolvimento de mecanismos da rede ARPANET e submetia os seus argumentos aos demais pesquisadores e desenvolvedores a fim de colher sugestões, comentários e eventuais melhoramentos àquilo que estava propondo como melhores práticas e ou padronização.

Com o passar do tempo o projeto ARPANET amadureceu e aquela rede inicial de pesquisa evoluiu bastante e cresceu rapidamente. A partir daí, ela foi renomeada para INTERNET e houve a necessidade de se criar um organismo que pudesse normatizar as suas tecnologias e tudo que pudesse funcionar sobre a pilha TCP/IP. E foi assim que o então grupo do projeto ARPANET deu origem ao IETF (Internet Engineering Task Force). A conformação atual é de grupos de trabalho composto por membros de várias empresas de tecnologia, universidades e instituições de pesquisas que comungam interesses comuns em padronizar determinada funcionalidade, aqui entendido como um protocolo ou aplicação, que possa ser executada sobre a arquitetura TCP/IP.

Hoje um documento rotulado como RFC que estagia no standards track (trilhando as etapas de padronização) especifica, define e descrever um padrão que todos os fabricantes/fornecedores precisam seguir.

Um Internet Standard é um Request for Comments (RFC) especial ou conjunto de RFC’s. Uma RFC que deve se tornar um Padrão ou parte de um Padrão começa como um Internet-Draft, e é depois (geralmente após várias revisões) aceito e publicado pelo Editor RFC como uma RFC e é rotulada como Proposed Standard. Depois, uma RFC é rotulada como Draft Standard e, finalmente, como Standard. Coletivamente, esses estágios são conhecidos como standards track, e estão definidos na RFC 2026. O rótulo Historic é aplicado aos documentos que foram descontinuados no standards-track ou àquelas RFC's obsoletas que foram publicadas antes de o estabelecimento do standards-track.

O termo standards-track é sinônimo de: trilhas de padronização; em fase de padronização; em vias de padronização. A seqüência que uma RFC segue no standards track (tramitando na trilha de padronização) é:

1 – Proposed Standard (padrão proposto);
2 – Draft Standard (anteprojeto do padrão);
3 – Standard (padrão definitivo).

Processo de Padronização

Um processo completo para produzir um padrão consiste de quatro etapas no IETF, as quais são chamadas:

1 – Internet Draft (documento rascunho),
2 – Proposed Standard (padrão proposto),
3 – Draft Standard (anteprojeto do padrão), e finalmente
4 – Standard (padrão definitivo).

Se uma RFC for parte de uma proposta que está no standards-track, então no primeiro estágio, o padrão é proposto e, subseqüentemente, organizações decidem se implementam esse Proposed Standard. Após três implementações distintas, revisões e correções adicionais serem feitas na RFC, então um Draft Standard é criado. No estágio final, a RFC torna-se um Standard.

Internet-Draft

Essa é fase preliminar durante o desenvolvimento de uma especificação. Especialistas em tecnologia da Internet podem apresentar um Documento-Rascunho em versões preliminares que são disponibilizadas para revisão informal e para receber comentários e sugestões. Esses documentos são colocados no diretório "Internet-Drafts" do IETF, a fim de tornar disponíveis imediatamente tais documentos em evolução ao grande público, facilitando assim o processo de análise e revisão.

Segundo o IETF, em hipótese nenhuma um Internet-Draft deve ser referenciado por artigos, relatórios ou pedidos-de-proposta, e nenhum fabricante deve argumentar que esteja em conformidade com um Internet-Draft.

Proposed Standard

Um Proposed Standard (PS) é geralmente estável, resolveu escolhas de design conhecidas, acredita-se esteja bem compreendido, recebeu revisão significativa da comunidade, e parece desfrutar de interesse suficiente da comunidade para ser considerado apreciável. Contudo, uma maior experiência pode resultar em alguma mudança ou até mesmo retração da especificação antes de ela avançar. Normalmente, nem implementação e nem experiência operacional é exigido.

Draft Standard

Uma especificação à qual, ao menos, duas implementações independentes e interoperáveis a partir de bases de código diferentes foram desenvolvidos, e que a experiência operacional bem sucedida suficiente foi atingido, pode ser elevado ao nível Draft Standard (DS).

Um Draft Standard deve ser normalmente considerado como uma especificação final, e mudanças devem ser provavelmente feitas só para resolver problemas específicos encontrados. Em muitas circunstâncias, é razoável aos fabricantes fazerem implementações de Draft Standards em um ambiente sensível a ruptura.

Standard

Uma especificação à qual a implementação significativa e experiência operacional bem sucedida foi obtida, pode ser elevada ao nível Internet Standard (STD). Um padrão Internet, que pode ser referido simplesmente como Standard, é caracterizada por alto grau de maturidade técnica e por uma crença generalizada de que o protocolo especificado ou o serviço fornece benefício significativo à comunidade Internet. Geralmente Internet Standards cobrem as questões de interoperabilidade de sistemas na Internet através da definição de protocolos, formatos de mensagens, esquemas e línguas. O mais fundamental dos Standards são aqueles que definem o Internet Protocol (IP).

Todos os Internet Standards recebem um número na série STD – o primeiro documento dessa série, o STD 1, descreve os documentos restantes na série, e tem uma lista dos Proposed Standards.

Cada RFC é estática, ou seja, não mais será alterada; se o documento for alterado, ele é submetido novamente e atribuído um novo número RFC. Se uma RFC se torna um Internet Standard (STD), é-lhe atribuído um número STD, mas mantém seu número RFC. Quando um Internet Standard é atualizado, seu número permanece o mesmo e ele simplesmente se refere a uma RFC diferente ou conjunto de RFC's. Um dado Internet Standard, STD n, pode ser as RFC's x e y em um dado momento, mas depois o mesmo Standard pode ser atualizado para ser RFC z no lugar. Por exemplo, em 2007, a RFC 3700 era um Internet Standard – STD 1 – e em maio de 2008, foi substituída pela RFC 5000, assim a RFC 3700 mudou seu status para Historic, e agora um STD 1 é a RFC 5000. Quando um STD é atualizado novamente, ele é simplesmente referido pela nova RFC, mas ainda será um STD 1. Note que nem todas as RFC's são documentos no standards-track, mas todos os Internet Standards e outros documentos no standards-track são RFC's.

Institucionalizando padrões para comunicações unificadas

2011-07-25T23:24:00.006-03:00

Irwin Lazar, Nemertes Research

http://searchunifiedcommunications.techtarget.com/tip/Standardizing-on-unified-communications-standards?asrc=EM_USC_14514813&track=NL-1045&ad=841877

Empresas têm relutado em suportar padrões de comunicações unificadas (UC), mas usuários demandam por conectividade pela extranet e acesso para aplicações UC para além do firewall está despertando renovado interesse em padrões UC.

Padrões no mundo das comunicações unificadas e telefonia IP são um tanto parecido com o fazer exercícios e comer de forma saudável – todos concordam que eles são uma coisa boa, mas na realidade, poucos fazem valer seu uso. Pesquisas da Nemertes mostram que a vasta maioria de implementações UC diz que suportam padrões, mas não fazem nada para promovê-los; eles exigem suporte ao SIP para interconectividade de sistema a sistema, mas dependem largamente de protocolos proprietários como SCCP da Cisco, RTAudio/RTVideo da Microsoft ou outros protocolos proprietários para aplicações nas pontas.

Contudo, os padrões UC estão ganhando nova atenção entre os projetistas UC graças à crescente demanda de usuário por conectividade pela extranet. Setenta e quatro por cento dos participantes no próximo Benchmark Comunicações e Computação da Nemertes 2011-2012 estão implantando, planejando implantar ou avaliar a diversidade de aplicações UC para extranet incluindo IM, presença, voz e vídeo. Abarcar o abismo de aplicações UC apenas internas para permitir conectividade além das fronteiras da empresa, e normalmente com sistemas distintos, requer um meio de comunicação padrão.

Muitos projetistas em TI já estão praticamente familiarizados ao SIP, mas o SIP tão somente não é tudo em termos de interoperabilidade de UC. O SIP define meramente um padrão de sinalização; negociação de codec’s reais, segurança/criptografia e gerenciamento e ainda exigem padrões interoperáveis subjacentes como o H.264 para encapsulamento de vídeo ou G.711 para áudio.

Em adição ao SIP e aos codec’s subjacentes, projetistas em TI devem familiarizar-se com vários outros padrões UC porque eles estendem aplicações UC para além do firewall.

Extensible Messaging and Presence Protocol (XMPP)

O XMPP é o avô de todos os protocolos UC, desenvolvido em suporte ao projeto mensageria instantânea Jabber de código aberto há muitos anos. O XMPP foi quase tido como morto, devido ao crescimento do SIP e o protocolo SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLES) complementar adotado pela Microsoft e outros, mas o XMPP ressurgiu graças ao suporte inicial do Google e aquisição do Jabber pela Cisco.

Agora, outros fornecedores estão aumentando o suporte XMPP graças à simplicidade e extensibilidade do desenvolvimento baseado em XML. Até mesmo o Skype recentemente adicionou suporte XMPP ao seu cliente Windows atual em beta teste. Analise o XMPP, tanto pela ótica da interoperabilidade como estratégia para estender os protocolos de mensageria para outras aplicações empresariais (por exemplo, serviços de alerta customizados).

SIPconnect 1.1

O Fórum SIP desenvolveu SIPconnect para permitir aos operadores de serviços SIP trunking e fornecedores de sistemas de telefonia IP padronizar interconexões, esperar-se com isso evitar problemas de interoperabilidade que têm assolado muitas das primeiras implementações SIP trunking. Os compradores de TI devem exigir suporte ao SIPconnect 1.1 em qualquer sistema que comprem. Preste atenção também aos resultados dos eventos SIPit para interoperabilidade do Fórum SIP em que fabricantes e operadores de serviço testaram a interoperabilidade baseado em serviços SIP incluindo voz e vídeo.

Telepresence Interoperability Protocol (TIP)

Introduzido pela Cisco e agora suportado pela Polycom e outros, o TIP é projetado para padronizar tudo que for relacionado à interoperabilidade de tele-presença entre múltiplas plataformas de fabricantes abarcando todos os recursos, incluindo áudio direcional e troca de tela para falante ativo. O Consórcio Internacional de Telecomunicações Multimédia (IMTC) realizou recentemente um teste de interoperabilidade TIP com sistemas de fornecedores como Cisco, Polycom, Radvision e Teliris. Avalie o TIP como parte de seus planos de tele-presença pela extranet.

Cada um desses padrões irá desempenhar um papel crescente nos planos de diversas extranet's. Converse com seus fornecedores a cerca de seus planos de suportar e acompanhar os esforços de desenvolvimento de padrões.

About the author: Irwin Lazar is the vice president for communications and collaboration research at Nemertes Research, where he develops and manages research projects, develops cost models, conducts seminars and advises clients. Lazar is responsible for benchmarking the adoption and use of emerging technologies in the enterprise in areas including VoIP, UC, video conferencing, social computing, collaboration and advanced network services.

RFC 3261 Português Página 1

2011-07-11T23:15:00.000-03:00




Grupo de Trabalho em Rede                                               J.  Rosenberg
Request for Comments: 3261                                                dynamicsoft
Obsoleta a: 2543                                                       H. Schulzrinne
Categoria: Standards Track                                                Columbia U.
                                                                         G. Camarillo
                                                                             Ericsson
                                                                          A. Johnston
                                                                             WorldCom
                                                                          J. Peterson
                                                                              Neustar
                                                                            R. Sparks
                                                                          dynamicsoft
                                                                           M. Handley
                                                                                 ICIR
                                                                          E. Schooler
                                                                                 AT&T
                                                                           Junho 2002





             SIP: Session Initiation Protocol



Status desse Memorando

Esse documento especifica um protocolo que tramita na trilha de padronizações 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 o estado da padronização e status desse protocolo. Distribuição desse memorando é ilimitada.


Aviso sobre Direitos Autorais

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


Resumo

Esse documento descreve o Session Initiation Protocol (SIP), um protocolo de controle (sinalização) da camada de aplicação para criar, modificar e terminar sessões com um ou mais participantes. Essas sessões incluem chamadas telefônicas pela Internet, distribuição multimídia e conferências multimídia.

Requisições INVITE do SIP usadas para criar sessões transporta descrições de sessão que permite aos participantes estabelecer acordo sobre um conjunto de tipos de mídias compatíveis. O SIP faz uso de elementos chamados servidores proxy para ajudar rotear requisições ao local atual do usuário, autenticar e autorizar usuários para serviços, implementar políticas de roteamento de chamadas pelo provedor e fornecer recursos aos usuários. O SIP também fornece uma função de registro que permite aos usuários atualizar suas localizações correntes para uso por servidores proxy. O SIP funciona no topo de vários protocolos de transporte diferentes.






Rosenberg, et. al.          Standards Track                     [Página 1]

Tabela de Conteúdo

Página Seguinte