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

Aqui nesse poste eu listo e faço uma breve descrição do corpo de RFC´s dos grupos de trabalho do organismo normatizador internacional IETF que especifica o protocolo de sinalização SIP (Session Initiation Protocol) em que um sistema completo de telefonia IP ou Comunicação Unificada construído no SIP precisa obedecer a fim de preservar a interoperabilidade entre fabricantes. E quando se deseja implementar uma arquitetura tecnológica orientada à serviço, a observância a essas normas é também uma condição sine qua non.

Esse documento foi organizado em funcionalidades em nível macro do protocolo, tomei como referência as orientações conforme sugerido no Guia de Introdução ao SIP para Iniciantes, na RFC de instrução 5411 (2009).

Prezado leitor, sugestões, inclusões e eventuais correções a essa lista são muito bem-vindas. Favor deixe-me conhecê-las!

Cada RFC, a seguir, está rotulada com S, E, B e I conforme legenda a seguir, e ano que foram publicadas:

S: Trâmite de Padronização: Proposed Standard (PS), Draft Standard (DS) ou Standard (STD)

E: Experimental

B: Melhores Práticas Correntes

I: Informativas

E, adicionalmente, eu acrescentei o rótulo ‘O’ para me referir que uma RFC ficou obsoleta em detrimento de outra RFC.

Essas normas devem ser interpretadas conforme as regras estabelecidas pelo próprio IETF na RFC 2119 para documentos em trâmite para se tornarem padrões, em que várias palavras/verbos são usadas para indicar os requisitos na especificação. Essas palavras/verbos são frequentemente em maiúsculas. Tal documento define essas palavras/ verbos do modo como elas devem ser interpretadas em RFC’s do IETF, conforme a seguir:

MUST:

Essa palavra/verbo, ou os termos "REQUIRED" ou "SHALL", significam que a definição é uma exigência absoluta da especificação.

O verbo MUST exprime obrigatoriedade, algo mandatório, exigido, forçoso, requerido, necessário e preciso. Na língua portuguesa palavras/verbos sinônimos são: PRECISAR, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO, NECESSITAR, É MANDATÓRIO.

MUST NOT:

Essa frase, ou a frase "SHALL NOT", significam que a definição é uma proibição absoluta da especificação.

Em português equivale a: NÃO PODE, É PROIBIDO, É VEDADO.

SHOULD:

Essa palavra/verbo, ou o adjetivo "RECOMMENDED", significam que pode haver razões válidas em circunstâncias particulares para se ignorar um item particular, mas as implicações completas precisam ser compreendidas e cuidadosamente ponderadas antes de se escolher um curso diferente.

Em português equivale a: DEVE, É RECOMENDADO.

SHOULD NOT:

Essa frase/verbo, ou a frase "NOT RECOMMENDED" significam que pode haver razões válidas em circunstâncias particulares quando o comportamento particular é aceitável ou mesmo útil, mas as implicações completas devem ser compreendidas e o caso cuidadosamente ponderado antes de implementar qualquer comportamento descrito com esse rótulo.

Em português equivale a: NÃO DEVE, NÃO É RECOMENDADO.

MAY:

Essa palavra/verbo, ou o adjetivo "OPTIONAL", significa que um item é opcional verdadeiramente. Um fabricante pode escolher incluir o item seja porque um mercado particular o exige ou porque o fabricante percebe que isso melhora o produto ao passo que outro fabricante pode omitir o mesmo item. Uma implementação que não inclui uma opção particular PRECISA estar preparada para interoperar com outra implementação que inclui a opção, embora, possivelmente com funcionalidades reduzidas. No mesmo espírito, uma implementação que inclui uma opção particular PRECISA estar preparada para interoperar com outra implementação que não inclui a opção (exceto, claro, para o recurso que a opção fornece).

Em português equivale a: PODE, É OPCIONAL.

1.            Especificações do Núcleo SIP

1.1 RFC 3261 (S) – Essa RFC é o núcleo central da especificação SIP (2002). Essa especificação tornou obsoleta a RFC 2543 a qual primeiro definiu o SIP. A RFC 3261 é atualizada pelas RFC’s 3265, 3853, 4320, 4916, 5393, 5621, 5626, 5630, 5922, 5954, 6026 e 6141. Ela é complementada por RFC’s, Drift’s e suas erratas correspondentes que estendem suas funcionalidades, conforme segue:

1.2 RFC 3263 (S) – Define a localização de Servidores SIP (2002). Essa também tornou obsoleta a RFC 2543;

1.3 RFC 3264 (S) – Define o modelo para negociação de Codec no processo de formatação do corpo da mensagem SIP pelo SDP (2002). Esse documento foi atualizado pela RFC 6157 e também tornou obsoleta a RFC 2543;

1.4 RFC 3265 (S) – Define o mecanismo de notificação SIP NOTIFY/SUBSCRIBE (2002). Esse documento foi atualizado pelas RFC’s 5367 e 5727;

1.5 RFC 3325 (I) – Define extensões de segurança ao SIP (2002) para permitir a uma rede de servidores confiáveis assegurarem a identidade de usuários finais ou sistemas finais, chamado SIP Asserted Identity;

1.6 RFC 3327 (S) – Define o campo-cabeçalho de extensão SIP (2002) para implementar registro em contactos não-adjacentes;

1.7 RFC 3581 (S) – Extensão ao SIP p/o Roteamento Simétrico de Resposta (2003): Define o parâmetro rport do cabeçalho Via. Esse permite que respostas SIP atravessem NAT. É uma das várias especificações que são utilizados pelo NAT transversal;

1.8 RFC 3840 (S) – Indicação Capacidades de Agente Usuário no SIP (2004): Define mecanismo para transportar informação de capacidade sobre um agente usuário em requisições REGISTER e requisições de diálogo em formação como INVITE;

1.9 RFC 4320 (S) – Trata problemas identificados com transações Não-INVITE do SIP (2006). Esse documento atualiza a RFC 3261;

1.10 RFC 6026 (S) – Define a correção essencial ao SIP (2010): Essa correção resolve o erro no tratamento nas respostas de classe 2xx para requisições INVITE que levam a retransmissões de INVITE ser tratado como novas requisições e proíbe encaminhamento de respostas a INVITE disperso. Esse documento atualiza a RFC 3261;

1.11 RFC 6141 (S) – Define como manipular as mensagens-requisições Re-INVITE e Target-Refresh (2011) no SIP. Esse documento atualiza a RFC 3261;

1.12 RFC 3455 (I) – Conjunto de cabeçalhos privados – P-headers no SIP (2003): Esse documento descreve cabeçalhos privados usados pelo Projeto 3rd-Generation Partnership (3GPP), junto com sua aplicabilidade, que está limitada a ambientes particulares. Os cabeçalhos P-headers são para uma variedade de propósitos dentro das redes que os partners usam, incluindo charging e informação sobre as redes que uma chamada atravessa;

1.13 RFC 4474 (S) – Melhorias no Gerenciamento de Identidade Autenticada no SIP (2006): Define um mecanismo para prover uma identidade criptograficamente verificável da parte chamante em uma requisição SIP. Conhecido como "SIP Identity", esse mecanismo fornece uma alternativa para a RFC 3325. Tem sido pouco implementada até o agora, mas sua importância como construção chave para técnicas anti-spam e novos mecanismos de segurança o torna uma parte núcleo das especificações SIP;

1.14 RFC 5627 (S) – Obtendo e Usando o Globally Routable User Agent (UA) URI’s - GRUU’s (2009) no SIP: Essa especificação descreve um mecanismo para fornecer um identificador único agente-usuário que seja ainda globalmente roteável. Esse identificador é chamado GRUU. Várias aplicações do SIP requerem de um UA construir e distribuir um URI que possa ser usada por todos na Internet a fim de rotear uma chamada para aquela instância UA específica. Um URI que roteia por uma instância UA específica é chamada um GRUU. Esse documento descreve uma extensão ao SIP para obter um GRUU de um registrar e para comunicar um GRUU a um peer dentro de um diálogo;

1.15 RFC 5626 (S) – Essa trata do problema gerado pela existência de NAT ou firewall (2009) no meio de conexões entre Registrador ou Proxy SIP e cliente e que conexões inicializadas pelo cliente são possíveis e no sentido inverso não, ou seja, do Proxy para o cliente. Esse documento atualiza as RFC’s 3261 e 3327;

1.16 RFC 4566 (S) – Esse documento define o SDP (2006): Define os comandos da sessão de mídia que um sistema suporta. O SIP usa o SDP para formatar o corpo das mensagens-requisições. Esse documento tornou obsoletas as RFC’s 2327 e 3266;

1.17 RFC 5939 (S) – Negociação de Capacidade no SDP (2010): O propósito desse documento é tratar aquelas lacunas estendendo o SDP com parâmetros de negociação de capacidade e procedimentos associados offer/answer a usar aqueles parâmetros de uma forma retro-compatível. Esse documento define uma infra-estrutura geral para Negociação de Capacidade no SDP. Ele também especifica como fornecer atributos e protocolos de transporte como capacidades e negociá-los usando a infra-estrutura. Extensões para outros tipos de capacidades (p.ex., tipos de mídia e formatos de mídia) podem ser fornecidos em outros documentos;

1.18 RFC 5245 (S) – Interactive Connectivity Establishment (ICE): Um Protocolo para NAT Transversal para Protocolos Oferta/Aceite: Essa especificação define o ICE como uma técnica para NAT transversal para media streams baseado no UDP, embora o ICE possa ser estendido para tratar outros protocolos de transporte, como o TCP (ICE-TCP) estabelecido pelo modelo oferta/aceita. Esse documento descreve um protocolo para NAT transversal para sessões multimídia baseado no UDP estabelecido com o modelo oferta/aceita. O ICE usa o protocolo STUN e sua extensão, o TURN. O ICE pode ser usado por qualquer protocolo que utiliza o modelo oferta/aceite, como o SIP. Esse documento tornou obsoletas as RFC’s 4091 e 4092;

1.19 RFC 3605 (S) – Define uma forma explicita de sinalizar, dentro da mensagem SDP (2003), o endereço IP e a porta para uso do RTCP, ao invés de usar a regra porta+1 do RTP conforme RFC 3550. É necessária para dispositivos atrás de NAT e essa especificação é exigida pelo ICE;

1.20 RFC 4916 (S) – Define como atualizar a identidade das partes de uma chamada (2007) quando do evento de encaminhamento, distribuição, captura, transferência, estacionamento e recuperação de chamada, etc. Chamada SIP Connected ID. Esse documento atualiza a RFC 3261;

1.21 RFC 3311 (S) – Define o método UPDATE do SIP (2002). A mensagem-requisição UPDATE entre outras funções atualiza uma sessão SIP;

1.22 RFC 5630 (S) – Trata do uso do esquema URI no SIPS (2009) não especificado na RFC 3261 do SIP. Esse documento atualiza as RFC’s 3261 e 3608;

