Category Archives: Telefonia

Habilitar licença de fax no Asterisk

tux_kisuke

Eae pessoal, testei a instalação do free fax for asterisk que você pode obter no site do asterisk.org faça seu cadastro completo, e clique na opção FAX LICENSE FREE.

Objetivo no meu caso foi gerar esse post, não uso fax eu diria a alguns anos, porém tem o fax to pdf que é bem legal.

Com a licença free seu asterisk terá 1 canal habilitado para fax.

Segue abaixo o passo a passo que a digium me passou para instalar a licença no meu asterisk 11.

 

Routing básico no OpenSips

Na configuração abaixo OpenSIPS não trata o tráfego de áudio/RTP, este é passado diretamente para o servidor Asterisk/A2Billing.

O código a seguir é o todo OpenSIPS.cfg, depois quero adicionar o artigo todo após testado completamente.

 

 

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

asterisksss

Achei esse material formidável, e publico para vocês agora verem como o mundo de voz é complexo se for tratado corretamente.

 

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).

Origem: http://www.clevitonmendes.blogspot.com.br/search/label/Constela%C3%A7%C3%A3o%20SIP

Projeto de telefonia IP: Caterpillar Está Convertendo 100.000 telefones

asterisksss

Case antigo mas, achei nos meus favoritos vale a postagem.

No meio de um projeto gigante de telefonia IP, a Caterpillar está se desvencilhando de um sistema de voz analógico caro, descentralizado e está lançado as bases para inauguração de um sistema de comunicações unificadas de domínio global para a corporação.

A Caterpillar, o maior fabricante de equipamentos pesados para construção e mineração do mundo, já converteu até agora 35.000 de seus 100.000 telefones para telefonia IP, incluindo todas as 24.000 linhas na sede da companhia em Peoria, Illinois, de acordo com Steve Bergstrom, arquiteto de voz e de comunicações unificadas (UC) da empresa.

A equipe de Bergstrom está eliminando gradualmente uma constelação de PABXs analógicos que foram dispersados ao redor do globo — dispersados e tão numeroso que não se consegue chegar a um número exato de quantos a companhia tinha precisamente.

“Só em Peoria, nós tínhamos oito PABXs”, disse Bergstrom. “Em toda a companhia foi duro se conseguir um número exato. Nós tínhamos padrões corporativos, mas se você vascular as diferentes unidades da empresa, com idéias e evolução independentes com aquisições e descartes, nós iniciamos coletando os vários tipos diferentes de equipamentos”.

Citando razão de política corporativa, firmemente, Bergstrom declinou em falar sobre quais fornecedores a Caterpillar está usando neste projeto. Entretanto, já que ele apresentou o seu projeto de telefonia IP como um estudo de caso de cliente recentemente no evento “Cisco Live” em Orlando, é seguro dizer que a Cisco Systems tenha algum tipo de envolvimento no empreendimento.

Uma primeira etapa no projeto de telefonia IP foi consolidar o roteamento de chamada entre os três “centros de informação regionalizados”, disse Bergstrom. A sede de Peoria atende a América do Norte e a América do Sul, enquanto que centros similares na Bélgica e em Singapore servem o resto do mundo.

Essa abordagem centralizada da tecnologia de telefonia IP ajudou a Caterpillar de várias formas, disse ele. Por exemplo, o custo total de propriedade para voz está caindo porque a companhia consolidou sistemas e suporte.

“Eu não preciso manter duas redes distintas. Eu tenho uma rede única para voz e dados”, disse Bergstrom. “E em vez de colocar sistemas que possua capacidade para 500 telefones em um site remoto que só precisa efetivamente de 200 telefones, nós os colocamos em um sistema centralizado de sorte que podemos dividi-los de forma mais eficiente”.

Também, com PABXs IP centralizados, a Caterpillar não precisa mais colocar uma central em cada regional. “Isso é uma coisa a menos para se preocupar. Não existe equipamento nos sites”, disse ele.

A consolidação do suporte foi uma revelação para a empresa, disse Bergstrom. Ele não mais precisa de uma pessoa em cada regional para gerenciar a telefonia. Ele pôde usar sua equipe centralizadamente, que o tornou tudo mais eficiente.

