Interagindo com Aplicações Telecom - Artigo Revista Java Magazine 93

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

O artigo descreve os conceitos da API Media Server Control (JSR-309), uma API para interação com servidores de mídia utilizada em aplicações de telecomunicações, tais como centrais de atendimento e sistemas bancários via telefone.

De que se trata o artigo:

O artigo descreve os conceitos da API Media Server Control (JSR-309), uma API para interação com servidores de mídia utilizada em aplicações de telecomunicações, tais como centrais de atendimento e sistemas bancários via telefone. Os exemplos são executados utilizando a plataforma Mobicents, um projeto do grupo JBoss para criação de aplicações em redes convergentes.


Para que serve:

Tradicionalmente, uma sessão de comunicação é estabelecida entre duas pessoas como um meio para que elas se comuniquem. Através da API Media Server Control é possível estabelecer sessões de comunicação entre pessoas e aplicações, que interagem com o usuário através de diversas funcionalidades e tipos de mídia, tais como áudio e vídeo.


Em que situação o tema é útil:

O tema é útil no contexto de aplicações multimídia baseadas nos protocolos de comunicação da Internet, como o SIP e o RTP. Com a API é possível criar aplicações multimídia e interativas, tais como aquelas presentes em centrais de atendimento automatizadas e em sistemas de vídeo conferência.

Resumo DevMan:

A API Media Server Control cria um modelo de programação e de objetos único e independente do protocolo utilizado para controlar e interagir com servidores de mídia. Podemos utilizar a API para tocar arquivos de áudio/vídeo para o usuário, fazer gravações e mixar diferentes fontes de dados. Com as classes dela também é possível implementar funcionalidades de conversão de texto para voz, voz para texto e detecção de dígitos teclados pelo telefone.

Autores: Wilson Akio Higashino e Paulo R Sigrist Jr

O estado da arte da tecnologia vem passando por profundas transformações, em que sistemas cada vez mais complexos, executados em hardwares cada vez mais poderosos, aliam o poder de processamento dos mainframes do passado e a flexibilidade inerente dos softwares. Isso não é diferente nas redes de telecomunicações de próxima geração (Next Generation Networks – NGN), em que as grandes centrais telefônicas estão sendo gradativamente substituídas por poderosos servidores, que controlam via software o estabelecimento, o encaminhamento de chamadas e a troca de informações.

Independência de plataforma, alta escalabilidade e desempenho são muito importantes para esse tipo de ambiente, o que faz com que o Java tenha uma presença forte nesse universo. No JCP, por exemplo, é possível listar 22 APIs que fazem parte da iniciativa JAIN (Java APIs for Integrated Networks), um conjunto de APIs focadas em protocolos e arquiteturas direcionadas para redes convergentes de telecomunicações.

Uma API essencial desse conjunto é a SIP Servlets, definida nas JSRs 116 e 289. Essa API permite a criação de Servlets que falam SIP, o protocolo de sinalização padrão das NGNs. O artigo “O futuro das Telecomunicações e o Java”, publicado na Edição 86, possui uma pequena introdução sobre o universo telecom, além de detalhar melhor o protocolo SIP e a API SIP Servlets. Um breve resumo sobre o assunto também pode ser conferido na seção “Sinalização e Mídia”.

Neste artigo, vamos falar sobre outra especificação da iniciativa JAIN: a API Media Server Control, definida na JSR 309. O principal objetivo desta API é prover capacidades multimídias, tais como a geração de streamings de áudio e vídeo e a sintetização de voz, para aplicações servidoras Java. Para isso, ela cria uma camada de abstração sobre Servidores de Mídia (Media Servers), que são servidores utilizados em redes de telecomunicações de nova geração.

Sinalização e Mídia

Antes de iniciarmos o assunto, vamos revisar rapidamente a diferença conceitual entre protocolos de Sinalização e de Mídia.

Suponha duas pessoas, Alice e Bob, que desejam estabelecer uma sessão de comunicação de voz através da Internet. Alice, ao falar em um microfone, tem a sua voz codificada para um formato digital e enviada através da rede. Bob, ao receber esse sinal, realiza o processo inverso de decodificação e reproduz os sons pelo alto falante. Para garantir uma boa comunicação, esta transmissão deve ser feita com baixíssima latência e sem interrupções. O protocolo que transmite esses pacotes multimídias é o que chamamos de protocolo de transporte de mídias, sendo o RTP (Real-time Transport Protocol) o mais comum.

Por outro lado, um protocolo de sinalização tal como o SIP tem o foco no estabelecimento do canal de comunicação entre os pares. É ele que lida com o endereçamento dos pares de origem e destino, com o aviso para o destinatário de chamadas que chegam e com a negociação dos codecs que são utilizados no RTP. Em outras palavras, é a sinalização que encontra o destinatário e faz com que o seu telefone toque.

O SIP está padronizado na RFC 3261 e baseia-se fortemente no HTTP e no paradigma de solicitação/resposta. Assim como o HTTP, uma mensagem SIP possui um método, uma URI de destino, um conjunto de cabeçalhos com informações adicionais e um corpo. Alguns métodos SIP importantes são:

• REGISTER: define o chamado procedimento de registro, equivalente ao login em um site ou comunicador instantâneo. Permite aos usuários registrarem no servidor o endereço físico (IP/Porta) no qual eles se encontram;

• INVITE: utilizado para iniciar uma sessão multimídia. É importante relembrar que no corpo de requisições do tipo INVITE são enviados pacotes SDP (Session Description Protocol), que descrevem as capacidades multimídias do agente que iniciou a chamada. Esta informação é importantíssima, pois permite que os pares possam entrar em acordo quanto ao tipo de mídia que será trocada (ex: áudio, vídeo ou ambos), além dos codecs utilizados para a digitalização das informações;

• BYE: finaliza uma sessão de comunicação.

Servidores de Mídia e a API MSC

Os principais elementos presentes em redes de telecomunicações de nova geração são os servidores SIP, que controlam a sinalização e o estabelecimento de sessões de comunicação. Normalmente, as sessões de comunicação são estabelecidas entre dois UAs (User Agents), que trocam diretamente a mídia através de protocolos tais como o RTP. Todavia, essa comunicação também pode ser feita com o Servidor de Mídia, que entre outras possibilidades pode:

• Fornecer mídias diversas diretamente para o usuário, como anúncios, tons e mensagens;

• Gravar e armazenar sessões de voz/vídeo;

• Detectar dígitos teclados pelos usuários e agir em função disso. A esta funcionalidade é frequentemente associado a sigla DTMF (Dual-Tone Multi-Frequency), embora este termo tenha surgido no contexto da telefonia analógica;

• “Mixar” diferentes canais de voz/vídeo de entrada em um único canal de saída, permitindo a criação de conferências entre múltiplos usuários;

• Fornecer serviços de TTS (Text-To-Speech), possibilitando a leitura dinâmica de dados;

• Fornecer serviços de STT (Speech-To-Text), facilitando e automatizando a interação dos usuários.

Observe na Figura 1 um diagrama da implantação de uma rede NGN. Nessa figura, o agente do usuário comunica-se com um servidor SIP para a criação de uma sessão com um servidor de mídia. A seta vermelha entre os servidores indica que o servidor SIP controla o de mídia. No entanto, as informações da sessão são trocadas diretamente entre os pares envolvidos, sem passar pela sinalização SIP.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?