1.23 RFC 3665 (B) – Exemplos de Fluxos de Chamada SIP Básicos (2003): Contém exemplos de melhores práticas para o fluxo de chamada nas interações SIP básicas – estabelecimento, terminação de chamada e implementação de registro;

1.24 RFC 6140 (S) – Roteamento de Número Identificável Globalmente (2011) – Executar Registro para Múltiplos Números de Telefone no SIP. Esse documento define um mecanismo pelo qual um servidor SIP atua como um PABX tradicional que pode se registrar com um SIP Service Provider (SSP) para receber ligações telefônicas de Agentes-Usuários (UA’s) SIP. A fim de funcionar adequadamente, esse mecanismo requer que cada um dos Addresses of Record (AOR’s) registrados no bulk mapeie para um conjunto único de contatos. Esse requerimento é satisfeito por AOR’s que representam números de telefone independentemente do domínio, como números de telefone são completamente qualificados e globalmente únicos. Esse documento, contudo foca nesse caso de uso. Esse documento também atualiza a RFC 3680;

1.25 DRAFT-SIP-ESSENTIAL-CORRETION – Correções Essenciais ao SIP (2008): O SIP definido na RFC 3261 e em grande número de extensões formam um considerável corpo de trabalho, que devido ao vasto número tem inúmeros erros que requerem correção. Esse documento explica o processo para gerenciar correções essenciais ao SIP;

1.26 DRAFT-SIPPING-BLA – Implementação Multiple Line Appearances (MLA) usando o SIP (2007): Define o método para implementar o grupo de recurso de telefonia comumente chamando Bridged Line Appearance (BLA), SIP MLA ou Shared Call/Line Appearance (SCA), esse é um método para implementar o recurso conhecido como Chefe-Secretária;

1.27 DRAFT-ENUM-TRUNK-SIP – Uso de Grupo Tronco no ENUM (2009): Descreve um método para incorporar parâmetros de grupo de tronco em uma resposta E.164 (ENUM) na URI do serviço SIP (RFC 3261). Define o uso de contextos de grupo tronco como definido na (RFC 4904) como parâmetros adicionais no URI de registro NAPTR enumservice E2U+SIP (RFC 3403);

1.28 RFC 3427 (B) – Processo de Mudança p/o SIP (2002): Esse documento aborda um processo pensado a aplicar a disciplina arquitetural para o futuro desenvolvimento do SIP. Tem havido preocupações com relação a novas propostas ao SIP. Especificamente, aquelas relacionadas à adição de novos recursos SIP que podem ser prejudicial à segurança e/ou aumentar enormemente a complexidade do protocolo. Os administradores da Área de Transporte, junto com os lideres dos grupos de trabalho SIP e do grupo Session Initiation Proposal Investigation (SIPPING), forneceram sugestões para modificações e para extensões ao SIP. Essa RFC ficou obsoleta em favor da RFC 5727. Esse é atualizado pelas RFC’s 3968 e 3969;

1.29 RFC 5727 (B) – Processo de Mudança p/o SIP e a Área RAI (2010): Esse documenta um processa pensado para organizar o desenvolvimento futuro do SIP e funcionamento relacionado na Área de (Real-time Applications and Infrastructure - RAI). Como os ambientes em que o SIP é implementado crescem mais numerosa e diversamente, modificar ou estender o SIP de alguma forma pode ameaçar a interoperabilidade e a segurança do protocolo; contudo, o processo do IETF precisa também servir as realidades de implementações existentes e servir as necessidades dos implementadores que trabalham com o SIP. Esse documento, portanto, define as funções de dois grupos de trabalho longa data na Área RAI que são, respectivamente, responsáveis pela manutenção do núcleo de especificações SIP e o desenvolvimento de novos esforços para estender e aplicar work nesse espaço. Esse documento tornou obsoleto a RFC 3427. Ele atualiza as RFC’s 3265 e 3969;

2.            Interconexão Com PSTN Legada

2.1 RFC 2848 (S) – Esse documento define extensões ao SIP e ao SDP (2000) para Acesso IP ao serviço de chamada telefônica no protocolo do serviço PINT;

2.2 RFC 3910 (S) – Define o Protocolo SPIRITS (2004): Esse documento descreve os Serviços na PSTN que requerem o protocolo Internet Services (SPIRITS). O propósito do protocolo SPIRITS é suportar serviços que originam na rede celular ou na rede PSTN e necessita de interações entre a PSTN e a Internet. No lado PSTN, os serviços SPIRITS são mais freqüentemente iniciados a partir das entidades Intelligent Network (IN). Internet Call Waiting (ICW) e Internet Caller-ID Delivery são exemplos de serviços SPIRITS, porque são serviços baseados na localização da rede celular. O protocolo define os blocos de construção a partir dos quais muitos outros serviços podem ser construídos;

2.3 RFC 3372 (B) – SIP p/ Telefones (SIP-T), Contexto e Arquiteturas (2002): SIP-T define um mecanismo para uso do SIP entre pares de gateways PSTN. Sua idéia essencial é tunelar a sinalização ISDN User Part (ISUP) entre os gateways dentro do corpo das mensagens SIP. O SIP-T motivou o desenvolvimento do método SIP INFO (RFC 2976). O SIP-T viu implementação mais ampla do modelo de desenvolvimento limitado ao qual trata. À medida que endpoints ISUP desaparecem da rede, a necessidade de incluir esse mecanismo vai diminuindo;

2.4 RFC 3398 (S) – Define o Mapeamento ISUP p/o SIP (2002): Define como executar o mapeamento de protocolo da sinalização ISUP SS7 no SIP. É amplamente usado nos gateways SS7 para SIP e faz parte da infra-estrutura SIP-T;

2.5 RFC 3204 (S) – Tipos de Mídia em formato MIME p/o ISUP e Objetos QSIG (2001): Define objetos MIME para representar mensagens de sinalização SS7 e QSIG. Mensagens de sinalização SS7 são transportadas no corpo de mensagens SIP quando SIP-T for usado. Mensagens de sinalização QSIG podem ser transportadas de modo similar. Esse documento foi atualizado pelas RFC’s 3459 e 5621;

2.6 RFC 4497 (B) – Interconexão entre o SIP e QSIG (2006): Define como executar o mapeamento do protocolo da Q.SIG, usado na sinalização PABX, para SIP;

2.7 RFC 3578 (S) – Mapeamento de Sinalização ISUP Overlap p/o SIP (2003): Define um mecanismo para mapear overlap-dialing no SIP. Essa especificação é amplamente considerada como a especificação SIP mais feia, como a introdução à especificação em si aconselha que esse tenha muitos problemas. Overlap signaling (prática de enviar dígitos na rede à medida que são digitados ao invés de esperar completar a coleção do número da parte chamada) é largamente incompatível com SIP em quase todos os níveis fundamentais. Dito isso, a RFC 3578 é normalmente inócua e viu alguns usos;

2.8 RFC 3960 (I) – Mídia Early e Geração de Tom no SIP (2004): Define algumas orientações para manipular mídia early - a prática de enviar mídia a partir da parte chamada ou um servidor de aplicação ao chamador antes da aceitação fim da chamada. Mídia early é freqüentemente gerada a partir da RTPC;

2.9 RFC 3959 (S) – Tipo de Disposição Sessão Early p/o SIP (2004): Define um novo tipo para dispor a sessão para uso de mídia early. Essa indica que o corpo no SDP é para uma sessão de mídia early especial;

2.10 RFC 3666 (B) – Fluxos de Chamada PSTN-SIP (2003): Fornece as melhores práticas nos fluxos de chamada em toda a interconexão com a PSTN;

2.11 RFC 5486 (I) – Terminologia SPEERMINT (2009): Define a terminologia que deve ser usada na descrição de Sessão PEERing para Multimídia INTerconnect (SPEERMINT). Esse documento introduz terminologia padrão para uso na caracterização de sessão peering de real-time. Note, contudo, que enquanto esse documento é primariamente tencionado para o caso peering VoIP, a terminologia descrita aqui é aplicável àqueles casos em que o peer dos provedores de serviço usando sinalização SIP (definido como Provedores de Serviço SIP) para comunicações não-voz ou quase-real-time como mensageira instantânea;

2.12 RFC 3966 (S) – Define a URI tel p/ números telefônicos (2004). Esse documento foi atualizado pela RFC 5341 e tornou obsoleta a RFC 2806;

2.13 RFC 4694 (S) – Define parâmetros de portabilidade de número para URI "tel" (2006);

2.14 RFC 3761 (OS) – O E.164 to URI Dynamic Delegation Discovery System (DDDS) Application (ENUM) (2004): Esse documento discute o uso do DNS para o armazenamento de números E.164. Mais especificamente, como DNS pode ser usado para identificar serviços disponíveis conectado a um número E.164. Esse documento tornou obsoleto a RFC 2916 e ficou obsoleto em favor das RFC’s 6116 e 6117;

2.15 RFC 3764 (S) – enumservice executando registro p/ Addresses-of-Record (AOR) no SIP (2004): Esse documento registra um serviço Eletronic Number (ENUM) ao SIP, de acordo com as orientações da RFC 3761. Especificamente, este documento concentra no provisionamento ao AOR do SIP no ENUM. Esse documento foi atualizado pela RFC 6118;

2.16 RFC 3824 (I) – Usando números E.164 c/o SIP (2004): Esse documento ilustra como os dois protocolos podem funcionar em concerto, clarifica o authoring e processamento de registros ENUM para aplicações SIP. Ele também fornece orientações para instâncias nas quais ENUM, por alguma razão, não pode ser usado para resolver um número de telefone;

3.            Extensões a Infraestrutura de Propósito Geral

3.1 RFC 3262 (S) – Define o método para respostas provisionais confiáveis no SIP (2002), chamado SIP PRACK;

3.2 RFC 3323 (S) – Define mecanismo privativo para uso no SIP (2002);

3.3 RFC 5839 (S) – Entity-Tags p/ Eventos SIP (2010): A infra-estrutura de eventos SIP possibilita recepção assíncrona de notificação de vários eventos a partir de outros agentes-usuários SIP. Essa infra-estrutura define os procedimentos para criar, atualizar e terminar subscriptions, bem como buscar e periodicamente pollar estado de recurso. Esses procedimentos não fornecem nenhuma ferramenta para evitar responder notificações de evento que já tenham sido recebidos por um agente-usuário. Esse documento define uma extensão a eventos SIP que permite ao subscriber condicionar a requisição subscription a qualquer que seja o estado que tenha sido alterado desde que a notificação anterior foi recebida. Quando tal condição for verdadeira, tanto o corpo de uma notificação de evento resultante quanto à mensagem de notificação inteira será suprimida;

3.4 RFC 2976 (OS)– Define o envio de sinalização DTMF usando o método INFO (2000), chamado SIP INFO. Essa foi tornada obsoleta pela RFC 6086;

3.5 RFC 6086 (S) – Método SIP INFO e Infra de Pacote (2011): Esse documento define um método, INFO, para o SIP, e um mecanismo para Pacote Info. Por razões de retro-compatibilidade, esse documento também especifica um modo de uso "legado" do método INFO que é compatível com o uso anteriormente definido na RFC 2976, referenciado como "legacy INFO Usage" nesse documento. Esse documento tornou obsoletas as especificações da RFC 2976;

