UFPR - UNIVERSIDADE FEDERAL DO PARANÁ

MESTRADO EM TELECOMUNICAÇÕES

AUTOR: MARCELO NELSON WADECK

OUTUBRO DE 2001

TELEFONIA IP

ABSTRACT

One of the key topics in telecommunication business nowadays is the convergence between circuit-switching based networking and packet-switching based networking. IP telephony and convergence services are one of the fastest growing emerging telecom sector.

The main purposes of this paper are to present some basic concepts regarding Voice over IP tecnologies and arquitectures, as well to provide a glimpse of the solutions available and related protocols, capturing the state of the art of today telecom industry.

KEYWORDS: Voice over IP, IP telephony, Media Gateway, Media Gateway Controllers, MGCP, Megaco, H.323, SIP.

RESUMO

Um dos tópicos chaves na área de telecomunicações atualmente é a convergência de entre redes comutadas e redes de pacotes. A telefonia IP e serviços convergentes formam uma das tecnologias emergentes que mais crescem no setor de telecomunicações.

O propósito principal deste trabalho é apresentar alguns conceitos básicos relativos às tecnologias e arquiteturas de Voz sobre IP, bem como fornecer uma idéia geral das soluções disponíveis e seus respectivos protocolos, visando capturar o estado da arte da indústria de telecomunicações atual.

PALAVRAS-CHAVE: Voz sobre IP, telefonia IP, Media Gateway, Media Gateway Controllers, MGCP, Megaco, H.323, SIP.

PARTE 1: Introdução às tecnologias Voz sobre IP

1. Por que telefonia IP?

Quando falamos de Voz sobre IP (VoIP) e telefonia IP estamos nos referindo à transmissão de voz na forma de pacotes, em contraste com a transmissão comutada por circuitos das redes telefônicas convencionais.

Contudo, a transmissão de voz em redes de pacotes é vista pela grande maioria das pessoas como uma tecnologia precária, de pouca eficiência, em contraste com a bem conhecida e confiável rede telefônica convencional. Esta visão é decorrente, principalmente, do contato destas pessoas com soluções simples de transporte de voz na Internet, a mais conhecida rede de pacotes.

Embora seja a mais conhecida, a Internet não é a única rede de pacotes. De fato, embora sua performance seja questionável, a tecnologia VoIP tem despertado grande interesse na indústria de telecomunicações, para o uso em redes proprietárias das operadoras de serviço de telecomunicações.

Existem muitas razões para este interesse. A primeira delas é a crescente convergência de voz e dados. Cada vez mais, os usuários das redes de telecomunicações querem transportar mais do que apenas voz. Uma única transmissão pode conter áudio, figuras, vídeo, diversas formas de conteúdo. Muito em breve, o tráfego de dados mundial deve superar o tráfego de voz.

Essa integração oferece novas possibilidades de serviços que podem ser oferecidos aos usuários. E com estes novos serviços, vêm novas formas de tarifação. Os proprietários das redes de telecomunicações podem agora não apenas cobrar por tempo alocado de sua rede ao usuário, mas pode cobrar por conteúdo oferecido, tipo de mídia e serviço, quantidade de dados transportados. Surgem novas fontes de renda não atrelados ao sistema tarifário engessado das redes tradicionais.

E o modelo convergente de redes permite às operadoras adentrar nestes novos mercados sem perder de vista o tráfego telefônico convencional, que continua e continuará, pelo menos por algum tempo, a ser o forte de sua receita. Preparar-se para o futuro sem perder os pés no presente.

A telefonia IP oferece ainda outras vantagens aos operadores de rede: a consolidação de sua estrutura e melhora aproveitamento da banda disponível. Antes, uma operadora tinha que possuir e manter uma rede TDM para o transporte de sinais de voz e outra rede, separada, para transportar os dados de seus clientes. Agora, uma única estrutura pode ser utilizada para transportar diversos tipos de mídias.

A rede telefônica convencional é bastante ineficiente na alocação de seus recursos. Baseada na multiplexação por tempo (TDM) de seus circuitos, este tipo de rede reserva banda e recursos aos usuários mesmo quando estes não tem nada a transmitir. Esta estrutura se torna extremamente não atrativa para o transporte de dados.

Por exemplo, em uma ligação telefônica convencional, a rede oferece ao usuário uma banda continuamente, mesmo que ele não esteja falando nada. E como em uma conversação normal existem muitas pausas e silêncio (cerca de 50% do tempo de uma conversação normal são constituídos de silêncio), esta banda está sendo desperdiçada, poderia estar sendo utilizada para o transporte de dados de outro usuário.

A rede de transporte de dados está projetada para tirar proveito desta situação. E ainda mais, já que outros cerca de 20% de uma conversação são constituídos por padrões repetitivos, que podem ser eliminados através de algoritmos de compressão.

Assim, enquanto os canais de voz de uma rede telefônica convencional operam a 64 kbits/s, a rede de dados, utilizando modernas técnicas de conversão analógico-digital, pode oferecer canais de voz de alta qualidade que operam a apenas 4,8 a 8 kbits/s. Uma economia de banda de transmissão de cerca de um para oito em relação ao método convencional.

Contudo, a rede IP não foi concebida para o transporte de dados em tempo real, como demandada pela transmissão de voz. Uma série de desafios precisou ser enfrentada, em especial relativos à latência da redes, sua característica de entrega não confiável (best effort), entrega de pacotes não necessariamente pela mesma rota e na mesma ordem (o que inviabiliza uma transmissão telefônica), perda de pacotes, problemas de supressão de eco, supressão de silêncio e geração de ruído de conforto, e outras questões associadas com as limitações do protocolo IP e características do ouvido humano.

Então por que escolher uma tecnologia de redes que apresenta tantas limitações e dificuldades. Afinal, existem outras tecnologias de redes por pacotes muito mais aprazíveis a transmissão de dados em tempo real e com qualidade de serviço (podemos citar a tecnologia ATM).

A resposta é bastante simples: porque o IP está lá. O protocolo IP não é especialmente atrativo para o transporte de telefonia, porque foi desenhado para o transporte de dados. Entretanto, sua presença virtualmente universal em computadores pessoais, servidores, workstations, equipamentos de redes, etc., o tornam uma plataforma lógica e conveniente para o suporte de tráfego telefônico.

Em contraste com a penetração de outras tecnologias de rede, como o ATM e Frame Relay, o IP tem grandes vantagens, operando em um nível fim-a-fim, usuário-a-usuário, e não somente sobre segmentos de rede. Essa “localização” universal do IP foi decisiva em sua escolha como protocolo de transporte de voz. O mercado demanda soluções IP.

