DevMedia
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
Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia.

Clique aqui para saber como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 69,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

Java Magazine 86 - Índice

O futuro das telecomunicações e o Java - Java Magazine 86

O artigo inicia descrevendo o conceito de NGN (Next Generation Networks), uma arquitetura de rede de telecomunicações convergente baseada em IP. Em seguida, o SIP é apresentado como o protocolo que possibilita a criação de sessões de comunicação nestas redes. Por fim, a API SIP Servlets é apresentada através de exemplos, integrada ao desenvolvimento Java EE e ao servidor de aplicações SailFin.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo
O futuro das telecomunicações e o Java
Desenvolvendo aplicações de comunicação em Java
Conheça os recursos da API SIP Servlets e prepare sua aplicação para Redes de Próxima Geração e o futuro das telecomunicações

A necessidade de comunicação é algo que está no cerne do ser humano. Desde o seu primórdio, a humanidade tem desenvolvido novas maneiras para permitir uma comunicação rápida e eficiente. Atualmente, esta necessidade está ainda mais evidente, o que é refletido diretamente nas três redes principais que utilizamos no nosso dia-a-dia: internet, rede de telefonia móvel e rede de telefonia fixa.
Observem: utilizamos três redes diferentes, todas com o mesmo intuito de habilitar a comunicação entre pessoas e prover serviços para os seus usuários. Parece um pouco redundante? Por isso o conceito de NGN é tão importante.
Next-Generation Networks (NGN) é um termo amplo, utilizado para descrever um conjunto de evoluções arquiteturais nas redes de telefonia fixa/móvel, cujo objetivo primordial é convergir todas as redes em apenas uma. Esta nova rede será baseada em pacotes (mais especificamente no protocolo IP) e será utilizada para transportar todas as informações e serviços. Em outras palavras, é utilizar a internet para os serviços que as redes de telefonia hoje nos provêm, sem perder a mobilidade e a onipresença das redes móveis. Outro ponto importante é que nas NGNs define-se uma arquitetura unificada para a implementação e disponibilização de serviços, independente da camada de transporte, que poder ser acessada de qualquer dispositivo e lugar.
Neste momento, você poderia imaginar: “Mas eu já uso a linha do meu telefone fixo para conexão de internet! Isto não significa que meu telefone já está na internet?”
Esta é uma dúvida bastante comum entre as pessoas. Hoje, utilizamos apenas o meio físico do telefone fixo para acessar a internet. A internet é uma infraestrutura de certa forma paralela à rede fixa. Semelhantemente, quando você acessa a internet através de seu celular, você está utilizando apenas o meio físico para se conectar. Essas três grandes redes são diferentes e independentes, o que requisita manutenção dobrada e frequentes conversões entre os domínios (feitas pelos chamados gateways).
Esta unificação citada trará inúmeras vantagens para os usuários e operadoras, tais como:
•    Uma rede única baseada em pacotes, que tende a fazer um melhor uso de banda que redes baseadas em circuitos tradicionais;
•    Acesso unificado e integrado aos serviços, tais como acesso à caixa postal do telefone pela web, confirmação de transações eletrônicas via telefone e videoconferência entre dispositivos diversos;
•    Independência de dispositivo e de localidade. Assim, você liga para alice@domain.com, não para um número de celular ou telefone fixo. Em qualquer lugar do planeta você recebe uma ligação, no dispositivo em que você estiver conectado;
•    Tarifação diferenciada, baseada no conteúdo trafegado (nem todos os dados são iguais).