3.6 RFC 3326 (S) – Adiciona o campo-cabeçalho Reason ao SIP (2002);

3.7 RFC 3388 (OS) – Define o agrupamento de linhas de mídia no processo de formatação do SDP (2002). Essa foi tornada obsoleta em favor da RFC 5888;

3.8   RFC 5888 (S) – Infra-Estrutura de Agrupamento SDP (2010): Essa especificação define uma infra para agrupar linhas "m" no SDP para diferentes propósitos. Essa infra-estrutura usa os atributos SDP "group" e "mid", ambos os quais são definidos nessa especificação. Adicionalmente, especifica como usar a infra para dois diferentes propósitos: para sincronização lip e para recepção de um fluxo de mídia consistindo de vários streams de mídia sobre diferentes endereços de transporte. Esse documento tornou obsoleto a RFC 3388;

3.9 RFC 3420 (S) – Define o transporte do tipo MIME de mídia (2002) para mensagens SIP fragmentadas bem formatadas em vez de uma mensagem SIP inteira, com segurança fim-a-fim;

3.10 RFC 3608 (S) – Campo Cabeçalho de Extensão ao SIP p/ Serviço (2003) de Descoberta de Rota Durante o processo de Registro: Permite ao cliente determinar, a partir de uma resposta ao REGISTER, um caminho de Proxy’s a usar em requisições que ele envia fora de um diálogo. Também pode ser usado por Proxy’s para verificar o campo-cabeçalho Route em requisições iniciadas pelo cliente. Essa foi atualizada pela RFC 5630;

3.11 RFC 3841 (S) – Define um conjunto de cabeçalhos (2004) que um cliente pode incluir em uma requisição a fim de controlar a forma na qual a requisição é roteada para-trás. Isso permite a um cliente direcionar uma requisição pra frente uma UA com capacidades específicas, o que um UA indica usando a RFC 3840. É chamado de Caller Preferences;

3.12 RFC 4028 (S) – Define o mecanismo keepalive p/ sinalização SIP (2005). Ele é principalmente pensado para fornecer a forma de limpar estado precedente em Proxy’s que mantém estado de chamada para chamadas a partir de terminais que nunca foram encerradas normalmente. Chamado de SIP Session-Timers;

3.13 RFC 4168 (S) – SCTP como Transporte p/o SIP (2005): Define como transportar mensagens SIP sobre o Stream Control Transmission Protocol (SCTP – RFC 4960). O SCTP viu uso muito limitado para transportar o SIP;

3.14 RFC 4244 (S) – Extensão ao SIP para Requisição de Informação de Histórico (2005): Define o campo-cabeçalho History-Info, que indica informação sobre como e porque uma chamada veio a ser roteada por um destino particular;

3.15 RFC 4145 (S) – Transporte de Mídia no SDP Baseado no TCP (2005): Define uma extensão ao SDP ao estabelecer sessões baseadas no TCP entre agentes usuários. Define quem estabelece a conexão e como seu ciclo de vida é gerenciado. Tem visto relativamente pouco uso devido ao pequeno número de tipos de mídia até aqui que usa o TCP. Essa foi atualizada pela RFC 4572;

3.16 RFC 4091 (OS) – Semântica ANAT para a Infraestrutura de agrupamento do SDP (2005): Define mecanismo para incluir endereços tanto IPv4 quanto IPv6 para uma sessão de mídia como alternativa. Esse mecanismo foi descontinuado em favor do ICE e ficou obsoleta em favor da RFC 5245;

3.17 RFC 4092 (OS) – Descreve como usar a semântica ANAT (2005) (tipos de endereços alternativos de rede) da infra-estrutura de agrupamento SDP no SIP. Essa foi tornada obsoleta pela RFC 5245;

3.18 DRAFT-SDP-MEDIA-CAPABILITIES – CMED (2010): Negociação de capacidade SDP fornece uma infra-estrutura geral para indicar e negociar capacidades no SDP. A infra-estrutura base define só capacidades para negociar protocolos e atributos de transporte. Nesse documento, amplia-se a infra ao definir a capacidade de mídia que podem ser usadas para negociar tipos de mídia e seus parâmetros associados. Essa extensão é projetada para mapear facilmente atributos de mídia existentes e futuros do SDP, mas não codifica e nem formata;

3.19 RFC 5621 (S) – Define como o corpo de mensagem de texto como no formato MIME (2009) deve ser manipulado no SIP. Esse documento atualiza as especificações das RFC’s 3204, 3261 e 3459;

4.            Mecanismos de Suporte ao NAT Transversal no SIP

4.1 As RFC 3581, RFC 5627, RFC 5626, RFC 5245 e RFC 3605 já referenciadas anteriormente também abordam a questão do NAT transversal;

4.2 DRAFT-ICE-TCP – Candidatos TCP c/o ICE (2011): O ICE define um mecanismo de NAT transversal para protocolos comunicação multimídia baseado no modelo oferta/aceite na negociação de sessão. O ICE funciona fornecendo um conjunto de endereços de transporte candidato para cada media stream, que são então validados com checagem de conectividade peer-a-peer baseado no STUN. O ICE fornece uma infra-estrutura geral para descrever candidatos, mas só define protocolos de transporte baseado no UDP. Essa especificação estende o ICE para mídia baseado no TCP, incluindo a capacidade de oferecer um mix de candidatos baseados no TCP e UDP para uma única stream;

4.3 RFC 5389 (S) – Define o Protocolo Session Traversal Utilities for NAT – STUN (2008): é o protocolo que serve como uma ferramenta para outros protocolos lidar com o NAT transversal. Ele pode ser usado por um endpoint a fim de determinar o endereço IP e a porta que lhe foi atribuído por um NAT. Também pode ser utilizado para verificar a conectividade entre duas pontas finais, e como protocolo keep-alive para manter ativo esse mapeamento de NAT. Esse documento torna obsoleto a RFC 3489;

4.4 RFC 5766 (S) – Traversal Using Relays around NAT – TURN (2010): Especifica extensões Relay ao STUN: Essa especificação define o protocolo TURN (Traversal Using Relays around NAT), que permite ao host controlar a operação relay e trocar pacotes com seus peers usando relay. O TURN difere de alguns outros protocolos de controle relay em que permite a um cliente se comunicar com múltiplos peers usando único endereço relay. O protocolo TURN foi projetado para ser usado como parte da abordagem do ICE com NAT transversal, embora ele possa ser usado também sem o ICE;

4.5 RFC 5928 (S) – Mecanismo de Resolução p/o TURN (2010): Define um mecanismo de resolução para gerar uma lista de endereços de servidor transporte que pode ser tentado para criar uma alocação TURN;

4.6 RFC 6062 (S) – Extensões ao TURN p/ Alocações TCP (2010): Essa especificação define uma extensão do TURN, um protocolo relay para NAT transversal. Essa extensão permite a um cliente TURN requisitar alocações TCP, e define novas requisições e indicações para o servidor TURN abrir e aceitar conexões TCP com os peers do cliente. O TURN e essa extensão ambos propositadamente restringem os modos pelos quais o endereço relayed pode ser usado. Em particular, isso evita os usuários de executar servidores propósito geral a partir de portas obtidas do servidor TURN. Esse documento torna obsoleto a RFC 3489;

5.            Primitivas de Controle de Chamada

5.1 RFC 3515 (S) – Define o método de transferência SIP (2003), é o chamado SIP REFER;

5.2 RFC 3725 (B) – Melhores Práticas Atuais p/ Third Party Call Control - 3pcc (2004): Define inúmeros fluxos de chamada diferentes que permite a uma entidade SIP, chamada de controlador, criar sessões SIP entre os demais agentes-usuários SIP;

5.3 RFC 3911 (S) – Campo-Cabeçalho Join do SIP: Define o campo-cabeçalho Join (2004). Quando enviado em um INVITE, esse campo faz o destinatário se unir ao diálogo resultante em uma conferência com outro diálogo em progresso;

5.4 RFC 3891 (S) – Define o método de controle para comunicações multimídia (2004), chamado SIP "Replaces" Header;

5.5 RFC 3892 (S) – Mecanismo Referred-By do SIP: Define o campo-cabeçalho Referred-By (2004). É usado em requisições disparadas por REFER, e fornece a identidade da parte sendo transferida para a parte referred-to;

5.6 RFC 4117 (I) – Invocação de Serviços Transcodificação no SIP Usando Third Party Call Control (2005): Define como usar 3pcc para os propósitos de chamar serviços de transcodificação para uma chamada;

6.            Infra-Estrutura de Evento

6.1 A RFC 3265 já referenciada antes também trata desse assunto;

6.2 RFC 3903 (S) – Define o método SIP PUBLISH para publicar estado de evento (2004): O método PUBLISH permite ao usuário criar, modificar e remover estado em outra entidade que gerencia esse estado em seu nome;

6.3 RFC 4662 (S) – Extensão de Notificação de Evento SIP para Listas de Recurso (2006): Define um recurso chamado Servidor de Lista de Recurso (RLS);

6.4 A RFC 3891 já referenciada antes também faz parte desse tópico;

6.5 RFC 5025 (S) – Regras de Autorização do mecanismo de Presença (2007): A autorização é uma função fundamental em sistemas de presença. Define políticas de autorização, também conhecido como regras de autorização especificam quais as informações de presença pode ser fornecidas a certos observadores e quando. Esta especificação define um documento no formato XML para expressar as regras de autorização de presença;

6.6 RFC 3863 (S) – Presence Information Data Format – PIDF (2004): Especifica o PIDF do Common Profile for Presence (CPP) como um formato comum de dados de presença para protocolos Presença em conformidade com o CPP, e também define um novo tipo de mídia "application/pidf+xml" para representar a entidade MIME XML para o PIDF;

6.7 RFC 5261 (S) – Infra-estrutura de Operações c/o Patch XML (2008): Utilizando Seletores de Linguagem XML Path (XPath): Define a infra-estrutura remendar o XML usando seletores de linguagem XML Path (XPath);

6.8 RFC 5262 (S) – Extensão ao PIDF p/ Presença Parcial (2008): Em ambientes onde links de largura de banda baixa e latência alta podem existir, às vezes é benéfico limitar a quantidade de informação transportada através da rede. Este documento apresenta um novo tipo de MIME que permite transportar tanto partes alteradas apenas quanto informação integral de presença baseada no PIDF;

6.9 RFC 4480 (S) – Extensões Rich ao formato PIDF (2006): O formato Rich Presence Information Data format (RPID) descreve uma extensão que adiciona elementos opcionais ao PIDF. Essas extensões fornecem informações adicionais sobre o presentity e seus contatos. A informação é projetada de sorte que muito dela possa ser derivada automaticamente, por exemplo, de arquivos calendário ou de atividade do usuário. Essa extensão inclui informações sobre o que a pessoa está fazendo, um identificador de agrupamento para uma tupla, quando um serviço ou dispositivo foi usado pela última vez, tipo de lugar onde está a pessoa, quais mídias de comunicação podem ficar privativas, relacionamento de um serviço tupla com outra presentity, mood da pessoa, fuso horário onde está, tipo de serviço que oferece, ícone refletindo o status do presentity e função completa do presentity. Essas extensões incluem informação de presença de pessoas, serviços (tuplas) e dispositivos;