Outro fator decisivo para o transporte de voz através de redes de pacotes foi a evolução e disseminações de processadores de sinais analógico-digital (DSPs), de baixo custo, e capazes de codificar/decodificar sinais de áudio em tempo real.

É também decisiva a maturação das tecnologias IP para fornecer soluções aos problemas já mencionados. Quando nos referimos a VoIP, não estamos apenas falando de acomodar os sinais de voz digitalizados em datagramas IP. Existem uma série de tecnologias e protocolos associados, de modo a fornecer uma solução plausível não só a todos os problemas de transporte em tempo real de sinais de voz, mas os relativos à administração em tempo real de uma rede de dados convertida em uma rede multimídia.

2. A arquitetura VoIP

Em sua infância, a tecnologia de transmissão de voz em redes de pacotes não precisava mais que um par de computadores equipados com placas de som e modem e um pacote de aplicativos VoIP. Os próprios usuários tratavam da configuração de seus equipamentos e estabelecimento/manutenção da conexão.

Contudo, esta arquitetura simples sofre de uma falta de escalabilidade e apelo comercial.

Uma solução só se torna viável quando, além de acessível financeiramente a uma grande parcela da população, tem sua utilização simples a ponto de qualquer pessoa possa operá-la (como a rede telefônica atual), e administrável de forma a operadora obter controle total de suas operações, de forma a maximizar seus lucros.

Uma solução VoIP em larga escala envolve uma série de procedimentos, como autenticação e autorização, acesso à rede, além dos já conhecidos problemas de codificação e transporte.

No que se refere ao acesso à rede, é pouco provável que a rede IP chegue ao usuário final na forma como hoje conhecemos, através do uso de computadores. Embora sua disseminação hoje se torne cada vez maior, seu alto custo os torna candidatos pouco prováveis como equipamentos terminais. Equipamentos terminais IP, chamados telefones IP, já existem e poderiam ser alternativas viáveis, contudo sua utilização esbarra na legislação protetora das operações de telecomunicações.

Uma outra tendência da indústria atual e operadoras é aproveitar ao máximo a estrutura da rede telefônica legada. E uma grande parte desta estrutura é composta pelos pares de fios trançados que chegam a cada casa para prover acesso telefônico. Não faz sentido estender outra rede de acesso aos usuários quando dispomos de uma rede já existente de tão grande penetração.

Assim, utilizamos esta rede legada de acesso até a central telefônica, onde os sinais de voz seriam então convertidos e transmitidos pela rede convergente da operadora.

Outro cenário possível é a utilização de PBXs (centrais telefônicas privadas de pequeno porte) IPs em empresas e ambientes corporativos. Estes PBXs forneceriam linhas convencionais de voz para ramais da companhia, e então converteriam os sinais recebidos para transportá-los em suas redes de comunicação de dados.

Nestes cenários apresentados, podemos identificar dois elementos essenciais à arquitetura VoIP. Um elemento de conversão, que trataria de converter os sinais analógicos de áudio em pacotes de dados digitais, chamado de Media Gateway; e um elemento de controle destas media gateways, que também trataria da interface de sinalização entre a rede IP e as redes legadas (como o SSN7), chamado de Media Gateway Controller, ou Call Agent. Este elemento de controle seria o responsável pelo estabelecimento e controle das chamadas efetuadas (o “cérebro” da arquitetura).

Existem diversos tipos de media gateways, desenhados para interfacear diversos tipos de redes. Como exemplos de implementações de gateways, podemos citar “trunking gateways”, que provêem interface entre a rede telefônica e a rede IP, “Voice over ATM gateways”, que provêem a mesma funcionabilidade, somente que para redes ATM; “residential gateways”, que provêem uma interface analógica convencional à rede VoIP (como por exemplo telefones IP, dispositivos xDSL, acesso via Cablemodem. etc.); “access gateways”, que provêem acesso à rede IP para sistemas PBX analógicos e digitais; etc.

Tendo esta visão da arquitetura VoIP, identificamos duas áreas onde protocolos são necessários: em como os dados são codificados, empacotados e transmitidos entre os gateways; e em como os elementos da rede VoIP são controlados e administrados pelo call agent.

Para a primeira área, a codificação/transporte, os maiores competidores são a família de protocolos H.323 definida pelo ITU-T e o SIP (Session Initiation Protocol) definido pelo IETF. A família H.323 compreende uma série de protocolos, definidos cada um para uma tarefa, como o H.245 para controle, o H.225.0 para o estabelecimento da conexão, o H.332 para conferências amplas, os protocolos H.450.1, H.450.2 e H.450.3 para serviços suplementares, o H.235 para segurança, e o H.246 para interoperabilidade entre serviços baseados em comutação.

Já na área de controle, existe uma série de protocolos que foram desenvolvidos ao longo dos anos, como MGCP, SGCP, IPDC, Megaco, H.GCP, H.248 e NCS. Todos estes protocolos foram desenvolvidos em torno do conceito de decomporem a sinalização das centrais telefônicas tradicionais em sinais e funções de Media Gateway Control, a fim de promoverem a integração das plataformas de comunicação.

A figura 1 nos fornece uma visão geral em como estes protocolos estão organizados em relação a pilha IP.

Figura 1: Os protocolos de Telefonia IP

PARTE 2: Protocolos de sinalização e controle

3. A evolução dos protocolos de controle

A evolução histórica dos protocolos de controle de media gateways é bastante rica e conturbada. O controle e administração eficiente das redes são tópicos essenciais tanto para os fabricantes de equipamentos de última geração quanto para operadores de serviços convergentes emergentes.

Atualmente, o MGCP (Media Gateway Control Protocol) ocupa o centro das soluções de controle IP. A batalha das operadoras para oferecer serviços convergentes se baseia nele e em seu novo sucessor, o Megaco, para prover um modelo de negócios eficiente, viável e rentável.

O MGCP está sendo desenvolvido atualmente dentro do IEFT como parte dos trabalhos do grupo de Media Gateway Control, também conhecido como grupo Megaco, que é parte da área de transporte do IETF.

Sua evolução começou com o desenvolvimento e utilização dos protocolos DSM-CC e Diameter, e sua evolução para o IPDC, desenvolvido pela Level3, uma provedora de serviços de telecomunicações baseados em IP, do Colorado, Estados Unidos. O IPDC, que significa Internet Protocol Device Control, se concentrava mais no controle dos dispositivos que no controle das chamadas.