E o que nós desenvolvedores ganhamos com este movimento? Primeiramente, abre-se a possibilidade de desenvolvimento de uma nova gama de serviços unificados e de amplo alcance. Além disso, neste novo cenário quase tudo passa a ser controlado por software, o que aumenta também as oportunidades de desenvolvimento de softwares que fazem parte do coração da rede. É uma grande mudança de paradigma se comparado com as grandes centrais telefônicas do passado.
Um lembrete importante: NGN é um conceito arquitetural/comercial. Em termos práticos, existe a especificação de uma arquitetura baseada em NGN chamada de IMS (IP Multimedia Subsystem) e que promete ser o novo padrão do mercado. Esta especificação é atualmente mantida pelo 3GPP, órgão importantíssimo no cenário de telecomunicações, que entre outras responsabilidades mantém tudo que é relacionado ao GSM. Na arquitetura IMS o protocolo de sinalização (ver quadro “Sinalização e Mídia”) utilizado é o SIP, o que ressalta sua importância no cenário atual.
Como não poderia deixar de ser, a plataforma Java está bastante presente neste novo cenário. 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. Algumas das JSRs mais importantes são:
•    JSR 116/289 (SIP Servlets v1.0/1.1), que trataremos neste artigo. Vamos apresentar a API, o que podemos fazer com ela e como integrá-la em nossas aplicações;
•    JSR 22/240 (JAIN SLEE v1.0/1.1), que define um ambiente de execução padronizado para serviços e aplicações;
•    JSR 309 (Media Server Control API v. 1.0), que trata do controle programático de servidores de mídia.

Sinalização e Mídia [13]
Suponha duas pessoas, Alice e Bob, que desejam estabelecer uma sessão de comunicação de voz através da Internet. É razoável supor que ambos os pares deverão ter em seu computador um programa capaz de captar a voz através do microfone, convertê-lo em um formato digital e enviá-lo através da rede. Do outro lado desta linha, um programa terá que receber estes pacotes e decodificá-los a fim de reproduzir os sons pelo alto falante.
Para garantir uma boa comunicação, esta operação deve ser feita com baixíssima latência. Além disso, a voz deve ser amostrada com alta frequência e o envio destas informações deve ser constante, garantindo um canal de comunicação contínuo. O protocolo que transmite estes pacotes multimídias é o que chamamos de protocolo de transporte de mídias. Quando falamos do “universo” SIP, o protocolo de mídia mais comum é o RTP (Real-time Transport Protocol), que funciona em cima da pilha UDP/IP.
Este protocolo seria suficiente se ambos os pares estivessem sempre online e possuíssem sempre um mesmo endereço IP, mas por outro lado seria pouco conveniente, já que exigiria que os usuários combinassem previamente um horário para a sessão. Um protocolo de sinalização, cujo SIP é um representante, procura suprir estas lacunas, lidando com:
•    Aviso ao destinatário de que existe alguém querendo estabelecer uma sessão de comunicação, equivalente ao tocar do telefone na telefonia tradicional;
•    Informe a origem sobre o status da chamada, indicando se uma chamada está em curso, se o usuário está ocupado ou se uma ligação foi atendida;
•    Negociação dos codecs a serem utilizados na codificação/decodificação de mídia;
•    Auxílio no endereçamento dos pares de origem e destino, de forma que eles possam se encontrar, independente do dispositivo e local em que se encontram.

É importante ressaltar que os protocolos de mídia e sinalização normalmente são independentes e podem existir em diferentes combinações. O protocolo RTP, por exemplo, é frequentemente utilizado junto ao H.323, um protocolo de sinalização semelhante ao SIP.
Além disso, embora estejamos exemplificando através de protocolos “IP”, estes conceitos também se aplicam às redes de telecom tradicionais, cujo principal protocolo de sinalização é o SS7.

O que é SIP?
SIP é um protocolo de sinalização baseado em texto cujo objetivo principal é o estabelecimento de sessões entre dois ou mais participantes. Por sessão entende-se uma sessão de comunicação multimídia, que pode incluir voz, vídeo, mensagens instantâneas e outros tipos de informações. O SIP habilita a descoberta dos endereços de rede para comunicação dos pares e a negociação das capacidades multimídia.
Em um cenário regido por este protocolo, os usuários podem estar conectados através de múltiplos dispositivos, o que necessita conhecermos o seu endereço de rede atual. Além disso, estes dispositivos variam quanto a sua capacidade multimídia, o que obriga a negociação das mídias que serão utilizadas em uma sessão de comunicação. Por exemplo: alguns dispositivos possuem suporte a vídeo, enquanto outros são restritos a áudio e/ou mensagens de texto.
Este protocolo está padronizado na RFC3261 e baseia-se fortemente no HTTP e no paradigma de solicitação/resposta. Veja um exemplo de uma requisição SIP na Listagem 1.