6.10 RFC 4481 (S) – Extensões de Presença Temporizada ao PIDF (2006) p/ Indicar Informação de Status para Intervalos de Tempo Passado e Futuro: Estende o PIDF, adicionando uma extensão temporizada ao status (elemento ) que permite a um presentity para declarar seu status a um intervalo de tempo completo no futuro ou no passado;

6.11 RFC 4826 (S) – Formatos XML p/ Representação de Listas de Recurso (2007): Na comunicação multimídia, há uma necessidade nos sistemas de presença e de mensageira instantânea para definir URI’s que representam serviços que estão associados com um grupo de usuários. Um exemplo é um serviço de lista de recursos. Se um usuário envia uma mensagem SUBSCRIBE do SIP para URI que representa o serviço de lista de recursos, o servidor irá obter o estado dos usuários no grupo associado, e os fornece ao remetente. Para facilitar a definição desses serviços, essa especificação define dois documentos XML. Um documento contém as URI’s de serviço, junto com sua definição de serviço e uma referência ao grupo associado de usuários. O segundo documento contém as listas de usuários que são referenciados a partir do primeiro. Essa lista de usuários pode ser utilizada por outras aplicações e serviços. Ambos os documentos podem ser criados e a gerenciados com o XCAP;

6.12 RFC 4827 (S) – XCAP para Manipular Conteúdo do Documento de Presença (2007): Descreve um uso do XCAP para manipular o conteúdo dos Dados PIDF baseado nos documentos de presença. Destina-se a ser usado em sistemas de presença baseado no SIP, onde o Compositor do Evento de Estado pode usar o documento de presença manipulado pelo XCAP como uma das entradas no qual constrói o estado de presença completo do presentity;

6.13 RFC 4482 (S) – Informação de Contacto para o PIDF – CIPID (2006): O CIPID é uma extensão que adiciona elementos ao PIDF que fornecem informações adicionais de contato sobre uma presentity e seus contatos, incluindo referências às entradas da agenda e ícones;

6.14 RFC 5196 (S) – Define uma extensão ao PIDF p/ representar (2008) capacidades SIP do Agente Usuário;

6.15 RFC 5263 (S) – Extensão SIP p/ Notificação Parcial de Informação de Presença (2008): Define a notificação parcial quando o servidor de presença entrega às sentinelas apenas aquelas partes das informações de presença que mudaram em comparação com as informações de presença enviadas nas notificações anteriores. Isso reduz a quantidade de dados que é transportado através da rede;

6.16 RFC 5264 (S) – Publicação de Informação Parcial de Presença (2008): Define a solução a fim de reduzir o overhead e melhorar a eficiência do transporte, introduzindo mecanismo que permite a publicação de informações parciais de presença;

6.17 RFC 4745 (S) – Formato de Documento p/ Expressar Preferências de Privacidade (2007): Define uma infra-estrutura de políticas de autorização para controlar o acesso aos dados específicos da aplicação. Essa infra-estrutura combina aspectos de localização comum e autorização específica de presença. Um esquema XML especifica a língua na qual as regras da política comum são representadas. A infra-estrutura comum da política pode ser estendida a outros domínios de aplicação;

6.18 RFC 4661 (S) – Formato Baseado no XML para Filtragem de Notificação de Evento (2006): Esse documento apresenta um formato na forma de documento XML;

6.19 RFC 3858 (S) – Formato Baseado no XML p/ Informação do Watcher (2004): Watchers são definidos como entidades que requisitam (ou seja, inscreva-se) para obter informações sobre um recurso. Há estado relativamente complexo associado a essas subscrições;

6.20 RFC 4479 (S) – Define o modelo subjacente para dados de presença usados pelo SIP (2006) para mensageiria instantânea e para agentes de presença Presence Leveraging Extensions (SIMPLE);

6.21 RFC 5874 (S) – Formato de Documento XML p/ Indicar Mudança nos Recursos XCAP (2010): Essa especificação define um formato de documento que pode ser usado para indicar que uma muda ocorreu em um documento gerenciado pelo XCAP. Esse formato reporta qual documento foi alterado e suas tags entity anterior e nova. Ele pode reportar as diferenças entre versões do documento, usando um formato de patch XML. Ele pode reportar elemento existente e o atributo Content quando versões de um documento servidor XCAP mudar. Documentos diff XCAP podem ser entregues para diferenciar clientes usando inúmeros meios, incluindo a pacote evento do SIP;

6.22 RFC 5875 (S) – Pacote Evento XCAP Diff (2010): Esse documento descreve um pacote evento "xcap-diff" do SIP para a Infra-Estrutura de Notificação de Evento do SIP, em que os clientes podem usar para receber notificações de mudanças nos recursos XCAP. A troca de informação para sincronização inicial e atualização de documento é baseada no formato XCAP Diff;

7.            Pacotes de Eventos

7.1 RFC 3680 (S) – Pacote-Evento SIP do processo de Registro (2004): Define um pacote de evento para descobrir alterações no estado de registro. Esse documento foi atualizado pela RFC 6140;

7.2 RFC 5628 (S) – Extensão ao Pacote-Evento Registration p/ GRUU do SIP (2009): RFC 3680 define um pacote-evento SIP for registration state. Esse pacote permite a um watcher aprender sobre informação estocada por um registrador SIP, incluindo seu contacto registrado. Contudo, o contacto registrado é freqüentemente inalcançável e, portanto, inútil para watchers. O Globally Routable User Agent URI (GRUU), definido na RFC 5627, é uma URI que é capaz de alcançar um contacto particular. Contudo esse URI não foi incluído no formato definido na RFC 3680. Essa especificação define uma extensão ao pacote evento registration para incluir GRUU’s atribuída pelo registrador;

7.3 RFC 3842 (S) – Mensagem de Sumário e Pacote Evento de Mensagem (2004) de Indicação à Espera p/o SIP: Define uma forma de o agente usuário obter informações sobre mensagens de voz e outras mensagens que estão esperando por ele. Seu objetivo principal é habilitar o led de espera do correio de voz em muitos telefones empresariais;

7.4 RFC 3856 (S) – Mecanismo SIP Presence (2004) p/ monitoração de estado de ramais (Ocupado, Disponível, Tocando, Offline,... ): Esse documento descreve o uso do SIP para gerar subscriptions e notificações de presença. Presença é definida como a voluntariedade e a habilidade de um usuário se comunicar com outros usuários na rede. Historicamente, presença tem sido limitada aos indicadores "on-line" e "off-line"; a noção de presença aqui é mais ampla. Subscriptions e notificações de presença são suportadas ao se definir um pacote-evento dentro da infra-estrutura geral de notificação de evento SIP. Esse protocolo está também em conformidade com a infra-estrutura Common Presence Profile (CPP);

7.5 RFC 3857 (S) – Modelo de Pacote p/ Evento de Informação ao Watcher no SIP (2004): Também conhecido como winfo, fornece um mecanismo ao agente-usuário descobrir quais subscrições estão acontecendo para um pacote-evento particular. Seu uso principal é com presença, mas pode ser usado qualquer outro pacote-evento. Este documento define o modelo de pacote de informações watcher para a infra-estrutura de eventos SIP. Informação de watcher refere-se ao conjunto de usuários cadastrados em um recurso particular dentro de um pacote-evento particular. Informações de watcher mudam dinamicamente quando usuários se inscrevem, des-inscrevem, são aprovados ou são rejeitados. Um usuário pode se inscrever para essa informação e, portanto, aprender sobre as alterações a ela. Esse pacote-evento é um modelo de pacote, pois ele pode ser aplicado a qualquer pacote-evento, incluindo a si próprio;

7.6 RFC 4235 (S) – Pacote-Evento de Diálogo Iniciado c/ INVITE no SIP (2005): Define um pacote de evento para aprender o estado dos diálogos em progresso de um agente-usuário, e é uma das várias RFC’s que começa com o número significativo 42. Esse documento define um pacote-evento de diálogo para a arquitetura de Eventos SIP, junto com um formato de dados usado em notificações para esse pacote. O pacote de dialogo permite aos usuários se inscrever em outro usuário e receber notificação das mudanças no estado para os usos de diálogo iniciado por INVITE em que o usuário inscrito está envolvido;

7.7 RFC 4575 (S) – Pacote-Evento do SIP p/ Estado da Conferência (2006): Define um mecanismo para aprender sobre alterações no estado da conferência, incluindo membros da conferência;

7.8 RFC 4730 (S) – Pacote-Evento SIP p/ (Key Press Stimulus - KPML) (2006): Define uma forma para uma aplicação na rede subscrevera ao conjunto de key presses feito no teclado de um telefone tradicional. Essa, junto com a RFC 4733, são os dois mecanismos definidos para tratar DTMF. A RFC 4730 é uma solução no meio da sinalização, e a RFC 4733 é uma solução no caminho da mídia;

7.9   RFC 6035 (S) – Define o pacote-evento SIP que permite a coleta e a divulgação de indicadores (2010) para medir a qualidade das sessões de voz sobre a rede IP;

7.10 DRAFT-IETF-SIP-SESSION-POLICY-FRAMEWORK – Infra-Estrutura para Política de Sessão (2011): Servidores Proxy’s jogam uma função central como um intermediário no SIP quanto eles definem e impactam políticas sobre roteamento de chamada, salas de conferências, e outros recursos de chamada. Esse documento especifica uma infra-estrutura para políticas de sessão SIP que fornece um mecanismo padrão pelo qual um Proxy pode definir ou influenciar políticas nas sessões, como os Codec’s ou tipos de mídia a ser usada. Ele define um modelo, uma arquitetura geral e novos mecanismos de protocolo para políticas de sessão;

7.11 DRAFT-IETF-SIPPING-PACKAGE – Pacote-Evento p/ Política de Sessão (2010): Essa especificação define um pacote-evento SIP para políticas especificas de sessão. Esse pacote-evento permite aos agentes-usuários se inscrever a políticas de sessão para uma sessão SIP e receber notificações se essas políticas mudarem;

7.12 RFC 5362 (S) – Pacote de Eventos Adicionais ao SIP Pending (2008): Documento define um pacote-evento SIP que permite a um UA aprender se o consentimento foi ou não fornecido pela adição de um endereço a uma "lista mailing" SIP. É usado em conjunção com a RFC 5360 sobre a infra-estrutura SIP para consentimento;

8.            Qualidade de Serviço

