4o Congresso Temático de Dinâmica, Controle e Aplicações

6-10 de junho de 2005

UNESP – Campus de Bauru

Protocolo Cyclops de Teleconferência

Mendes, John A. F., Tusset, Angelo M.

Depto de Ciência da Computação, UnC,
89400-000, Porto União, SC
john@wnet.com.br, angelo@pu.unc.br

Wangenheim, Aldo v.
Depto de Ciência da Computação, CTC, UFSC,
88040-900, Florianópolis, SC
awangenh@inf.ufsc.br

Resumo: Este trabalho apresenta uma proposta de
um protocolo de comunicação em nível de aplicação
para possibilitar a realização de teleconferências
radiológicas ponto a ponto permitindo a transferência
de pacotes de dados e imagens. O protocolo foi
batizado de “Protocolo Cyclops de Teleconferência -
PCT”.
Para validação do PCT, foi desenvolvido um
sistema voltado a telemedicina ou especificamente
para a área da teleradiologia. O sistema proposto
denomina-se “Sala de Laudos Virtual Ponto a Ponto –
SLVPP”, onde seu principal objetivo é compartilhar
entre os usuários participantes de uma mesma sessão,
arquivos de imagem no padrão DICOM 3.0 e suas
ações durante a utilização do sistema.
Durante toda a sessão de utilização do sistema, os
usuários poderão se comunicar através de chat e
também através voz sobre IP.
O resultado final deste trabalho é um protocolo
PCT que permite a criação de sistemas ponto a ponto
gerando um ambiente colaborativo para que dois
usuários médicos possam efetuar laudos em conjunto.
Palavras-chave: PCT, Protocolo,
Teleconferência, VoIP, Cyclops.
Introdução
Dentre as pesquisas e aplicações desenvolvidas
para área médica estão trabalhos voltados para
telemedicina e teleradiologia, por exemplo. Para estes
dois exemplos, nem todas as aplicações desenvolvidas
possuem tecnologia própria para seu pleno
funcionamento, portanto, são adotadas ferramentas
que foram desenvolvidas para outros fins para
satisfazer um requisito específico, por exemplo, a
aplicação Microsoft Netmeeting®, que pode ser
utilizado para transferência de áudio, vídeo e dados.
Em alguns casos, algumas ferramentas oferecem
um conjunto de bibliotecas e dispositivos de acesso
que permitem a sua integração com outros sistemas.
Exemplo disso é o Kit de Desenvolvimento de
Software, SDK, que é fornecido por algumas empresas
para que suas aplicações possam ser integradas a
outros aplicativos, como NetMeeting[1].
A proposta deste trabalho é oferecer um protocolo
de comunicação pertencente da camada de aplicação
que permita ser integrado em sistemas médicos
distribuídos. Espera-se que o protocolo denominado
PCT, Protocolo Cyclops de Teleconferência, permita o
desenvolvimento de sistemas de informática médica,
como por exemplo, sistemas de telemedicina e
teleradiologia que utilizam técnicas de
teleconferências possam a vir ter uma biblioteca
específica para seu desenvolvimento.
As funcionalidades do PCT são de transmitir dados
e imagens. Ainda nesta versão não haverá recursos de
transmissão de áudio ou vídeo.
A utilização da biblioteca PCT poderá evitar a
utilização de aplicativos que foram desenvolvidos para
fins outros que não exclusivamente para
teleconferências médicas.
Espera-se que o protocolo PCT proposto por esta
pesquisa, permita a médicos que trabalham em centros
de saúde remotos ou hospitais e demais centros de
saúde que não dispõem de médicos especialistas,
possam utilizar softwares que adotem o PCT como
protocolo de teleconferência de seus sistemas,
permitindo discutir imagens médicas com outros
especialistas. Esse processo poderá evitar o
deslocamento do paciente para centros de saúde
maiores. Caso a utilização do sistema seja eficiente
como se espera, pode-se supor também que haverá
economia no que diz respeito a translado de pacientes
ou médicos, inclusive de chapas de raios-X que
deixam de ser impressas e passam a ser utilizada
somente por meio digital, já que o protocolo permitirá
a transferência de imagens entre sistemas distribuídos.
No ponto de vista educacional e social, poderá
haver uma maior integração entre especialistas
médicos, sendo assim, o protocolo permitirá a criação
de sistemas voltados a teleconferências médicas, como
a teleradiologia.