No começo de 1998, Level3 formou um Technical Advisory Council (TAC) para promover sua nova arquitetura de controle e protocolo em ambas as entidades ITU e IETF. Este tipo de proposta, simultaneamente em ambas as instituições, foi bastante não ortodoxa, e rendeu poucos frutos.

Contudo, a necessidade de uma arquitetura de controle para a emergente solução convergente continuava. Nesta mesma época, o Dr. Christian Huitema e seu grupo na Telcordia desenvolveram o SGCP, ou Simple Gateway Control Protocol, a fim de prover funcionalidade similar ao IPDC, porém mais com mais ênfase no controle de chamadas. Esta solução ganhou o importante suporte e apoio da Cisco, já que esta estava trabalhando na época em projetos conjuntos de telecomunicações.

Eventualmente, Telcordia e Level3 entraram em acordo e decidiram juntar esforços, no que resultou em uma proposta única, que foi chamada de MGCP, ou Media Gateway Control Protocol.

É também importante mencionar a participação da Cablelabs, o consórcio das industrias de operação por cabo, na fusão do IPDC com o SGCP, colaborando na criação de um subset do MGCP que trata das necessidades específicas da indústria de transmissão por cabo, chamado de NCS.

O processo de padronização do MGCP tomou lugar inicialmente no IETF, mas foi um esforço conjunto entre este e o ITU. Em fevereiro de 1999 o MGCP estava padronizado e era considerado capaz de suprir as necessidades de controle das media gateways de telefonia.

Mas o grupo Megaco, liderado pelo Dr. Huitema, decidiu continuar seus trabalhos, aperfeiçoando o protocolo para cobrir controle de gateways de vídeo e outras mídias. A Lucent também submeteu ao IETF um outro protocolo, chamado de MDCP. A Lucent submeteu a mesma proposta também ao ITU, onde acabou sendo chamado de H.GCP. No IETF, a proposta de um MGCP influenciado pelo MDCP ficou conhecida como MegacoP. O Internet Draft de MGCP da IETF (draft-huitema-megaco-mgcp-v0r1-05.txt) se tornou a base para testes de interoperabildiade entre soluções de controle de diversos fabricantes.

ITU e o grupo de trabalho Megaco do IETF continuaram seus trabalhos, gerando em co-autoria uma versão mais rica do protocolo, que ficou conhecida como Megaco/H.248. Este protocolo representa a negociação/compromisso entre o MegacoP do IETF e o H.GCP do ITU.

A necessidade do mercado para controladores de media gateways e a pressão de alguns membros do ITU levam o Megaco/H.248 a ser uma evolução do MGCP.

Estes dois protocolos, o MGCP e o Megaco, são os representantes atuais dos protocolos de controle de media gateways e resumem a tendência do mercado atual.

4. MGCP – Media Gateway Control Protocol

O propósito principal do MGCP é permitir o controle de gateways de telefonia a partir de elementos externos denominados media gateway controllers ou call agents. É uma definição de um conjunto de comandos que um servidor de telefonia utilizaria para controlar um dispositivo de interface entre a rede telefônica convencional e a rede VoIP, bem como o conjunto de respostas que esta interface retornaria ao servidor.

O MGCP é, em essência, um protocolo do tipo mestre/escravo, assumindo que existe um elemento “inteligente” que controla os gateways, chamado de call agent. É esperado que os gateways executem os comandos enviados pelo call agent e lhe retornem o resultado.

Mas o MGCP também assume que os diversos call agents sejam capazes de se sincronizar entre si, a fim de emitir comandos coerentes para os gateways sobre seus controles. O MGCP não provê ou define este tipo de mecanismo de sincronização e comunicação entre call agents, nem mecanismos de autenticação. Todas estas tarefas devem ser realizadas antes do MGCP ser utilizado, através do protocolo conhecido como IPDC (IP Device Control).

Os comandos e sinais do MGCP são definidos como pacotes IP, tendo como protocolo de transporte o UDP, o que o permite que seja independente do sistema operacional ou linguagem de programação utilizada. Assim, o call agent pode ser executado em uma plataforma genérica da rede.

O MGCP é um protocolo orientado a conexão. Sendo assim, seus elementos básicos são as conexões e os pontos finais (endpoints) que as definem.

Endpoints são fontes ou sumidouros de dados e podem ser físicos ou virtuais. Exemplos de endpoints físicos são uma interface em uma gateway que onde termina um tronco conectado a uma central comutada (“trunk gateway”), ou uma interface em uma gateway onde termina uma conexão analógica a um telefone ou PBX (“residential gateway”). Um exemplo de um endpoint virtual é uma fonte de áudio em um servidor de conteúdo.

A criação de endpoints físicos requer instalação de hardware, enquanto a criação de endpoints virtuais pode ser feita via software.

As conexões podem ser tanto ponto-a-ponto como ponto-a-multiponto. Uma conexão ponto-a-ponto é uma associação entre dois endpoints com o propósito de transmitir dados entre estes dois endpoints. Uma conexão ponto-a-multiponto é estabelecida conectando-se um endpoint a uma sessão multiponto, como por exemplo, uma conferência.

O tipo de endpoint define sua funcionalidade. Existem muitos tipos de endpoints definidos, como, por exemplo: canal digital 8Khz (interface ISDN), linha analógica (interface para o telefone clássico), ponto de acesso a anúncios, ponto de acesso a serviços interativos de voz, ponto de acesso à conferência, etc.

Os endpoints são determinados pelos seus identificadores, compostos do nome de domínio da gateway que controla o endpoint e de um nome local dentro da gateway (ambos não são “case sensitive”).

As conexões são agrupadas em chamadas, que podem conter uma ou mais conexões. Diversas conexões, independente de pertencerem a mesma chamada ou não, podem terminar no mesmo endpoint. As conexões e chamadas são estabelecidas pela iniciativa de um ou mais call agents.

Cada conexão é designada localmente por um identificador de conexão, e será caracterizada pelos seus atributos.

O tipo da conexão é definida pelo seu modo, um parâmetro ajustável, que define em como os sinais de áudio serão tratados nesta conexão. Exemplos de modos de conexão são: o gateway pode apenas transmitir pacotes (sendonly), o gateway pode apenas receber pacotes (recvonly), o gateway pode transmitir e receber pacotes (sendrecv), o gateway deve colocar a conexão em modo conferência (confnce), o gateway não deve nem enviar nem receber pacotes (inactive), etc.