8.1 RFC 3312 (S) – Define a integração de gerenciamento de recurso e SIP (2002): Esse documento define uma infra-estrutura genérica para precondições, que são extensíveis por meio do IANA registration. Esse documento também trata como qualidade de serviço de rede pode ser feita com uma precondição para estabelecimento de sessões iniciadas pelo SIP. Essas precondições exigem que o participante reserve recursos de rede antes de continuar com a sessão. Não se define novos mecanismos de reserva de QoS; essas precondições simplesmente exigem que um participante use os mecanismos de reserva de recurso existente antes de iniciar a sessão;

8.2 RFC 5432 (S) – Mecanismo de Seleção de QoS no SDP (2009): O modelo oferta/aceite do SDP assume que as pontas remotas de alguma forma estabeleçam o QoS exigido para mídia streams eles estabeleçam. As pontas remotas em ambientes fechados tipicamente concordam com out-of-band (p. ex., usando informação de configuração) a considerar qual mecanismo QoS a usar. Contudo, na Internet, há mais de um serviço de QoS disponível. Conseqüentemente, há uma necessidade de um mecanismo para negociar qual mecanismo de QoS a usar para uma mídia stream particular. Esse documento define tal mecanismo;

8.3 RFC 3313 (I) – Define extensões privativas ao SIP p/ autorização de mídia (2003): Esse documento descreve a necessidade de QoS e autorização de mídia e define uma extensão ao SIP que pode ser usada para integrar o controle de admissão QoS com sinalização de chamadas e ajudar a proteger contra ataques de negação de serviço. O uso dessa extensão é aplicável apenas em domínios administrativos, ou entre federações de domínios administrativos com políticas acordadas previamente, onde ambos os Proxy SIP autorizam QoS e controle da política da rede subjacente fornecendo QoS, pertencente àquele domínio administrativo ou federação de domínios;

8.4 RFC 3524 (S) – Mapeamento de Mídia Streams p/ Fluxos de Reserva de Recurso (2003): Esse documento define uma extensão à infra-estrutura de agrupamento SDP. Esse permite requisitar um grupo de mídia streams a ser mapeado em um único fluxo de reserva de recurso. A sintaxe SDP necessária é definida, bem como uma nova "semântica" para atributo chamado Single Reservation Flow (SRF) com a finalidade de QoS;

8.5 RFC 3487 (I) – Exigências de mecanismos de priorização de recurso p/o SIP (2003): Esse documento sumariza requerimentos para priorizar acesso a rede comutada por circuito, sistema da ponta e recursos de Proxy para prontidão comunicações de emergência usando o SIP;

9.            Operações e Gerenciamento

9.1 RFC 6080 (S) – Infra-Estrutura p/ Entrega de Perfil de UA SIP (2011): Esse documento especifica uma infra-estrutura para permitir configuração de UA’s SIP em implementações SIP. A infra-estrutura fornece um meio de entregar dados de perfil que UA’s precisam para ser funcional, automaticamente e com mínima ou nenhuma intervenção de Usuário e do Administrador. A infra-estrutura descreve como UA’s SIP podem descobrir origem, perfis de requisição, e receber notificações relacionadas a modificações de perfil. Como parte dessa infra-estrutura, um novo pacote-evento SIP é definido para notificação de alterações de perfil. A infra-estrutura fornece opções mínimas para recuperar dados a fim de assegurar a interoperabilidade. A infra-estrutura não inclui especificação dos dados de perfil dentro de seu escopo;

9.2 A RFC 6035 já referenciada antes também faz parte desse tópico;

10.       Compressão SIP

10.1 RFC 3320 (S) – Protocolo SigComp (2003): Esse documento define a Compressão de Sinalização (SigComp), uma solução para comprimir mensagens geradas por protocolos de aplicação como o SIP (RFC 3261) e o Real Time Streaming Protocol – RTSP (RFC 2326). A arquitetura e pré-requisitos do SigComp são detalhados, junto com o formato da mensagem SigComp. A funcionalidade de descompressão para o SigComp é fornecida por um Universal Decompressor Virtual Machine (UDVM) otimizado para a tarefa de executar algoritmos de descompressão. O UDVM pode ser configurado para tratar a saída de muitos compressores bem-conhecidos como o DEFLATE (RFC 1951);

10.2 RFC 3321 (S) – Acrescenta Operações Estendidas ao SigComp (2003): Define operações estendidas para os mecanismos com SigComp para melhoria significativa a eficiência da compressão comparada a compressão por mensagem. Essa RFC foi atualizada pela RFC 4896;

10.3 RFC 3485 (S) – Define o dicionário estático SIP e SDP p/ SigComp (2003): Esse documento foi atualizado pela RFC 4896;

10.4 RFC 3486 (S) – Compressão do SIP (2003): Esse documento descreve um mecanismo para sinalizar aquela compressão é desejada para uma ou mais mensagens SIP. Ele também declara quando é apropriado enviar mensagens SIP comprimidas a uma entidade SIP. Esse documento foi atualizado pela RFC 5049;

10.5 RFC 4896 (S) – Correções e Clarificações ao SigComp (2007): Esse documento descreve más interpretações comuns e algumas ambigüidades no SigComp, e oferece orientação aos desenvolvedores para resolver alguns problemas resultantes. SigComp define um esquema para comprimir mensagens geradas por protocolos da camada de aplicação como o SIP. Esse documento atualiza as seguintes RFC’s: 3320, 3321 e 3485;

10.6 RFC 5049 (S) – Aplicando Compressão a Sinalização (SigComp) do SIP (2007): Esse documento descreve alguns questões específicas para se aplicar quando o SigComp for usado com o SIP, como os valores mínimos padrões dos parâmetros SigComp, compartimento e gerenciamento de estado, e algumas questões de uso do SigComp sobre o TCP. Qualquer implementação do SigComp para uso com SIP precisa conformar com esse documento e com o SigComp, e adicionalmente, suportar o SIP e o dicionário estático SDP;

10.7 RFC 1950 (I) e RFC 1951 (I) – Esses documentos definem o formato comprimido (1996) sem perda de dados, algoritmo DEFLATE. O SIP usa essas especificações para compressão de dados;

11.       URI’s do Serviço SIP

11.1 RFC 3087 (I) – Define o Controle de Contexto de Serviço usando SIP Request-URI (2001): Esse documento fornece informação para a comunidade Internet. Ele descreve uma forma útil de conceituar o uso do padrão SIP Request-URI que os autores e muitos membros da comunidade SIP acham que é adequado como convenção;

11.2 A RFC 4662 já referenciada antes também faz parte desse tópico;

11.3 RFC 5363 (S) – Considerações de Infra-Estrutura e Segurança para Serviços SIP URI-List (2008): Define a infra para serviços de lista no SIP. Nessa infra, um UA pode incluir um objeto de lista XML no corpo de várias requisições e o servidor fornecerá serviços orientados à lista como conseqüência. Por exemplo, uma requisição SUBSCRIBE com uma lista subscreve a URI na lista;

11.4 RFC 5367 (S) – Subscrições ÀS Listas de Recurso Contidas na Requisição no SIP (2008): Define a infra-estrutura de lista de URI (RFC 5363). Esse documento especifica uma forma de criar subscription para uma lista de recursos no SIP. Isso é conseguido incluindo a lista de recursos no corpo de uma requisição SUBSCRIBE. Ao invés de um assinante enviar uma requisição SUBSCRIBE para cada recurso individualmente, o assinante define a lista de recurso, inscreve-se-lhes, e recebe notificações sobre alterações nos estados dos recursos usando um único diálogo SUBSCRIBE. Esse documento atualiza a RFC 3265;

11.5 RFC 5365 (S) – Requisições MESSAGE para Múltiplos-Destinatários no SIP (2008): Usa a infra-estrutura de lista-URI (RFC 5363) e permite a um cliente enviar uma MESSAGE a inúmeros destinatários;

11.6 RFC 5366 (S) – Estabelecimento de Conferência Usando Listas Contidas em Requisição (2008) do SIP: Usa a infra-estrutura de lista-URI (RFC 5363). Isso permite a um cliente perguntar ao servidor para agir como focal da conferência e enviar uma requisição INVITE contida em cada destino na lista;

11.7 RFC 4240 (I) – Serviços Básicos de Mídia em Rede SIP (2005): Define uma forma de servidores de aplicação SIP invocar serviços de anúncios e conferência a partir de um servidor de mídia. Isso é realizado através de um conjunto de parâmetros URI definidos que diz ao servidor de mídia o que fazer como qual arquivo tocar e em qual linguagem renderizá-lo;

11.8 RFC 4458 (I) – URI’s do SIP para Aplicações como Voicemail e IVR (2006): Define uma forma para invocar serviços voicemail e IVR usando um URI SIP construída de uma forma particular;

11.9 RFC 4904 (S) – Representação de Grupos de Troncos nos URI’s tel/sip (2007): Define um mecanismo padronizado para transportar parâmetros sobre grupo de tronco nas URI’s SIP/ tel. Uma extensão do URI tel é definida com essa finalidade;

11.10 RFC 5954 (S) – Correção Essencial p/ ABNF IPv6 e Confrontação de URI na RFC 3261 (2010): Esse documento corrige as regras de geração de Augmented Backus-Naur Form (ABNF) associados com a geração de literais IPv6 na RFC 3261. Essa também esclarece a regra para comparação URI quando as URI’s contêm a representação textual de endereços IP;

11.11 RFC 3968 (B) – Registro de Parâmetro Campo-Cabeçalho IANA p/o SIP (2004): Esse documento cria um registro IANA para os parâmetros campo-cabeçalho do SIP e valores de parâmetro. Também lista os parâmetros já existentes e valores de parâmetro a ser usados como entradas iniciais para esse registro. Esse documento atualiza a RFC 3427;

11.12 RFC 3969 (B) – Registro de Parâmetro URI do IANA p/ SIP (2004): Esse documento cria um registro IANA p/os parâmetros URI do SIP e do SIPS, e seus valores. Esse documento também lista os parâmetros já existentes a ser usados como valores iniciais para esse registro. Esse documento é atualizado pela RFC 5727. Ele atualiza a RFC 3427;

12.       Extensões Secundárias

12.1 RFC 4488 (S) – Supressão de Subscription Implícitos do Método SIP REFER (2006): Esse documento define o campo cabeçalho "Refer-Sub" e a tag "norefersub" no SIP usado somente dentro de transação REFER. O método REFER especifica que todo REFER cria uma subscrição implícita entre o lançador do REFER e o receptor do REFER. Esse campo cabeçalho, quando definido como "falso", especifica que o originador do REFER requisita ao receptor do REFER para não estabelecer uma subscrição implícita e o diálogo resultante;

12.2 RFC 4538 (S) – Autorização de Requisição por meio da Identificação do Diálogo no SIP (2006): Fornece mecanismo que permite ao UAS autorizar uma requisição porque quem requisita prova que conhece um diálogo que está em progresso com o UAS. A especificação é útil em conjunção com a infra-estrutura de interação da aplicação SIP [INTERACT-FRAME];

12.3 RFC 4508 (S) – Transporte de Tag’s Feature no Método REFER do SIP (2006): Define um mecanismo para transportar tags conforme a RFC 3840 em requisição REFER. Isso é útil para informar ao destino do REFER sobre as características do destino tencionado da requisição referred;