“Se existisse um alguém em cada sites que mantivesse esse sistema, e que somente lhes ocupasse um pouco de tempo por semana, esse pouco de tempo seria relativo, porque para executar uma mudança eles precisariam se lembrar de uma senha, e depois precisariam se lembrar dos comandos, e então precisariam se lembrar de como executá-los”, disse ele. “Isso poderia levar de 30 minutos à uma hora para fazer algo que do ponto de vista centralizado gastaria somente alguns minutos porque estamos mais familiarizados com o sistema. Nosso pessoal é mais eficiente por causa da economia de escala”.

A transição para telefonia IP foi muito gradual para Caterpillar, ela não fez uma ruptura abrupta do analógico para IP. Bergstrom disse que a transição começou com 50 telefones no departamento de TI em Peoria. Quando a organização se tornou mais familiar à cerca de como funcionava o sistema, eles foram mais agressivos, e chegou ao ponto onde a companhia foi migrando cerca de 1.600 telefones por semana.

No início, Bergstrom contemplou o uso de mão de obra contratada para instalar fisicamente os telefones, mas em meio às conversações com os líderes da empresa, ele conseguiu que ele usasse um recurso disponível não aproveitado.

“A Caterpillar disse, ‘Por que os empregados não podem nos ajudar?’ Houve uma campanha em nível de supervisão”, disse ele”. A nossa equipe pôde fazer um exercício de equipe de infra-estrutura predial plugando os telefones a noite. Eu pensei que isso não funcionaria, mas funcionou. Surpreendentemente, as pessoas quiseram cooperar. Elas ficaram excitadas com a nova tecnologia e ficaram excitadas para se desvencilharem dos velhos telefones que tinham a 10 anos”.

Às sedes da corporação levou aproximadamente 18 meses para migrar para telefones IP, disse Bergstrom. “Com relação a esse novo ciclo da telefonia da corporação, apenas deixaremos passar as questões de desgaste ou de depreciação ou qualquer outra coisa do gênero”.

Com a telefonia IP marcando presença firmemente, Bergstrom volta agora a sua atenção para as comunicações unificadas. A Caterpillar está explorando suas opções como de presença e usando clientes unificados.

“Nós estamos nos esforçando nisso enquanto companhia, tentando compreender como chegar lá”, disse ele. “Nós estamos agora focando bastante no recurso de presença e em um cliente unificado. Eu diria que o cliente unificado está em primeiro plano do que nós tínhamos dado atenção até agora. O UC está juntando todas essas coisa de modo que os usuários na sua mesa de trabalho tenham todas as ferramentas de que eles precisam. Nós precisamos avaliar minuciosamente quais são os custos e qual é o valor agregado disso. Nós gastaremos ou não com UC, e qual é a forma mais inteligente de implementá-lo? Também, nós implementaremos tudo de uma só vez, ou partes dele e em camada sobreposta [dele]?”

O sistema de telefonia IP já se pagou em dividendos de produtividade, particularmente nos contact centers da companhia. O sistema para os telefones IP coincidiu com a instalação da nova tecnologia de contact center IP.

“Antes, nós tínhamos contact centers muito diferentes”, disse Bergstrom. “Nós começamos a uniformizá-los. Já que a tecnologia permite você virtualizar. O contact center existe em uma nuvem em vez de um site. Você pode pegar agentes de qualquer lugar que você desejar”.

Bergstrom disse que ele pode pegar pessoas com diferentes perfis de habilidade e mesclá-las entre os diferentes contact centers. Essas pessoas podem entrar e sair de diferentes filas de chamadas para pegar ligações baseadas em situações. Como resultado, os contact centers da Caterpillar reduziram a duração média de seu atendimento em 60 segundos e aumentou o seu volume de chamadas em 15%.

“Não é freqüente que você aumente o volume de chamada e, ao mesmo tempo, reduza o seu tempo de atendimento”, disse ele.

Fonte da onde tirei essa informação: http://clevitonmendes.blogspot.com.br/2008/07/caterpillar-est-migrando100000.html

 

ISDN

ISDN Tutorial

This tutorial is a response to requests from my engineering colleagues for an introduction to ISDN. They wanted to quickly understand the basics, without having to plough through detailed standards and textbooks. I hope this will help.