Um sistema básico de telefonia IP baseado em MGCP envolve um ou mais media gateways e pelo menos um call agent. Este call agent receberia a sinalização de todos os media gateways que o servem, de eventos como chamada entrante, off-hook e desconexão. Também enviaria comandos a todas estes media gateways para tocar telefones, discar números, e estabelecer conexões RTP/RTCP.

Esta configuração básica pode ser vista na figura 2, onde um call agent controla dois gateways, aos quais estão conectados telefones.

Figura 2: Modelo básico de telefonia MGCP

Quando o usuário da esquerda levanta o monofone do gancho, o gateway envia um sinal ao call agent. Este então pede ao gateway para criar uma conexão (comando “create connection”) no primeiro endpoint. O gateway aloca recursos para esta conexão e responde ao comando provendo um descritor de sessão, que contém a informação necessária para um terceiro enviar pacotes a recém criada conexão (endereço IP, porta UDP e parâmetros do empacotamento).

O gateway então gera tom de disco para o telefone, e coleta os dígitos discados. Estes dígitos são passados para o call agent, que determina que o assinante de destino está conectado ao gateway da direita. Como o call agent controla o destino, ele tem o endereço IP e informações de algoritmo de compressão necessários para estabelecer a chamada.

O agente então envia um comando para criar uma conexão (“create connection”) no gateway da direita, com o descrição de sessão fornecida pelo primeiro gateway. O segundo gateway aloca os recursos para esta conexão e responde ao comando, provendo seu próprio descritor de sessão. Neste momento, este gateway também deve estar aplicando cadência de ringing para o assinante à direita.

O agente então utiliza um comando para modificar a conexão (comando “modify connection”) para prover ao primeiro endpoint o descritor de sessão do segundo endpoint. Depois disto, a comunicação pode prosseguir em ambas as direções, com os gateways estabelecendo sessões RTP/RTCP.

No caso dos dois endpoints estarem localizados em gateways sob a administração de diferentes call agents, estes dois call agents devem trocar informação através de um protocolo de sinalização call agent a call agent (usualmente IPDC), a fim de sincronizar a criação da conexão entre os dois endpoints. Este cenário mais complexo pode ser visto na figura 3.

Figura 3: Arquitetura geral MGCP em uma rede

A definição do protocolo MGCP pode ser encontrada na RFC 2705, que define sua interface como uma série de transações. As transações são compostas de um comando e uma resposta mandatória.

Existem nove comandos definidos. Os que são iniciados pelo agente para o gateway incluem:

- EndpointConfiguration, utilizado para especificar a codificação do sinal que vai ser recebida pelo endpoint;

- CreateConnection, utilizado para criar uma conexão entre dois endpoints;

- ModifyConnection, utilizado para modificar as características de como o gateway “enxerga” a conexão;

- NotificationRequest, utilizado para requisitar ao gateway que emita notificações quando da ocorrência de eventos especificados em um endpoint;

- AuditEndpoint, utilizado para obter o status de um dado endpoint;

- AuditConnection, utilizado para auditar uma conexão específica.

O único comando que pode ser enviado tanto pelo call agent como pelo gateway:

- DeleteConnection, utilizado para terminar uma conexão.

E por fim os comandos que são iniciados pelo gateway incluem:

- Notify, utilizado para informar da ocorrência de eventos requisitados pelo agente;

- RestartInProgress, utilizado para informar que um endpoint ou grupo de endpoints está sendo colocado em serviço ou fora de serviço.

Todos os comandos e respostas são compostos de um cabeçalho, seguido opcionalmente por uma descrição da sessão. Tanto os cabeçalhos como os descritores de sessão são codificados como um conjunto de linhas de texto, separadas por um caracter de mudança de linha. Os cabeçalhos são separados dos descritores de sessão por uma linha vazia.

O MGCP utiliza um identificador de transação para correlacionar comandos e respostas. Este identificador é codificado como um componente do cabeçalho do comando e repetido no cabeçalho da resposta.

O cabeçalhos dos comandos é composto de uma linha de comando e um conjunto de linhas de parâmetros.

A linha de comando contém o nome da ação requisitada (ou verbo, veja tabela 1), o identificador da transação, o nome do endpoint que deve executar o comando, e a versão do protocolo MGCP.

Command	Code
EndpoinConfiguration	EPCF
CreateConnection	CRCX
ModifyConnection	MDCX
DeleteConnection	DLCX
NotificationRequest	RQNT
Notify	NTFY
AuditEndpoint	AUEP
AuditConnection	AUCX
RestartInProgress	RSIP

Tabela 1: Nomes de verbos de comando (ações) no MGCP

As linhas de parâmetros contém o nome do parâmetro seguido pelo seu valor. O nome do parâmetro é, em muitos casos, constituído de um único caracter em maiúsculas, seguido de dois pontos, espaço e então os valores do parâmetro.

Todos estes itens são codificados como caracteres ASCII separados pro um espaço em branco (ASCII 0x20).

Os identificadores de transação são codificados como uma string de até 9 dígitos decimais, e nos comandos vem imediatamente após o nome do verbo. No mínimo, devem ser únicos pelo máximo tempo de vida das transações dentro do call agent que controla os gateways. Uma entidade MGCP não deve reutilizar um identificador mais rápido que três minutos após ele ter sido utilizado em um comando anterior.

Um exemplo de comando MGCP seria:

RQNT 5461 endpoint-55@tgw-41.infoinst.com MGCP 0.1

N: abc@cal.infoinst.com:5777

X: 45848484

R: hd

A primeira linha é a de comando. RQNT é a ação requisitada (verbo), NotificationRequest. O identificador da transação é 5461, o comando foi emitido para o endpoint chamado endpoint-55@tgw-41.infoinst.com, e a versão do protocolo MGCP é 0.1.

A segunda linha é a NotifiedEntity de abc@cal.infoinst.com:5777. A terceira linha é a string hexadecimal para RequestIdentifier. E finalmente, a última linha é o código para o evento de hook off.

Ou seja, este comando é enviado para a gateway monitorar a ocorrência de evento de hook off no endpoint chamado endpoint-55 da gateway tronco cal.infoinst. A porta UDP tem o número 5777.

Todos os comandos MGCP são confirmados. A confirmação carrega um código de retorno, que indica o status do comando. Este código é um número inteiro, para o qual quatro faixas foram definidas. Valores entre 100 e 199 significam uma resposta provisória, valores entre 200 e 299 uma execução com sucesso, valores entre 400 e 499 significam um erro transiente e valores entre 500 e 599 um erro permanente.

Um exemplo de uma resposta seria:

200 5461 OK