12.4 RFC 5373 (S) – Modos de Atendimentos a Requisição no SIP (2008): Define uma extensão para indicar à parte chamada se telefone deve ou não ringar e/ou ser atendido imediatamente. Isso é útil para push-to-talk e para aplicações diagnostico;

12.5 RFC 5079 (S) – Rejeitando Requisições Anônimas no SIP (2007): Esse documento define um mecanismo para uma parte chamada indicar à parte chamante que uma chamada foi rejeitada quando o chamador for anônimo. É necessário para implementar o recurso Anonymous Call Rejection (ACR) no SIP;

12.6 RFC 5368 (S) – Referring a Múltiplos Recursos no SIP (2008): Permite a um UA enviar uma REFER para pedir ao destino do REFER para gerar múltiplas requisições SIP, e não apenas uma. Isso é útil para conferencia, onde um cliente gostaria de pedir a um servidor de conferencia para ejetar múltiplos usuários;

12.7 RFC 4483 (S) – Mecanismo p/ Indireção de Conteúdo nas Mensagens SIP (2006): Esse documento define um mecanismo para indireção de conteúdo. Ao invés de transportar um objeto dentro do corpo da mensagem SIP, uma referência a URL é transportada no lugar, e o destino dereferencia a URL para obter o objeto. A especificação tem a aplicabilidade potencial para enviar grandes mensagens instantâneas, mas ainda precisa encontrar mais uso real;

12.8 RFC 3890 (S) – Modificador de Transporte Independente de Banda no SDP (2004): Esse documento especifica uma extensão SDP que permite a descrição da banda para uma sessão de mídia que é independente do mecanismo de transporte subjacente;

12.9 RFC 4583 (S) – Formato SDP p/ Streams Binary Floor Control Protocol – BFCP (2006): Esse documento define um mecanismo no SDP para sinalizar streams para controle de sala de conferência que usam BFCP. Isso é usado para controle de sala push-to-talk e de conferência;

12.10 RFC 5898 (S) – Precondições de Conectividade p/ Mídia Streams no SDP (2010): Esse documento define uma nova precondição de conectividade para a Infraestrutura precondição do SDP. Uma precondição de conectividade pode ser usada para atrasar o estabelecimento ou modificação de sessão até que a conectividade da mídia stream tenha sido verificada com sucesso. O método de verificação pode variar dependendo do tipo de transporte usado para a mídia. Para transportes de datagramas não confiáveis como UDP, verificação envolve sondar o stream com pacotes dados ou de controle. Para transportes confiáveis orientados a conexão como TCP, verificação pode ser conseguido simplesmente pelo estabelecimento conexão bem sucedido ou sondando a conexão com pacotes de dados ou controle, dependendo da situação;

12.11 RFC 4796 (S) – Acrescenta Atributo Content no SDP (2007): Esse documento define um atributo no SDP para descrever a finalidade de uma stream de mídia. Exemplos incluir um slide view, o speaker, um sinal feed de linguagem, e assim por diante;

12.12 RFC 6157 (S) – Transição p/o IPv6 no SIP (2011): Esse documento descreve como the IPv4 SIP agentes-usuários podem se comunicar com IPv6 SIP agentes-usuários (e vice-versa) na camada de sinalização bem como troca media uma vez que a sessão tenha sido estabelecida com sucesso. Ambas as pilhas única e dual (ou seja, só IPv4 e IPv4/IPv6) agentes-usuários serão considerados;

12.13 RFC 5923 (S) – Reuso de Conexão SIP (2010): Esse documento permite a um par de Proxy’s se comunicando reusar uma conexão controlada por congestionamento entre eles para enviar requisições nas direções pra-frente e pra-trás. Como a conexão é essencialmente aliased para requisições seguindo na direção pra-trás, reuso é previsto em ambos as pontas remotas se comunicando autenticando entre si usando certificados X.509 por meio do TLS. Por essa razão, nós só consideramos reuso de conexão para TLS sobre o TCP e TLS sobre o SCTP. Esse documento também fornece orientações sobre reuso de conexão e servidores SIP virtuais e a interação de reuso de conexão e consultas DNS SRV no SIP;

13.       Mecanismos de Segurança

13.1 A RFC 4474 já mencionada antes faz parte desse tópico;

13.2 A RFC 4916 já mencionada antes faz parte desse tópico;

13.3 A RFC 5630 já mencionada antes faz parte desse tópico;

13.4 RFC 5922 (S) – Trata da ampliação da capacidade de certificação/autenticação (2010) de Domínio no SIP, conforme a RFC 5280 que trata desse assunto. Esse documento atualiza a RFC 3261;

13.5 A RFC 3323 já mencionada antes faz parte desse tópico;

13.6 RFC 4567 (S) – Extensões ao SDP e ao RTSP p/ Gerenciamento de Chave (2006): Define extensões ao SDP que permitem o tunelamento de um protocolo de gerenciamento de chave, ou seja, MIKEY, através de trocas de mensagem oferta/aceite. Esse mecanismo é uma de três técnicas de codificação SRTP especificado para o SIP, Datagram Transport Layer Security (DTLS-SRTP) [SRTP-FRAME] sendo selecionado como a solução final;

13.7 RFC 4568 (S) – Descrições de Segurança do SDP p/ Fluxo de Mídia (2006): Define extensões ao SDP que permite na negociação material codificado diretamente através da oferta/resposta, sem um protocolo de gerenciamento de chave separado. Esse mecanismo, às vezes é chamado de sdescriptions, tem a desvantagem de que as chaves de mídia estão disponíveis a qualquer entidade que seja visível ao SDP. É uma de três técnicas de codificação SRTP especificado para o SIP, DTLS-SRTP [SRTP-FRAME] foi selecionado como a solução final;

13.8 RFC 5763 (S) – Infra-Estrutura DTLS-SRTP (2010): Esse documento especifica como usar o SIP para estabelecer um contexto seguro SRTP usando o protocolo Datagram Transport Layer Security (DTLS). Esse descreve um mecanismo de transporte de um atributo fingerprint no SDP que identifica a chave que será apresentada durante o handshake DTLS. A troca de chave viaja junto com o caminho de mídia em oposição ao caminho de sinalização. O mecanismo de Identidade SIP pode ser usado para proteger a integridade do atributo fingerprint a partir da modificação pelos Proxy’s intermediários;

13.9 RFC 3853 (S) – Define as exigências para uso do AES c/ S/MIME (2004), porque o SIP atualmente detalha suporte opcional (normativamente PODE) ao MIME seguro ou S/MIME (RFC 2633). Esse documento atualiza a RFC 3261;

13.10 RFC 6072 (S) – Serviço de Gerenciamento de Certificado p/o SIP (2011): Esse documento define um serviço de credencial que permite aos UA’s SIP usar um pacote-evento SIP para descobrir os certificados de outros usuários. Esse mecanismo permite aos Agentes-Usuários que desejam se contactar a um dado Address-of-Record (AOR) a fim de recuperar esse certificado AOR se inscrevendo ao serviço de credencial, o qual retorna uma resposta autenticada contendo tal certificado. O serviço de credencial também permite aos usuários armazenar e recuperar seus próprios certificados e chaves privadas;

13.11 RFC 3893 (S) – Formato Authenticated Identity Body (AIB) do SIP (2004): Define um fragmento de mensagem SIP que pode ser sinalizado a fim de fornecer uma identidade autenticada em uma requisição. Foi a primeiro predecessor da (RFC 4474), e conseqüentemente AIB não foi implementada;

13.12 DRAFT-SIP-SAML – Perfil e Binding sobre o SIP (2010): Esse documento especifica um perfil SIP de Security Assertion Markup Language (SAML) bem como um binding SAML SIP. O Perfil SIP SAML definido compõe com os mecanismos definidos na especificação de Identidade SIP e satisfaz requerimentos apresentados em "Trait-based Authorization Requirements for the SIP”;

13.13 RFC 5360 (S) – Infra-Estrutura para Comunicações Baseado no Consentimento no SIP (2008): Define várias extensões ao SIP, incluindo os campos-cabeçalhos Trigger-Consent e Permission-Missing. Esses campos-cabeçalhos, em adição a outros procedimentos definidos no documento, definem uma forma de gerenciar membros nas "listas mailing do SIP" usadas por mensageira instantânea ou conferência. Em particular, ajuda evitar o problema de usar tais serviços de amplificação com o propósito de um ataque na rede tornando seguro a um usuário autorizar a adição de seus endereços em tal serviço;

13.14 RFC 5361 (S) – Formato de Documento para Requisição de Consentimento (2008): Define um objeto XML usado pela infra-estrutura de consentimento. Documentos de Consentimento são enviados a partir dos "servidores da lista mailing" SIP para os usuários a fim de lhes permitirem gerenciar seus membros nas listas;

13.15 A RFC 5362 já mencionada antes faz parte desse tópico;

13.16 RFC 3329 (S) – Define o acordo sobre o mecanismo de segurança para o SIP (2003): Esse documento define nova funcionalidade para negociar os mecanismos de segurança usados entre um agente-usuário SIP e sua entidade SIP next-hop. Essa nova funcionalidade suplementa os métodos existentes de escolha de mecanismos de segurança entre entidades SIP;

13.17 RFC 4572 (S) – Transporte de Mídia Orientada a Conexão sobre o Protocolo TLS no SDP (2006): Especifica um mecanismo para sinalizar streams de mídia baseado no TLS entre endpoints. Essa expande os parâmetros de sinalização de mídia baseado no TCP definido na RFC 4145 para incluir informação fingerprint para streams TLS de sorte que o TLS possa operar entre endpoints usando certificados auto-sinalizados. Esse documento atualiza a RFC 4145;

13.18 RFC 5027 (S) – Precondições de Segurança para Streams de Mídia no SDP (2007): Define uma precondição para usar com a infra-estrutura de precondições da RFC 3312. A precondição de segurança previne uma sessão de ser estabelecida até que uma stream de mídia segura seja estabelecida. Esse documento atualiza a RFC 3312;

13.19 RFC 3310 (I) – Autenticação Digest HTTP Usando Autenticação e Acordo de Chave (2002): define uma extensão a autenticação digest a fim de permiti-lo funcionar com as credencias estocadas em telefones celulares. Embora tecnicamente essa seja uma extensão ao HTTP digest, sua aplicação primária é com o SIP. Essa extensão é útil primariamente aos implementadores de IMS;

13.20 RFC 4169 (I) – Autenticação Digest HTTP Usando Autenticação e Acordo de Chave (AKA) Versão-2 (2005): é uma melhoria a RFC 3310 que melhora ainda mais a segurança da autenticação;

13.21 DRAFT-TLS-USE-SIP – Uso do TLS no SIP (2006): Define o uso do Transport Layer Security (TLS) especificamente para o SIP com base na RFC 5246 do TLS e suas extensões para uso no SIP, no transporte seguro das mensagens-sinalização do SIP. O SPI pode usar o TLS para transporte criptografado de suas mensagens-sinalização;