It is designed to be read continuously from top to bottom and to be easily printed. Hyperlinks to detailed specifications that can be downloaded for free are provided. Both “European” and “North American” variants of ISDN are described.

Introduction

What is ISDN?

The Integrated Services Digital Network (ISDN) is a development of the plain old telephone service (POTS) that enables it to carry data and other traffic as well as voice calls. Instead of using a continuously changing analogue voltage on the line between the network and your house, it uses pulses having one of a few discrete voltage levels to encode a series of digits. This is known as “pulse code modulation” (PCM). It is the original “digital subscriber loop” (DSL) technology.

It is more complicated than the POTS way, but has some big advantages:

  • Two simultaneous phone calls can be made (or more on primary rate), using the same pair of wires that your POTS telephone used to connect to. This is achieved by interleaving the data for each call, a technique called “time division multiplexing” (TDM). The phone company doesn’t have to dig up the road to change to ISDN and effectively give you a second line.
  • Calls can be connected much more quickly – typically within one second over ISDN, compared with 20 seconds or more over POTS. This is especially important when connecting a home computer to an office network (“wide area networking”) or validating credit card transactions, for example.
  • Data can be sent faster (64,000 bits per second in each direction) and more reliably, so data calls can be shorter and therefore cheaper. You don’t need a modem to exchange data between computers, although you will probably need a cheaper “terminal adapter” (TA) or ISDN card instead. There is no modem “training” time to wait for (and perhaps pay for) after the call connects.
  • Noise, distortion, echoes and crosstalk become inaudible, because the telephone no longer has to measure an exact analogue value, it only has to decide which of a few discrete voltages is present at any particular instant. In most countries, the “trunk” network between telephone exchanges has already been converted to digital technology, for this reason. ISDN just extends it the “last mile” to your home.
  • The digits can represent any data, including faxes, files, web pages, sound, pictures and ordinary voice calls. This is the meaning of “integrated services”.

So why isn’t everyone using ISDN? Some disadvantages are:

  • ISDN may not be available in your area, because it is expensive to upgrade a telephone exchange to support it. A “network termination unit” (NTU) may also have to be installed at the user end (not necessary in North America), and any “loading coils” removed from the line. Also, it won’t work if you live more than about 5 km from your local telephone exchange, which affects around 10% of users, depending on location.
  • ISDN lines typically cost at least twice as much to install and rent as POTS lines. That’s fair enough if you want to be able to make two simultaneous calls, but makes it expensive if you only need one line.
  • In order to make fast data calls, both ends must have digital connections. Most internet service providers (ISPs) already support this. Voice calls can be made from ISDN terminals to ordinary POTS phones without problems.
  • Long-distance ISDN data calls may be considerably more expensive than voice calls because they can’t be compressed. ISDN data calls may also be charged by time in places where POTS calls are not normally timed. Voice calls over ISDN typically cost the same as over POTS, however.
  • Supplementary services such as “caller display”, “ring back when free” and “charge advice” work differently (usually better) than on POTS lines, but are not always available and may cost extra.
  • ISDN terminals often need a local power supply, which can be a problem in emergencies. POTS phones normally take their power from the line.

[ Top ] [ Introduction ] [ Types ] [ Layers ] [ Call Description] [ Installation ] [ Links ]

Types of ISDN line

Basic Rate

“Basic rate” ISDN lines connect to the network with a normal twisted pair of copper wires. Data is transmitted simultaneously in both directions (known as “full duplex” operation) using some clever echo-cancelling. The stream of bits is organised into two “bearer” channels (B-channels), each of which can transmit data for a single call at 64,000 bits per second, equivalent to 8,000 bytes per second. This is interleaved with a single 16,000 bit/s “D-channel” on the same pair of wires that carries the signalling information for setting up and clearing down calls, and some extra “overhead” bits to allow synchronisation and monitoring of the line (a total of 192,000 bit/s).