1
Material e Métodos
Foi feita uma análise para determinar qual seria a
estrutura do protocolo. Desta análise, foi constatado
que haveria o mesmo padrão do protocolo IP[7], mas,
o protocolo PCT trabalharia na camada de aplicação.
Seguindo o conceito do protocolo IP, alguns de
seus campos foram adotados para permitir a
integridade da transmissão. Os campos adotados para
compor o protocolo PCT foram, identificação,
comprimento, tipo de serviço, soma de verificação e
dados.
O protocolo PCT foi desenvolvido em uma
primeira versão visando comunicação ponto a ponto,
portanto, não foi necessário na composição deste
protocolo nenhum campo que controle a sessão da
comunicação, pois interpreta-se que há somente uma
única sessão em comunicação ponto a ponto.
A Figura 1 apresenta o protocolo PCT ponto a
ponto e sua composição de campos.
Cabeçalho Dados
ID SERVIÇO CS LN
Figura 1: Formato do protocolo PCT Ponto a Ponto
Na seqüência é apresentado o significado de cada
campo e seus objetivos:
Cabeçalho – esta área contém um conjunto de
campos para controle das informações que são
transmitidas. O tamanho total suportado é 63 bytes;
ID – Responsável pela identificação de cada
pacote, sendo seu tamanho máximo de sete
posições.
A identificação é importante para diferenciar
cada pacote que é transferido entre os
computadores, pois com essa identificação há a
possibilidade de efetuar controles de pacotes e até
organizá-los.
SERVIÇO – Responsável pela identificação
do tipo de serviço que o protocolo PCT
transportará, sendo seu tamanho máximo de doze
posições.
No campo serviço é colocado à informação
do tipo de dados que o pacote esta transportando.
Essa informação é fundamental para que o host
remoto que receber o pacote PCT saiba que tipo de
ação deve tomar, ou seja, se no serviço estiver
definido “mouse”, então, o host remoto pega as
coordenadas do mouse (x,y) que são enviadas no
campo dados e informa o sistema da nova posição
que o mouse deve tomar.
As ações gravadas neste campo são descritas
na Tabela 1 a seguir:
2
Tabela 1 - Representação das ações do campo Serviço
Serviço Descrição
createdir Criação de diretório;;
getwindow Envio da resolução de vídeo;
Sendchat Envia texto de diálogo;
sendalert Envio de Sinal de notificação;
numfiles Envio do número total de arquivos
que serão transferidos;
senddatafile Solicita o envio de dados do arquivo
a ser enviado;
sendzipfile Envio do arquivo compactado;
changectrl Notifica a troca de controle da
sessão;
namebytes Envio do Nome e Bytes do arquivo a
ser enviado;
changescreen Solicita a mudança de resolução do
vídeo;
mousemove Envio das coordenadas x e y do
mouse;
CS – Responsável pela soma de verificação
do conteúdo do pacote, sendo seu tamanho
máximo de sete posições.
A soma de verificação funciona
transformando cada caractere do conteúdo do PCT
em seu valor referente a posição da tabela ASCII.
Após isso, é feita uma soma de todas as posições e
divide-se por 256. Essa média é colocada no
campo CS.
Basicamente o mesmo trabalho é efetuado
quando o pacote chega no seu destino, então, o
valor do calculo efetuado quando o pacote chega
ao destino é comparado com o valor do campo CS,
caso não confirme, é enviada uma solicitação para
retransmitir o pacote.
LN – Responsável pela soma do comprimento
do pacote, sendo seu tamanho máximo de sete
posições.
O tamanho máximo do pacote PCT é de
10.000 bytes, portanto, retirando 63 posições
referente a seu cabeçalho que é fixo, temos um
comprimento que é variável e que pertence à
camada de dados. Esse valor de comprimento é
importante para que se possam desenvolver
sistemas capazes de gerar estatísticas de fluxo de
dados durante uma sessão, ou mesmo para sua
validação de dados.
Dados – esta área é responsável pelo
armazenamento dos dados que são transmitidos entre
os hosts. Sua capacidade máxima é de 9937 posições.
As ações descritas na Tabela 1 possuem papel
importante para o perfeito funcionamento do PCT.
Cada ação é descrita como segue:
Createdir – Quando o protocolo transmite esta
ação, ele permite que o computador remoto crie um
diretório com um nome específico (hora, dia, mês,
ano, nome paciente). O diretório criado tem a função
de armazenar as imagens Dicom que também são
transmitidas por este protocolo.
Getwindow – Esta ação permite que o protocolo
negocie entre ambos hosts, qual a menor resolução de
vídeo, ou seja, ambos computadores participantes da
teleconferência deverão ter resoluções igual ao
iniciarem uma sessão, portanto, a troca de resoluções é
fundamental.
Sendchat – O protocolo PCT permite troca de
mensagens entre os participantes de uma
teleconferência. Esta ação permite que seja enviado
um pacote contendo em sua camada de dados uma
mensagem para o host remoto.
Sendalert – Semelhante a ação sendchat, porém,
sua função é permitir troca de sinais entre os
participantes de uma teleconferência. Estes sinais
podem ser utilizados para definir ações específicas
entre ambos hosts. Sinais como de início e término da
sessão, ou qualquer outra notificação que o
desenvolvedor de uma aplicação de teleconferência
desejar.
Numfiles – Uma sessão de teleconferência pode
haver transferência de arquivos como imagens Dicom,
portanto, o protocolo PCT permite com esta ação
informar ao host destino o número de arquivos que
serão transmitidos. Esta ação é obrigatória para que se
possa transferir um arquivo entre ambos hosts.
Senddatafile – Esta ação trabalha em conjunto
com Numfiles, ou seja, ela é responsável pelo envio de
informações referente ao arquivo a ser enviado. O
nome do arquivo e tamanho em bytes são enviados
antes do envio real do arquivo. As informações são
utilizadas para validar os dados ao final da
transmissão.
Sendzipfile – Solicita ao host remoto que envie o
arquivo descrito pelas informações repassadas pela
ação senddatafile. Quando o host remoto recebe o
número de arquivos que serão enviados, ele solicita o
envio dos dados de cada arquivo através da ação
senddatafile, e em seguida é solicitado o envio dos
arquivos um a um através desta ação. Mas, antes de
enviar o arquivo, ele é compactado com algoritmo de
compressão sem perda de dados e somente após a
compressão é despachado.
Changectrl – Diante de uma teleconferência, cada
participante necessitará de um momento exclusivo
para trabalhar e expressar seus interesses e dúvidas.
Portanto, para haver ordem durante uma sessão,
apenas um participante da teleconferência poderá
utilizar o mouse e executar suas ações sem a
interferência do outro membro participante. Para esta
situação, esta ação permite definir quem está o estatus
de usuário ativo. Este status permite que apenas um
usuário se manifeste por vez. Quando achar
necessário, o usuário poderá repassar o controle da
sessão para o outro usuário através deste comando.
Namebytes – Esta ação permite que o participante
da teleconferência que receberá as imagens, solicite ao
3
outro host que envie os dados do arquivo. Não deve
ser confundido esta ação com a ação senddatafile pois
esta ação efetua a solicitação dos dados, e a ação
senddatafile as envia.
Changescreen – Permite alterar a resolução do
vídeo do host remoto. Esta ação executa a solicitação
de mudança da resolução para a menor resolução
investigada pela ação getwindow.
Mousemove – Por fim, esta última ação é
responsável pelo envio de coordenadas do mouse. O
usuário que estiver com o controle da sessão que é
obtido através da ação changectrl poderá transmitir as
coordenadas x,y para o host remoto.
Tecnologia Empregada
Para efetuar a transmissão dos pacotes, foi adotada
as bibliotecas de sockets que são encontradas na
maioria dos sistemas operacionais modernos[3].
Socket podem ser utilizados para efetuar
transmissões de mensagens entre computadores, sendo
necessário apenas o IP e porta de comunicação do host
destino. Basicamente esta biblioteca utiliza a API
Winsock1 do sistema operacional Windows, uma
camada de interface entre um aplicativo Windows e
uma rede TCP/IP subjacente[4].
Fica claro que o ambiente de funcionamento é
Microsoft Windows®. Já a ferramenta de
desenvolvimento foi Borland Delphi® que possui as
bibliotecas TcpClient sockets e TcpServer sockets.
A porta de comunicação utilizada pelo protocolo
PCT é 31280, mas pode ser configurada para qualquer
outra.
Funcionamento
Para utilizar o protocolo PCT, deve-se seguir o
conceito de chamar a classe do protocolo em modo
instanciado, definir o serviço no cabeçalho e quais os
dados que serão enviados. O Quadro 1 demonstra
claramente o processo de envio de mensagens entre os
hosts utilizando o PCT. No local onde descreve
nome_do_serviço é inserido um dos serviços descritos
na Tabela 1. No local onde esta descrito dados, pode-
se inserir os dados que devem ser transportados pelo
PCT. Todos os demais campos dentro do cabeçalho
como, ID, CS e LN são automaticamente preenchidos
antes do envio do pacote.
ProtocolPCT := TProtocolPCT.Create; //Instancia a classe.
ProtocolPCT.sendProtocol('nome_do_serviço’,dados); //Envio
dos dados
Quadro 1 – Exemplo de envio de dados utilizando PCT.
1
Winsock é uma forma abreviada de Windows
Sockets. A interface de sockets originou-se no Unix de
Berkeley como a API de sua pilha de rede TCP/IP. O
Winsock é baseado na API Berkeley Sockets e inclui a
maioria das funções-padrão da API BSD, bem como
algumas extensões específicas do Windows[4].
 Para o recebimento da mensagem que contém o
protocolo PCT, é criada uma variável para armazenar
a mensagem. A variável denominada Buffer permite
armazenar em seu conteúdo até 10.000 bytes por Preparação da Sessão
pacote PCT. Após seu recebimento, outras variáveis Médico A (Sala de
passam a receber os conteúdos dos campos do Laudo Virtual)
protocolo. A terceira linha do Quadro 2, exibe a
extração feita do campo serviço e é armazenado em
uma variável de mesmo nome.
Após seu cabeçalho ser desmontado, é feita a
validação do CS e em seguida é analisado o campo
SERVIÇO onde define qual tarefa dever ser executada. Seleção de Imagens Envio de Imagens
Para cada tipo de serviço encontrado no campo
SERVICO, o desenvolvedor poderá programar uma
tarefa que sua aplicação deve executar.
O Quadro 2 exibe parte do código utilizado no
recebimento do pacote PCT.

Var Buffer : Array [0..9999] Of Char; //Variável de Canal de Áudio

armazenamento das mensagens.
servico : String; //Variável de armazenamento do servido Host Destino
do pacote PCT.
servico := Copy(Buffer,15,12); //extraindo o conteúdo do
campo serviço.

Quadro 2 – Exemplo de recebimento do pacote PCT.

Ambiente de Análise das Imagens

Figura 3 – DCU – Refinamento do Módulo Sala de

Cyclops Personal
Paciente Médico B
Ambiente de Análise das
Médico A Sala de Laudos Virtual P2P
Figura 2 – DCU – Visão Geral
Segundo o diagrama da Figura 2, o paciente
submete-se a tomografia para obtenção das imagens
DICOM. O médico com base nas imagens obtidas a
partir do tomógrafo, utiliza a aplicação Cyclops
Personal para visualizar as imagens permitindo
analisar e laudar.
Com base nas Imagens, o médico poderá acessar o
módulo de Sala de Laudos Virtual para obter uma
segunda opinião.
No diagrama apresentado pela Figura 3 podemos
ver o refinamento do diagrama anterior da Figura 2. O
módulo Sala de Laudos Virtual se abre em outros
casos de uso, mostrando seu objetivo.
Laudos Virtual
O fluxo de evento da Preparação de Sessão
consiste em o médico acessa o ambiente de preparação
de sessão para dar início a laudos cooperativos. Caso
nenhuma imagem esteja aberta, o sistema emite um
alerta de que não é possível acessar Sala de Laudos
Virtual sem Imagens.
O fluxo de evento de Seleção de Imagens permite
que o médico com base nas imagens obtidas no exame
do tomógrafo possa selecionar somente as imagens
que deseja utilizar durante o laudo cooperativo,
evitando assim que imagens desnecessárias sejam
transferidas para o host remoto.
Para o fluxo de evento Host Destino, o médico
entra com DNS do host destino ou IP. Caso o DNS
esteja errado, o sistema retorna uma mensagem
alegando que não é possível efetuar conexão.
Há também a possibilidade de haver exceções,
como, o host não responder a conexão, e, portanto o
sistema emite um aviso de que não foi possível
estabelecer uma conexão.

4
 considerada o coração do protocolo PCT. Todas as
demais classes estão relacionadas a ela.
A classe é responsável pela formatação do
Canal de Áudio Disposição das Ima protocolo e também pela leitura e manipulação dos
Médico (Ambiente de
Análise das Imagens) dados transmitidos e recebidos entre os hosts.

USelectImagesForRoomOfDecision uRoD_Communication
ThumbiesList : TList ClientSocket : TTcpClient
Linha Ampliação Status : TStatus memProtocol : array of str
numFiles : Integer
lastIndex : Integer sendProtocol( )
selectedImages : TList genID( )
sListImages : TStringList receiveMoveMouse( )
applicationModel : TApplicationModel receiveImgPosition( )
numfileReceive : Integer receiveScrollImage( )
lenData : Integer receiveImgMove( )
Círculo Rotação sumSizeFile : Longint receiveImgZoom( )
nameFile : String receiveImgLupe( )
currentSeries : TCyclopsSeries receiveActivateLupe( )
bRoD : Boolean receiveHideLupe( )
bScrollBar : Boolean receiveImgWindow( )
bLupe : Boolean complete( )
bControl : Boolean
Alteração bImageMove : Boolean
checksum( )
Retângulo IsManager : Boolean
receivePing( )
MeioPressionado : Boolean
Ângulação IsConnected : Boolean
nPing : Integer
idFrame : Integer
Figura 4 – DCU – Refinamento do Módulo Ambiente ScreenWidth : Integer
ScreenHeight : Integer
de Análise das Imagens iCol : Integer
iRow : Integer
userSelected : Integer
Para o fluxo de evento Canal de Áudio, inicia-se nSessions : Integer
nUsers : Integer
uma conexão com o host destino e abre um canal para nIntervalo : Integer
nAuxIntervalo_Mouse : Integer
áudio conferência. Caso o host destino não aceitar nAuxIntervalo_ImgMove : Integer
áudio, o sistema emite um alerta de impossibilidade de nAuxIntervalo_ImgZoom : Integer
nAuxIntervalo_ImgWindow : Integer
estabelecer um canal de áudio. nIntervalo_ImgMove : Integer uRoD_PreparationSession
sDateTimeSession : String
Por fim, o fluxo de evento, Envio de Imagens, sDirSession : String ClientSocket : TTcpClient
sDirSession : String
executa o envio das imagens para o host destino para IPCall : String
Ultimo_Pacote : String sDataSession : String
que inicie o laudo cooperativo. Essa ação pode sDataGlobal : String numFiles : Integer
nPercPartialSizeFile : Integer
idSession : String
retornar mensagens alertas como, direito de acesso a nPercSizeFile : Integer
ping( ) sNameFileDICOM : Integer
disco. SpBHelpClick( )
sendScreen( )
A Figura 4 apresenta o refinamento das analise de TcpServerAccept( )
TcpClientError( ) receiveScreen( )
imagens onde o médico já com a conexão estabelecida TcpClientDisconnect( ) getScreen( )
receiveChat( )
GetZipFile( )
com o outro host remoto permite laudar SendZipFile( ) zipFileDICOM( )
GetDataFile( ) unZipFileDICOM( )
colaborativamente. SendDataFile( ) sendFileDICOMCompress( )
receibeFileDICOMCompress(
Diversas ações podem ser executadas entre ambos zipNumFiles( )
beginDecision( ) createSession( )
os hosts, como, efetuar marcações sobre as imagens subString( ) sendNumFiles( )
changeVideo( )
edtHostKeyPress( )
com linhas, círculos, retângulos e ângulos. Também SpBNewClick( ) createDirSession( )
unZipFileDICOM( ) sendNameUser( )
pode-se movimentar as imagens, rotacionar, e efetuar getSizeFile( ) receiveListSessions( )
receiveListUsers( )
ampliação. preparationConnection( )
changeStatus( ) joinSession( )
A Figura 5 representa o diagrama de classes. Estas getServerSessions( )
closeSessionsAndSystem( )
classes foram adicionadas ao sistema que permitiu exitSession( )
configButtonsManagerSessio
validar o protocolo como descrito na seção resultados.
As classes foram divididas seguindo um critério
simples de organização de atributos e métodos. Um
grupo de atributos e métodos são responsáveis pela Figura 5 - Diagrama de Classes
seleção das imagens, esta classe possui uma interface
com o usuário e é denominada
UselectImagesForRoomofDecision. Resultados
A segunda classe denominada
Para validar o protocolo PCT foi proposta e
URoD_PreparationSession, é responsável pela
desenvolvida uma aplicação denominada “Sala de
comunicação inicial entre os hosts, ou seja, esta classe
Laudos Virtual – SLV”. A SLV deveria funcionar
comprime as imagens e as envia como também cria os
como sistema distribuído que contenha todas as
diretórios para seu armazenamento e configura as
funcionalidades possíveis que o PCT pudesse ser
resoluções de tela de ambos os hosts.
testado em todas suas possibilidades de
Por fim, a classe URoD_Communication, é
funcionamento.
responsável por toda a comunicação, sendo

5
 A SLV é uma aplicação ponto a ponto onde seu
objetivo é fornecer recursos de uma sala virtual para
que médicos possam discutir e efetuar lado médico
com base em imagens digitais médicas no padrão
DICOM 3.0[5].

Figura 7 – Interface de Abertura da SLV

A Figura 8 é o segundo passo para iniciar um

laudo colaborativo, sendo necessário selecionar as
imagens que aparecem do lado esquerdo da janela e
arrastá-las para o lado direito. Esta ação determinará
Figura 6 – Interface de Abertura da SLV quais imagens serão utilizadas durante o laudo
colaborativo.
A SLV foi desenvolvida para ser utilizada sobre
uma aplicação já existente, Cyclops Personal. Esta
aplicação já executa as tarefas de leitura de arquivos
no padrão DICOM 3.0 e também manipulação sobre
as imagens.
Para Cyclops Personal foi utilizada a ferramenta de
desenvolvimento Borland Delphi® e seu código-fonte
foi disponibilizado para que fosse adaptado para
utilização da SLV.
As classes desenvolvidas foram integradas ao
Cyclops Personal e permitiram a validação e testes
utilizando o protocolo PCT.
A Figura 6 apresenta a interface inicial da
aplicação da SLV. As funcionalidades desta interface
consistem em abrir imagens DICOM, ampliar, marcar,
alterar o window2, alterar a disposição das imagens e
iniciar um laudo colaborativo com o protocolo PCT.
A Figura 7 representa a interface principal já com
algumas imagens DICOM abertas. Este seria o
primeiro passo para um laudo colaborativo. Figura 8 – Interface de Abertura da SLV
Pressionando o último botão da barra de ferramentas
desta interface, é apresentada uma nova janela Dispondo das figuras selecionadas, basta digitar o
representada pela Figura 8. DNS ou IP do host remoto e clicar em Connection. As
barras de progressão indicam a transmissão das
imagens para o destino.
Após o envio completo das imagens, é aberta uma
nova janela onde ocorrerá o laudo colaborativo.
A Figura 9 apresenta o resultado da janela de laudo
colaborativo onde são executadas as ações descritas no
caso de uso da Figura 4, ou seja, mover as imagens,
rotacionar, ampliar, alterar o window, sinalizar sobre
as imagens e também alterar o modo de exibição das
imagens.
2
Alteração de window consiste em uma ação
disponível no padrão DICOM que determina a
quantidade de água e tecidos podem ser visualizados.

6

Figura 9 – Interface de Abertura da SLV
A Figura 10 representa a interface que permite
alterar o modo de exibição das imagens. Esta
funcionalidade permite ter uma visão geral das
imagens que estão disponíveis.
Figura 10 – Interface de Abertura da SLV
O ambiente da SLV permite que as imagens
enviadas através do protocolo PCT possam ser
discutidas como se estivessem utilizando um
negatoscópio. Um usuário de cada vez pode
movimentar e clicar com seu mouse sendo que suas
coordenadas são transmitidas para o host destino
através do protocolo PCT. A SLV também oferece
diálogo por chat, o que permite uma maior interação
entre os participantes da sessão, sendo que todo o
diálogo é transmitido através do PCT.
A aplicação SLV também efetuou transferência de
voz sobre IP, mas para isso, contou com ajuda de
aplicações externas. Inicialmente foi adotada a API da
aplicação NetMeeting®, porem sua flexibilidade
deixou a desejar, sendo mais interessante utilizar uma
outra ferramenta de voz sobre ip gratuita e de código
fonte aberto. A ferramenta adotada denomina-se
REMKO[6] e permite capturar o áudio, comprimir
através de APIs do próprio sistema operacional
7
Windows®, ou seja, pode-se escolher o melhor
algoritmo de compressão que desejar, como, gsm 6,10,
pcm, ou qualquer outro codificador disponível pelo
Windows®.
A ferramenta de áudio REMKO permite também a
transferência de dados através de UDP para o host
destino bastando indicar o IP e porta desejada.
Resultados e Discussão
O protocolo PCT atingiu os objetivos esperados.
Efetuou a transmissão das imagens corretamente uma
a uma e possibilitou a transferência das coordenadas
de mouse e suas ações.
Foi constatado que é necessário o desenvolvimento
de um sistema de validação de ações transmitidas, pois
há uma seqüência obrigatória a seguir para que o
protocolo PCT possa trabalhar com eficiência.
Em alguns casos durante os testes com o aplicativo
Cyclops Personal, o protocolo PCT interrompeu sua
transmissão em um dos hosts por motivo de pré-
requisitos de dados anteriores, ou seja, não poderia ser
possível a execução de uma ação específica sem antes
ter enviado informações pertinente que permitissem a
próxima ação.
Esta falta de validação de pré-requisitos se não
controlada pelo desenvolvedor através de códigos
adicionais durante o desenvolvimento de sua aplicação
de teleconferência permitirá a existência de brechas
causando eventuais erros durante uma sessão.
O protocolo PCT permitirá o desenvolvimento de
diversas aplicações médicas que necessitem
transmissão de coordenadas e ações de mouse,
diálogos por chat e também transferências de imagens
entre hosts.
Há também a necessidade de integração ao
protocolo PCT de recursos de transmissão de voz
sobre ip autônomos sem que haja a necessidade de
utilização de ferramentas de terceiros como a
ferramenta REMKO adotado nos testes.
Esta versão do PCT oferece recursos apenas para
desenvolvimento de sistemas ponto a ponto. Há a
possibilidade de serem efetuadas modificações no
protocolo PCT para que ele possa ser utilizado em
aplicações multiponto.
Embora a versão atual do PCT não esteja
encapsulada em uma biblioteca, como uma dll, isso
poderá ser feito para que ela possa ser integrada em
qualquer sistema independente da linguagem de
desenvolvimento.
Pode-se considerar como alternativa para esta
biblioteca o desenvolvimento de uma nova versão para
ambientes Unix. Deste modo, dois grandes ambientes,
Microsoft Windows® e Unix®, poderão contar com
uma biblioteca de teleconferência para auxiliar no
desenvolvimento de aplicações médicas.
Referências Bibliográficas
[1] Microsoft Netmeeting; Kit de Desenvolvimento de
Software; Disponível em
<http://support.microsoft.com/default.aspx?scid=fh
;PT-BR;nmtINT>, acessado em 10 de julho de 04.
[2] Mendes, John A. F.; Wangenheim, Aldo von; Sala
de Laudos Virtual – Uma Proposta para
Teleradiologia, [artigo] publicado no III SCPDI –
Simpósio Catarinense de Processamento Digital de
Imagens realizado em Florianópolis, SC em 2003;
[3] Tanembaum, Andrew S. Sistemas Operacionais –
Projeto e Implementação 2ª ed., editora Bookman,
São Paulo, 1999.
[4] Taylor, Don. Et al. Programando Delphi 3 –
Técnicas Avançadas, editora Makron Books, São
Paulo, 1999;
[5] Mendes, John A. F.; Wangenheim, Aldo von. Sala
de Laudos Virtual – Uma Proposta para
Teleradiologia. [artigo], SCPDI – Simpósio
Catarinense de Processamento Digital de Imagens,
2002.
[6] REMKO. Biblioteca de VoIP.
<http://www.prinsengracht.org/remko-ananda/>,
consulta em janeiro de 2003.
[7] Arnett, Matthew F. et al. Desenvolvendo o TCP/IP
– Métodos de instalação, manutenção e
implementação de redes TCP/IP, editora Campus,
Rio de Janeiro, 1997.