FISL7 - Padrões Abertos e Software Livre para Vídeoconferência

  • 1,838 views
Uploaded on

Palestra no FISL7 - Padrões Abertos e Software Livre para Vídeoconferência - Prof. Mauro Tapajós Santos

Palestra no FISL7 - Padrões Abertos e Software Livre para Vídeoconferência - Prof. Mauro Tapajós Santos

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,838
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
35
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Padrões Abertos e Software Livre para o Serviço de Vídeoconferência FISL 7 - 19/04/2006 Prof. Msc Mauro Tapajós
  • 2. Objetivo
    • Quais são os padrões abertos atuais usados no serviço de vídeoconferência sobre redes de dados e o estado atual de pesquisa nestes padrões? Esta palestra irá apresentar alguns dos SL já existentes para se implementar este tipo de serviço e alguns cenários já possíveis, encontrados na pesquisa na UCB.
  • 3. Mini-Currículo
    • Professor da Universidade Católica de Brasília (UCB)
    • 4. Coordernador Técnico do Projeto CESMIC
    • 5. Aluno de pós-graduação en "Dirección de Sistemas de Información en Entornos de Software Libre" na Universidad Obierta de Catalunya (Barcelona)
    • 6. Mestre em Telecomunicações e Redes pela UnB
    • 7. Engenheiro Eletricista pela UnB
    • 8. Trabalho com SL dede 1996 (várias empresas)
  • 9. Serviço de Vídeoconferência
    • Comunicação humana
    • 10. Sessão de comunicação em tempo real por vídeo e áudio entre dois ou mais pontos
    • 11. Existem muitas situações onde cabe o serviço: reuniões, cursos, conferências, telemedicina, educação à distância-debates-palestras, etc
    • 12. Dispersão geográfica
    • 13. Necessita certa qualidade do serviço de rede
  • 14. Objetivos Comuns
    • Ampliar o alcance de comunicação entre profissionais
    • 15. Reduzir o gasto utilizados no deslocamento físico
    • 16. Facilitar decisões que dependam de dois ou mais responsáveis
    • 17. Realizar treinamento simultâneo entre grupos que estejam em locais distintos
  • 18. Origem do Serviço
    • Interesse surge com o nascimento da TV
    • 19. Primeiras VCFs baseadas na tecnologia de TV – ligação de sistemas de TV com cabos
    • 20. NASA – links VHF/UHV com astronautas em órbita
    • 21. Links satelitais – usados pelas emissoras de TV
    • 22. A tecnologia dos PCs e evolução de CODECs e protocolos viabilizou o uso de VCF pelo público em geral
  • 23. Histórico
    • 1964 – AT&T apresenta o Picture Phone ( Freeze frame e Slow motion)
    • 24. 1973 – Pacotes de voz pela ARPANET
    • 25. 1976 – NVP Network Voice Protocol
    • 26. 1981 – PVP (vídeo sobre pacotes)
    • 27. 1982 – CCITT - CODEC de vídeo H.120 (2 Mbps)
    • 28. 1990 – CCITT - CODEC de vídeo H.261
    • 29. 1990 – CCITT – Padrão H.320 para VCF sobre ISDN
    • 30. 1992 – RTP
    • 31. 1996 – IETF – RTPv2
    • 32. 1996 – ITU-T CODEC H.263 (baixas velocidades)
    • 33. 1996 – H.324 VCF sobre POTS
    • 34. 1996 – H.323 v1 VCF sobre pacotes
    • 35. 1998 – H.323 v2
    • 36. 1999 – H.323 v3
    • 37. 2000 – H.323 v4
    • 38. 2003 - CODEC H.264
  • 39. Norma H.200 do ITU-T
    • Framework for Recommendations for audiovisual services
    • 40. Áudio conferência (somente áudio)
    • 41. Teleseminário (áudio e vídeo unidirecionais de uma origem com retorno em áudio)
    • Conferência Audiográfica (áudio, documentos e imagens)
    • 42. Conferência Audiodocumentacional (similar à audioconferência com transmissão de texto)
    • 43. Freeze Frame Videoconferência (similar á conf. audiográfica com envio de snapshots dos participantes)
    • 44. Videoconferência (similar à conf. audiográfica com vídeo)
  • 45. Facilidades do Serviço
    • Quadro Branco
    • 46. Troca de arquivos/msgs
    • 47. Câmera secundária
    • 48. Controle remoto da câmera
    • 49. Modos multiponto:
      • Tela cheia ( full screen )
      • 50. Continuos presence – impacto na banda necessária
  • 51. Tipos de VCF
    • Quanto à plataforma:
      • Appliance Systems
      • 52. Baseada em PC ( Desktop )
    • Quanto ao porte:
      • Sistemas de sala
      • 53. Set Top
      • 54. Desktops (CODECs implementados em software)
  • 55. Salas de Vídeoconferência
    • Dimensionamento
    • 56. Localização Geográfica
    • 57. Iluminação
    • 58. Acústica
    • Decoração
    • 59. Layout
    • 60. Mobiliário
    • 61. Rack/Suporte
    • 62. Infra-estrutura (cabeamento de rede, aterramento)
  • 63. Preocupações Não-Técnicas
    • Conjunto de procedimentos necessários para facilitar a realização de reuniões, tais como:
    • Agendamento de conferência
    • 64. Divulgação dos participantes
    • 65. Etiqueta
    • 66. Configuração do sistema para que a sessão possa ser realizada
    • 67. Permitir, durante o serviço, facilidades para que os participantes possam trocar informações (apresentações, documentos, transferência de arquivos, etc.)
  • 68. Cenários para VCF
  • 74.
    • Melhor exemplo – protocolos Internet:
      • Protocolos de rede: TCP/IP (aberto) X protocolos proprietários (Novell, Win, etc)
      • 75. Serviço de Mail: RFC 822 (aberto) X X.400 (CCITT)
      • 76. Protocolo de gerenciamento: SNMP (aberto) X CMIP (OSI)
    • Já existem vários padrões abertos para VCF (principalmente do ITU-T, ISO e IETF)
    Padrões Abertos
  • 77.
    • G.711 (A e micro) – 64 kbps
    • 78. G.722 – SB-ADPCM - 48 a 64 kbps
    • 79. G.722.1 – MLT – 24 a 32 kbps
    • 80. G.722.2 – ACELP – 6,60 a 23,85 kbps
    • 81. G.726 – ADPCM – 16 a 40 kbps (32 kbps)
    • 82. G.727 – mesmo que G.726 com otimizações para PCME
    • 83. G.728 – LD-CELP 16 kbps
    • 84. G.729 – CS-ACELP 6,4 a 11,8 kbps (8 kbps) – Patentes!
    • 85. GSM – 13 kbps
    • 86. iLBC (RFC 3951) – de 13,3 a 15,2 kbps) – licença gratuita!
    • 87. Speex – voz em baixas taxas (2 a 22,4 kbps)
    • 88. MP3 não é um CODEC de telefonia! – apenas é usado para música em espera
    CODEC's de Voz para VCF
  • 89.
    • H.261 – 40 kbps a 2 Mpbs – chega a 288x352 – projetado para as linhas ISDN nx64 kbps (hoje considerado obsoleto)
    • 90. H.262/MPEG2 Part-2
    • 91. H.263 projetado para baixas taxas - já é considerado obsoleto diante de H.264
    • 92. H.264/MPEG4 Part 10/AVC (Advanced Video Coding) -
    • 93. Theora – livre
    CODEC's de Vídeo para VCF
  • 94.
    • Grupo de trabalho ISO
    • 95. MPEG-1 - áudio/vídeo
      • MP3 (layer III) e VCD
      • 96. 352x240 (NTSC 30 fps) e 352x288 (PAL 25 fps) 320x240 (PC)
      • 97. 1,2 a 1,5 Mbps - Qualidade: VHS a 30 fps
    • MPEG-2 – áudio/vídeo de alta qualidade
      • DVD
      • 98. Velocidades de 2 Mbps até 15 Mbps são suportadas
      • 99. 720X480 (4:3) até 1920x1080 (16:9 HDTV)
    Padrões MPEG ( Moving Picture Experts Group )
  • 100.
    • MPEG-4 – áudio/vídeo para redes de banda limitada
      • Velocidades de 56 kbps até 2 Mbps
      • 101. AAC (Apple iTunes, por exemplo)
      • 102. Container de vários tipos de objetos de mídia sicronizados
      • 103. Suporte a DRM!
    • MPEG-7 - Multimedia Content Description Interface
      • Metadados
    • MPEG-21 - Multimedia Framework
      • DRM
    Padrões MPEG ( Moving Picture Experts Group )
  • 104.
    • Multimídia sobre:
      • H.320 – ISDN
      • 105. H.321, H.310 – Broadband ISDN
      • 106. H.322 – comutação de pacotes, com QoS, Ethernet isócrona
      • 107. H.323 - comutação de pacotes, sem QoS, principalmente sobre IP
      • 108. H.324 - redes de circuitos comutados PSTN
    Padrões ITU-T H.xxx para VCF
  • 109. Multimídia sobre Redes de Pacotes
    • Informações como voz e vídeo geram grandes quantidades de dados e são muito associadas à temporização da rede, daí surge a necessidade de haver algum tipo de controle sobre atrasos e velocidade
    • 110. CODECs sofisticados exigem processamento e imbutem atrasos no fluxo de dados
    • 111. “ IP is everywhere” - Universalização da plataforma
  • 112. TCP/UDP como Protocolo de Transporte Multimídia
    • TCP
      • Protocolo ponto-a-ponto com conexão ( multicast!)
      • 113. Atrasos intoleráveis na maior parte das aplicações de tempo-real
      • 114. Não possui um mecanismo para anexar informação de tempo nos segmentos
    • UDP
      • Também não define os mecanismos de temporização citados acima
    • Apesar de certas funcionalidades poderem ser incluídas a nível de aplicação, existe um conjunto de funções que merecem ser implementadas num protocolo específico para tráfego de tempo-real
  • 115. RTP - Real Time Protocol RFC 3550
    • É o protocolo adequado para transmitir multimídia digitalizada sobre uma rede IP
    • 116. Tem funções de protocolo de transporte mas roda sobre UDP e pode trabalhar com multicasting
    • 117. RTP não garante a entrega sincronizada dos pacotes, apenas provê informações que ajudam na reprodução do fluxo na recepção
    • 118. Oferece suporte a:
      • Mixagens ( mixing ): combinação de múltiplos fluxos num único (necessidade de um ponto com funções de mixer )
      • 119. Tradutores (translators)
  • 120. Mixer RTP
    • Faz o relay de tráfego (fluxos) recebidos de um ou mais originadores, combina os fluxos recebidos e encaminha para um ou mais destinos
    • 121. Por exemplo: combinação de tráfegos de voz numa conferência para transmissão por link de menor velocidade
  • 122. Tradutores (Translators) RTP
    • Faz o relay de tráfego (fluxos) RTP recebidos para um ou mais destinos, após haver ou não transformado os dados do fluxo
    • 123. Por exemplo: transformação de fluxo de vídeo de alta resolução num fluxo de baixa resolução, travessias através de firewalls ou encaminhamento unicast de tráfego multicast
  • 124. RTP ( Real Time Protocol )
    • Integração direta com a aplicação – aceite por parte desta da entrega de segmentos com perdas
    • 125. A própria aplicação pode reenviar dados ao ser sinalizada dos termos de QoS
    • 126. A aplicação, então, define seus PDU’s (APU’s – Application Data Units )
    • 127. Do mesmo modo RTP complementa UDP agregando funções (como sequenciamento) e trabalha num modo integrado entre camadas de protocolos
  • 128. Cabeçalho RTP
    • Versão : 2 (atual)
    • 129. P : padding. Usado quando a aplicação o requer
    • 130. X : sinaliza o uso de cabeçalho de extensão
    • 131. CC : número de geradores de fluxo
    • 132. M : marker. Sua interpretação depende do tipo de payload . Normalmente sinaliza limites de um fluxo de dados, como o fim de um frame de vídeo.
    • 133. Sequence num : números de sequência. Primeiro é randômico
    • 134. Media timestamp : deve ser contínuo mas com granularidade adequada ao payload
    • 135. Ptype: .codificação/tipo dos dados
    • 136. Synchronization source identifier : origem do fluxo
    • 137. Contributing source ID : cada campo deste tipo (podem ser vários) identifica cada um dos geradores de fluxo. Gerado por um mixer RTP.
  • 138. Alguns Tipos de Payload RTP
  • 139. Pilha RTP
  • 140.
    • Vários pacotes podem ter o mesmo timestamp caso os dados tenham sido gerados ao mesmo tempo (ex. Um frame de vídeo que ocupa vários pacotes)
    • 141. Mídias diferentes devem ir por fluxos diferentes (por exemplo: o vídeo e seu áudio)
    RTP ( Real Time Protocol )
  • 142. RTP ( Real Time Protocol )
    • Um número de sequência garante a ordem dos pacotes, a eliminação de duplicatas e a detecção de perdas
    • 143. O timestamp permite a reprodução dos pacotes do fluxo no tempo correto em que o dado foi gerado
  • 144.
    • É parte obrigatória do RTP e utiliza uma porta imediatamente superior à porta UDP sendo usada pelo RTP
    RTCP ( Real Time Control Protocol )
  • 145. RTCP
    • Oferece informações de controle para fontes de tráfego RTP:
      • Monitoramento da rede durante a sessão (aspectos de QoS e congestionamento)
      • 146. Sinalização de controle fora-de-banda
      • 147. Identificação adequada de fontes de fluxo
    • Mensagens RTCP são periodicamente enviadas pelos participantes
    • Existem vários tipos de mensagens para implementar as funcionalidades acima
  • 148. Padrão H.323
    • H.323 é um padrão ITU-T e define um conjunto de protocolos para transmissão de tráfego multimídia sobre redes de pacotes e que podem trabalhar em conjunto oferecendo os serviços básicos para compor um sistema de telefonia IP funcional
    • 149. O conjunto provê suporte à todos os aspectos de uma chamada como:
      • Registro de um terminal
      • 150. Sinalização de controle de chamadas e serviços
      • 151. Codificação dos dados em tempo real
      • 152. Transmissão dos dados codificados
  • 153. Padrão H.323
    • Oferece ainda suporte para aplicações de vídeo, compartilhamento de dados durante as sessões e as codificações/decodificações necessárias
    • 154. Define como é a negociação de chamadas e os formatos das informações necessárias
    • 155. Não define:
      • Codificação de endereços
      • 156. Priorização de tráfego
      • 157. Segurança
  • 158. H.323
    • Entidades previstas
    • Protocolos
      • H.225.0 – RAS ( registration, admission, status ) e sinalização de chamada ( call signalling )
      • 162. Q.931 – Configuração de chamadas e terminação
      • 163. H.245 – Controle de mídia / Sinalização de capacidades
      • 164. T.120 – Compartilhamento de dados
      • 165. RTP/RTCP – Transporte de mídia
  • 166. Componentes de uma rede H.323
    • MCU ( Multipoint Control Unit ): suporta os servições de múltiplos usuários como conferências (endereçamentos unicast e multicast)
    Gateways : permitem a interconexão de terminais H.323 com outros dispositivos de áudio e traduzem a sinalização de um lado para o outro Gatekeepers executam as funções de servidor de diretórios (conversão de endereços) e supervidor do sistema (controle e gerenciamento das chamadas)
  • 167. Gatekeeper
    • Funções:
      • Tradução de endereços
      • 168. Controle de admissão
      • 169. Controle de banda
      • 170. Gerenciamento de zonas
      • 171. Sinalização de controle de chamadas
      • 172. Controle de chamadas
    • Descoberta do gatekeeper - a través de mensagens multicast (224.0.1.41 - UDP 1718)
    • 173. Porta para registros e status: UDP/1719
    • 174. Podem auxiliar a montagem de conferências multiponto com H.245 repassando as conexões com todos os participantes e depois passando o canal H.245 para uma MCU
  • 175.
    • Chamada ponto a ponto ≠ multiponto
    • 176. Responsável por prover recursos para três ou mais entidades
    • 177. Formado por duas entidades:
      • MC - Multipoint Controller - Obrigatório - prover controle para realização da conferência
      • 178. MP - Multipoint Processor - Opcional - Distribui fluxos de vídeo e áudio para entidades
    MCU – Multipoint Control Unit
  • 179. Pilha de Protocolos H.323
    • Codecs de áudio e vídeo comprimem e descomprimem fluxos multimídia
    • 180. Fluxos multimídia são transportados por RTP/RTCP, rodando sobre UDP
    • 181. A sinalizaçao é transportada confiávelmente sobre TCP
      • RAS - registration, admission, status
      • 182. Q.931 – Configuração de chamadas e terminação
      • 183. H.245 – Sinalização de capacidades
  • 184. Telefonia IP – Protocolos H.323
  • 185. Estabelecimento e Configuração de de Chamadas
    • Através de mensagens H.225 e Q.931/2 se estabelece a chamada, através de conexão na porta TCP/1720 ( call control )
    • 186. H.225 també é usado para RAS ( registration, admission, status ) - comunicação com o gatekeeper
    • 187. H.245 permite a o posterior acerto de canais lógicos, codecs e capacidades através da porta TCP indicada em mensagens de estabelecimento da chamada
    • 188. H.245 é usado depois do estabelecimento da chamada
    • 189. Existe uma facilidade de fast start para reduzir os passos na criação da chamada
  • 190. Exemplo de Chamada H.323
  • 191. SIP – Session Initiation Protocol – RFC 3261
    • Padrão IETF para um protocolo de aplicação (sinalização) que cobre somente a sinalização necessária para se iniciar, modificar, convidar outros (para participar) e terminar chamadas (sessões)
    • 192. Não oferece toda a funcionalidade do H.323 – pretende ser parte da arquitetura IETF de suporte a aplicações multimídia
    • 193. Baseado nos princípios aprendidos da comunidade Internet – independente de aplicação
  • 194. SIP
    • Herdou muito do protocolo HTTP (como o modo textual ou códigos de erro, por exemplo)
    • 195. + SIMPLES! Implementações mais baratas
    • 196. UTF-8
    • 197. DEVE suportar TCP e UDP (porta 5060)
    • 198. PODE suportar outros transportes (como SCTP)
    • 199. Expansível
    • 200. Pode permitir serviços comuns das redes telefônicas ( follow-me , rede inteligente, etc)
  • 201. SIP
    • Call setup
    • 202. Negociação de funcionalidades e mídia
    • 203. Gerenciamento de chamada e mudanças “on the fly”
    • 204. Mapeamento de nomes
    • 205. Localização de usuários
    • 206. Redirecionamento de chamadas
  • 207. Componentes de uma rede SIP
    • User agents Client – UAC – porção cliente localizada no terminal SIP
    • 208. User Agent Server – UAS : encaminha um pedido de chamada e trata as respostas para o terminal chamador
      • Proxy Server – age como cliente/servidor tratando os pedidos e até reescrevendo as mensagens para o devido encaminhamento
      • 209. Redirect server – redireciona chamadas (tratando adequadamente parâmetros como endereços). Não aceita nem inicia chamadas. Devolve as informações.
      • 210. Registrar – servidor que permite que terminais SIP registrem sua presença
      • 211. Location server – encontra destinos
  • 212. Arquitetura SIP
  • 213. Métodos SIP
    • Outros métodos foram definidos por outras RFC's
  • 214. Pilha de Protocolos SIP
  • 215. Chamadas SIP
    • Terminal chamador localiza servidor
    • 216. Envio de request SIP via servidor
    • 217. Terminal chamado responde
    • 218. Resposta chega ao chamador
    • 219. Chamador envia ACK
    • Endereços SIP: [email_address]
    • 220. Nomes de servidores sugerido: sip.domínio (como é feito para os demais protocolos Internet. Ex. ftp.domínio )
  • 221. Exemplo de Chamada SIP
  • 222. SDP – Session Description Protocol – RFC 3264
    • Originalmente desenvolvido para descrever sessões multicast no MBone
    • 223. Descreve informações de sessões multimídia:
      • Codificação da mídia
      • 224. Números de porta
      • 225. Endereços multicast
    • Não negocia parâmetros de mídias
    • 226. Pode convidar pessoas ou até robôs (como um media storage server ) para uma conferência
    • 227. Suas mensagens trafegam encapsuladas em mensagens SIP
  • 228. Alguns Protocolos Relacionados
    • RFC 3489 - STUN Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
    • 229. RFC 2974 – SAP Session Announcement Protocol (anúncio de conferências e sessões multicast -ainda experimental)
    • 230. H.350/RFC 3944 - Directory Services Architectures in Support of Multimedia Conferencing - Armazenamento de informações de conferências multimídia em serviços de diretório LDAP
  • 231.
    • SIPPING – aplicação de SIP em vários contextos de telefonia e multimídia
    • 232. XCON – Protocolos para conferências centralizadas (preocupação com itens como autenticação, privacidade, permissão e combinação numa sessão)
    • 233. SIMPLE – SIP em aplicações IMP ( messaging e presence )
    • 234. AVT – Transporte de Áudio e Vídeo
    • 235. MMUSIC - Multiparty Multimedia Session Control – trata SDP e demais protocolos
    Grupos de Trabalho IETF Relacionados
  • 236.
    • Alternativa criada pela comunidade Asterisk à SIP e H.323, mas não é um padrão reconhecido oficialmente
    • 237. Codificação binária
    • 238. Sinalização e mídia usam as mesmas portas (udp/4569) – fácil uso com NAT
    • 239. Interrompe a chamada no caso de ausência da outra parte
    • 240. O Asterisk suporta vídeo H.261 e H.263 através de canais IAX2 e SIP
    IAX – Inter Asterisk eXchange Protocol
  • 241.
    • Vídeos grandes via WEB
    • 242. Aplicações interativas
    • 243. Distribuições de vídeo em larga escala ( webcasts )
    • 244. Melhor controle do que é visto e por quem
    • 245. Pode ser usado para replicar sessões de VCF em tempo real para outros usuário
    Streaming
  • 246.
    • Protocolo de apresentação
    • 247. Controla a entrega sob demanda de dados real-time de áudio e vídeo – mas não carrega tráfego de A/V!
    • 248. Fontes destes dados podem ser registros ao vivo ou armazenados em mídias
    • 249. Suporta entregas em múltiplas sessões, permite a escolha de canais de entrega como UDP, multicast UDP, TCP e mecanismos baseados no RTP
    • 250. Adequado para distribuição de vídeo para a Internet e vídeo sob demanda
    RTSP – Real Time Streaming Protocol – RFC 2326
  • 251.
    • Chamadas / Sessões
      • Antes: somente voz
      • 252. Hoje: Voz + Vídeo + Messaging + ...
    • VCF é mais um tipo de sessão como jogos em rede, messaging ou VoIP
    • 253. Herda o “modelo telefone”
    VCF em Redes de Pacotes
  • 254.
    • Assunto complicado
    • 255. Servidores que oferecem o serviço de VCF sofrerão assim como os demais
    • 256. Registro/autenticação – contabilização
    • 257. Privacidade nas conversações
    • 258. Ainda não existe infraestrutura de administração para VCF
    Segurança em VCF sobre Redes de Pacotes
  • 259.
    • Protocolos de Sinalização – como H.323, SIP e IAX
    • 260. Transporte de Mídia – normalmente RTP
    • 261. Protocolos de Suporte (redirecionamentos/localização, QoS, etc) - DNS, SDP, LDAP, TRIP, RSVP, COPS, MEGACO, Diameter/Radius, etc
    Protocolos para VCF em Redes de Pacotes
  • 262.
    • Normalmente o estabelecimento da chamada e sua sinalização em geral é independente do fluxo de mídia que será gerado por ela
    • 263. A portas usadas pelos vários protocolos são distintas, de forma que seja difícil a associação de uma chamada com o fluxo de mídia
    • 264. Não há solução direta e simples
    • 265. Para Linux: existe um patch SIP/RTP para o netfilter
    O problema com NAT
  • 266.
    • www.asterisk.org
    • www.gnugk.org
    • www.ekiga.org
    • 267. www.gnomemeeting.org
    • www.voxgratia.org
    • 268. www.openh323.org (antigo)
    Alguns Softwares Livres para VCF
    • yate.null.ro
  • 269.
    • VRVS ( Virtual Room Videoconferencing System) - www.vrvs.org
    • 270. AccessGrid - www.accessgrid.org
    • 271. OpenWengo - www.openwengo.com
    • 272. Skype - www.skype.org
    • 273. CuSeeMe - www.cuworld.com
    Alguns Serviços VCF na Internet
  • 274.
    • Sistema de VCF de baixo custo disponível via Internet criado pela CalTech e CERN
    • 275. Limita banda nas VCF – 256 kbps
    • 276. Usa ferramentas do Mbone (vic, rat, etc)
    VRVS – Virtual Room Videoconferencing System
    • Suporte clientes H.323, quickplayer e VNC
    • 277. Refletor: servidor que serve de ponte do usuário com uma sala virtual
  • 278.
    • Serve como instrumento de divulgação e capacitação – inclusão social, redução do analfabetismo, formação profissional
    • 279. Exige capacidade para ter qualidade - custo!
    • 280. VCF já pode ser implementada mas com limitações sobre plataformas totalmente livres
    • 281. Atenção aos CODECs a serem usados! Patentes!
    • 282. FILME - http://uwtvproduction.org/convergence.html
    Observações Finais
  • 283. Questões?
  • 284. Site do Projeto CESMIC: www.cesmic.ucb.br Site Professor: www.ucb.br/prg/professores/maurot Stand FISL M06