The network end of the line is called the “line termination” (LT) and the user end is called the “network termination” (NT). In Europe, the network termination is usually a box attached to the wall of the customer’s premises and owned by the telephone company that converts the two-wire line from the network (the “U interface”) to four wires (the “S/T interface” or “S-bus”). The S-bus allows up to eight items of “terminal equipment” such as telephones or computers to be connected to one line, called a “point-to-multipoint” configuration. Remember that no more than two calls can be made simultaneously, because there are only two B-channels. The network provides sufficient power (around one watt) to run the NT and a simple ISDN telephone for emergency calls.

In North America, it is common for terminal equipment to connect directly to the network, in a “point-to-point” configuration. This saves the cost of the network termination unit, but restricts the connection to a single physical terminal. American ISDN lines do not normally provide any power.

Primary Rate

“Primary rate” ISDN lines are much more expensive, use much higher data speeds and different wiring. European “E1” primary rate lines have 30 B-channels, one D-channel and a synchronisation channel (total 2.048 Mbit/s). American “T1” primary rate lines have 23 B-channels and one D-channel (total 1.544 Mbit/s). Cheaper lines are often available that have some of the B-channels disabled but are otherwise identical.

Primary rate connections are presented to the user on four wires – one pair for each direction. They are usually 120 ohm “balanced” twisted pairs using standard network cable, but older installations may use 75 ohm “unbalanced” coaxial cables. Devices called “baluns” can convert between the two types. The connection from the NTU to the network may use additional pairs or optic fibre, depending on the distance. Primary rate connections are always point-to-point.

Primary rate lines are mainly used to connect to a private branch exchange (PBX) in an office or hotel. The PBX then typically provides many POTS telephone lines or basic rate ISDN lines to the users.

Broadband

The term “broadband” is a rather loose one, often used to describe any connection faster than primary rate ISDN, or a connection capable of passing video signals. Reasonable quality video can in fact be sent over the public ISDN by grouping together six or more B-channels into “H-channels”, which are sometimes called “broadband” connections. Since these connections are “circuit-switched” like a normal phone call, users have exclusive use of the bandwidth and so the connections are of good quality but expensive.

Higher speed ISDN lines (T2, E2 etc) carrying even more B-channels than primary rate lines are also used within the network and to connect to large companies, and can be considered to be broadband ISDN connections.

In many places, the network is being converted to “asynchronous transfer mode” (ATM). This is essentially a stream of small, fixed-size “cells” that can effectively handle both circuit-switched streaming traffic such as voice and video, and packet-switched traffic such as the internet. This too can be considered to be broadband ISDN.

In the local loop, faster DSL technologies such as ADSL are also capable of transmitting video signals (at least in one direction) and are sometimes called broadband connections. However, they typically connect to packet-switched networks and are not called ISDN.

[ Top ] [ Introduction ] [ Types ] [ Layers ] [ Call Description] [ Installation ] [ Links ]

The layers

ISDN is specified by reference to the bottom three layers of the OSI seven layer model, described below. These layers are only conceptual – they are not necessarily physically separate in a particular implementation, but they make the protocol easier to understand. The layers communicate with each other using similarly conceptual messages called “primitives”.

Layer 1 (Physical)

The physical layer electrically connects devices to each other. The higher layers can request a physical connection at any time by sending a PH-ACTIVATION request primitive to layer 1. If not already activated, layer 1 will try to wake up the device at the other end of the line (its “peer”) and synchronise to the stream of bits. If successful, layer 1 will then return a PH-ACTIVATION indication to layer 2. If unsuccessful, a PH-DEACTIVATION indication is returned.

Once activated, a continuous stream of bits to and from the peer will be available on the D-channel and B-channels. There is no error correction at this stage, so line noise will occasionally cause errors. Errors tend to occur in bursts, but an average of one bit error per B-channel per minute would be considered normal. Layer 2 sends data to layer 1 in PH-DATA request primitives and receives data in PH-DATA indication primitives.

See I.430 (basic rate), I.431 (primary rate) and ETS 300 012-1 for detailed information.

Layer 2 (Data link)

The data link layer applies error correction to the stream of D-channel bits, to ensure that the essential “signalling” information used for setting up and clearing down calls is transmitted reliably. It also adds addressing, so that signalling information from several terminals can be sent to and from the network over one shared physical channel. The protocol used is known as the “link access procedure for the D-channel” (LAPD). See Q.921 or ETS 300 125 for more information.