A linha de resposta inicia-se com o código de resposta, seguido pelo identificador de transação e um comentário opcional.

5. Megaco/H.248 – a evolução dos protocolos de controle de gateways

A continuação dos trabalhos do grupo liderado pelo Dr. Huitema deu origem ao protocolo conhecido como Megaco/H.248, ou simplesmente, Megaco. Ambos os protocolos, o MGCP e o Megaco, compartilham de uma arquitetura comum, realizam as mesmas tarefas, porém diferem em muitas áreas.

O protocolo Megaco foi definido mantendo em vista um modelo de conexão paras os media gateways que é composto por duas entidades, as terminações (terminations) e os contextos (contexts).

Terminações são fontes ou sumidouros de um ou mais fluxos de mídia, podendo ser físicos (permanentes) ou efêmeros (temporários, por exemplo, apenas durante a duração de uma chamada).

Contextos são conexões estrela criadas pela associação de múltiplas terminações. Um contexto nulo contém todas as terminações não associadas.

Uma chamada típica Megaco entre dois participantes contém duas terminações. Uma terminação física representada por um tronco PSTN e a outra uma terminação efêmera representada por um fluxo RTP. As terminações são conectadas em um único contexto identificado por um context id. Ambas as terminações são explicitamente adicionadas ao contexto utilizando-se comandos Megaco. Logo, um contexto é essencialmente um agrupamento de terminações conectadas para uma chamada. Toda a contabilidade e logging da utilização de recursos é feita para um contexto.

O modelo Megaco simplifica consideravelmente o estabelecimento da conexão entre o media gateway e entidades fora dele. Ele simplifica o mecanismo pelo qual o agente pode especificar fluxo de mídia e direções deste fluxo. Logo, é capaz de prover um suporte a aplicações muito maior que o MGCP. Por exemplo, estabelecer uma conferência entre múltiplos participantes utilizando o Megaco meramente envolve adicionar várias terminações a um contexto. No caso da utilização de MGCP, entretanto, o call agent precisa estabelecer diversas conexões para um tipo especial de endpoint chamado de ponte de conferência.

O modelo Megaco introduz o conceito de terminações efêmeras para acomodar fluxos RTP, enquanto no caso do modelo MGCP o fluxo RTP está implícito na conexão e é automaticamente criado.

O modelo Megaco introduz o conceito de terminações multiplex e fluxos dentro de uma terminação onde uma única terminação pode ter múltiplos fluxos de mídia que podem ser transmitidas ou recebidas em diferentes canais de transmissão. Isto possibilita o suporte a terminais multimídia H.320.

De fato, o protocolo Megaco é “multimedia ready”, já que tem definida maneira de marcar parâmetros mistos para áudio e vídeo. O suporte a múltiplos fluxos de mídia por terminação e a habilidade de sincronizar fluxos através de propriedades de contexto lhe conferem uma grande vantagem sobre o MGCP, que não prevê suporte multimídia.

Um exemplo de aplicação multimídia é uma videoconferência onde nem todos os participantes tem capacidade de vídeo. Para estes, apenas os fluxos de áudio seriam recebidos/enviados, sem prejuízo para os demais participantes da videoconferência. O Megaco provê mecanismos para separar os fluxos de áudio e de vídeo.

O conjunto de comandos do Megaco é mais flexível em relação ao MGCP, incluindo maneiras de, por exemplo, indagar as capacidades do media gateway (como tipos de pacotes suportados), e portanto se interfacear de acordo com estas capacidades. Isto permite uma grande gama de variedade e complexidade dos gateways.

O conjunto completo é constituído de sete comandos:

- Add, adiciona uma terminação a um contexto;

- Modify, utilizado para modificar as propriedades, eventos e sinais de uma terminação;

- Subtract, que disconecta uma terminação de seu contexto e retorna estatísticas da participação da terminação no contexto;

- Move, que move uma terminação para outro contexto;

- AuditValue, que retorna o estado corrente das propriedades, eventos, sinais e estatísticas de terminações;

- AuditCapability, que retorna todos os possíveis valores para propriedades das terminações, eventos e sinais suportados pelo media gateway;

- Notify, que permite ao media gateway informar o call agent da ocorrência de eventos;

- ServiceChange, que permite ao media gateway informar o call agent que uma terminação ou grupo delas está para ser retirada de serviço ou retornou ao serviço.

Os comandos são enviados para mudar o comportamento do media gateway, em qualquer de seus níveis funcionais, terminações ou contextos.

A maioria dos comandos é enviada pela iniciativa do call agent, para que o media gateway responda. As exceções são os comandos Notify e ServiceChange, enviados a partir do media gateway.

Diferente do MGCP, os comandos e repostas entre o call agent e o media gateway no Megaco são facilmente agrupados em transações, utilizando regras de construção simples e flexíveis. Assim, o overhead nas mensagens pode ser sensivelmente reduzido, bem como também o tempo para o estabelecimento de chamadas.

No MGCP a maioria dos comandos após o estabelecimento da conexão referenciam-se diretamente ao endpoint, sem menção ao connection id, enquanto no Megaco a maioria dos comandos se aplicam às terminações dentro dos contextos. O modo em MGCP se aplica às conexões, enquanto modo no Megaco se aplica às terminações.

Além disso, o Megaco possuí muito mais descritores de parâmetros que o MGCP, permitindo um suporte a uma gama maior de aplicações.

Os pacotes são o principal mecanismo de extensão dentro do Megaco. Pacotes definem novos comportamentos às terminações via parâmetros, eventos, sinais e estatísticas adicionais. A padronização básica do Megaco define um conjunto simples de tipos de endpoints e parâmetros, com os pacotes promovendo um suporte mais amplo.

Os pacotes suportados pelo MGCP estão incluídos em sua padronização principal, enquanto que no Megaco eles serão definidos em RFCs separadas ou anexos, permitindo uma fácil extensão do protocolo. Ao contrário, a extensão do protocolo MGCP é complexa e requer uma nova revisão do protocolo.

Ambos os protocolos, MGCP e Megaco, tratam do quesito segurança. O MGCP, contudo, depende do IPSec como mecanismo de segurança. O Megaco provê um mecanismo adicional de segurança que incluí um cabeçalho de autenticação, quando o IPSec não está disponível.

Podemos concluir que o protocolo Megaco é muito mais flexível e avançado, como era a intenção do grupo Megaco. Criar uma evolução do protocolo MGCP, a fim de suportar uma gama maior de serviços.