13.22 RFC 3324 (I) – Define exigências de termo curto para identidade segura na rede (2002);

13.23 RFC 2617 (S) – O SIP usa o esquema de autenticação HTTP Digest (1999). Essa RFC já entrou na fase DS. Esse documento torna obsoleto a RFC 2069;

13.24 RFC 5393 (S) – Trata do problema da amplificação da vulnerabilidade de segurança (2008) quando Proxy’s SIP bifurcam. Esse documento atualiza a RFC 3261;

14.       Implementação de Conferências

14.1 RFC 4574 (S) – Acrescenta Atributo Label ao SDP (2005): Define um atributo ao SDP para fornecer um rótulo opaco para media streams. Esses rótulos podem ser referenciados por documentos externos, e em particular, por documentos políticas de conferência. Isso permite a um UA juntar documentos que podem obter através de mecanismos de conferencia para media streams para os quais eles se referem;

14.2 A RFC 3911 já mencionada antes faz parte desse tópico;

14.3 A RFC 4575 já mencionada antes faz parte desse tópico;

14.4 A RFC 5368 já mencionada antes faz parte desse tópico;

14.5 A RFC 5366 já mencionada antes faz parte desse tópico;

14.6 RFC 4579 (B) – Controle de Chamada SIP – Conferência por Agentes-Usuários (2006): define melhores práticas de procedimentos e de fluxos de chamada em conferência. Isso inclui criação, adesão e discagem da conferência, entre outras capacidades;

14.7 A RFC 4583 já mencionada antes faz parte desse tópico;

14.8 RFC 5589 (B) – Controle de Chamada SIP – Transferência: descreve o provimento de capacidades Transferência de Chamada no SIP. Extensões ao SIP como REFER e Replaces são usadas para fornecer inúmeros serviços de transferência incluindo os tipos de transferência às cegas, consultiva e assistida. Esse trabalho é parte da infra-estrutura de controle de chamada multiparticipantes do SIP;

15.       Mensageiria Instantânea, Presença e Multimídia

15.1 RFC 3428 (S) – Esse documento define extensões ao SIP para mensageiria instantânea (2002);

15.2 A RFC 3856 já mencionada antes faz parte desse tópico;

15.3 A RFC 3857 já mencionada antes faz parte desse tópico;

15.4 RFC 5547 (S) – Modelo Oferta/Aceite SDP p/ Transferência de Arquivo (2009): Esse documento fornece um mecanismo para negociar a transferência de um ou mais arquivos entre dois endpoints usando o modelo oferta/aceite do SDP especificado na RFC 3264. O SDP é estendido para descrever os atributos dos arquivos a ser transferido. O ofertador pode descreve tanto os arquivos que ele deseja enviar quanto os arquivos que ele gostaria de receber. O aceitador pode tanto aceitar quanto rejeitar a oferta separadamente para cada arquivo individual. A transferência de um ou mais arquivos é iniciada após uma negociação bem sucedida. O Protocolo Message Session Relay (MSRP) é definido como o mecanismo default para transportar realmente os arquivos entre os endpoints. As convenções de como usar o MSRP para transferência de arquivo são também fornecidas nesse documento;

15.5 RFC 3861 (S) – Resolução de Endereço para Mensageiria Instantânea e Presença (2004): Este documento fornece orientação para localizar recursos associados com URI’s que empregam esquemas 'im' para INSTANT INBOXes e 'pres' para PRESENTITIES;

15.6 RFC 3862 (S) – Common Presence and Instant Messaging - CPIM (2004): Define o tipo 'Message/CPIM' de conteúdo MIME, um formato de mensagem para protocolos que obedecem à especificação CPIM;

16.       Serviços de Emergência

16.1 RFC 4411 (S) – Extensão ao Campo-Cabeçalho Reason do SIP para Eventos de Antecipação (2006): Define uma extensão ao campo-cabeçalho, para permitir a uma UA saber qual diálogo foi descartado porque uma sessão de prioridade mais alta apareceu;

16.2 RFC 4412 (S) – Prioridade de Recurso de Comunicações para o SIP (2006): Define um novo campo-cabeçalho, Resource-Priority, que permite a uma sessão ganhar tratamento prioritário da rede;

16.3 DRAFT-SIPCORE-LOCATION-CONVEYANCE – Transporte de Localização no SIP (2011): Esse documento define uma extensão ao SIP para transmitir informação de localização geográfica de uma entidade SIP para outra entidade SIP. A extensão SIP cobre o transporte fim-a-fim bem como roteamento baseado em localização, onde os intermediários SIP tomam as decisões de roteamento baseadas na localização do Location Target;

17.       Protocolos Fundamentais que Servem ao SIP: SDP, RTP, RTCP, SRTP

17.1 RFC 3550 (S) – Protocolo de transporte mídia em tempo real – RTP (2003): Esse documento define o RTP que fornece serviços de entrega fim-a-fim para dados com características de tempo real, como áudio e vídeo interativo. É nessa RFC que também é definido o protocolo Real-time Transport Control Protocol (RTCP). O SIP usa o RTP para o transporte de mídia. Esse documento já entrou no estágio STD. Esse documento é atualizado pelas RFC’s 5506, 5761, 6051 e 6222. Ele também tornou obsoleto a RFC 1889;

17.2 RFC 3551 (S) – Descreve o perfil "RTP/AVP" p/ uso do RTP, versão 2 (2003): É o protocolo de controle associado, RTCP, dentro de conferências de áudio e vídeo com múltiplos participantes com controle mínimo. Esse documento é atualizado pela RFC 5761. Esse documento já entrou no estágio STD. Ele também tornou obsoleto a RFC 1890;

17.3 RFC 3984 (OS) – Formato de Payload RTP p/ Vídeo H.264 (2005): Esse documento descreve o formato Payload RTP para o codec de vídeo da Recomendação H.264 do ITU-T e o codec vídeo tecnicamente idêntico do International Standard 14496-10 da ISO/IEC. Esse documento foi obsoletado em favor da RFC 6184;

17.4 RFC 6184 (S) – Formato de Payload RTP p/ Vídeo H.264 (2011): Esse documento descreve um formato Payload RTP para o codec de vídeo H.264 da Recomendação ITU-T e o codec de vídeo 14496-10 tecnicamente idêntico do Padrão Internacional ISO/IEC, excluindo a extensão Scalable Video Coding (SVC) e a extensão Multiview Video Coding, para os quais os formatos de payload RTP são definidos elsewhere. O formato de payload RTP permite pacotização de uma ou mais Network Abstraction Layer Units (NALUs), produzido por um codificador de vídeo H.264, em cada payload RTP. O formato de payload tem aplicabilidade ampla, porque ela suporta aplicações de simples uso conversacional de baixa taxa de bit, a stream de vídeo na Internet com transmissão com interleaving, a vídeo-on-demand com alta taxa de bit. Esse documento torna obsoleto a RFC 3984. Mudanças da RFC 3984 são sumarizadas na Seção 14. Questões de retro-compatibilidade com RFC 3984 são discutidas na Seção 15 da mesma;

17.5 RFC 3389 (S) – Formato de payload RTP para transporte de CN (2002): Esse documento define um tipo de payload para comfort noise (CN) é primariamente usado com Codec’s de áudio que não suportam ruído de conforto como parte do codec em si como os Codec’s G.711, G.726, G.727, G.728 e G.722 das Recomendações ITU-T;

17.6 RFC 2833 (OS) – Define sinais de Tom (2000): Esse documento descreve como transportar sinalização DTMF, outros sinais de tons e eventos de telefonia em pacotes RTP. Essa especificação ficou obsoleta em favor das RFC’s 4733 e 4734;

17.7 RFC 4733 (S) – Payload RTP para Dígitos DTMF, Tons de Telefonia e Sinais de Telefonia (2006): Descreve como transportar sinalização DTMF, outros sinais de tom e eventos de telefonia em pacotes RTP. Essa tornou obsoleta a RFC 2833;

17.8 RFC 3952 (E) – Define o formato do Payload RTP p/o Codec de fala na internet iLBC (2004) e os detalhes necessários para o uso do iLBC com o MIME e o SDP;

17.9 RFC 3267 (OS) – Especifica o formato do Payload RTP (2002) a ser usado por sinais de fala codificada Adaptive Multi-Rate (AMR) e Adaptive Multi-Rate Wideband (AMR-WB). Esse documento foi obsoletado pela RFC 4867;

17.10 RFC 4734 (S) – Eventos de Telefonia p/ Modem, Fax e Texto (2006): Essa atualiza a RFC 4733 ao acrescentar códigos de eventos para sinalização de telefonia de modem, fax e texto quando transportado no payload RTP de eventos de telefonia. Substitui a atribuição de códigos de evento para esse propósito na RFC 2833 e conseqüentemente tornou obsoleta tal parte da RFC 2833;

17.11 RFC 3711 (S) – Secure Real-time Transport Protocol – SRTP (2004): Define o SRTP que tem a finalidade de garantir a confidencialidade, autenticação de mensagens e proteção a respostas ao tráfego RTP e ao tráfego do controle do RTCP. O SIP pode requisição os serviços do SRTP para o transporte criptografado da mídia. Esse documento foi atualizado pela RFC 5506;

17.12 RFC 3830 (S) – Codificação Multimídia Internet KEYing (MIKEY) na Internet (2004): Este documento descreve em detalhes um esquema de gerenciamento de chaves para uso no SRTP que podem ser usado para aplicações em tempo real (tanto para comunicação fim-a-fim quanto para comunicação em grupo). Esse documento foi atualizado pela RFC 4738;

17.13 RFC 4738 (S) – MIKEY-RSA-R – Modo Adicional de Distribuição de Chave no MIKEY (2006): A especificação MIKEY descreve vários modos de distribuição de chave que tratam cenários multimídia (p. ex., chamadas SIP e sessões RTSP) usando chaves pré-compartilhadas, chaves públicas e, opcionalmente, uma troca de chave Diffie-Hellman. No modo chave-pública, o Iniciador encripta uma chave randômica com a chave pública do Respondedor e a envia ao Respondedor. Em muitos cenários de comunicação, o Iniciador pode não saber a chave pública do Responder, ou em alguns casos o ID do Respondedor (p. ex., encaminhar chamada) adiante. Esse modo também melhora o suporte ao gerenciamento de chave de grupo no MIKEY. Esse documento atualiza a RFC 3830 com o modo RSA-R;

17.14 RFC 3611 (S) – RTP Control Protocol Extended Reports – RTCP XR (2003): Define o tipo de pacote Extended Reports (XR) para o RTCP, e define como o uso de pacotes XR pode ser sinalizado por uma aplicação que emprega o SDP. Pacotes XR são compostos de blocos de relatório, e sete tipos de blocos são definidos aqui. Algumas aplicações, como inferência multicast de características de rede (MINC), ou de monitoramento do transporte de Voz sobre IP (VoIP), exigem outras estatísticas mais detalhadas;

17.15 RFC 2429 (OS) – Especifica o formato de cabeçalho para o payload RTP (1998) aplicável à transmissão de streams de vídeo gerado baseado na versão 1998 da Recomendação H.263 do ITU-T. Essa RFC ficou obsoleta em favor da RFC 4629;