The higher layers can request an error-corrected D-channel connection at any time by sending a DL-ESTABLISH request primitive to layer 2. If successful, a DL-ESTABLISH indication will be returned to layer 3. If unsuccessful, a DL-RELEASE indication is returned. Once a data link has been established, layer 3 can use it to reliably transmit signalling messages to its peer in DL-DATA requests and receive them in DL-DATA indications.

The layer 2 specification only describes the D-channel protocol, because the ISDN network is not usually concerned with the content of the B-channels – that is up to the user. The “V.120” or “LAPB” protocol, which is sometimes used to pass data over a B-channel with error correction and flow control, is very similar to LAPD. Voice calls use “mu-law” encoding on the B-channel in North America and “A-law” encoding everywhere else.

Layer 3 (Network)

The network layer implements the call setup and cleardown procedures over the D-channel. The terminal tells the network what number to “dial” and what type of connection is required, and the network indicates which B channel to use and when to connect or disconnect from it. See Q.931 or ETS 300 102-1 for more information.

Supplementary services such as caller display, multiple subscriber numbering and call forwarding are also implemented by layer 3. See Q.932 and ETS 300 196 for more information.

The interface from layer 3 to higher layers and the user depends on the application. A standard known as CAPI (common ISDN application programming interface) is often used.

[ Top ] [ Introduction ] [ Types ] [ Layers ] [ Call Description] [ Installation ] [ Links ]

Typical call description

A walkthrough of a typical call setup and cleardown may be the quickest way to understand how the process works. Here is an example of a call from a simple ISDN telephone, starting right from the beginning.

Outgoing call

The first user (the “A-party”) picks up the handset of the telephone (the “terminal”). The software inside the telephone signals this event to its layer 3 entity. The layer 3 entity constructs a SETUP message containing a “bearer capability” information element indicating call type “speech”. It needs to send this message through the D-channel to the layer 3 entity in the network (its “peer”), but first layer 2 must be established.

Layer 3 knows that layer 2 is not already established, because it has never received a DL-ESTABLISH indication message from layer 2, in this example. Therefore, it sends a DL-ESTABLISH request message to layer 2 to request establishment of the data link.

We assume layer 2 is in the TEI UNASSIGNED state when it first receives this message. This means it needs to get a terminal endpoint identifier (TEI) from the network before it can establish the data link. The TEI is an address byte which is used in all messages between this particular terminal and the network.

However, layer 2 can do nothing until layer 1 is activated, so it first sends a PH-ACTIVATION request to layer 1 to request activation of the physical link.

Activation of layer 1

Layer 1 is initially in the DEACTIVATED state, which means that there is no signal on the line, a state known as an “INFO 0” signal. The terminal starts transmitting an INFO 1 wake-up signal (any non-zero signal) to begin the activation sequence. The network detects this, and responds with a signal known as an INFO 2, similar to normal communication but with the “activation bit” not set.  The terminal synchronises to this signal, and responds with an INFO 3, the normal communication signal from the terminal side. The network  detects this, and responds with an INFO 4, the normal signal with activation bit set.

This situation, with the terminal sending INFO 3 and the network sending INFO 4, is the “ACTIVATED” state. The layer 1 entities at each end of the line send PH-ACTIVATION indications to their respective layer 2 entities when this state is achieved.

A full-duplex communication path now exists between the first terminal and the network, consisting of two B-channels and a D-channel (possibly shared with other terminals on the same line).

Establishment of layer 2

After receiving the PH-ACTIVATION indication primitive, layer 2 in the terminal transmits a message called an IDENTITY REQUEST to the network over the activated D-channel. The network should respond with an IDENTITY ASSIGN message containing a TEI that will be used in all future messages between this particular terminal and the network. This automatic TEI assignment procedure is only necessary on basic rate point-to-multipoint connections, because on a point-to-point connection there is only one terminal and so the addressing is unambiguous, and a fixed TEI (zero) is used.

To complete the data link establishment process, layer 2 sends a “set asynchronous balanced mode extended” (SABME) command to the network, using the TEI it has just been assigned. The network responds with an “unnumbered acknowledgement” (UA) message to the same TEI. Both layer 2 entities are now established and send DL-ESTABLISH indication primitives to their respective layer 3 entities.