O Megaco cobre uma ampla gama de requisitos, é facilmente extensível, provê um suporte maior de aplicações e uma melhor performance em comparação ao MGCP. O Megaco incluí quase todos os pontos fortes do MGCP (por exemplo, transporte, eventos, pacotes, sinais, etc.) e adiciona novas facilidades que permitem a fabricação de gateways com mais capacidades, emergindo como a solução definitiva para a interface entre media gateways e seus controladores.

PARTE 3: Protocolos de empacotamento e transmissão

6. A família H.323

A especificação H.323 na verdade constituí-se de uma série protocolos associados (muitas vezes chamados de família H.323 ou H.32X), fazem parte das recomendações ITU-T para prover serviços de comunicação multimídia sobre uma variedade de redes. Outros padrões incluem o H.255.0 para estabelecimento de chamada e mensagens de gatekeeper, e descreve a utilização do RTP (o Real-time protocol do IETF), e o H.245 para controle de conferência e mensagens de troca de capacitações.

H.323 é um padrão que especifica os componentes, protocolos e procedimentos que provêem serviços de comunicação multimídia, incluindo áudio em tempo real, vídeo, dados, sobre redes de pacotes, inclusive redes baseadas em IP. Pode ser aplicado em uma grande variedade de mecanismos: somente áudio (telefonia IP), áudio e vídeo (videotelefonia), áudio e dados, e os três combinados, incluindo em comunicações multiponto, provendo, deste modo, uma ampla gama de serviços.

Sua primeira especificação data de maio de 1995, porém era extremamente despretensiosa, estabelecendo apenas as bases para a transmissão de áudio/vídeo sobre redes de pacotes, não provendo qualidade de serviço (QoS). Ou como foi chamada na época, de "sistemas telefônicos visuais e equipamentos para redes locais que provêem uma não-garantida qualidade de serviço".

Foi seguida da versão 2, em fevereiro de 1998, que continha três anexos: mensagens h.245 utilizadas pelos endpoints H.323, procedimentos para vídeo codecs em layer e H.323 sobre ATM. Seguiu-se aprimoramentos na versão 3, de fevereiro de 2000, na última versão, 4, datada de novembro 2000 (que já trata dos problemas correlacionados com a solução SIP do ITU-T).

A grande maioria dos fabricantes implementa a versão 2, e estão passando a implementar a versão 4, bypassando a versão 3.

Pode-se afirmar que a implementação H.323 é hoje a mais importante arquitetura na telefonia IP, sucesso alcançado devido à sua grande flexibilidade e escalabilidade, bem como a facilidade de reutilização a infra-estrutura pré-existente.

O H.323 especifica cinco componentes principais:

- Terminais, que são os pontos finais (endpoints) que provêem uma comunicação bidirecional em tempo real ao usuário final, que podem ser tanto um computador pessoal (PC), como um dispositivo stand-alone, que roda aplicações multimídia e H.323;

- o Gatekeeper, componente opcional que fornece o controle de utilização da rede, autorização e autenticação de terminais e gateways, gerenciamento da banda, tarifação, translações de endereços e outros serviços;

- o Gateway, que habilita os terminais H.323 a conectarem-se a outros tipos de redes (ISDN, POTS, etc.), provendo conectividade entre uma rede H.323 e outra não-H.323;

- o Controle de Multiponto (Multipoint Controller), que prove controle centralizado para uma conferência entre três ou mais terminais ou gateways.

- a Unidade de Controle Multiponto (Multipoint Control Unit, ou MCU), que prove processamento de áudio e/ou vídeo para uma conferência.

Todas as mensagens H.323 são codificadas utilizando ASN.1.

Todo terminal H.323 deve suportar o protocolo H.245, utilizado para negociar capacitação e utilização dos canais, e o protocolo H.225 para sinalização de chamada na conexão/desconexão. Também são requeridos outros dois componentes: o protocolo RAS para comunicação com o Gatekeeper (registro, admissão e status), e o suporte para RTP/RTPC para seqüenciamento de pacotes de áudio/vídeo.

O protocolo RAS (Registration, admission and status) é utilizado entre os endpoints (terminais e gateways) e o gatekeeper, para realizar o registro, controle de admissão, mudanças de banda disponível, status, e procedimentos de desconexão. Um canal RAS é utilizado para a troca de mensagens RAS. Este canal de sinalização é aberto entre o endpoint e o gatekeeper antes do estabelecimento de qualquer outro canal.

O protocolo de controle H.245 é utilizado para trocar mensagens de controle fim-a-fim, ditando a operação do endpoint H.323. Estas mensagens de controle carregam informações tais como: troca de capacitações, abertura e fechamento de canais lógicos utilizados para transportar fluxos de mídia, mensagens de controle de fluxo, comandos gerais e indicações.

O protocolo H.225 (sinalização de chamada) é utilizado para estabelecer uma conexão entre dois endpoints H.323. Isto é obtido através da troca de mensagens H.245 no canal de sinalização de chamada. Este canal de sinalização é aberto entre dois endpoints ou entre um endpoint e o gatekeeper.

O protocolo de transporte em tempo real RTP prove serviços de entrega em tempo real de áudio e vídeo. Considerando que o H.323 é normalmente utilizado para transportar dados sobre redes baseadas em IP, o RTP é utilizado para transportar dados através do protocolo UDP. O conjunto RTP e UDP fornecem a parte de transporte de protocolos. Os pacotes de áudio e vídeo são encapsulados no protocolo RTP e carregados em uma conexão UDP entre o emissor e o receptor. O RTP fornece identificação do tipo de payload, numeração de seqüência, timestamping, e monitoramento da entrega. O UDP fornece multiplexação e checksum. O RTP também pode ser utilizado com outros protocolos de transporte.

O RTCP (Real-time transport control protocol) é a contraparte do RTP que fornece serviços de controle. Sua principal função é fornecer feedback sobre a qualidade da distribuição de dados, mas suas tarefas também incluem transportar um identificador (a nível de transporte) para uma fonte RTP, chamado de número canônico, que é utilizado pelos receptores para sincronizar áudio e vídeo.

Outra tecnologia associada à especificação H.323 são os codecs que são utilizados para codificar/decodificar os sinais de áudio e vídeo transmitidos/recebidos.

Cada terminal H.323 deve suportar ao menos uma especificação de codecs de áudio, como definido na ITU-T G.711 (codificação de áudio a 64 kbits/s). Outros codecs opcionais de áudio incluem as especificações G.722 (64, 56 e 48 kbits/s), G.723.1 (5.3 e 6.3 kbits/s), G.728 (16 kbits/s) e G.729 (8 kbits/s).