Listagem 1. Exemplo de Requisição SIP do tipo INVITE.
INVITE sip:Bob@domain.com SIP/2.0
Max-Forwards: 70
Content-Length: 380
Supported: replaces
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
To: <sip:Bob@domain.com>
Contact: <sip:alice@192.168.1.101:63059>
Cseq: 1 INVITE
User-Agent: X-Lite 4 release 4.0 stamp 58833
Via: SIP/2.0/UDP 192.168.1.101:63059;branch=z9hG4bK-...
Content-Type: application/sdp
Call-Id: YzZmYzQxZGE0YmZhMDdhYjM2YjIyZDg5ZTkwYTMxM2U.
From: "Alice"<sip:alice@domain.com>;tag=1863dd45

v=0
o=- 1285808055518345 1 IN IP4 192.168.1.101
s=CounterPath X-Lite 4.0
c=IN IP4 192.168.1.101
t=0 0
a=ice-ufrag:6508a3
a=ice-pwd:a16d43e8a9b27543f6db20919f37d01d
m=audio 56948 RTP/AVP 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=candidate:1 1 UDP 659136 192.168.1.101 56948 typ host
a=candidate:1 2 UDP 659134 192.168.1.101 56949 typ host

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. No exemplo mostrado, o método é o INVITE, que define um convite para a URI sip:Bob@domain.com para participação em uma sessão. Por sua vez, o corpo é um pacote SDP que determina as capacidades de mídia do usuário que iniciou a comunicação.

SDP: SDP (Session Description Protocol) é um formato para descrição de parâmetros de inicialização para streaming de mídias e está descrito na RFC 4566. Ele especifica as mídias suportadas por um dispositivo, os codecs e todos os outros parâmetros relacionados.

O SIP, no entanto, possui algumas diferenças importantes em relação ao HTTP. Primeiramente, SIP é um protocolo peer-to-peer, onde todos os participantes podem enviar requisições. Além disso, requisições SIP podem ser assíncronas, assim, um par pode enviar respostas provisórias, que fornecem um status parcial do andamento da solicitação.
O estabelecimento de Sessão
A Figura 1 mostra um exemplo do estabelecimento de uma sessão SIP. Temos dois usuários que exercem o papel (lógico) de User Agents (UA). A origem e o destino da sessão são identificados pelas SIP URIs sip:alice@domain.com e sip:bob@domain.com respectivamente. A primeira parte de uma SIP URI representa o usuário e a segunda o seu domínio. Assim, Alice deseja iniciar uma sessão multimídia com Bob e para isso envia uma requisição SIP do tipo INVITE, endereçada a sip:bob@domain.com, para um servidor que exerce o papel de Proxy. O Proxy tem como objetivo principal realizar o roteamento da requisição para o usuário destino.

É importante relembrar que no corpo do INVITE é enviado um pacote SDP, que descreve as capacidades multimídias do UA 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, além dos codecs utilizados para a digitalização das informações.
O UA destino recebe o INVITE e envia uma resposta provisória com status 180, indicando que uma chamada está em progresso, mas ainda não foi atendida. Ao atendê-la, uma resposta de código 200 (Ok) é enviada ao chamador. Nesta resposta, é enviado também um pacote SDP com as capacidades de streaming do destino. Finalmente, o chamador envia uma mensagem do tipo ACK para confirmar o recebimento da resposta 200. Com isso, a sessão é estabelecida e os pares estabelecem a conversação através da troca de mídia via streaming.
"

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



A DevMedia é um portal para analistas, desenvolvedores de sistemas, gerentes e DBAs com milhares de artigos, dicas, cursos e videoaulas gratuitos e exclusivos para assinantes.

O que você achou deste post?
Publicidade
Serviços

Mais posts