It is quite common for layer 2 to remain established even though no calls are in progress. However, either the network or the terminal may release layer 2 by sending a layer 2 DISC message (acknowledged with a UA), provided no layer 3 calls are in progress. If no layer 2 entities are established, the network may then deactivate layer 1, which saves power. Some countries charge a small fee whenever layer 2 is established, for this reason.

An error-free connection now exists through the D-channel between the network and this particular terminal.

Service profile identification

In North America, basic rate terminals are usually required to send a service profile identification (SPID) to the network at this stage, before any incoming or outgoing calls can be made. The SPID is specific to the line and to the type of terminal, and must be obtained from the service provider and configured in the terminal by the user. It typically consists of the phone number of the line with some extra digits such as “0101” added. A different SPID (and TEI) is needed for each simultaneous call, so there are usually two SPIDs per line.

The exact message used to send a SPID on the D-channel varies with the manufacturer of the switch, so information about the switch type must also be obtained from the service provider and configured in the user’s terminal. Typical choices are “Nortel DMS100”, “AT&T 5ESS”, “NI-1” or “NI-2”.

An example of the signalling procedure is described in Q.932 Annex A. The terminal sends an INFORMATION message containing a service profile identification information element to the network using the “dummy” call reference. The network responds with an INFORMATION message containing an “endpoint identifier” information element with a “user service identifier” and “terminal identifier”.

Outside North America none of this service profile identification is necessary, so you can typically connect a terminal to an ISDN line and make calls without further configuration.

Call setup by layer 3

Layer 3 in the terminal is at last able to send its SETUP message. It puts the message in a DL-DATA request to layer 2, which wraps the message in a layer 2 information frame (I-frame) and then forwards it to layer 1 in a PH-DATA request. Layer 1 then transmits the frame to the network via the D-channel.

The layer 1 entity in the network receives the frame, removes the “zero bit stuffing” and “flags”, checks the frame length and “frame check sequence”, and passes the frame to layer 2 in a PH-DATA indication. The layer 2 entity checks the address, frame type and sequence numbers, extracts the information field and passes it to layer 3 in a DL-DATA indication – unless the frame arrives corrupted, in which case layer 2 retransmits it automatically until it is received intact.

The network will decode the SETUP message and usually return a SETUP ACKNOWLEDGE message, containing a “channel identification” information element indicating “B-channel 1” or “B-channel 2”. The network will usually also transmit dialtone on the indicated B-channel. The terminal receives the message and connects a “CODEC” to the indicated B-channel to decode the digital information into analogue form so that the user can hear the dialtone.

Everything described above typically occurs within a few tenths of a second, so dialtone is probably already present by the time the handset reaches the user’s ear.

The user then dials the digits of the number to call. As each digit is dialled, the telephone sends it to the network in the “called party number” information element (Europe) or “keypad facility” information element (North America) in an INFORMATION message. When the network has received enough digits to route the call, it typically returns a CALL PROCEEDING message to the terminal. The network then passes the SETUP message to the remote user.

An alternative procedure to this so-called “overlap sending” procedure can be used if all the digits to be dialled are known before the start of the call. In that case, all the digits can be included “en-bloc” in the first SETUP message and the network does not need to return dialtone or a SETUP ACKNOWLEDGE message.

The call is now proceeding through the network.

Incoming call

At the remote end (the “B-party”), the call arrives as an incoming call. The network allocates a free B-channel, activates layer 1 and sends the SETUP to the user’s terminal. If the line is configured at the network as “point-to-multipoint” (basic rate only), the SETUP message is “broadcast” to all terminals on that line using TEI 127. On a point-to-point line, the message is sent using fixed TEI 0.

The ISDN terminal(s) on the B-party’s line receive a SETUP message, indicating the call type, the allocated B-channel and perhaps other information such as the called and calling numbers. If the call type is acceptable (in this case, “speech” or “3.1kHz audio”, A-law encoded and so on) and the addressing information is acceptable (e.g. the called number, sometimes called “MSN” or “DDI”, matches any number programmed into the phone by the user), the phones start to ring and each returns an ALERTING layer 3 message to the network, which passes it through to the A-party. The network normally also generates “ringback” tones down the B channel back to the A-party so he can “hear” the phone ringing.