O suporte a codificação de vídeo é opcional na especificação H.323. Contudo, qualquer terminal capaz de prover comunicação de vídeo deve suportar a codificação especificada na recomendação ITU-T H.261. Outro codec de vídeo muito utilizado é a recomendação ITU-T H.263.

O suporte a transporte de dados é especificado no ITU-T T.120.

Uma visão geral da pilha de protocolos que constituí a família H.323 pode ser obtida na figura 4.

Áudio	Vídeo	Dados	Interface de controle do sistema
G.711 G.722 G.723 G.728 G.729	H.261 H.263	T.120	Controle de chamada H.225	Controle RAS H.225	Controle H.245
RTP/RTCP
UDP		UDP ou TCP
IP
Camada de enlace
Camada física

Figura 4: Pilha de protocolos H.323

O procedimento de estabelecimento de uma conexão simples ponto-a-ponto H.323 pode ser resumida da seguinte forma: o protocolo H.245 abre uma conexão TCP do ponto chamador para o ponto chamado, utilizando uma porta conhecida. Esta conexão carrega o diálogo de estabelecimento da chamada e é freqüentemente referida como “canal Q.931”. Uma vez estabelecida a chamada, o ponto chamado espera em uma porta efêmera (transmitida pelo chamador no canal Q.931) por uma conexão H.245 que é utilizada para a troca de informações de capacitações de áudio e vídeo. Uma vez estabelecida esta conexão H.245, neste cenário simples, é possível encerrar o canal Q.931. Uma relação mestre/escravo é estabelecida através do canal H.245 e, mais importante, a caracterização das sessões RTP que irão então carregar o tráfego. O canal H.245 permanece ativo durante toda a chamada, e é novamente utilizado para a desconexão da chamada. O protocolo RTP fornece uma terminação lógica para o fluxo, e o protocolo H.245 especifica qual terminação de chamada deve ser sinalizada.

7. SIP - Session Initiation Protocol

O Session Initiation Protocol, ou simplesmente SIP, é uma resposta do IETF ao protocolo H.323 definido pelo ITU-T. É o produto do trabalho do grupo MMUSIC, na parte do IETF de dados multimídia e arquitetura de controle, a mesma equipe responsável pelo desenvolvimento dos protocolos RTP e RTCP, tendo sido padronizado pela RFC 2543, datada de março de 1999. Desde então, tem sido a solução preferida de grandes grupos da indústria VoIP, tais como MCI, Level3 e ISC.

O SIP introduz um modelo diferente do modelo H.323/MGCP, sendo fortemente baseado nos protocolos SMTP (Simple Mail Transfer Protocol), a base do serviço de e-mail, e HTTP (Hypertext Transfer Protocol), a base da World Wide Web (WWW). Como estes dois protocolos, é um protocolo textual cliente-servidor, onde requisições são emitidas pelo cliente e respostas são retornadas pelo servidor.

O SIP reutiliza muito da sintaxe e semântica do HTTP, incluindo sua arquitetura de códigos de resposta, muitos cabeçalhos de mensagens, e sua operação em geral. Ele mapeia cada função de telefonia IP a uma ou mais requisições de transação emitidas pelo cliente, e a uma ou mais respostas retornadas por um ou mais servidores.

Também de forma semelhante ao HTTP, cada requisição é uma tentativa de invocar um método no servidor. Dos seis métodos existentes, o mais básico é o “invite”, utilizado para iniciar uma chamada entre o cliente e o servidor.

Porém diferentemente do HTTP e SMTP, o SIP pode ser executado tanto sobre TCP como sobre UDP, já que prove seus próprios mecanismos de confiabilidade. De fato, o UDP é utilizado para permitir mensagens SIP multicast. O UDP também fornece velocidade de operação e escalabilidade, em relação ao TCP.

Um sistema SIP é constituído de apenas dois elementos: os agentes de usuário e os servidores de rede.

Um agente de usuário é um sistema final que atua em favor de quem quer participar de uma chamada. O agente contém ambos os protocolos, de cliente (UAC – User Agent Client), utilizado para iniciar uma chamada, e o de servidor (UAS – User Agent Server), utilizado para atender uma chamada. A presença de ambos os protocolos no agente permite operação peer-to-peer utilizando um protocolo cliente-servidor.

Os servidores de rede podem ser de dois tipos: proxy e redirect. O primeiro atua de maneira semelhante a um proxy HTTP ou agente de transferência de mensagem SMTP (MTA). Recebe uma requisição, determina a qual servidor enviá-la e então reencaminha a requisição a este servidor (possivelmente alterando alguns campos do cabeçalho). O servidor SIP proxy não tem meios de saber se o próximo servidor que receberá a mensagem é outro servidor proxy, um servidor redirect ou um UAS (usuário final). Por esta razão, as requisições de SIP podem trafegar por muitos servidores durante seu caminho entre o UAC e o UAS. As respostas a estas requisições trafegam pelos mesmos servidores em seu caminho de volta, apenas na ordem inversa.

Um servidor do tipo redirect recebe as requisições, mas ao invés de encaminhá-las ao próximo hop, ele informa ao cliente para que este contacte diretamente o próximo servidor, respondente à requisição com uma resposta de redirecionamento, que contém o endereço do próximo servidor.

A principal função do servidor de rede SIP é fornecer a resolução de nomes e localização de usuários. Quando um usuário quer estabelecer uma chamada, o UAC envia uma requisição “invite”. Em geral, o usuário chamador não conhece o endereço IP ou nome de host do UAS do usuário chamado, ele apenas terá o seu nome, usualmente um endereço tipo e-mail, que representa-o (como por exemplo, carlosp@minharede.com). Utilizando este nome, o UAC pode determinar qual servidor de rede pode ser capaz de resolver o nome em um endereço IP. O servidor de rede então reencaminhará a chamada a outros servidores, chegando eventualmente a um servidor que conhece o endereço IP onde o usuário destino pode ser contactado. A resposta à requisição “invite” contém este endereço IP, que será utilizado pelo UAC para enviar transações subseqüentes ao UAS.

O processo de determinação do próximo servidor é conhecido como next-hop routing, e similarmente a outros protocolos de roteamento, como o BGP, prevê mecanismos para a detecção de loops. Para determinar este próximo servidor, um servidor de rede SIP pode utilizar-se de vários mecanismos, incluindo procura via DNS, acesso a banco de dados, execução de programas ou mesmo indagar usuários. Esta habilidade de se determinar o próximo passo de qualquer maneira a disposição permite uma grande mobilidade ao protocolo.