17.16 RFC 4629 (S) – Formato de Payload RTP para Vídeo H.263 do ITU-T Rec. (2007): Esse documento descreve um esquema para pacotizar stream de vídeo no formato H.263 para transporte usando o RTP com qualquer dos protocolos subjacentes carregando o RTP. O documento também descreve a sintaxe e a semântica dos parâmetros SDP necessários para suportar o codec de vídeo H.263. Esse documento torna obsolete a RFC 2429 e atualiza as partes sobre os tipos de mídia H263-1998 e H263-2000 na RFC 3555;

17.17 RFC 2327 (OS) – SDP: Essa especificação foi a primeira do SDP (1998): O SDP é pensado para descrever sessões multimídia com os propósitos de anuncio de sessão, estabelecimento de sessão, e outras formas de inicialização de sessão multimídia. Esse documento foi o resultado do grupo de trabalho Multiparty Multimedia Session Control (MMUSIC) da Força Tarefa da Engenharia Internet. Essa RFC ficou obsoleta em favor da RFC 4566, e foi atualizada pela RFC 3266;

17.18 RFC 3266 (OS) – Suporte para o IPv6 no SDP (2002): Esse documento descreve o uso de endereços do IPv6 em conjunção com o SDP. Especificamente, esse documento clarifica o texto existente no SDP com respeito à sintaxe de endereços IPv6. Essa RFC ficou obsoleta em favor da RFC 4566;

17.19 RFC 2198 (S) – Payload RTP para Dados de Áudio Redundante (1997): Esse documento descreve o formato do payload para uso com o RTP, versão 2, para codificar dados de áudio redundante. A motivação primária para o esquema descrito aqui é o desenvolvimento de ferramentas para implementação de conferência com áudio para uso com redes com perda de pacotes tais como Mbone (Multicast backbone) Internet, embora esse esquema não esteja limitado a somente tais aplicações;

17.20 RFC 1889 (OS) – Esse documento foi a primeira especificação a descrever o RTP (1996): O RTP fornece funções de transporte de rede fim-a-fim apropriada para aplicações que transmitem dados em tempo real, como dados de áudio, vídeo ou simulação, sobre serviços de rede multicast ou unicast. O RTP não trata de reserve de recurso e não garante serviço de qualidade para serviços em tempo real. O transporte de dados é acrescido por um protocolo de controle (RTCP) a fim de permitir monitorar a entrega de dados de uma forma escalável para grandes redes multicast, e fornecer controle mínimo e funcionalidade de identificação. O RTP e o RTCP são projetados para ser independentes das camadas de rede e de transporte subjacentes. O protocolo suporta o uso de tradutores e mixadores em nível do RTP. As especificações dessa RFC ficaram obsoletas em favor da especificação que consta na RFC 3550;

17.21 RFC 6222 (S) – Orientações p/ Escolher Canonical Names – CNAME’s do RTCP (2011): O Canonical Name (CNAME) do RTCP é um identificador persistente em nível de transporte para uma ponta remota RTP. Enquanto o identificador Synchronization Source (SSRC) de uma ponta remota RTP pode alterar se uma colisão for detectada ou quando a aplicação RTP é reiniciada; seu CNAME do RTCP é pensado para ficar inalterado, de sorte que as pontas remotas RTP possam ser exclusivamente identificadas e associadas com suas streams de mídia RTP. Para funcionalidade apropriada, os CNAME’s do RTCP devem ser únicos dentre os participantes de uma sessão RTP. Contudo, as orientações existentes para escolher o CNAME do RTCP fornecido no padrão RTP são insuficientes para conseguir essa exclusividade. Essa RFC atualiza aquelas orientações da RFC 3550, a fim de permitir às pontas escolher CNAME’s únicos do RTCP;

17.22 RFC 6051 (S) – Sincronização Rápida de Fluxos RTP (2010): Esse documento descreve como sessões RTP são sincronizadas, e discute como tal sincronização pode ocorrer rapidamente. Nós mostramos que muitas sessões RTP podem ser sincronizadas imediatamente, mas que o uso de switch de vídeo Multipoint Conference Units (MCU’s) ou grandes grupos Source-Specific Multicast (SSM) podem aumentar enormemente o atraso de sincronização. Esse aumento no atraso pode ser inaceitável para algumas aplicações que usam Codec’s empilhados e/ou multidescrição. Esse documento introduz três mecanismos para reduzir o atraso de sincronização para tais sessões. Primeiro, atualiza as regras de temporização do RTCP para reduzir o atraso da sincronização inicial para sessões SSM. Segundo, um novo pacote feedback é definido para uso com o perfil RTP estendido para feedback (RTP/AVPF) baseado no RTCP, permitindo aos switch’s MCU’s de vídeo rapidamente requisitar re-sincronização. Finalmente, novas extensões de cabeçalho RTP são definidas para permitir rápida sincronização de aderentes posteriores, e garantir a ordem correta de decodificação baseada no timestamp a fim de recuperar Codec’s empilhados na presença de relógio impreciso. Essa especificação atualiza a RFC 3550;

17.23 RFC 5761 (S) – Multiplexando RTP e RTCP (2010): Esse documento trata das questões que surgem ao multiplexar pacotes dados RTP e pacotes RTCP em uma única porta UDP. Ele descreve quando tal multiplexação é e não é apropriada, e explana como o SDP pode ser usado para sinalizar sessões multiplexadas. Essa especificação atualiza as RFC’s 3550 e 3551;

17.24 RFC 5506 (S) – Reduced-Size RTCP no Perfil RTP (2009): Esse documento trata os benefícios e questões que surgem quando permitindo pacotes RTCP ser transmitidos com tamanho reduzido. O tamanho pode ser reduzido se as regras de como criar pacotes compostos descritos na RFC 3550 são removidos ou alterados. Baseado nessa analise, esse documento define certas mudanças as regras para permitir mensagens feedback a ser enviadas como pacotes RTCP com Tamanho Reduzido sob certas condições ao usar o perfil RTP/AVPF (Real-time Transport Protocol/Audio-Visual Profile with Feedback – RFC 4585). As especificações desse documento atualizam as RFC's 3550, 3711 e 4585;

17.25 RFC 4585 (S) – RTP/AVPF (2006): Streams de mídia em tempo real que usam o RTP são, em algum grau, resiliência contra perdas de pacotes. Receptores podem usar os mecanismos base do RTCP para reportar estatísticas de recepção de pacote e assim permitir ao remetente adaptar seu comportamento de transmissão no médio prazo. Esse é o único meio para feedback e reparar erro baseado em feedback (além de alguns mecanismos específicos de codec). Esse documento define uma extensão ao Audio-Visual Profile (AVP) que permite aos receptores fornecer, estatisticamente, feedback mais imediato aos remetentes e assim permitir adaptação em curto prazo e mecanismos de reparo eficientes baseado no feedback a ser implementado. Esse perfil de feedback inicial (AVPF) mantém as restrições de largura de banda do AVP no RTCP e preserva escalabilidade para grupos grandes. Essa especificação é atualizada pela RFC 5506;

17.26 RFC 1890 (OS) – AV Profile – Perfil RTP p/ Conferências c/ Áudio e Vídeo c/ Controle Mínimo (1996): Descreve um perfil para o uso do RTP, versão 2, e o protocolo de controle associado, o RTCP, dentro de conferências com áudio e vídeo multiparticipantes com controle mínima. Ela fornece interpretações de campos genéricos dentro da especificação RTP adaptável para conferências com áudio e vídeo. Em particular, esse documento define um conjunto de mapeamentos default de numerosos tipos de payload para codificações. O documento também descreve como dados de áudio e vídeo podem ser transportados dentro do RTP. Ela define um conjunto de codificações padrões e seus nomes quando usado dentro do RTP. Contudo, as definições de codificação são independentes do mecanismo particular de transporte usado. As descrições fornecem apontadores para referenciar implementações e os padrões detalhados. Esse documento é pensado como uma meta aos implementores de áudio, vídeo e outras aplicações multimídia de tempo real. Essa especificação ficou obsoletada pela RFC 3551;

17.27 RFC 6189 (I) – ZRTP Acordo de Chave p/ Caminho de Mídia p/ RTP Unicast Seguro (2011): Esse documento define o ZRTP, um protocolo para troca Diffie-Hellman de caminho de mídia para acordo sobre uma chave de sessão e parâmetros para estabelecimento SRTP unicast para aplicações VoIP. O protocolo ZRTP é codificado no caminho da mídia porque ele é multiplexado na mesma porta do RTP e não requer suporte no protocolo de sinalização. O ZRTP não supõe uma Public Key Infrastructure (PKI) ou requer a complexidade de certificados nos dispositivos das pontas. Para a sessão de mídia, o ZRTP fornece confidencialidade, proteção contra ataques man-in-the-middle (MiTM), e, em casos onde o protocolo de sinalização fornece proteção de integridade e autenticação de ponta-a-ponta. O ZRTP pode usa uma atributo SDP para fornecer discovery e autenticação através do canal de sinalização. Para prover menor esforço ao SRTP, o ZRTP usa perfis RTP/AVP (Audio-Visual Profile) normal. O ZRTP assegura sessões de mídia que inclui stream de voz e pode também assegurar sessões de mídia que não inclui voz usando uma assinatura digital opcional;

17.28 RFC 5244 (S) – Define Eventos p/ Sinalização de Telefonia Orientada a Canal (2008): Essa atualiza a RFC 4733 ao acrescentar códigos de evento para sinalização de telefonia usada pela sinalização de canal-associado quando transportado no payload RTP dos eventos de telefonia. Substitui e acrescenta a atribuição original de códigos de evento para esse propósito na Seção 3.14 da RFC 2833. Conforme documentado no Apêndice A da RFC 4733, alguns dos eventos da RFC 2833 ficaram obsoletos por causa de sua especificação que era ambígua, errônea, ou redundante. De fato, o grau de mudança da Seção 3.14 da RFC 2833 é tal que as implementações do presente documento serão completamente retro-compatíveis com as implementações da RFC 2833 só no caso dos bits de sinalização ABCD completa. Esse documento expande e melhora a cobertura para o sistema de sinalização comparado com a RFC 2833. Esse documento atualiza a RFC 4733;

18.       Recursos Acessórios

18.1 RFC 3050 (I) – Define a interface CGI p/o SIP (2001);

18.2 RFC 3319 (S) – Define as opções DHCP-IPv6 para servidores SIP (2003);

18.3 RFC 3361 (S) – Define a opção DHCP-IPv4 para servidores SIP (2002);

18.4 RFC 4825 (S) – Define o Protocolo XML Configuration Access Protocol (XCAP) (2007).

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

Autor

Tópicos

Postagem

Muito Bem Vindo

terça-feira, 14 de junho de 2011

Porque Alguns Padrões Prevalecem Sobre Outros

terça-feira, 7 de junho de 2011

Constelação de RFC's que Especificam o SIP