A call has now been “initiated” all the way through the network, but not yet connected or charged for.

Call connection

When the remote (B-party) user picks up one of the ringing phones to answer the call, that phone sends a CONNECT message to the network. The network returns a CONNECT ACKNOWLEDGE message to that phone (and RELEASE messages to any other ringing phones on that line to stop them ringing), and forwards the CONNECT message through the network to the A-party caller. The B channel is “cut-through” (connected) all the way from the caller to the called party and back, and the call charging starts.

The call is now fully connected.

Call cleardown

When either of the users replaces the handset to end the call, that telephone sends a layer 3 DISCONNECT message to the network, containing a “cause” code, in this case cause 16, “normal user clearing”. See Q.850 or ETS 300 102-1 for a list of cause codes. The network disconnects the B-channel and returns a RELEASE message, indicating that all resources associated with the call should be released. The telephone responds with a RELEASE COMPLETE message when this is done.

Meanwhile, the DISCONNECT message has been forwarded through the network to the other user. The user may remain connected to the B-channel for a while to listen to any tones or announcements. When the user replaces the handset (or after a timeout), the telephone disconnects from the B-channel and returns a RELEASE message to the network. The network releases all resources associated with the call and returns a RELEASE COMPLETE message.

The call is now completely cleared.

[ Top ] [ Introduction ] [ Types ] [ Layers ] [ Call Description] [ Installation ] [ Links ]

Installation hints

Basic rate

Basic rate terminals can normally be plugged straight into an NTU (or direct to the line in North America) using normal “category 5”, “unshielded twisted pair” (UTP) network cable with standard “RJ45” plugs and sockets wired “straight through”. Note that the pairing of pins is important and not intuitive: the four twisted pairs of wires should connect to pin pairs 1-2, 3-6, 4-5 and 7-8. Polarity is important if more than one terminal is connected. Network cables must be kept away from mains cables.

If all terminals are less than about 10 meters from the NTU no further wiring configuration is needed. On a basic rate line configured as “point-to-multipoint” at the network, up to eight terminals can simply be connected in parallel at the NTU, otherwise only one terminal is allowed on “point-to-point” lines.

If a basic rate terminal is to be connected further than about 10 meters from NTU, 100 ohm termination resistors must be connected between pins 3 and 6 and between pins 4 and 5 at the far end of the cable, and the termination resistors inside the NTU disconnected. Companies such as RS sell suitable plugs with termination resistors and on the NTU there should be a switch that can be set to “OUT”. Terminals can be connected anywhere along this “passive bus”, but any “stubs” should be as short as possible (10m maximum).

Terminals can be connected further than 150m from the NTU, up to a maximum of about 800m, but they must be clustered together near the end of the bus and at the extreme length only one terminal can be connected. Termination resistors must be used at the end of the cable as described above and there should be a switch on the NTU that is set to “LONG” to enable “adaptive” timing in this configuration.

In Europe, terminals should be configured for “Euro ISDN” or “ETSI” or “CTR3” operation. In North America, a switch type and SPIDs need to be configured as described above. Other countries are often compatible with Euro ISDN, or may need a specific configuration (e.g. INS64 for Japan).

If more than one number is allocated to the line, you may need to configure your terminal to only accept calls to a specific number, sometimes called an MSN (multiple subscriber numbering), otherwise it will ring for all calls. Usually only the last few digits are necessary.

If outgoing voice calls are being rejected, try changing the configured call type from “speech” to “3.1kHz Audio” or vice versa. “Speech” calls are sometimes cheaper, but may not work for modem or fax connections.

Primary rate

Primary rate lines are also often connected using standard network cable and “RJ45” plugs, but using different pins. They are always point-to-point and therefore there is no need to worry about termination resistors or polarity. Older lines may connect using coaxial cable as described above, or with simple screw terminals.

Transmit and receive pairs are frequently presented the wrong way round, so some experimentation with “crossover” cables may be necessary. Primary rate crossover cables are not the same as basic rate or ethernet crossover cables!

Older primary rate lines sometimes do not support the standard framing scheme known as “CRC4 multiframing”. It may be necessary to disable this option in the terminal. There are also legacy lines such as “DASS2” lines in the UK that are electrically compatible and functionally similar, but completely different at layers 2 and 3.