Uma outra característica deste tipo de arquitetura é que o servidor de rede pode ser complemente independente de estados, não necessita guardar qualquer informação a respeito de requisições e respostas. Ele recebe uma requisição ou resposta e a reencaminha, esquecendo-a completamente após isso. As requisições e respostas contém toda a informação necessária ao seu roteamento, alinhando-se perfeitamente com a arquitetura de datagramas da Internet. Um servidor pode ser retirado de serviço sem afetar as chamadas iniciadas através dele.

Este tipo de arquitetura “stateless” facilita a escalabilidade da solução, mostrando claramente suas vantagens em relação ao H.323 (que foi inicialmente concebido para ser utilizado dentro de uma rede local e depois foi extendido a multi-domínios), trabalhando em uma escala global, e simplificando o estabelecimento da conexão.

As requisições SIP são constituídas de uma linha de requisição, campos de cabeçalho e um corpo de mensagem. Os vários campos de cabeçalho contém informação como endereços, tipo de chamada, prioridade da chamada, requisições de roteamento, facilidades do protocolo, entre outras.

O corpo da mensagem, indiferente para o SIP, pode conter qualquer coisa, e é utilizada para acomodar uma descrição do conteúdo de mídia da sessão, usualmente através do protocolo de descrição de sessão SDP, uma sintaxe textual para descrever sessões multimedia unicast e multicast (contendo informações sobre codecs, portas, e protocolos a serem utilizados no envio de dados ao destino, como parâmetros do RTP).

As transações SIP são constituídas de dois tipos de métodos, requisições enviadas pelos agentes-cliente (UAC) e respostas enviadas pelos agentes-servidor (UAS). Os seguintes métodos podem ser utilizados nas mensagens de requisição:

- INVITE, que indica que o usuário ou serviço está sendo convidado a participar de uma sessão;

- ACK, que confirma que o UAC recebeu a resposta final a uma requisição INVITE;

- OPTIONS, que indaga as capacidades do UAS;

- BYE, utilizada pelo UAC para solicitar uma desconexão ao UAS;

- CANCEL, que cancela uma requisição pendente ainda não processada;

- REGISTER, utilizada para registrar um endereço de usuário em um servidor de rede SIP.

As respostas a estas requisições são categorizadas em seis diferentes tipos, identificados pelo seu código de status de três dígitos.

1XX – Informacional (provisória). Requisição recebida e continuando a processá-la;

2XX – Sucesso (final). Ação recebida com sucesso, entendida e aceita;

3XX – Redirecionamento (final). Mais ações são necessárias para cumprir a requisição;

4XX – Client Error (final). A requisição contém uma má sintaxe, ou não pode ser cumprida neste servidor.

5XX – Server Error (final). O servidor não foi capaz de cumprir uma requisição aparentemente válida.

6XX – Global Failure. A requisição não pode ser cumprida em nenhum servidor.

Como o SIP é um protocolo textual, a geração e envio destas mensagens é uma tarefa trivial, podendo ser utilizado linguagens de processamento de texto como o Perl (Practical Extration Report Language).

BIBLIOGRAFIA

. A comparison of H.323v4 and SIP. Nortel Networks, janeiro de 2000.

. H.323 Tutorial. Trillium, The International Engeneering Consortium, Web ProForum Tutorials. www.iec.org.

. MGCP Whitepaper. Anatel Comunnications. www.anatel.net.

. Surpass Solution Package Description – Carrier Class. Siemens Ltda, 2000.

. Surpass Solution Package Description – Virtual Trunking. Siemens Ltda, 2000.

. Use of MEGACO vis-à-vis MGCP to build a Gateway Solution. Hughes Software Systems, 1999. www.hssworld.com.

ARANGO, M.; DUGAN, A.; ELLIOTT, I.; HUITEMA, C.; PICKETT,S. Media Gateway Control Protocol. RFC 2705, outubro de 1999.

BLACK, Uyless. Voice over IP. Prentice Hall, 1999.

GREENBERG, Gary M. IP Telephony Protocols. Unisphere Solutions, Voice Division, outubro de 1999.

HANDLEY, M.; SCHULZRINNE, H.; SCHOOLER, E.; ROSENBERG, J. SIP: Session Initiation Protocol. RFC 2543, março de 1999.

HERSENT, Olivier; GURLE, David; Petit, Jean-Pierre. IP Telephony – Packed-based multimedia communications systems. Person Education Limited, 2000.

HUITEMA, Christian. The design of MGCP and the Call Agent Architecture. Telcordia Technologies, dezembro de 1999.

HERSENT, Olivier; GURLE, David; PETIT, Jean-Pierre. IP Telephony – Packet-based multimedia communications systems. Addison Wesley, Pearson Education Limited, Great Britain, 2000.

MEYER, Gerald. H.323-SIP-MEGACO presentation. Siemens, 1999.

SCHULZRINNE, Henning; ROSENBERG, Jonathan. A comparison of SIP and H.323 for Internet Telephony.

TAYLOR, Tom. MEGACO/H.248: A new standard for Media Gateway Control. IEEE Communications Magazine, outubro de 2000, p. 124-32.

GLOSSÁRIO

ATM Asynchronous Transfer Mode

BGP Border Gateway Protocol

CODEC Coder/decoder

DSL Digital Subscriber Loop

DTMF Dual Tone Multi-Frequency

ETSI European Telecommunications Standardization Institute

HTTP Hypertext Transfer Protocol

IANA Internet Assigned Numbers Authority

IETF Internet Engineering Task Force

IPDC Internet Protocol Device Control

IP Internet Protocol

IPSEC Internet security protocol

ISO International Standardization Organization

IVR Interactive Voice Response

LAN Local Aread Network

MCU Multipoint Control Unit

MG Media gateway

MGC Media gateway controller

MGCP Media Gateway Control Protocol

NTP um padrão de formatação de timestamps

PBX Private Branch Exchange

PC Personal Computer

Perl Practical Extration Report Language

PSTN Public Switched Telephone Network

RAS Registration, admission and status

RFC Request for Comment

RTP Real-time transport protocol

RTPC Real-time transport control protocol

SCN Switched Circuit Network

SDP Session Description Protocol

SGCP Simple Gateway Control Protocol

SIP Session Initiation Protocol

SMTP Simple Mail Transfer Protocol

SSRC Synchronous source – source of an RTP stream

TAC Technical Advisory Council

TCP Transport Control Protocol

TDM Time division multiplexing

UDP User Datagram Protocol

VoIP Voice over IP