A “loss of framing” (LOF) or “no signal” indication probably means there is no connection, or that the transmit and receive pairs are swapped. A “remote alarm indication” (RAI) means that the terminal is receiving a correct signal from the network but the network has detected a problem in the signal from the terminal. An “alarm indication signal” (AIS) means there is a signal from the network but the line is out of service.

[ Top ] [ Introduction ] [ Types ] [ Layers ] [ Call Description] [ Installation ] [ Links ]

Links

Standards

Tutorials

  • Peter Ilieve’s uk.telecom mini-FAQ has many links to UK-specific information, including all the operators.
  • Ralph Becker has a comprehensive tutorial that covers similar ground to this one.
  • Dan Kegel’s ISDN Page has many useful links to other sites as well as a tutorial. Last updated in 1996, though.
  • Dialogic have a complete “Introduction to ISDN” course online.
  • Thomas A. Fine has another good tutorial.
  • Protocols.com is more technical, with a good list of country variants.
  • SEG communications has a practical UK-specific ISDN overview.

source : https://www.mckerracher.net/isdn

Reproduzir áudio no Asterisk sem atender a chamada – 183 Session Progress

tux_JEDI

Dica muito interessante, fonte: http://blogdovoip.com/asterisk/reproduzir-audio-no-asterisk-sem-atender-a-chamada-183-session-progress/

 

Nos tempos de telefonia analógica, a maior parte das sinalizações telefônicas eram audíveis, o que forçava a ocupar um canal para que ela fosse interpretada, porém com o advento da telefonia digital (TDM e IP) foram criados canais específicos para sinalização das chamadas, possibilitando que essas sinalizações pudessem acontecer em paralelo com as chamadas. Estes recursos sofreram uma evolução muito maior com os protocolos de telefonia IP e com a entrada do SS7 ISDN – para telefonia TDM.

Com essas sinalizaçõs, veio a sinalização de ring (o tom de chamando um telefone), onde é a plataforma responsável pelo usuário que está sendo chamado envia o áudio com esse tom, nos protocolos de telefonia TDM  – similar à telefonia analógica – e para o VoIP, existe uma sinalização especial para tom de ring onde quem origina a chamada que gera esse tom ao receber esse sinal.

Porém, para interoperar com a telefonia TDM (padrão nas redes de telefonia publica) os protocolos VoIP tiveram que abrir a possibilidade de ter uma sinalização de ring onde é enviado o áudio com esse tom, gerando a sinalização Session Progress (183 para o SIP).

Como o tom de ring indica que o telefone está chamando, ele obviamente não atendeu a chamada. Desta forma, é possível explorar essa sinalização para enviar qualquer áudio que seja desejado. No Asterisk, existe uma aplicação para o plano de discagens que ao invés de atender a chamada, envia uma sinalização de Session Progress para o originador, esta aplicação é a Progress().

Aliado à aplicação Progress() no plano de discagem do Asterisk, devemos pôr o parâmetro noanswer na aplicação Playback(), para que ela não atenda a ligação, somente toque o áudio. A aplicação Playback() é a aplicação responsável por reproduzir os arquivos de áudio no Asterisk.

Desta forma, para enviar uma mensagem audível para quem ligar para seu Asterisk sem que o originador seja tarifado em sua operadora de telefonia, devemos executar a aplicação Progress() seguido de Playback(nome_do_arquivo_de_audio,noanswer), tendo como exemplo:

exten =>_X.,1,Progress()

exten => _X.,n,Playback(tt-monkeys,noanswer)

exten =>_X.,n,Hangup()

Neste exemplo, será tocado o áudio tt-monkeys (som dos macacos berrando – padrão do Asterisk) através de uma sinalização de Session Progress.

Vale ressaltar que, caso o tronco de entrada das chamadas seja analógico (FXO) ou TDM com sinalização R2D, a sinalização de progress não terá efeito, sendo interpretada como chamada atendida pela operadora. Esta dica só vale para chamadas em VoIP (testadas com SIP) e TDM com sinalização ISDN (RDSI em portugês). Algumas operadoras também podem definir limites para o session progress e tarifar após excedido o limite